# ticketchng

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

  Applied changes to head which cause mime and smtp to adapt
  at runtime to whatever version of md5 is loaded.


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

  Fixed and committed to head (ftpd.tcl CVS version 1.24). 
  This will be in the next release of tcllib.

  You may want to check out the current version and verify the
  fix.


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

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


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

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

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

  instead of

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


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


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

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


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

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


login: robert_hicks
username: robert_hicks
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1528214

  I would like this added as well plus a way to add a
  javascript script. I have coded the following and tested
  using TclHttpd server.

  # ::html::css
  #Create the text/css tag and tuck it away for usage
  #
  # Arguments:
  #hrefThe location of the css file to include the filename
  and path
  #
  # Results:
  #HTML for the  section

  proc ::html::css {href} {
      variable page
      ::set html ""
      append html "<link rel=\"stylesheet\" type=\"text/css\"
  href=\"[quoteFormValue $href]\">\n"
      lappend page(css) $html
      return ""
  }

  # ::html::js
  #   Create the text/javascript tag and tuck it away for usage
  #
  # Arguments:
  #hrefThe location of the javascript file to include the
  filename and path
  #
  # Results:
  #HTML for the  section

  proc ::html::js {href} {
      variable page
      ::set html ""
      append html "<script language=\"javascript\"
  type=\"text/javascript\" src=\"[quoteFormValue
  $href]\"></script>\n"
      lappend page(js) $html
      return ""
  }

  I then changed the ::html::head section to include these
  like meta tags:

  # ::html::head
  #
  #Generate the <head> section.  There are a number of
  #optional calls you make *before* this to inject
  #meta tags - see everything between here and the bodyTag proc.
  #
  # Arguments:
  #titleThe page title
  #
  # Results:
  #HTML for the <head> section

  proc ::html::head {title} {
      variable page
      ::set html "[openTag html][openTag head]\n"
      append html "\t[title $title]"
      ::if {[info exists page(author)]} {
  append html "\t$page(author)"
      }
      ::if {[info exists page(meta)]} {
  ::foreach line $page(meta) {
      append html "\t$line\n"
  }
      }
      ::if {[info exists page(css)]} {
      ::foreach style $page(css) {
          append html "\t$style\n"
      }
      }
      ::if {[info exists page(js)]} {
      ::foreach script $page(js) {
          append html "\t$script\n"
      }
      }
      append html "[closeTag]\n"
  }


login: sigzero
username: sigzero
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1339209

  Addendum: For the html::js (and I am not sure how) it needs to know whether it 
  is in the <head> section or the <body> section I am thinking. You don't embed 
  a .css file in the body of the html but you *can* with .js files.


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

  Committed the implementations, after reworking them to be a
  bit simpler. I am bailing out on the javascript-in-body issue.


login: nobody@129.247.247.239
username: nobody@129.247.247.239
mimetype: text/plain
icomment:
  BWidget 1.8 / T cl 8.5.2 / Windows-XP

  Perhaps the following observation is related to this case:
  Changing the foreground color with [option add ...] does not affect SpinBox Arrow buttons.
  The arrow buttons are displayed black-on-black while the show read-on-blach, when the mouse cursor moves over.
  I'm using the following color settings:
      #
      # Night-Mode colors
      #
      option add *backgroundblackwidgetDefault
      option add *foregroundred4widgetDefault
      option add *insertBackgroundred4widgetDefault

      option add *disabledBackgroundblackwidgetDefault
      option add *disabledForegroundred4widgetDefault

      option add *highlightBackgroundblackwidgetDefault
      option add *highlightColorblackwidgetDefault

      option add *selectColorblackwidgetDefault
      option add *selectBackgroundblackwidgetDefault
      option add *selectForegroundred3widgetDefault

      option add *activeBackgroundblackwidgetDefault
      option add *activeForegroundred3widgetDefault


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Okay, I withdraw my previous comment.
  using the default "interactive" priority solves the problem.

  option add *foreground red4 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  That is true by design. The default value is hard coded to 15x15.

  Is there any need to transfer it to a BWResource ?

  The option declaration is as follows:
      Widget::declare ArrowButton [list \
      [list -typeEnum button 0 [list arrow button]] \
      [list -dirEnum top    0 [list top bottom left right]] \
      [list -widthInt150"%d >= 0"] \
      [list -heightInt150"%d >= 0"] \
      [list -ipadxInt00"%d >= 0"] \
      [list -ipadyInt00"%d >= 0"] \
      [list -cleanInt20"%d >= 0 && %d <= 2"] \
      [list -activeforegroundTkResource""0 button] \
      [list -activebackgroundTkResource""0 button] \
      [list -disabledforeground TkResource""0 button] \
      [list -foregroundTkResource""0 button] \
      [list -backgroundTkResource""0 button] \
      [list -stateTkResource""0 button] \
      [list -troughcolorTkResource""0 scrollbar] \
      [list -arrowbdInt10"%d >= 0 && %d <= 2"] \
      [list -arrowreliefEnumraised0[list raised sunken]] \
      [list -commandString""0] \
      [list -armcommandString""0] \
      [list -disarmcommandString""0] \
      [list -repeatdelayInt00"%d >= 0"] \
      [list -repeatintervalInt00"%d >= 0"] \
      [list -fgSynonym-foreground] \
      [list -bgSynonym-background] \
      ]


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

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


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

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


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

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


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


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

  I've hardcoded a fix for my usage.

  In proc ::smtp::initialize_ehlo, after the TLS code, I added:

     if [catch {smtp::talk $token 300 "AUTH PLAIN"} result]  {
         array set response [list code 400 diagnostic $result args ""]
     } else {
         array set response $result
     }    
     if {$response(code) != 334}  {
         puts stderr "Bad response to AUTH PLAIN = '$response(diagnostic)'."
         catch {close $state(sd)}
         return {} 
     }    

     if [catch {smtp::talk $token 300 "A------------
  redacted----------------------hZGE="} result]  {
         array set response [list code 400 diagnostic $result args ""]
     } else {
         array set response $result
     }    
     if {$response(code) != 235}  {
         puts stderr "Bad response to the base64 password = 
  '$response(diagnostic)'."
         catch {close $state(sd)}
         return {}
     }    

  It took a bit of Googling to find out the format, the RFC didn't state it.

  FYI, you'd better give the user a choice of AUTH methods, because
  I first coded this for AUTH LOGIN and it seemed to work - gave a
  success for authorization - but it would fail to work if I was sending
  to a different domain (and it was a forward, not a POP box) that
  was handled by the same POP server. I don't know if this was a
  qmail quirk or not. Switching to AUTH PLAIN worked. If the (eventually)
  fixed smtp.tcl doesn't give a choice and it chooses the first one listed
  by the EHLO output, it would fail for local aliases at my provider.

  I'm suggesting to my provider to drop AUTH LOGIN from the EHLO output.


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

  Update: regarding giving a choice of AUTH methods, it turns out
  that was a problem on my end, nevermind. It may or may not be
  a useful thing to be able to specify.


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

  The current CVS version of the smtp package has AUTH support
  for DIGEST-MD5, CRAM-MD5, LOGIN and PLAIN. It also supports
  the use of the STARTTLS extension to enable a secure link if
  you have the tls package available. This has been tested
  against sendmail, postfix and Microsoft's SMTP server.


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

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

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

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

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


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

  Not my department.  Damon?

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


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

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

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


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

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


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

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


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

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

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

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

  Time to file a bug for Tk I think.


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

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


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

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


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

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

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

      mime::finalize $tok
   }

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

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


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

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

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


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

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

      ./sak.tcl nroff calendar FOO

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


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

  The commands were modeled after the core builtins [file
  split] / [file join], which exhibit the same sort of asymmetry.


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

  Duplicate of [Tcllib SF Bug 948273].

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

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


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

  which version of Tcl and what platform? I am using ASTcl
  8.4.7 on windows, and it works. I think the ability to do a
  package require struct::record was just added, so you might
  have an old tcllib (even if it does say 1.6)


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

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


login: 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: aku
mimetype: text/plain
icomment:
  Thinking about things a bit more I may make this a doc change, a section talking about protocols and how it is the responsibility of the application to select what should be used, instead of the package using TLS (package).


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Accepted, with some rewriting.
  Put the text block into a new location for reusable text blocks.
  Updated not only oauth, but all packages in Tcllib using TLS (even if optional).

  Commit [a5887963b0].
  Pushed.
  Done.

  Thank you.


login: aku
mimetype: text/html
icomment:
  <p>I wrote a paper on these things in 2009, available at
  <a href="http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2009/proceedings/TclChannels/rtc.pdf">
  Reflecting and Transforming Channels
  </a>

  <p>Does that help ?

  <p> The referenced examples of that paper became the virtchannel_* modules in Tcllib, i.e. core, base channels, and transforms.
  <p> The exception is the code of the file transfer example in section 5.3.
  That I should dig out and add to Tcllib as well.


login: anonymous
username: gahr@gahr.ch
mimetype: text/plain
icomment:
  I just realized that 8.4 doesn't have the "u" flag char. If compatibility with 8.4 is to be kept, please disregard this ticket.


login: aku
mimetype: text/plain
icomment:
  Actually, given that "aes" is currently assuming Tcl 8.2 it is overdue to be moved to a modern revision of the core.

  I will apply this patch, bump the package to version 1.2 and declare that to require Tcl 8.5.

  At that point please feel free to add more 8.5-isms, if sensible ({*}, lassign, in/ni operators, whatever).


login: aku
mimetype: text/x-fossil-wiki
icomment:
  The aes-modernize patch uses 'lmap'.
  That is a Tcl 8.6 command, and not available for 8.5.
  Six places.

  But we have lassign and can unroll the loops (4 iterations is small enough). Note, this makes use of our knowledge about the size of the list, i.e. that it always has 4 elements.

  And that fixes the test breakage I saw.
  Can't say if that gives us perf gains or not.

  Did you use the aes.bench to benchmark things ?

  For the moment I put the patch + mods on branch "aes-modernize" so that I can benchmark it versus the original using aes.bench.

  Commit [5903319520]
  Pushed.


login: aku
mimetype: text/plain
icomment:
  Config for both variants:
  - Tclsh 8.5.7
  - Repeat 10 (= run 11 times (1+ 10 repeats))
  - Collate min (take best time over all runs)

  Gains about 1-3% it looks like.
  Col 1 = aes/trunk
  Col 2 = aes/modernize
  Normalized to column 1.
  To check against 8.5.16 and 8.6

  +----+-----------------------------+------+------+
  |    | INTERP                      |    1 |    2 |
  +----+-----------------------------+------+------+
  |  1 | AES-128 CBC keyschedule     | 1.00 | 1.00 |
  |  2 | AES-128 ECB decryption      | 1.00 | 1.01 |
  |  3 | AES-128 ECB decryption core | 1.00 | 1.00 |
  |  4 | AES-128 ECB encryption      | 1.00 | 0.99 |
  |  5 | AES-128 ECB encryption core | 1.00 | 0.97 |
  |  6 | AES-128 ECB keyschedule     | 1.00 | 1.00 |
  |  7 | AES-192 CBC keyschedule     | 1.00 | 1.01 |
  |  8 | AES-192 ECB decryption      | 1.00 | 1.01 |
  |  9 | AES-192 ECB decryption core | 1.00 | 1.00 |
  | 10 | AES-192 ECB encryption      | 1.00 | 0.98 |
  | 11 | AES-192 ECB encryption core | 1.00 | 0.98 |
  | 12 | AES-192 ECB keyschedule     | 1.00 | 1.00 |
  | 13 | AES-256 CBC keyschedule     | 1.00 | 1.00 |
  | 14 | AES-256 ECB decryption      | 1.00 | 1.00 |
  | 15 | AES-256 ECB decryption core | 1.00 | 1.01 |
  | 16 | AES-256 ECB encryption      | 1.00 | 0.99 |
  | 17 | AES-256 ECB encryption core | 1.00 | 0.98 |
  | 18 | AES-256 ECB keyschedule     | 1.00 | 0.99 |
  +----+-----------------------------+------+------+


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: aku
mimetype: text/x-fossil-wiki
icomment:
  Thank you.
  I will try to review ASAP (after I manage to fix up TLS for the POODLE [1]).

  In the mean-time, may I impose on you and ask you to start on a proper testsuite for the packages too ? Note that I would prefer this (testsuite) done on the trunk of Tcllib. That way I can test the current implementation and then later yours, after the merge, or before, from your branch, if you merged that testsuite into it.


  (Ad 1) http://googleonlinesecurity.blogspot.ca/2014/10/this-poodle-bites-exploiting-ssl-30.html


login: hypnotoad
username: hypnotoad
mimetype: text/plain
icomment:
  Will do. This week is a little rough between pumping out papers and a deadline at work, but I will endeavor to get it done sometime after next week.


login: aku
mimetype: text/plain
icomment:
  Thank you. It certainly is not urgent.

  (I know that the package works due to our use in the AT buildsystem. However with big changes I'd rather have a testsuite with which to guard against breakge before merging).


login: aku
mimetype: text/plain
icomment:
  Notes on the commits ...

  * I wonder if it might make sense to test directly for the 'zlib'
    ensemble command instead of testing the version number.

  * I wonder if might make sense to define internal mini-wrapper
    procs for the two cases (native vs Trf/zlibtcl) instead of
    using the variable "::zipfile::decode::native_zip_functs" to
    switch dynamically.

  * The new encoder currently seems to be missing the definitions
    which make it API-compatible with the pre-86 code. Or, IOW, the
    two implementations currently export completely different APIs.


login: hypnotoad
username: hypnotoad
mimetype: text/plain
icomment:
  Notes on the notes to the commits:

  1) Knowing the zlib command exists doesn't tell us enough. Older zlib implementations don't understand Tcl's channel push/pop mechanism. And pre 8.5 tcl doesn't understand Tcl's push/pop mechanism. So at some point which version of Tcl is a decision mechanism.

  2) Definitely. This was a first pass to fix the encode/decode for 8.6 (as I was having a devil of a time getting Trf to work on Windows.) The mission critical piece could be wrapped in a command that tcllib defines at source time depending on conditions.

  3) The new encoder exploits a lot of 8.6isms. And... the older implementation uses an entirely different operating principle based on snit. To reconcile the two would involve massively rewriting the new to target that various zlib extensions and channel wrapping mechanisms in the wild.

  The temporary cheat was to use the new implementation for 8.6+, and the old implementation for < 8.6

  And my own comment:) There is a lot of code that encode and decode could share. I would also create a third package zipfile::common which would implement those functions, and have encode and decode package require zipfile common, and then import them into their respective namespaces.

  Functions like "encode a date in dos time" really should not be implemented twice. Technically three times because decode has one, and encode has two now.


login: aku
mimetype: text/plain
icomment:
  Notes on the notes to the commits:

  > 1) Knowing the zlib command exists doesn't tell us enough.
  > Older zlib implementations don't understand Tcl's channel
  > push/pop mechanism. And pre 8.5 tcl doesn't understand Tcl's
  > push/pop mechanism.

  Ok. This should possibly noted in the code to prevent other people from asking againg, or changing things.

  > 2) Definitely. This was a first pass to fix the encode/decode for 8.6
  > (as I was having a devil of a time getting Trf to work on Windows.)

  I wonder what is going on with that. Build trouble, or runtime ?
  The AT build does not have issues AFAIK.

  > 3) The new encoder exploits a lot of 8.6isms. And... the older
  > implementation uses an entirely different operating principle based on snit.  > To reconcile the two would involve massively rewriting the new to target that
  > various zlib extensions and channel wrapping mechanisms in the wild.

  > The temporary cheat was to use the new implementation for 8.6+, and the
  > old implementation for < 8.6

  The thing is, the user of 'encode' currently has to distinguish 8.6+ and pre-8.6 also, to code to each API.

  Note that I do not mind using TclOO to recreate the object parts of the API,
  and not having any of the logger stuff.

  Another thing to note is that the version numbers of the two packages are 0.x ... If we can agree on a nice API I do not mind changing it around before going 1.x


  > And my own comment:) There is a lot of code that encode and decode
  > could share. I would also create a third package zipfile::common
  > which would implement those functions,

  ++100

  (I think (seem to remember) that the two packages were created at different times and independently. That would explain the duplication.)

  > Technically three times because decode has one

  Wondering now why decode would have an encoding function


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Attached my variant of oauth, reformatted to fit into Tcllib.
  Notes:
  * Requires Tcl 8.5 (dict cmd, lsearch -nocase, clock milliseconds)
  * Most error returns encapsulated into helper command "Error".
  * Added error-code information to thrown errors.
  * Fixed namespace and version information.
  * Internal date information ($created) switched to use ISO standard date format.
  * Moved https registration outside of command to global.

  Javi, please take the attached code and test if it still works for you.
  It does for me, using the test script you gave me in mail.

  The code is also in the repository, in branch "oauth".
  Revision [7b3a12af1f].


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Documentation received by email.
  Edited.
  Integrated.
  Branch merged.

  Relevant commits are 
  	[0982cecb8c] and 
  	[5f1d4b4301].

  Pushed.
  We are done.
  Closing branch.


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Duplicate of [b3577ed586], maybe ?

  Regardless, I do not know enough of the oo stuff with delegates.
  This has to go through dkf I believe.


login: aku
mimetype: text/plain
icomment:
  Ok. When you have the patch please attach it to this ticket.

  Please make a small self-contained test case as well, which I can then add to the package's testsuite.


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Applied the fix for ticket [b3577ed586].

  This was pushed as oo::util 1.2.1

  Please report if that helped with this problem as well.

  Note that oo::util has the beginnings of a testsuite now.
  Any fix for this should have a self-contained testcase we can add to it.


login: aku
mimetype: text/plain
icomment:
  Received in direct mail to me, instead of commenting here...
  > I am using TCL8.6
  > Regards, Vijay

  Ok. Since Tcl 8.6 the socket command was extended to support IPv6 and I would expect that this automatically conveys IPv6 ability to packages built on top of that, like Tcllib's ftp package.

  In other words, the ability to use IPv6 comes out of the Tcl core in use, and not the ftp package. And the core you are using does support IPv6.

  Given your experience to the contrary I now need more information to reproduce your issue. The best would be if you were to attach a script here (to the ticket) which demonstrates the problem you are seeing.


login: anonymous
mimetype: text/plain
icomment:
  I am running Xlight FTP server over IPv6.

  Here Is the FTP-client using TCL's FTP library:
  -----------------------------------------------
  package require ftp
  set server_ip	"::1"
  set usernm	"anonymous"
  set passwd	"anonymous"
  set ::ftp::VERBOSE 1
  set ::ftp::DEBUG 0

  #Defining Callbacks

  proc Hash {total} {
  	puts -nonewline "#"
  }
  proc ServerReply {id msg state} {
  	puts $msg
  }

  # open a new connection

  set ftp_id [::ftp::Open $server_ip $usernm $passwd -timeout 20 -mode active -output ServerReply -progress Hash]

  #########
  # Till Here everything is going fine. But I am getting error with the below line of code. 
  # Below is the Error I'm getting:
  #08/26/2014 10:46:58 (anonymous ::1<--[::1]:21) "425 PORT doesn't support ipv6 address, use EPRT for ipv6"
  #########

  ::ftp::Get $ftp_id 100MB_file
  ::ftp::Close $ftp_id


login: aku
mimetype: text/plain
icomment:
  Ok, reading

  > (anonymous ::1<--[::1]:21)
  > "425 PORT doesn't support ipv6 address, use EPRT for ipv6"

  it seems to me that the Xlight server expects that the PORT command contains only IPv4 addresses and that IPv6 addresses should be requested via EPRT. Even if it can recognize an IPv6 address in PORT.

  So what we have here is not a low-level IPv6 issue (as I thought initially), but an issue at the level of the FTP protocol itself.

  Searching a bit the relevant RFC seems to be
      http://tools.ietf.org/html/rfc2428

  Is there something in the responses coming from XLight which would allow the FTP package to automatically recognize the need/support for the EPRT command ?

  As an extension of the ftp protocol the package cannot really assume that everybody understands EPRT/EPSV now. Of course, in the worst case use of either PORT or EPRT can be made into an option we can set on an ftp session.


login: aku
mimetype: text/html
icomment:
  Having a second look, I should be able to use the 
  <a href="doc/trunk/embedded/www/tcllib/files/modules/dns/tcllib_ip.html">
  "ip" commands</a>
  to detect use of IPv6 addresses and use that information to automatically activate use of EPRT/EPSV. No user intervention required.


login: anonymous
mimetype: text/plain
icomment:
  Thank you very much for your help.

  AKU:
       Is there something in the responses coming from XLight which would allow the FTP package to automatically recognize the need/support for the EPRT command ?

  ANSWER:
       This morning I tried windows ftp client over IPv6. Below is the response I got from XlightFtp server:
      09/02/2014 12:05:15 (vijay ::1-->[::1]:21) "EPRT |2|::1|58404|"

  Could you let me know how you have used "ip" commands to detect use of IPv6 addresses?


login: anonymous
mimetype: text/plain
icomment:
  FYI

  http://www.juniper.net/documentation/en_US/junos12.1x46/topics/concept/security-alg-ftp-commands.html


login: aku
mimetype: text/html
icomment:
  > Could you let me know how you have used "ip"
  > commands to detect use of IPv6 addresses?

  While I have not done any coding yet the general idea is to use
  <a href="doc/trunk/embedded/www/tcllib/files/modules/dns/tcllib_ip.html#1">
  ip::version</a> on the IP address of the client itself. Depending on the result, either 4 or 6 it should then be possible to have the code doing data connection handling use either PORT or EPRT commands to communicate that address to the server.


login: aku
mimetype: text/plain
icomment:
  > I have gone through the attached ftp.tcl code.
  > Here I found that, this code does not support
  > EPRT or EPSV commands. Please correct me if I
  > am wrong.

  My apologies for not being clear enough in my comments.

  Yes, the code does not support EPRT/EPSV.

  My comments regarding the ip package were thoughts and musings on what changes will have to be made to add such support.


login: anonymous
mimetype: text/plain
icomment:
  Could you let me know what is your next step, I mean are you people going to add EPRT and EPSV commands support to the ftp library in 8.6 itself?


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:
  Interesting how fossil is able to handle the unicode chars as is.

  I guess that we are talking about the unicode code-points
      \u4F60  -- Unicode Han 'you, second person pronoun'
  and \u597D  -- Unicode Han 'good, excellent, fine; well'
  respectively, right?

  In the line marked INCORRECT, what is the expected correct result ?
  And again, for the messy string, what was the expected correct result ?

  Need this for my translation of the information in the description into test cases. Also, please write any unicode chars in the expected results using Tcl's \u.... notation. I have to know the code-points, not the ideograms shown to me by the browser.


login: aku
mimetype: text/plain
icomment:
  Can you explain the "O60Y7D" as well ?
  I would have thought that the unquote returns unicode which went into quote, i.e. that they are inverses of each other:

     x = unquote (quote (x))

  The example seems to contradict that.
  Also, is O60Y7D another encoding for a unicode point?

  (You may notice that I am not the author of the package, and are currently working and researching a bit to understand things.)


login: aku
mimetype: text/plain
icomment:
  Reading RFC 2141 referenced in the docs, and glancing over urn-scheme.tcl I believe I begin to see the problem.

  (1) The unicode codepoints should have been converted into UTF8 bytes, and
  (2) each byte should become a %.. sequence, with the hex after % limited to two characters.
  Whereas quote generates a 4byte hex from the exact code-point.

  And unquote should likely reject %-sequences with more than two hex characters. Right now it seems to convert only the first two hex. I am unsure if it converts the next two separately or ignores them.

  And the last unquote was where it got fed a 2 3-byte utf8 characters and converted them wrongly. Likely as separate bytes/chars.

  And the testsuite covered only ASCII, and nothing in the higher unicode points.


login: anonymous
mimetype: text/plain
icomment:
  "你好" together means "how are you?"

  uri::urn::quote 你好 
  the correct result is %E4%BD%A0%E5%A5%BD

  uri::urn::unquote %4F60%597D
  %4F is O, %59 is Y, thus "O60Y7D", not "你好" as I expected.


login: aku
mimetype: text/plain
icomment:
  Ok, the correct result is as I suspected after reading the RFC.
  6 hex sequences, each representing a 3-byte utf-encoded character.

  And now I understand the back-conversion as well, which properly takes only 2 bytes from the hex sequence and treats the remainder as regular characters.

  This side also needs a back conversion from utf-8. That is the reason for the messy string I believe. I.e. you get 6 separate binary bytes back, instead of two utf-8 characters.

  Work on this can commence.


login: aku
mimetype: text/plain
icomment:
  Fixed with revision [9c454867a1].
  Pushed.
  Version bumped to 1.0.3.
  Had to fix the original test cases as well, were broken (made to the bad implementation).

  Thank you for the report and help.


login: aku
mimetype: text/plain
icomment:
  Meh. I wanted to say that this may be a documentation bug, except, these commands are NOT documented at all.

  It seems that 'dict2json' assumes that it only has to quote the keys, and that the values are already properly formatted as JSON.

  The 'list2json' command apparently does the same.

  And the 'string2json' command does not perform proper quoting of all the special characters. Ok, this is a bug.

  At this point I am tempted to say that the best course here is to

  (1) Remove these commands (not documented anyway).
  (2) Point users to the package "json::write" which is documented.
      Which includes notes on which arguments are expected to be
      proper json already.

  Would that work for you ?


login: anonymous
mimetype: text/plain
icomment:
  For me ok.
  For now i understand (probably) problems with JSON -> dict -> JSON conversions.
  I found another solution.
  I would like to add new command to json package: json2huddle.
  With huddle we have solution for this conversions.
  After testing i send RFE patch.


login: anonymous
mimetype: text/plain
icomment:
  Finally my addons to json lib:
  - new proc json2huddle which returns HUDDLE object.

  Simple test: 
  huddle jsondump [json2huddle $jsonText]


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: aku
mimetype: text/plain
icomment:
  Sigh. Yes.

  While I would like to simply disable the whole testsuite when the package is not found the TclOO-dependent pieces are very much in the minority and should not block the entire testsuite.

  Well, at least for pt I am sure of that. Have to check how it looks for tar.


login: aku
mimetype: text/x-fossil-wiki
icomment:
  Fix, part II (pt, actually also easy, except where I reworked things to properly count the skipped tests).
  Revision [5f6ff5bde3].
  Pushed.

  This completes the set of fixes needed to close the ticket.
  Thanks for the report.


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: 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: 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
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: aku
mimetype: text/plain
icomment:
  Thank you for the report and patch.
  The parts about superfluous and uninitialized variables look good and I see no problem with applying them as is.

  The chunks adding cast to (uintptr_t) etc. in various places however will need more work. There are still machines around which do not have inttypes.h, and related header files. IOW, these are not portable.

  It might be useful to check if using the tcl.h macros INT2PTR() and PTR2INT() will work for these.

  I would also be interested in knowing which compiler/platform is throwing the warnings. Because if I have access to such a machine myself I could work things out myself instead of going through you to test any changes I may make.


login: anonymous
mimetype: text/plain
icomment:
  You do have a point about inttypes.h not being universally available. Using INT2PTR is a good idea, provided that critcl compiles the files with -DHAVE_INTPTR_T. The only place where I see that declaration is in tclConfig.sh.

  Anyway, I probably cooked this patch before you committed your long / void * fixes. The current source code compiles without warnings on FreeBSD, amd64, clang 3.4.1.

  So, as long as sizeof(long) == sizeof(void *) all is good.


login: aku
mimetype: text/plain
icomment:
  Just checked and the macros are defined even when HAVE_INTPTR_T is not defined.
  In that case they pretty much look what I did with my casting, i.e. only (void*) etc, without going through the intptr_t et al.

  I guess I simply have to check each chunk if it still applies or not.

  critcl does not check by itself to ascertain what is in the environment or not.
  I.e. it is not autotools.

  The critcl::utils package has some commands which allow the package getting compiled to make such checks. I might look into that. Still have to bring Tcllib's C parts up to critcl 3.x anyway.


login: anonymous
mimetype: text/plain
icomment:
  Perhaps a safer way would be to add a check for sizeof(int) == sizeof(void *) in tclInt.h and if not, cast first using size_t. I conjecture that if there's an integral type the same size of a pointer, that's size_t on any sensible machine nowadays.


  --- generic/tclInt.h
  +++ generic/tclInt.h
  @@ -102,21 +102,31 @@
   #if !defined(INT2PTR) && !defined(PTR2INT)
   #   if defined(HAVE_INTPTR_T) || defined(intptr_t)
   #	define INT2PTR(p) ((void *)(intptr_t)(p))
   #	define PTR2INT(p) ((int)(intptr_t)(p))
   #   else
  -#	define INT2PTR(p) ((void *)(p))
  -#	define PTR2INT(p) ((int)(p))
  +#	if sizeof(int) == sizeof(void *)
  +#	    define INT2PTR(p) ((void *)(p))
  +#	    define PTR2INT(p) ((int)(p))
  +#	else
  +#	    define INT2PTR(p) ((void *)(size_t)(p))
  +#	    define PTR2INT(p) ((int)(size_t)(p))
  +#	endif
   #   endif
   #endif
   #if !defined(UINT2PTR) && !defined(PTR2UINT)
   #   if defined(HAVE_UINTPTR_T) || defined(uintptr_t)
   #	define UINT2PTR(p) ((void *)(uintptr_t)(p))
   #	define PTR2UINT(p) ((unsigned int)(uintptr_t)(p))
   #   else
  -#	define UINT2PTR(p) ((void *)(p))
  -#	define PTR2UINT(p) ((unsigned int)(p))
  +#	if sizeof(unsigned int) == sizeof(void *)
  +#	    define UINT2PTR(p) ((void *)(p))
  +#	    define PTR2UINT(p) ((unsigned int)(p))
  +#	else
  +#	    define UINT2PTR(p) ((void *)(size_t)(p))
  +#	    define PTR2UINT(p) ((unsigned int)(size_t)(p))
  +#	endif
   #   endif
   #endif
   
   #if defined(_WIN32) && defined(_MSC_VER)
   #   define vsnprintf _vsnprintf


login: aku
mimetype: text/plain
icomment:
  > Perhaps a safer way would be to add a check for
  > sizeof(int) == sizeof(void *) in tclInt.h [...]

  You might wish to propose this on the tcl-core mailing list.
  If there are any portability issues with that type of check
  somebody there should know.


login: aku
mimetype: text/plain
icomment:
  Applied the parts about unused variables, missing initialization.
  Not applied the chunks doing casting.

  Commit [5d35be9b3a].
  Pushed.


login: emmanuel
username: emmanuel
mimetype: text/plain
icomment:
  Since the handler (callbacks) are bound to a (web)socket, and since this error occurs without even having a socket, there are few other ways than the ones that are documented, i.e. returning an empty string as an error indication from ::websocket::open.

  It's a little bit a matter of taste: either we let through the error (which originates from the HTTP library) or (as it is) we catch it, letting the caller testing for the empty string which is being returned. Are there any guidelines around error generation for tcllib that explained these kind of decisions?


login: aku
mimetype: text/plain
icomment:
  > Are there any guidelines around error generation for tcllib ...

  There are currently no guidelines for Tcllib.
  Each package (author) makes up their own mind.

  > It's a little bit a matter of taste

  Not quite. With "letting the caller testing for the empty string" it seems that the larger information about the cause of the error (i.e. error message and error code) are lost. While I can say "something failed" after the test I do not know what.


login: emmanuel
username: emmanuel
mimetype: text/plain
icomment:
  Actually, while the websocket package does not explicitely set the origin field, the field can still be set via the -headers option to ::websocket::open. The RFC does not states that the origin field must be set, so I believe that this isn't as severe as it looks like. But I am open to discussing this.

  (And I agree, more interop testing is required and I thank you for your efforts (and reports!))


login: aku
mimetype: text/plain
icomment:
  > ... the field can still be set via the -headers option to ::websocket::open

  True. That is what I did here to get around the issue. Did not need the URLmatcher part because I have the host directly in the higher layers.

  > The RFC does not states that the origin field must be set.

  Huh. I guess the websocket server I am talking to is then stricter than needed :(

  > I believe that this isn't as severe as it looks like

  I have no problem with dropping the severity of the ticket.


login: anonymous
mimetype: text/plain
icomment:
  In my opinion, the websocket client does not need to know about headers other than Connection, Upgrade and Sec-Websocket-*.

  RFC6455 section 1.3:
     This header field is sent by browser clients; for non-browser
     clients, this header field may be sent if it makes sense in the
     context of those clients.

  Users of the library should choose whether it makes sense for them to send an Origin header. They can do so with an interface similar to that of http::geturl, by using the -headers option.

  On the other hand, it would be nice if the websocket _server_ offered some way of checking Origin headers sent by clients.


login: emmanuel
username: emmanuel
mimetype: text/plain
icomment:
  I've dropped the severity of this ticket as a result of the discussion. I hope that it was appropriate.


login: emmanuel
username: emmanuel
mimetype: text/plain
icomment:
  As for server implementations, the current API supposes that the headers sent by the client to the server are pushed further to websocket::test for testing of the upgrade request viability. This means that the current API supposes that the server has taken all the necessary steps to parse the headers of the incoming request, including "Origin" and could segragate if necessary before calling websocket::test or after (but before calling websocket::upgrade)

  In this context, I hope that it is ok to close the bug.


login: emmanuel
username: emmanuel
mimetype: text/plain
icomment:
  You are right, I had not overseen this in the specification and never have had to use it.

  There is an embryo to an implementation in websocket::test, what would you propose as an API for this?


login: emmanuel
username: emmanuel
mimetype: text/plain
icomment:
  I have an actual usecase for separating the test and upgrade in a server implementation. However, I think that you are right. One solution would be to document the variable created and change the calling/return interface: websocket::test would return fullyqualified name of the variable as an identification of success, otherwise an empty string. It would be up to the caller to remove (unset) the variable if no upgrade is to be performed.

  What do you think?


login: aku
mimetype: text/plain
icomment:
  Found that I made some pt code changes on Aug 11, 2014 and forgot to update the tests to match them.

  Fixed with revision [98f00771ae].
  Committed.
  Pushed.
  Thanks again for the report.


login: emmanuel
username: emmanuel
mimetype: text/plain
icomment:
  Have changed the message, which will contain an explicit mention that this is an HTTP error and of the numerical code. Hope this helps.

  I close the ticket and open another one explicitely for documentation errors and missing bits and pieces to keep things clear.


login: aku
mimetype: text/plain
icomment:
  Fixed with revision [1a2e9c5b7b].
  Committed.
  Pushed.
  Version bumped to 0.3.
  Updated documentation
  Testsuite extended to cover the extend syntax.


login: aku
mimetype: text/plain
icomment:
  Yes. I did quite a lot of work on the parse tools, see the branch
      https://core.tcl.tk/tcllib/timeline?r=pt-work&n=200
  if you are interested in the details.


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: aku
mimetype: text/plain
icomment:
  > Why use custom regular expressions in ncgi when we have uri::split?

  IIRC "ncgi" existed before "uri" was written.


login: aku
mimetype: text/plain
icomment:
  Accepted the patch, with slight modifications.
  - Replaced (dict get) with array commands.
  - Keeps the package at needing Tcl 8.4+, instead of bumping it to require Tcl 8.5+

  Fixed in revision [9f2e9488eb].
  Committed.
  Pushed.

  Thank you.


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

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


login: aku
mimetype: text/plain
icomment:
  Confirmed. Thank you for the report.

  Ah. This particular type of problem has the name

      "creative writing (of a global variable)".

  Due to a missing 'variable' declaration for X the core's var resolution is in the global namespace when it finally comes to the creation of the variable X.

  Given that we have more Tcllib packages than just "uuid" using the LoadAccelerator pattern to detect and choose among multiple implementations of their functionality this means we may have more instances of this problem lurking. Review of all places in Tcllib with this will be required.


login: aku
mimetype: text/plain
icomment:
  Thank you very much for the report. The final result of the review was that 6 packages were affected by this, including uuid. 14 other packages were not affected. Details in the commit.

  Fixed in revision [64c68f3380].
  Committed.
  Pushed.

  uuid      :: Bumped to 1.0.4.
  sha1      :: Bumped to 1.1.1.
  md4       :: Bumped to 1.0.6.
  ripemd128 :: Bumped to 1.0.5.
  ripemd160 :: Bumped to 1.0.5.
  crc32     :: Bumped to 1.3.2.


login: anonymous
username: hypnotoad
mimetype: text/plain
icomment:
  I have prepared a patch, and checked it into my private tcllib mirror.

  The fix is available at:
  http://fossil.etoyoc.com/fossil/tcllib/timeline?r=ticket-f03637392d


login: aku
mimetype: text/plain
icomment:
  Pulled from mirror.
  Reviewed. Some things are missing ...
  Action items for missing things ...
  - Update doctools version number (bugfix -> patchlevel increment).
  -- Update documentation (version change).
  -- Update pkgIndex.tcl (version change).
  - Fix analogous errors in the doctools::toc and doctools::idx packages.
  Actions completed.
  Revision is [700345aa09].
  Updated embedded docs, revision [1aebd8a08b].
  Committed.
  Merged to trunk.
  Pushed.


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: anonymous
username: Andy Goth
mimetype: text/plain
icomment:
  Appear to be other issues with the code, for instance using both EXCL and TRUNC open modes.  I just posted a tighter version on the wiki which may assist in refactoring:

  http://wiki.tcl.tk/_/diff?N=772&V=37&D=36&W=0#diff0


login: aku
mimetype: text/plain
icomment:
  Removed the pid reference.
  Revision [0b83eb3dd5].
  Committed.
  Pushed.

  Regarding the referenced code on the wiki, some questions, to understand it a bit more before going for it.

  (1) It apparently removes the loop doing multiple tries. Why ?
  (2) It removes the precheck of file existence in favor of just trying to open it ?
  (3) In case of problems it removes the after-check if the directory is not writable ?
  (4) What is the issue with having both EXCL and TRUNC ?


login: anonymous
username: Andy Goth
mimetype: text/plain
icomment:
  (1) The multiple tries loop is still there. I just moved the $maxtries tunable directly into the loop condition because my goal was to cut the line count.  You don't need to adopt every change I make, so take it or leave it.  I merely offered my code to "assist in refactoring".

  (2) Checking for the file's existence is implied by EXCL, so checking twice is redundant.  Also, the [after 1] serves no discernible purpose.

  (3) Checking for directory writability failure is a minor performance optimization.  Trying and failing ten times takes practically the same amount of time, and it is certainly a rare and fatal situation in which the configured temporary directory is not writable.  The fault I see with my code (which I optimized to be brief, not to be directly suitable for Tcllib) is that unwritable temporary directory is reported as failure to find unused temporary file names.

  (4) EXCL and TRUNC are fundamentally contradictory.  If the file already exists, EXCL says to fail, and TRUNC says to open it with size zero.


login: aku
mimetype: text/plain
icomment:
  (Ad 1) Looking more closely I now see that you are right. You kept the loop and hard-coded the value instead of using a local 'config' variable.

  (Ad 4) Ok. Getting rid of this then.

  (Ad 2) Getting rid of it. ... The after 1 was possible thought as some sort of backing off to let whoever held the found temp file have the time to go away. Except that the next round through the loop will come up with a completely new random suffix and so avoid the found file anyway. Getting rid of that too.

  (Ad 3) So if we wish to report this right the most simplification we can do is to drop the bool flag variable. If it fails it fails immediately, if not, we have 10 more checks which won't fail. ... Hm ... I leave that in for now. 

  Revision [9520c7d9d7].
  Committed.
  Pushed.
  Bumped to version 1.14.8.


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
  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: 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:
  Please note that the official documentation now resides at

  https://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/log/loggerUtils.html

  Not that it changes the report, this package and documentation have not been touched in some time, and the docs above are the same.


login: aku
mimetype: text/plain
icomment:
  Ah! You are talking about the aclocal.m4 as part of Tcllib's configure(.in) code.
  Had to look at the referenced artifact to understand.

  Have to see if the tcl.m4 in the latest TEA is better in this regard.
  (TEA_PROG_TCLSH).

  Trying to run the tclsh ... makes sense.


login: aku
mimetype: text/plain
icomment:
  Thank you for the report and fix.
  Applied.
  Additionally bumped package version to 1.3.4.
  Committed to revision [55876840bd].
  Pushed.


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:
  Fixed with revision [02c0fddd03].
  (Disarm the bad char sequence + new option -comments allowing the user to disable the comment generation for this).
  Committed.
  Pushed.

  Bumped package "pt::peg::to::cparam" to version 1.1.
  Thank you for the report.


login: aku
mimetype: text/plain
icomment:
  Fix extended with revision [ea593a875e].
  Disarm /*-opener as well, for C compilers supporting nested /* ... */ comments.
  Committed.
  Pushed.
  Package bumped to version 1.1.1.
  Thanks for the report.


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: aku
mimetype: text/plain
icomment:
  Thank you for the report and patch.
  Applied with some small changes
  - Split the big nested expression into multiple commands.
  - Fixed same issue in the finalization, although it would not be that severe there.

  Revision [15c6984635].
  Committed.
  Pushed.
  Package version bumped to 1.1.4.


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:
  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: anonymous
mimetype: text/plain
icomment:
  The problem seems to be in computing the left bound of the Gershgorin region of the matrix A in ::math::linearalgebra::eigenvectorsSVD procedure.

  The bound in the procedure is currently the minimum of 2|a_ii|-sum_j|a_ij|, but it should be the minimum of a_ii+|a_ii|-sum_j|a_ij| (the center of the disk is in a_ii, and not in |a_ii|).

  Just replace
  set sum [expr {2.0*abs($aii) - [norm_one $row]}]
  by
  set sum [expr {$aii + abs($aii) - [norm_one $row]}]
  in ::math::linearalgebra::eigenvectorsSVD proc and this bug will be fixed.


login: aku
mimetype: text/plain
icomment:
  [13:57]	schelte	The fix is very simple too. Just check for eof and if so, close the socket.
  [14:00]		<silas> looks at the clock and dashes out the door
  [14:01]		<Eof> macht wie eine Banane...
  [14:03]	aku	ok


login: anonymous
mimetype: text/plain
icomment:
  This should fix the issue, testing is simple, telnet to the open comm channel *without* sending any data (no <enter>) and close the telnet. Without patch it keeps looping, with the patch the socket is simply closed.

  --- comm.tcl.ORIG       2014-04-11 23:39:35.000000000 +0200
  +++ comm.tcl    2014-04-25 16:17:14.627764129 +0200
  @@ -929,6 +929,11 @@
   
       # Check if we have a complete line.
       if {[gets $fid protoline] < 0} {
  +       #commDebug {puts stderr "commIncomingOffered no data"}
  +       if {[eof $fid]} {
  +           commDebug {puts stderr "commIncomingOffered eof on fid=$fid"}
  +           catch {close $fid}
  +       }
          return
       }


login: anonymous
username: sample yaml code that triggers error
mimetype: text/plain
icomment:
  This should trigger an error with the prepatched code, while being handled properly after the patch.



  ---
  - &foo
  - &bar
  - alpha: 43
    beta:
      houston: [*foo]
      newyork:  [[*bar,[aaa]]]


login: aku
mimetype: text/plain
icomment:
  Thank you for the example.
  This indeed demonstrated both the bug and that it was fixed after patching.

  This is now fixed in revision [06bdef76a4].
  Committed.
  Pushed.

  Package version bumped to 0.3.7.


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: aku
mimetype: text/plain
icomment:
  Right, these files definitely should not be installed.
  Moving them into a sub-directory of their modules should do the trick.


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:
  This is IMHO a problem of "yeti" assuming a specific ordering for the arcs.

  None of the "arcs" or "nodes" methods of the graph package
  promise to deliver a specific ordering or having it consistent
  across implementations.

  The ordering you see/get is based on the internal ordering in the Tcl_HashTables (Tcl implementation) vs. the lists in the C implementation.

  This is similar to how changes to the Tcl_HashTable implementation between Tcl 8.4 and 8.5 affected the ordering of keys returned by "array names". The Tcllib testsuite imposes explicit ordering on results in numerous places to ensure that they are comparable regardless of the Tcl version used to run the tests.

  This issue is the same.

  If the ordering is important for yeti it is better to explicitly impose the desired order instead of assuming to get it from the graph package.


login: aku
mimetype: text/plain
icomment:
  Revision [27f9dbf374].
  Committed.
  Pushed.
  With Thanks.
  This was a duplicate of [2875035fff], i.e. a re-submission.


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


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

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


login: aku
mimetype: text/plain
icomment:
  This looks to be fixed for quite some time now, with no feedback from the original submitter regarding the veracity of the fix. Closing as fixed.


login: aku
mimetype: text/plain
icomment:
  Ah. The 3rd party json-c library.

  Yes, we had this library in Tcllib, for a bit.
  Checking the history it was
  from Dec 10, 2013 (rev [c51875a02a])
  to   Jan 06, 2014 (rev [11390a7baa] dropping it)

  See branch "ak-bug-6efa4f571af052-jsonc" and "trunk" to end date.
  See also ticket [6efa4f571af052].

  This was never in a release.
  (Was added after 1.15, and got removed before 1.16)

  The C code we currently have in Tcllib for JSON parsing is by Mikhail Teterin with modifications by myself, directly using Tcl API, no other data structures, no external library.

  Conclusion:
  - Our releases not affected by the CVE's
  - People directly using one of the revisions in the range mentioned
    above may be affected, and should update.


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: aku
mimetype: text/plain
icomment:
  Patch accepted, with modifications
  - More tests to cover argument handling.
  - Fixed the documentation (missing closing bracket, listified id-list, phrasing).
  Version bumped to 1.4.3.

  Revision [42806b4246].
  Committed.
  Pushed.

  Thank you.


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.


login: anonymous
mimetype: text/plain
icomment:
  I ran your three test cases through another function that we use for our xmodem client to compute the expected results.  I created a test script and added the expected results for each of the values calculated by crc::sum.  You can run the test script from wish86 console.

  # checksumTest.tcl
  package require sum

  set v1 [string repeat a 1280]
  set expectSum1 58624
  set ckSum1 [crc::sum -sysv -- $v1]
  puts "Test 1. Expected: $expectSum1. Actual: $ckSum1"

  set v2 [string repeat fx 640]
  set expectSum2 11008
  set ckSum2 [crc::sum -sysv -- $v2]
  puts "Test 2. Expected: $expectSum2. Actual: $ckSum2"

  set v3 [string repeat \xfe 1280]
  set expectSum3 62976
  set ckSum3 [crc::sum -sysv -- $v3]
  puts "Test 3. Expected: $expectSum3. Actual: $ckSum3"

  -----
  Test run:
  % source checksumTest.tcl
  Test 1. Expected: 58624. Actual: 58625
  Test 2. Expected: 11008. Actual: 11010
  Test 3. Expected: 62976. Actual: 62980
  %


login: aku
mimetype: text/plain
icomment:
  Thank you for your efforts in getting test results to me.

  I have run your script on my machine here and can confirm that I get different actual results vs the expected. They are the same actual results as produced on your machine.

  As my machine is linux/32 (vs. your Win7/64) the issue does not look to be OS-dependent, nor does it look to be a 32 vs 64 bit issue.

  I have changed the ticket title to reflect this.


login: aku
mimetype: text/plain
icomment:
  Fixed with revision [56e6c4cdf2].
  Committed.
  Pushed.

  Thank you for the report and fix (% vs &).


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: 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:
  Thank you for the report.
  Removed the use of ::errorInfo, and simplified a bit.
  Fixed in revision [3b14767f50].
  Committed.
  Pushed.


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:
  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:
  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: aku
mimetype: text/plain
icomment:
  Branch commit first, please.

  This package has no tests :(
  Question is, how do you test this at all ?


login: aku
mimetype: text/plain
icomment:
  Applied patch, except for the "chan close changes, these were not explained in the bug report and therefore left out.
  Made equivalent changes in the coroutine::auto package.

  Bumped versions to 1.1.1 and 1.1.2 respectively.
  Revision [7bed475cb2].
  Committed.
  Pushed.


login: aku
mimetype: text/plain
icomment:
  Confirmed and fixed.
  Fixed another place using "getrect" instead of "get rect" in the method descriptions as well.

  Fixed with revision [ed580c5543].
  Committed.
  Pushed.
  No version bump (no code change).


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: 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: aku
mimetype: text/plain
icomment:
  Notes
  - Will extend the docs a bit to make explicit note of the ability to use css/js multiple times and accumulate the arguments.

  - Will rewrite the tests a bit. We can use html::head to show that the side-effect we wanted has occurred.

  - Will add commands to clear the css and js elements. This makes testing easier as well as we can then control the state going into the tests, and coming out of them (i.e. perform proper setup/cleanup).

  Otherwise looks good.


login: aku
mimetype: text/plain
icomment:
  Fixed with revision [8564870e90].
  Package version 1.4.2.
  Committed.
  Pushed.

  Note: Testsuite extended a bit more, i.e. check argument handling, single/multiple references.


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: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Michal,
  thank you for the contribution.
  I was on holiday. Will look to your patch propably next week.
  Regards,
  Harald


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I have tried the patch.
  Unfortunately, it breaks compatibility for me.
  - up to now, the font of the tabs was controled by the font attribute of the notebook or by the property *NoteBook.font

  Thus the font might be set by one of the following test scripts:
  <CODE>
  font create F16 -size 16
  pack [NoteBook .n -font F16] -fill both -expand true
  .n insert end a -text a
  </CODE>
  or
  <CODE>
  font create F16 -size 16
  option add *NoteBook.font F16
  pack [NoteBook .n] -fill both -expand true
  .n insert end a -text a
  </CODE>

  unfortunately, this is does not working any more.
  Instead, one may use:
  <CODE>
  font create F16 -size 16
  pack [NoteBook .n] -fill both -expand true
  .n insert end a -text a -font F16
  </CODE>

  I would favor for the change, if the current methods would still work and if the additional option may change the font from this default for the current tab only.

  IMHO, code should be added to transfer the default font, if the font option is not given.

  Sorry,
  Harald


login: sosna
username: sosna
mimetype: text/plain
icomment:
  Hello Harald!
  Sorry for such late response - I was on vacation with limited access to the Internet.
  I was rather thinking about possibility to change font of each tab individaully - for example bolded font for currently selected tab.
  What you've wrote is true - with my modification property *NoteBook.font will not work - since it sets font for the whole widget - I didn't think about that.

  Anyway, thanks for looking into this issue.

  Best regards,
  Michal.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  IMHO it is possible to make both work.
  Set and modify the default font of all tabs
  - by the -font option of the widget
  - by the option data base key (*NoteBook.font)
  Have an own font for a page as page option
  - If no page font is used, the default should be used
    (specially tricky, if the default font is changed later by widget configuration)
  - If a page font is used, use this one for this page.

  Prpably, an additional page property is needed, which is the empty string by default. In this case, use the default font, otherwise use this font.

  Please modify the patch to
  - keep compatibility
  - get your requirements work

  Thank you for your contribution!
  Harald


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

  >{"key": 000000}

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

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

  because in huddle.tcl:455,

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

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

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

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

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

  comments?


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

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

  do you think, the integer 000000 is regal?


login: anonymous
username: Ryan Fox
mimetype: text/plain
icomment:
  The "string" values should be checked with this in ::huddle::jsondump in order to determine if they are valid numbers in JSON:

  [regexp {^-?(0|[1-9]\d*)(\.\d+)?([eE][+-]?\d+)?$} $data]


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:
  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
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: 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:
  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:
  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: 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: oehhar
mimetype: text/plain
icomment:
  This ticket shows as "pending" in bwidget tracker with the same id: 1053086fff and is open here.

  Closed


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:
  Nit: The proper reference is http://wiki.tcl.tk/13489
  Please supply a patch implementing the feature.


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: 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: 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: aku
mimetype: text/plain
icomment:
  Yes, that looks right.
  Will apply.
  (Should add tests for CreateNonce, if that is a public command).


login: aku
mimetype: text/plain
icomment:
  Fixed in revision [f082bc61b7].
  Committed.
  Pushed.

  Online docs regenerated in revision [c1d83bd48d].
  Committed.
  Pushed.

  With thanks.


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


