# ticketchng

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

  'tie' is not problem.
  Just loading 'snit' (used by tie) triggers the problem.
  Continuing the investigation ...
  It is the new library of validation commands (validate.tcl) ...
  Defining the first validation snit::type (boolean) does it.
  Which reflects us back to snit itself. Rather, the actual use
  of snit, versus just loading its code.
  Disabling Comp.Define setting the type definition ...
  Not enough ... Comp.Compile is enough to trigger.
  Yes, disabling the snit type compiler makes it go away.
  Comp.Init is enough.

  Ah, ah. This creates a sub interpreter, via [interp create]. Bets that this is the problem. std channels are shared between interpreters, and I guess that there is osmething in there which messes TclX up.

  Confirmed ... 

  Replace the 'puts [package require tie]'
  with 'puts [interp create]'
  and you get your bug.

  Tie only exposes this, the root cause is somewhere in the core, its handling of std channels, and interaction with Tclx.

  I am closing this bug here, please report this in Tcl's bug tracker.

  (And while I am nominally responsible for Tcl's I/O system, and thus the std channels, the sharing of them between interpreters is not something I fully understand. And how this could influence TclX. Actually not fully true ... A first guess would be that TclX dup's the channel at OS level, making a new channel at Tcl level and somehow Tcl then gets confused.)


  Another question to consider ... When you went back to Tcllib 1.8, did you also change Tcl intepreters ? I.e. an older revision of the Tcl core itself ? Because I am quite sure that 'tie' in Tcllib 1.8 ... Ah, ok. Yes, tie in tcllib 1.8 uses snit already, however snit did not have the validation stuff ... Despite this tcllib 1.8 should exhibit the bug you see as well, the moment a snit::type is defined ... Was not dependent on snit in 1.8 ? You can try and remove thesnit dependency from tie ... I see nothing immediate why it is present ... Ah. While the tie core is not dependent on snit the standard data sources all are. However they are not loaded immediately, so not snit type is defined when tie is loaded and things go okay. For a while. When you get a sub interp later on by the first snit definition, or something else TclX will likely blow too. It is just delayed a bit.

  For now I consider the bug report as 'Rejected' here, because it is only a sympton for a Core/TclX bug.


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

  This is the same problem already mentioned in Bug 1645333 (for asnGetContext), which is fixed in CVS HEAD (since Version 0.8.1).


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

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


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

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

  "STOR this is my file name.txt"

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

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

  However, my STOR command says: set filename $list

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


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

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

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

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


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

  Logged In: YES 
  user_id=75003
  Originator: NO

  File Added: ftpd.diff


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

  Logged In: YES 
  user_id=75003
  Originator: NO

  File Added: ftpd.diff.2


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

  Logged In: YES 
  user_id=75003
  Originator: NO

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


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

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

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


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

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

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


login: sf-robot
username: sf-robot
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1312539
  Originator: NO

  This Tracker item was closed automatically by the system. It was
  previously set to a Pending status, and the original submitter
  did not respond within 14 days (the time period specified by
  the administrator of this Tracker).


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

  This is and always has been the intent. It just needs developers/testers to do the work or to submit suitable patches.


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

  Seems like freenode changed something so the host field stopped working. Added this in now.


login: kakaroto
username: kakaroto
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=686750
  Originator: NO

  oups.. submitted as nobody. should be submitted as 'kakaroto'. 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hello KaKaRoTo,

  thank you for the report.
  I have tried to emulate the situation with the following script.
  Unfortunately, I could not reproduce the situation.
  May you:
  - check if the issue is still there with the current implementation
  - provide a demo script.

  Thank you,
  Harald

  #-- Test script ---
  wm geometry . 500x500
  pack [ScrolledWindow .w -bg red] -fill both -expand true
  ScrollableFrame .w.f -constrainedwidth 1 -bg green -height 500 -width 500
  .w setwidget .w.f
  set f [.w.f getframe]
  pack [frame $f.f -bg yellow -width 100 -height 100]


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  By direct mail, KaKaRoTo provided the following test script:

  Anyways, the latest release is from 2006 and is 1.8.0 which is the same that we have in aMSN.. I just tried again to reproduce it (removing our workaround) and the issue is still there.. I wrote a small test program to reproduce it :
  #!/usr/bin/wish
  package require BWidget
  wm geometry . 500x500
  ScrolledWindow .sw
  ScrollableFrame .sw.sf -constrainedwidth 1
  .sw setwidget .sw.sf
  pack .sw -anchor n -side top -expand true -fill both
  set frm [.sw.sf getframe]
  canvas $frm.c -width 100 -height 100 -bg white
  pack $frm.c -expand false  
  All you have to do is *slowly* resize the window to a smaller size and you'll see the scrollbar appearing..If you only resize the height (without modifying the width), then the scrollbar will become smaller and you can move it.. as soon as you click on it, it will disappear...
  If you add these lines to the end of the script, the issue will disappear :
  proc ::ScrollableFrame::_frameConfigure {canvas frame width height} {
     $canvas:cmd configure -scrollregion [$canvas:cmd bbox all]
  }
  I hope this was helpful and I hope you can fix it upstream soon!
  Thank you,
  KaKaRoTo

  I have checked it:
  - Release 1.8.0: issue is there
  - current cvs: issue is not there (I don't know why but I don't bother
  at the moment).

  So if you allow, I will close the ticket without modifications on the current code.


login: federico__
username: federico__
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1628983
  Originator: YES

  sorry, Tcl Wiki is under maintenance. best to check that: http://rafb.net/p/tQ0k4t70.txt


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

  I will be looking into these shortly. I got the code from "ratfb" as a reference implementation.
  What we will need further is a few test cases and documentation. But let me study the code a bit
  first :)


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

  I have started the incorporation of the code into the linearalgebra package.
  That is: I am writing some tests to check the code (removing Tcl8.5-isms and
  one or two bugs along the way).

  Suggestion for the determinant:
  Use LU decomposition and then multiply the diagonal elements to obtain
  the determinant. (I am not familiar with cofactors, I am afraid, so I 
  cannot comment on their usefulness, but this would speed up the 
  computation).


login: federico__
username: federico__
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1628983
  Originator: YES

  hmmm....
  didn't know about LU (LDU) decomposition. I quickly read about it on wikipedia, an I see it is a slightly modified Gauss-Jordan algorithm.

  AFAIK Gauss elimination *changes* the determinant (well, it does in a predictable way). I can't find this information on the "LU decomposition" page though...
  also the Gauss algorithm has some quirks that make the code more complicated (if one wants to work with any kind of matrix), so it will require me time & knowledge (now I am a bit busy with exams)


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

  No, Gauss elimination does not change the determinant: you add a multiple of an existing row to another row and determinants are invariant under this operation. LU decomposition is indeed little
  more than Gauss elimination (I use the terms as synonyms).

  We should not be hasty - better do a good job that takes a bit longer than a sloppy one. So don't
  worry.


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  File Added - 240843: toregexp.dtx

  Logged In: YES 
  user_id=938835
  Originator: YES

  OK, I now have a working implementation, but it's nowhere near being integrated with the grammar::fa package. I probably won't do further work on this for a while, so I just wanted to make the results available.

  To load the code as provided, do:
   package require docstrip
   docstrip::sourcefrom toregexp.dtx pkg

  Top-level commands made available:

     grammar::fa::op::toRegexp $serialization
  Returns RE for the language accepted by the automaton whose serialisation is $serialization.

     grammar::fa::op::toRegexp2 $serialization
  Same, but tries to expand choices in the regexp.

     grammar::fa::op::simplifyRegexp $RE
  Seeks to simplify a regexp by converting it and all its subexpressions to an automaton (which is minimized) and back, picking the shorter of the two. (Seems to find some simplifications, but not others.)

     namespace inscope grammar::fa::op::tclre $RE $dict
  Converts a grammar::fa-style regular expression $RE to a Tcl-style regular expression (or rather a pair of a "surface type" and the actual regular expression). The $dict maps symbol names to such pairs. If a symbol is not in the dict then single-character symbols are interpreted as those characters and other symbols are interpreted as character class names.

  I will also attach a typeset form of the source. It might help explain the algorithm used.
  File Added: toregexp.dtx


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  File Added - 240844: toregexp.pdf

  Logged In: YES 
  user_id=938835
  Originator: YES

  In case you're not completely discouraged by the power series interpretation of formal languages that underlies the algorithm I used, the book

  Werner Kuich and Arto Salomaa:
  Semirings, automata, languages,
  Springer-Vlg, 1986 (ISBNs 0-387-13716-5 and 3-540-13716-5)

  develops this theory in more detail.
  File Added: toregexp.pdf


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

  We actually had a method which nearly did what you wanted, symbols@. Was not really documented however.
  This method has been extended for what you need:

      FA symbols@ s1 s2

  returns the set of symbols which transition from state s1 to state s2. The set is empty if there are no transitions between the two states. The empty symbol in the set indicates epsilon-transitions.

  That should make the generation of the matrix simpler.


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

  Note: The nullary .| has been submitted and can be used for this now.


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

  Accepted, and integrated. small change: toRegexp(2) takes an FA instead of a serialization of one. The serialization is done inside of the proc.
  Also wrote a wrapper command to the tclre namespace for infic translation => toTclRegexp.
  I would now really like to have examples and test-cases for this.


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

  I'm currently away at a conference and have very shaky internet connection, but I'll see what I can do.

  A catch concerning testing toRegexp (did it get spelt that way?) is that there can be many REs representing the same language, so it's a bit difficult to compare against. Maybe the best way is to have a set of test words and verify that Tcl's RE engine recognises the same subset of them as the grammar::fa engine does.


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

  Note: I already added some minimal testing for toRegexp, toRegexp2, simplifyRegexp, and toTclRegexp, based on a FA I found in some online material about FA theory.
  Of course, more testing is welcome, very much so.


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

  Because Tk already uses native scrollbars on Windows since 8.0.


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

  WinXP-style controls are used iif there is a manifest file. Wish has a manifest included on the executable (See http://tktoolkit.cvs.sourceforge.net/tktoolkit/tk/win/wish.exe.manifest.in?view=markup). If an application that embeds Tk wants xp-style controls when executed on XP, either it distributes a manifest along with the executable, or injects the manifest into the executable. Both ways have can cause problems (one more file to distribute and to depend on, modify the makefiles, etc).

  IMHO, it's simpler to avoid the issue once and for all using Tile's scrollbars.

  Besides, is there a reason for not using Tile's scrollbar and use tk's one, on a widget set that explicitly requires Tile?


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

  Another point supporting the use of Tile's scrollbar (and Tile widgets in general) was made by Georgios Petasis on comp.lang.tcl:

  Tk's scrollbar does not support themes. widget::scrolledwindow is ok as far as you want to always use xpnative theme on Windows XP, but becomes broken as soon as you change the theme.


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

  Fixed it - thanks for reporting this (I must have overlooked running the doctools)


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

  Fixed the description of the basic layer and messages.
  The SYNOPSIS section is currently always generated, even if not needed. This would be an RFE for doctools, not comm.
  EOL shown as whitespace fixed. I guess that doctools handled the \n in the text incorrectly. This could be a doctools bug, either general, or in specific backends.
  Added comm as keyword.
  Leaving 'communication' as keyword. The keywords describe the general topic of the document, and communication is certainly fitting.

  Committed.


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

  Synopsis lists commands in the order they are listed in the manpage body. Actually doctools hasn't specified any type of order for the sysnopis ... I.e. this is an undocumented implementation detail ... Fixed order in the body.

  Capitalization ... Apparently most explanations use uppercase tag names. See html::bodyTag, checkbox, checkSet, etc. I guess it is simply a kind of markup. ... Changing to lowercase now, and using 'term' as markup for tags, i.e. relatively general semantics. ... Done.

  openTag ... Worse, the param argument is even optional and not documented as such. It is actually not documented at all. Fixed.

  row ... done.

  Examples ... I haven't written this module and don't really know how to use it, therefore I am not really suited to writing examples.

  I am leaving this report open, with modified summary, unassigned, for whoever is able to provide examples.


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

  I also noticed this.  The explanation for title says: ::html::title title 
  Side effect only. Call this before ::html::head to define the TITLE for a page.

  This is incorrect.  ::html::title is called by ::html::head; calling ::html::title before calling ::html::head would have no effect. Calling ::html::title after callilng ::html::title would change the result of calling ::html::getTitle, but it does not affect the title of the page.


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

  A couple more clarifications.

  tableFromArray creates a two-column table with a heading that matches the array name, and each row containing a name, value pair. The array names are sorted by lsort before use.

  tableFromList creates a two-column table from a nonempty, with each row containing a label, value pair. 


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

  The following procedures exist in html.tcl but are not documented: css, doctype, js, tagParam, urlParent.

  The following procedures are not listed in alphabetical order: init, minorList, paramRow, set.
  This makes their documentation harder to find.


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

  Going through the accumulated comments

  html::title - Are you saying the documentation is wrong, that the behaviour of the package is wrong, or both ? From the description you give it seems to me that the documentation may be right, and actual behaviour wrong. However, not being the author, I am not really sure. Should the behaviour be wrong then this should be submitted as a separate bug.

  TableFromArray/List - I am guessing that you are asking me to extend the documentation for them, based on the described behaviour ?

  Undocumented procedures - I do not know what they do either. Can you draw up some documentation for them for me, and attach to this bug ?

  Sorting minorList, paramRow, etc. - I sorted these yesterday, see my first comment 'Fixed order in the body.'


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

  html::title documentation is wrong. It's used inside the package, but having the user call it makes no sense since it's called by html::head where the title is required anyway.

  Yes, I think the real behavior of tableFromArray/List should be documented.

  I can try to infer documentation to the undocumented procedures.

  I wasn't sure if you fixed all the sorting problems.

  I've been thinking of making a different version of this that would allow creation of more than one stack.  I might if I can find the time.


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

  tableFrom{Array,List} documentation extended. html::title documentation disabled (effectively removed from output, still in the .man, as comment). Committed. When documentation for the undocumented commands comes in this bug can be re-opened, or a new bug made.


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

  I see only one manpage reference, snitfaq. Agreed that this has to be fixed.
  All other uses I can find are in comments, and the ChangeLogs.
  Fixing the comments is of lesser priority.
  Still, when I come to snitfaq I can do them as well.
  I remember the places.
  I usually put them in when I have a 'eval/linsert etc. combo in the code and write in the comment the more readable 8.5 form.


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

  Fixed snitfaq manpage, and all uses inside of Tcl comments. Committed to CVS Head.


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

  Previous version used to pad keys to 64 bits so the key because "SeCrEt\0\0"
  Added an improved error message for short keys.
  If using the old command options, enable key padding with nulls.
  Added test.


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

  Check ... Is the -type feature supported by Tcl 8.3 ? The 'file join' can be replaced '-directory $dir *' as well. Also a feature not likely present in 8.3. Work on that.


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

  This is partially done already. All the manpages in the CVS should by now have a section abouts Bugs, and Feedback, and pointing to the SF Bug tracker for Tcllib.


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

  That's sounds very useful. Adding it to a README in either the top, src, or devdoc directory seems like another useful location.


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

  This was possibly due to the new dependency of math::statistics on math::linearalgebra. That was fixed in the Tcllib CVS head. Please test if your problems is still present. Platform is solaris ?


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

  What version of the ldap module do you use? (what is returned by package require ldap)


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

  Does it also fail with a more recent ldap version (best use 1.6.8 from cvs if you can, you need an updated asn package too). If you don't know how to check those out from cvs i can send you a small zip file with both packages, just email me...

  The output from the ::errorInfo when the error occurs would also help to pinpoint the problem.

  1.2 is already quite old, and i cannot reproduce the bug it with my local setup and ldap 1.6.8.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Bug confirmed.
  Listbox deltes the item widget as bwidget (bwidget::delete) but postphones the delete in the canvas to a after idletasks routine.
  An eventual pending resize event may be executed between the two tasks.
  The error may arise due to the half deleted item widget.

  A patch is attached. It consists of a check if the widget (to update) is on the "to-delete" list.
  Alternate solutions:
  - a simple catch -> drawback -> errorInfo pollution
  - a check if the widget was removed (widget::exists path.item

  Patch for listbox.tcl:
  1069,1070c1069,1072
  <         $path.c itemconfigure "n:$item" \
  <             -fill [_getoption $path $item -foreground]
  ---
  >         if {-1 == [lsearch -exact $data(upd,delete) $item]} {
  >             $path.c itemconfigure "n:$item" \
  >                 -fill [_getoption $path $item -foreground]
  >         }


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

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


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

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


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

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

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


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

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


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

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


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

  Yes, a duplicate of [ 1774302 ] error in CommRunHook error handling, @ https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1774302&group_id=12883

  Already fixed in the CVS Head.


login: fanwang
username: fanwang
mimetype: text/plain
icomment:
  File Added - 241931: STProxy

  Logged In: YES 
  user_id=1871132
  Originator: YES

  File Added: STProxy


login: fanwang
username: fanwang
mimetype: text/plain
icomment:
  File Added - 241934: STProxy

  Logged In: YES 
  user_id=1871132
  Originator: YES

  File Added: STProxy


login: fanwang
username: fanwang
mimetype: text/plain
icomment:
  File Added - 241936: STProxy

  Logged In: YES 
  user_id=1871132
  Originator: YES

  File Added: STProxy


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

  Logged In: YES 
  user_id=13222
  Originator: YES

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

  Patch is still bare implementation.
  File Added: patch_v2


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

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


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

  Something in just this test ... I am not sure about that. The test framework in sak uses Ctrl-M, aka CR, aka \r, aka 0x0D to move the cursor to the beginning of the current line without advancing a line, before printing the next line. To me it looks a bit like the terminal or other is gobbling this character, or transforming into linefeed (LF, \n).

  Well, I am running now on a solaris box too, will see if I can see the same problem. Setup is similar, xterm, Exceed server on WinXP. No gnome tough.


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

  Agreed. filterfor already runs 'expr' internally. Fixed in CVS head.


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

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


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

  Oh, I will have to look into that - I do not remember the details of why I made this
  change. 


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

  Yes, the result of matmul_vm (the underlying routine for matmul for the multiplication
  of a row vector and a matrix) actually returned a column vector. 

  (The change from 1.0 to 1.0.1 was meant to solve the issue of row and column vectors,
  there is a natural distintion possible between them. I tried to keep some of the previous, 
  sloppy behaviour, while at the same time being more strict in this distinction. I solved
  the problem by transposing the result - this gives a correct row vector and therefore
  a correct answer with the rest of the computations)

  See the CVS repository (version now: 1.0.2)


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

  TIP#190 ... Right, we should make a reference to that.


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

  Applied and committed to head. Thank you.
  No reference to #190 yet.


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

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

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


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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

  Side note regarding Ns_Sls.html ... "Ns_Sls} - Socket local storage" shows me that there is a closing brace to many somewhere in the documentation sources.

  Regarding parentheses and argument types: When doctools was written it was with the intent of documenting Tcl commands. C functions were not on my mind and so are not really supported. You can document them, but a number of things have to be done manually, like adding parentheses around the whole set of arguments to a function, and adding type names to arguments. We currently do not have any markup commands to highlight types.

  Would you be willing to write up a concrete proposal of the extensions (= markup command) needed for clean support on C functions ?


  Regarding "How do do you ... arrange", that is completely out of the scope of doctools. It is intended for the conversion of the manpages to HTML, nroff, and the like, however it has no truck with installing the results. That is left to the Makefile (or equivalent buildsystem) of the package being documented.


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


  Regarding command/function aliases, this seems part of what building a set of man pages is about. Ideally I would point doctools at a directory full of *.man sources and it would output the nroff (as it does now). But also, it would recognise that Ns_Sls.man actually documents half a dozen related functions and would create sym-links: Ns_SlsAlloc.man -> Ns_Sls.man etc. This allows a user to type 'man Ns_SlsAlloc' and have the right man page appear.

  I think you need the database of which commands are documented on which pages anyway, for the cross referencing to work.


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


  With your feedback, I took another go at it and it's looking a lot better:

    http://naviserver.sourceforge.net/3/naviserver/files/Ns_Sls.html


  That's completely not the mental model I had of how the macros worked.

    [call [fun Ns_SlsAlloc]([type Ns_Sls] *[arg sls], [type Ns_Callback] *[arg cleanup])]

  After marking up Tcl commands, I imagined each arg to 'call' was a significant element: func name, arg, option, type, etc. But it's actually just a blob of text..(?).

  The documentation for doctools doesn't really help. There are no examples. It doesn't tell you when or why you might use a particular macro. It doesn't tell you which macros go together.


  How do I handle return values? Do I just add type and arg in front of fun?


  (I haven't got as far as structures and other types yet. I'll have to think about it...)


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

  Regarding section titles. They are passed through as is from the input, currently by all backends. If you do not write all-caps they will not be all-caps in the output ... Could the real request be that you wish to write your titles normally, and the nroff backend convert it to all-caps, with the html backend passing them unchanged, as it does now ?

  Regarding the Table of contents. Do you have a concrete proposal or ideas for how the formatting of the TOC should be done instead ? Regarding the Synopsis the same question applies. Ditto regarding the formatting of examples.

  Paragraphs. As far as I know that is legal HTML, although possibly not legal XHTML. I agree, closing them would be nicer. The same for definition lists. I have added these to my TODO lists.

  dtplite has possibly quite rigid expectations. That is part of the reason it has the 'lite' moniker, as it made the implementation less complex. Is it possible for you to write up how your directory structure looked like, how dtplite behaved on it, and how your symlink forest helped in that regard ? Is it also possible to clarify the question on "how to add C library docs" a bit ? I have trouble understanding the problem with that ? From dtplite's perspective this would simply be another module in another directory. I think, if I interpret your question correctly.


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

  The closing of list elements (dt, dd, li) is now done. The closing of paragraphs is mainly done. Paragraphs in list elements do not get closed yet.


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

  I think I am will use this bug report as the one where we can discuss HTML styling in general.
  From the tcler's chat ...

  [15:43]<RockShox>aku continuing from yesterday re doctools
  [15:43]<RockShox>the class names dont matter as long as its documented
  [15:45]akuI guess. I added lots of lcass names today, no docs however yet for them.
  [15:52]<RockShox>its nice to have some divs too
  [15:52]<RockShox>like around the toc
  [15:52]<RockShox>or examples
  [15:53]akuI have no idea what you can do with CSS, please file bug/enhancement reports with examples of how you wish to change the HTML
  [15:55]<RockShox>you dont need to know what i can do with css
  [15:55]<RockShox>you just need to give me a way to address the distinct parts of a doc
  [15:55]<RockShox>if that makes sense
  [15:56]<RockShox>it probably means most doctools commands should generate something within a div or an individual tag with a class name
  [15:58]akuI may have phrased  my words badly too ... I have no idea what exactly you want me to put into the HTML which would support CSS. What is a div ? what attributes does it  have? things like that. I can work better when I see a concrete example of the change wanted, for this
  [16:00]<RockShox>a div is just a division
  [16:00]<RockShox>it doesnt really do much
  [16:00]<RockShox>but if you give it a class then the css can distinguish anything within that div
  [16:01]<RockShox>like i could make a link inside an example div different than a normal link
  [16:01]<RockShox>by addressing that class
  [16:05]akuso you are talking just about adding <div class=XXX>...</div> around certain things, or most things ?

  What is your opinion about this ?

  I am amenable to redo the generator to make it more accessible to CSS based styling.
  This pertains to the items in the report here too. Will adding divs and classes make the nested table superfluous, to be added back if wanted by css, or overridable by CSS, or ... ?


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


  Re formatting block level elements...


  The auto-generated table of contents at the top of each page currently looks like this:


  <h2><a name="table_of_contents">TABLE OF CONTENTS</a></h2>

  <p>&nbsp;&nbsp;&nbsp;&nbsp;<a href="#table_of_contents">TABLE OF CONTENTS</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#synopsis">SYNOPSIS</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#description">DESCRIPTION</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#commands">COMMANDS</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#examples">EXAMPLES</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#see_also">SEE ALSO</a><br>
  &nbsp;&nbsp;&nbsp;&nbsp;<a href="#keywords">KEYWORDS</a><br>


  (bug: note that "TABLE OF CONTENTS" appears twice; as a header and within the table of contents.. :-)


  It probably should look something more like this:



  <div id="table-of-contents" class="section">

    <h2>Table of Contents</h2>

    <ul>
      <li><a href="#synopsis">Synopsis</a></li>
      <li><a href="#description">Description</a></li>
      <li><a href="#commands">Commands</a></li>
      <li><a href="#examples">Examples</a></li>
      <li><a href="#see-also">See Also</a></li>
      <li><a href="#keywords">Keywords</a></li>
    </ul>

  </div>



  The synopsis should probably look something more like this:


  <div id="synopsis" class="section">

    <h2>Synopsis</h2>

    <ul>
      <li><a href="#ns_sls-get"><strong class="cmd">ns_sls get</strong> <i class="arg">key</i> <span class="opt">?<i class="arg">value</i>?</span></a></li>
      ...
    </ul>

  </div>



  The commands sections currently looks like this:



  <h2><a name="commands">COMMANDS</a></h2>
  <p></p>

  <dl>

  <dt><a name="1"><b class='cmd'>ns_atprestartup</b> <i class='arg'>script</i> ?<i class='arg'>args</i>?</a></dt>
  <dd>Pre-startup procs are called...
  <br><br>
  </dd>

  <dt>...



  It should look something more like this:



  <div id="commands" class="section">

    <h2>Commands</h2>

    <dl class="definitions">
      <dt id="ns_atprestartup" class="call"><b class='cmd'>ns_atprestartup</b> <i class='arg'>script</i> <span class="opt">?<i class='arg'>args</i>?</span></dt>
      <dd>Pre-startup procs are called...</dd>

    </dl>
  </div>



  The pattern is:

  - All sections have their own <div>, and the div wraps everything including the title

  - They all have a class of 'section', and an id. An id is like a class, you can use it for styling. However, it must be unique within a page, and is the recommended way of linking within a document. So, this works: cmd.html#synopsis. 

  - The id is the section name

  - Definition lists seem to be reused within doctools, i.e. [call ...] is another way to say [def ...], so we add a class of 'call' to the <dt>, even though it already appears within a <dl> classed with 'definitions'.



  The styling that used to be applied directly to the HTML elements can be moved to an embedded style sheet at the top of the page. If, the user passes a -style option to dtplite, the embedded styles are omitted and the link inserted.

  For example, to some vertical space between each section, and indent the Table of Contents, the styles will look like this:

  <head>
    <style type="text/css">
    <!--
      .section {margin-bottom: 2em;}
      #table-of-contents {padding-left: 4em;}
    -->
    </style>
  </head>


  The Table of Contents is a section, so it has both styles applied.



  Also, the whole content section should be enclosed in a div, like so:


    <body>
      <div id="doctools"
        ...
      </div>
    </body>


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

  Some clarifications ...

  Wrapping sections into div's ... A bit more complicated than you might think, as I know when a section starts, but not immediately where it ends. May need state flags ... At least I have to number more than one place ...

  id = section name ... you seem to actually use 'lower case section name'. what about spaces in the section name, is that allowed to be in the id too ? Or should we replace with underscore ?

  'call' = 'def'. Not quite. 'call' wraps an anchor around the defined item, and puts the information into the synopsis. 'def' doesn't do these things. Beyond that they are identical, yes.


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

  Yes, I canonicalised ID's by bashing to lower case and replacing spaces with dashes.

  I'm pretty sure you can't have spaces in ID names. If it were a class it would be considered two class names, but for ID's I'm pretty sure you can only have one anyway. Still, ID names are also used in fragments (the bit after the #hash in a URL) and in general it's a pain to have spaces there.

  I used dashes instead of underscores again because of the URL fragment. URLs are often shown underlined and it's sometimes difficult to distinguish an underscore from a space when the word is underlined.

  I forced to lowercase because of the requirement that nroff and html output titles in deferent cases. Probably best here to accept any input from the source, and force to uppercase for nroff, title case for html, and lower case for ID names. It's predictable for people generating URLs.


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

  I found later that I am generating the id's by going to lower case, and replacing
  spaces with underscores. Point taken regarding underscore/space vs. dash.


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

  Started to work on this again in the last few days (*) - cvs head now contains:
  - sections, subsections are now closed. they are put in div's.
  - examples are in divs (still have to drop the wrapping in table), sectref in spans.
  - whole body in a div
  - still to do: redoing toc and synopsis, embedded style, and lots of other small things.

  (*) Now that I have a big set of formatting examples used by the testsuite to check the output.
      (see doctools/tests/man/* for the testcases, doctools/tests/html/* for the current results).

  Regarding id's I have seen another way of generating them, in the tcler's wiki.
  It uses the crc16 or crc32 of the section title, formatted as hex.
  I believe an md5 would be better, more collision resistant. for subsections merge in the section title
  predictable generation, no issues with any type of casing, no spaces, no dashes, no underlines.


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

  It seems section titling is the only thing I have left to do with this, and the generation of nice (sub)section ids.

  Examples are now properly classed, without lots of tables and such. TOC and synopsis are now styled through the CSS as well, and a standard CSS is placed in the output. At least if the 'meta' engine parameter is not set. If it is it is assumed that its contents will specify their own style, be it internal, or external. Paragraph handling is now done into, through and in lists / list elements as well, so that should look nice too, now.


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

  Anchors for (sub)sections are now nicely generated (sectionNNN, subsectionNNN), nroff does automatic upper-casing of (sub)section titles, HTML doesn't do that any longer. The automatic sections (like keywords, see also, etc.) are now camel-cased instead of full uppercase. This completes the handling of this report.


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

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


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

  Fixed up the manual with this plus comments for all the commands.


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

  Hm. dtplite simply does 'package require doctools' and then assumes that the package management of the Tcl core will be set up to find it. When you installed tcllib into the local directory, was the tclsh you used correctly set up to find packages in that directory ?

  Note, if I add code like 'lappend auto_path ...' to extend the package search from within dtplite, then testing an uninstalled dtplite will be come difficult too ...

  I will have to look where tcllib and dtplite go, i.e. both prefix ? Is exec-prefix involved. If things are simple enough I should be able to write code which properly extends package search for all cases ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 247453: dtplite.autopath.tcl

  Logged In: YES 
  user_id=75003
  Originator: NO

  File Added: dtplite.autopath.tcl


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

  I have now attached a small tcl script, "dtplite.autopath.tcl", which may fix the problem. Its contents have to be inserted after the 'exec tclsh' at the top of dtplite. The code basically computes the location of dtplite itself, then looks into the filesystem for the two places where tcllib modules can be and adds the one it found to the package management.

  It should not only be tested that this fixes the problem, but also that it doesn't break the regular setup, i.e. when installed without a --prefix.


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


  Small typo. lappend auto_path is missing in the second arm:

      if {[file exists [file join $topdir modules]]} {
          lappend auto_path [file join $topdir modules]
      } elseif {[file exists [file join $topdir lib]]} {
          [file join $topdir lib]
      }


  Anyway, the above prefers the older version of tcllib (1.9 on my machine, distro installed) unless I do this:

      if {[file exists [file join $topdir modules]]} {
          set auto_path [linsert $auto_path 0 [file join $topdir modules]]
      } elseif {[file exists [file join $topdir lib]]} {
          set auto_path [linsert $auto_path 0 [file join $topdir lib]]
      }

  With the above change, dtplite finds and uses the correct version of tcllib when
  installed with --prefix. Without the change, it uses a mish-mash of old and new tcllibs.

  However...

  I'm not sure this is the right fix in the general case. It's not really a question
  of --prefix but --libdir, as that is what is used in the Makefile to install:


      pkglibdir = $(libdir)/@PACKAGE@@VERSION@
      ...
      install-libraries:
          $(TCLSH_PROG) `$(CYGPATH) $(srcdir)/installer.tcl` \
          -pkg-path   $(DESTDIR)$(pkglibdir) ...


  There is not necessarily a direct relationship between libdir and bindir, as both can be set independently on the configure command line. And that means you can't find your way to libdir by starting with [info script].

  For example, I already have tcllib-1.9 installed in /usr/share/tcl8.4 (standard fedora 7 rpm), with dtplite in /usr/bin, and to make sure the above fix works without passing a weird --prefix I wanted to install to /usr/share/tcl8.4, which is in my Tcl's library path.

  The directories tcllib1.10 and tcllib1.9 do not clash, but the dtplite script would overwrite the existing one in /usr/bin. So I used:

    ./configure --bindir=/home/sd/tmp/bin --libdir=/usr/share/tcl8.4

  which doesn't work. dtplite picks up tcllib-1.9.



  So the above fix works for a standard install where tcllib lives somewhere on the Tcl package path. And it works if you install somewhere non-standard by using --prefix at configure time. But it doesn't work if you install somewhere non-standard by using --libdir and/or --bindir/--exec-prefix.

  I think the usual way people handle relocatable autoconf packages is by embedding the paths in the scripts/binaries and/or using -rpath. Not sure if you want to handle that here. 


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

  Oops on the typo, apologies.

  Regarding bindir/libdir/prefix ... That is the part I had not yet looked into. Given your explanations it is now clear that I have to put a placeholder into the code of dtplite, and modify tcllib's installer to replace them with the correct path during installation ...

  That is a pain, because for ActiveTcl (*) I will have to replace the placeholder with a placeholder, or not at all, so that the distribution's installer can do the final replacement :(

  (*) Any other batteries included distribution will have the same problem.

  It is not clear why the linsert works but not the lappend. Package management reads all pkgIndex.tcl files in all paths, and later simply asks for a package satisfying the requested version. Only for packages with multiple implementations but the same version should order become important :(

  Note that 'tcllib 1.9' is not relevant information. The version of the 'doctools' package counts. Which is 1.3 in tcllib 1.10, and was 1.2.1 in tcllib 1.9. dtplite simply asks for doctools, no version, so should get the highest. If that is not the case something else is wrong. Or the tcllib 1.9 you have is from a CVS head and already at v1.3.


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

  These br's are gone if you write [list_begin definitions compact].
  Not documented tough. And I do not remember why it was added.
  Ah ... ChangeLog:

  2002-04-01  Andreas Kupries  <andreas_kupries@users.sourceforge.net>

  * Committed changes to list generation (better generation of
    whitespace for HTML, allowing hints). Only the HTML formatter
    currently acknowledges hints. This fixes SF Bug #535382.

  Link to that report:

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

  Do you have additional comments regarding this and the old report ? Is that something we could fix by using proper classes for list begin/end and items, so that a CSS can then influence the spacing instead ?


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

  Well, the br's have been yanked out, ditto the undocumented 'compact' hint. The argument is still accepted from manpages using it, but ignored. Any spacing has to be done through CSS now.


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

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


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

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

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

  So, this code:

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


  Which results in this HTML:

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


  Should instead produce this:

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


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


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

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


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

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

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


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

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


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

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


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

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


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

  Accepted. Command is 'uevent::list'. Advanced package version to 0.2. This command was also needed for a proper testsuite, to allow us to check that bind/unbind work as expected.


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

  Unfortunately there is more to it than just that - after repairing this and
  a few other bugs I get a division by zero. I will have to check the original
  implementation and add a proper testcase! (Serves me right for not having 
  done that)


login: mezis
username: mezis
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=276102
  Originator: NO

  Confirmed.
  The whole eigenvectorsSVD (as well as the rest of the SVD-related code) either doesn't run or produces erratic results.


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

  I know the solution for eigenvectorsSVD - it is much simpler than I thought, 
  but note it is _only_ meant for real symmetric matrices. I have not committed 
  it yet, as I wanted to be sure I understand the solution correctly.

  mezis, can you provide an example where the other SVD-related code does 
  not do its job?


login: mezis
username: mezis
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=276102
  Originator: NO

  I finished patching eigenvectorsSVD. I've submitted my patch against 1.10 :
  https://sourceforge.net/tracker/index.php?func=detail&aid=1852519&group_id=12883&atid=312883


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

  Applied the patch, added a simple test case. Increased the version number to 1.0.3
  Thanks again. (Tcllib 1.10 is slightly old though, I had already corrected a
  number of glitches)


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

  next time, provide a complete description of what you are doing.


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

  I am guessing that this the same as RFE [892318], just more detailed.


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

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

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

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

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


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

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

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

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


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

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

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


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

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

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


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

  I submitted the bug.

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


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

  Debugging gives this analysis:

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

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


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

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

  Deeper analysis:

  The trouble is line 893 mime.tcl

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

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

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

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

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

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


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

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

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

  sak.tcl validate


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

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

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

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


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

  I will have a look at it - perhaps a problem with integer values (rather than floats)?


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Apparently not an integer problem:

   ::math::statistics::cdf-normal 0.0 1.0 0.0

  gives the same error.


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

  No, I assumed it was because that is a common mistake with converting Fortran or C code to Tcl.
  However, we are in some limit situation for the algorithm. The quick-and-dirty solution is treat 
  x=0 as a special case. 


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  I can do the quick-and-dirty workaround no problem. Thanks! I just wanted to bring it to your attention.

  Take care,
  Eric


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

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


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

  This seems to be a dict'ionary ordering thing. The tcllib testsuite support provides a 'dictsort' command to generate a canonical representation, whatever the ordering returned by Tcl. This is not as important any longer now that dicts are keeping insertion order. It was originally made because Tcl 8.4 and 8.5 returned dicts and arrays in differing orders due to changes in the underlying hash(table).


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

  Committed updated tests to CVS. Note: The tests can run with a Tcl 8.4 using the backported dict package. This combination will now fail as the backported dict does not have the ordering changes of the Tcl 8.5 dict. either the backport has to be updated, or the testsuite has to get two tests per actual test, one per variant.


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

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


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

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


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

  Surprisingly, I don't have a test case for this--but in fact it's perfectly OK for an object to destroy itself.

  Of course, it shouldn't try to do anything else after calling "$self destroy".... 


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  There was an error in random-gamma. Here is the corrected version:

  # Generate a list of gamma-distributed random deviates
  # Use Cheng's envelope rejection method, as documented
  #   in Dagpunar, J.S. 2007. "Simulation and Monte Carlo:
  #   With Applications in Finance and MCMC"
  proc random-gamma {alpha beta number} {
      if {$alpha <= 1} {
          set lambda $alpha
      } else {
          set lambda [expr {sqrt(2.0 * $alpha - 1.0)}]
      }
      set retval {}
      for {set i 0} {$i < $number} {incr i} {
          while {1} {
              # Two rands: one for deviate, one for acceptance/rejection
              set r1 [expr {rand()}]
              set r2 [expr {rand()}]
              # Calculate deviate from enveloping proposal distribution (a Lorenz distribution)
              set lnxovera [expr {(1.0/$lambda) * (log(1.0 - $r1) - log($r1))}]
              if {![catch {expr {$alpha * exp($lnxovera)}} x]} {
                  # Apply acceptance criterion
                  if {log(4.0*$r1*$r1*$r2) < ($alpha - $lambda) * $lnxovera + $alpha - $x} {
                      break
                  }
              }
          }
          lappend retval [expr {1.0 * $x/$beta}]
      }
      
      return $retval
  }


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Also, adding a better way to test the random deviates. Now for the testing routine, add the pdf to the histogram of values. Here's the revised testing code:

  ##########################################################################################
  ##
  ## TESTING
  ##
  ## Can test pdf & cdf by running in a console. For random numbers, generate histograms:
  ##
  ##########################################################################################
  canvas .c
  pack .c -side top
  frame .f
  pack .f -side bottom
  label .f.alphal -text "alpha"
  entry .f.alphae -textvariable alpha
  pack .f.alphal -side left
  pack .f.alphae -side left
  label .f.betal -text "beta"
  entry .f.betae -textvariable beta
  pack .f.betal -side left
  pack .f.betae -side left
  button .f.run -text "Run" -command runtest
  pack .f.run -side left

  proc runtest {} {
      set vals [random-gamma $::alpha $::beta 5000]
      set remainder 5000
      for {set x 0.0} {$x < 20.0} {set x [expr {$x + 0.25}]} {
          lappend bins $x
          set distvallow [pdf-gamma $::alpha $::beta $x]
          set distvalhigh [pdf-gamma $::alpha $::beta [expr {$x + 0.25}]]
          # Total trials (5000) * step (0.25) * average value
          set distval [expr {int(5000 * 0.25 * 0.5 * ($distvallow + $distvalhigh))}]
          lappend distcounts $distval
      }
      # Assume none are left
      lappend distcounts 0.0
      set bincounts [::math::statistics::histogram $bins $vals]
      .c delete hist
      .c delete dist
      math::statistics::plot-scale .c 0 20 0 [math::statistics::max $bincounts]
      math::statistics::plot-histogram .c $bincounts $bins hist
      math::statistics::plot-histogram .c $distcounts $bins dist
      .c itemconfigure dist -fill {} -outline green
  }

  set alpha 1
  set beta 0.5
  runtest


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260324: gamma.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  This is not a change to the basic code. Instead, it's just rearranging the testing code a bit. I'm attaching a zip file with all of the needed files to run the tests. The code itself is (almost) stand-alone: just a few calls to "simple test" (also included).

  File Added: gamma.zip


login: erickb
username: erickb
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=816411
  Originator: YES

  Note that the zip file contains all of the fixes mentioned in previous posts. Also, it includes the incomplete gamma function. Finally, it puts everything in a "gamma" namespace (which I expect you'll move over to the math::statistics namespace).


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

  We have to wrap the read script into an 'uplevel #0' to simulate the -global option of invokehidden.
  Fixed, is in CVS, tie::file version 1.0.3.


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

  Patch already applied - but let me check the code to be sure


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

  Just checked: changelog refers to thi patch dd 23 december 2007


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

  The ldap library is naive in listufy the filterString in line 1352-1353 in ldap.tcl. This can be fixed by parsing the string. The code below should do the trick. Escaping of () in data in the search string remains the responsibility of the library user.

  Example:

  ldap::parseFilter "(&(objectGUID=3fas93*\\(#}\\))(&(cn=*)(on=*)))"
  & objectGUID=3fas93*(#\}) {& cn=* on=*}

  Code: 

  # include procs

  proc ldap::parseFilter {filterString} {
        if {![regexp -- {^\((.*)\)$} $filterString -> filterComp]} {
    error "invalid filter string: syntax is \"( ..... )\""
        }
        return [parseFilterComp $filterComp]
  }

  proc ldap::parseFilterComp {filterComp} {
        set first [string index $filterComp 0]
        set rest [string range $filterComp 1 end]
        switch -- $first {
   & -
           | -
           ! {
       return [linsert [parseFilterList $rest] 0 $first]
           }
   default {
           # we have an item return as a single element list
  return [string map {"\\(" "(" "\\)" ")"} $filterComp]
           }
        }    
  }

  proc ldap::parseFilterList {filterList} {
      puts "pfl: $filterList"
      set filters {}
      if {[string length $filterList] == 0} {
         return {}
      }
      if {[string index $filterList 0]!="("} {
    error "invalid filter component, syntax \"( ....\""
      } else {
          set filter [ldap::getFilterListElement filterList] 
          puts $filter
          return [list [parseFilter ($filter)] {*}[parseFilterList $filterList]]
     }
  }

  proc ldap::getFilterListElement {filterListVar} {
     upvar 1 $filterListVar filterList
     set prev {}
     set depth 0
     set idx 0
     foreach cur [split $filterList ""] {
          switch -- $cur {
              ( { if {$prev ne "\\"} {incr depth} }
              ) { if {$prev ne "\\"} {incr depth -1} }
          }
         incr idx
         set prev $cur
         if {$depth == 0} {
            set item [string range $filterList 1 $idx-2]
            set filterList [string range $filterList $idx end]
    return $item
         }
     }

  }

  # and replace regexps by: set filterString [parseFilter $filterString]


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

  What I posted before will fail on {(GUID=\\)} for example. 


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

  Hm the correct format according to the RFC is \hh where hh are hex digits, so my examples are incorrect.


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

  The following version works correctly on strings I have tested

  # include procs

  proc ldap::parseFilter {filterString} {
        if {![regexp -- {^\((.*)\)$} $filterString -> filterComp]} {
    error "invalid filter string: syntax is \"( ..... )\""
        }
        set result [parseFilterComp $filterComp]
  }

  proc ldap::parseFilterComp {filterComp} {
        set first [string index $filterComp 0]
        set rest [string range $filterComp 1 end]
        switch -- $first {
   & -
           | -
           ! {
       return [linsert [parseFilterList $rest] 0 $first]
           }
   default {
  return [subst -nocommands -novariables [regsub -all {\\(..)} $filterComp {\\u00\1}]]
           }
        }    
  }

  proc ldap::parseFilterList {filterList} {
      puts "pfl: $filterList"
      set filters {}
      if {[string length $filterList] == 0} {
         return {}
      }
      if {[string index $filterList 0]!="("} {
    error "invalid filter component, syntax \"( ....\""
      } else {
          set filter [ldap::getFilterListElement filterList] 
          puts "filter: $filter"
          return [list [parseFilter ($filter)] {*}[parseFilterList $filterList]]
     }
  }

  proc ldap::getFilterListElement {filterListVar} {
     upvar 1 $filterListVar filterList
     set depth 0
     set item {}
     while 1 {
        set char [string index $filterList 0] 
        puts $char
        switch -- $char {
             (   {incr depth}
             )   {incr depth -1}
        }
        append item $char
        puts $item
        set filterList [string range $filterList 1 end]
        if {$depth == 0} {return [string range $item 1 end-1]}
        if {[string length $filterList] == 0} { error "missing ')' brace" }
     }
  }


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

  Note that an even easier (complemetary) solution would be to use Tcl variables for binary data so one could write:

  set data (())))
  set query {(GUID=$data)}


login: sbron
username: sbron
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37987
  Originator: YES

  The contents of the history pane stops after the second line of these lines taken from the history in the main tkchat window:

  [03:23]<[Azbo]>test
  [03:24]<}>test2
  [03:24]<µ>3


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

  This is caused by the text widget cloning code using [append] to build strings when it should be using lists.
  Fixed in version 1.424


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



  File Added - 260327: poisson.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

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

  This code is more explicit about the tests.

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

  Eric

  File Added: poisson.zip


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

  This seems to be a http package issue. See tcl bug #1818565


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260283: simpletest.tcl

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: simpletest.tcl


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260287: invchisqr.tcl

  Logged In: YES 
  user_id=816411
  Originator: YES

  Hello,

  I'm adding to this an implementation of the inverse cumulative chi-squared distribution, since that's needed for statistical inference. It's a straightforward implementation of root solving. It turned out to be a little "touchy", but I think I've covered enough extreme cases that I can be pretty sure it will behave robustly.

  This has "source chisqr.tcl" at the top of the file and runs the tests at the bottom of the file, but it could really be put directly into the "chisqr.tcl" file.

  Eric

  File Added: invchisqr.tcl


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260314: invchisqr.tcl

  Logged In: YES 
  user_id=816411
  Originator: YES

  This is an improved inverse chi-square. More robust than the original. Also tested to tolerance of 1.0e-9 against R output.
  File Added: invchisqr.tcl


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260323: invchisqr.tcl

  Logged In: YES 
  user_id=816411
  Originator: YES

  OK, last fix to inverse chi-squared -- now catches when p = 1.0 (so return value should be infinity).
  File Added: invchisqr.tcl


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 260432: patch.diffs

  Logged In: YES 
  user_id=81875
  Originator: YES

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


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

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


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



  File Added - 260358: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


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



  File Added - 260368: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  I'm attaching a version of the incomplete beta function that is significantly faster (about 10 faster for some values) than the original version I posted.
  File Added: beta.zip


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



  File Added - 260370: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260371: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


login: erickb
username: erickb
mimetype: text/plain
icomment:
  File Added - 260396: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  Attaching a new version. Fixes an edge case that can make the routine hang. Also introduces a short-cut in case of integer value for b.
  File Added: beta.zip


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



  File Added - 260397: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


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



  File Added - 260416: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


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



  File Added - 260418: beta.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

  File Added: beta.zip


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

  Logged In: YES 
  user_id=816411
  Originator: YES

  This is a better implementation for the beta distribution. First, I extended the useful range for the pdf. Second, I implemented a much faster algorithm for the incomplete beta function, using a continued fraction from Abramowitz & Stegun. (I used the GNU Scientific Library for inspiration, but ended up using a different continued fraction expansion than they used, so there's no GPL concern here. The speeds are comparable.)
  File Added: beta.zip


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

  Incorporated this. One thing to think about:

  pdf-beta a b 0.0 or 1.0 are edge cases that should give either 0 or infinity (depending on a and b).

  Right now, they give 0 only.


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

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


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

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

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


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



  File Added - 261269: tdist.zip

  Logged In: YES 
  user_id=816411
  Originator: YES

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


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

  Logged In: YES 
  user_id=816411
  Originator: YES

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


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

  I guess your camera likes to record a MaxAperture of 0. fixed in version 0.3.2


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

  Its probably not a good idea to mask an error (and feeding junk into the decoder is clearly an error) by simply returning an empty string.  


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

  You have [catch] for dealing with errors raised. Garbage in should be considered an error. 


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

  Very likely.
  What version of snit was this ?
  IIRC Will made some changes to the option command and I might use the newer features.


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

  Made the dependency more strict, now requesting snit 1.3 or higher (incl. v2+, if using Tcl 8.5).


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

  Thanks for pointing this out - I will repair it asap


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

  Done - the pkgIndex.tcl file in the CVS repository now lists Plotchart as 1.4.0 


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

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


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

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

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


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

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

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

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

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


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


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

  What's going on here is that the 8.5 [clock] command is implemented in
  Tcl, A number of procedures, including ::tcl::clock::format (the guts
  of [clock format] are created at run time. The fact that the $compiler
  interpreter in Comp.Init overlaods ::proc and ::variable means that
  the Tcl code inside [clock] cannot function normally.

  A workaround - perhaps a fix, but I don't claim to understand what
  the compiler is actually doing - is to add the line:

  $compiler alias clock ::clock

  to the set of compilation aliases.  This will cause all [clock]
  commands to be evaluated in the master interp, obviating the need
  to run [clock]'s Tcl code in the slave. This at least got the original
  poster over the fault in initialization.

  I would anticipate the same sort of trouble if commands such
  as [msgcat::*], [package], [auto_load] or [parray] were to be 
  evaluated in the $compiler interp, since they, too, are implemented
  in Tcl and use [proc] and [variable].

  Any thoughts?


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

  This strikes me as being *not* a Snit bug, but a bug in the new implementation of "clock", etc.  Standard Tcl commands, it seems to me, should function normally in any interp, unless excluded for reasons of safety.  At the very least, they should be fully defined in a new interp *before* the interp's user starts changing things, rather than being defined lazily.

  I'm certainly willing to add a fix for this in Snit if it's determined that that's the right thing to do...but I'm not at all sure that it is.


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

  I don't think I can do what you're asking.

  [clock scan] and [clock format] both work by compiling new 
  Tcl code (defining a proc) every time a new format string is 
  encountered.  They rather depend on ::proc being there to do
  so. (And they suffer dreadfully in performance if they can't
  compile code.)

  Also, Snit overloads ::variable, and nearly every procedure
  in the [clock] implementation begins with one or more
  [variable] commands.  I don't really see how to avoid that
  one without using fully qualified variable names everywhere
  and eschewing [variable] entirely. Are you looking to inflict
  that level of unreadability on core code so that you can
  overload ::variable?

  I suspect that what you're really saying here is that you find it
  unacceptable that every Core command doesn't stand entirely
  alone -- that some of the Core is written in Tcl, so depends
  on other pieces of Tcl being there.  If you consider it a bug
  that not all Core commands are written in C, please bring that
  up on tcl-core, because we're moving more and more to
  using Tcl for at least some non-critical things.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  File Added - 265076: namespace-snit.diff

  Logged In: YES 
  user_id=72656
  Originator: NO

  While not necessarily a short-term solution for this, turning the snit compiler into a fully namespace-encapsulated solution for 8.5 seems possible.

  It would really depend on what level of importance independent namespacing has for snit.  Most of the code I see doesn't rely on that.

  I just created the following patch that is a first pass at this.  It runs our TclApp, VFSE and Inspector from TDK locally with only one change (where we had ::typevariable used in the snit body).  I of course don't have full tests for this, so it would need further vetting.

  It is built so you can switch the modes (from namespace to interp) at 1 point.

  File Added: namespace-snit.diff


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  File Added - 265077: namespace-snit.diff

  Logged In: YES 
  user_id=72656
  Originator: NO

  Updated my patch to correct one.
  File Added: namespace-snit.diff


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  File Deleted - 265077: 



  File Added - 265078: namespace-snit.diff

  Logged In: YES 
  user_id=72656
  Originator: NO

  Update to one that still works with interp method
  File Added: namespace-snit.diff


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

  Sorry, Kevin, I don't mean to be difficult.  It wasn't clear how you were using proc--I assumed it was just how the code was loaded, rather than being part of a scheme to compile code dynamically.  To the extent the core commands place serious restrictions on what you can do with an interpreter without breaking them, those constraints need to be clearly documented.  Are they?

  Jeff, I don't understand what you mean by "turning the snit compiler into a fully namespace-encapsulated solution for 8.5" and "independent namespacing".  Are you using a namespace *instead* of an interpreter?  Or putting the Snit compilation commands into a namespace *within* the current slave interpreter?  I'd like some better notion of what you're doing before I dive into your code.


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

  The patch should be rather self-explanatory.  It does all the snit stuff in the same interp in ::snit::compiler instead of in a separate interp.  This has benefits and disadvantages, but I think that the benefits may outweigh in the long run.


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

  By the way, the way that [clock] command is evaluated in the 
  slave strikes me as a trifle strange.

  I see:

  snit::widgetadaptor sframe {
      option -foo [clock format [clock seconds] -format %Y]
      constructor args {installhull using frame}
  }

  How does that differ in principle from

  proc foo {} {return bar}
  snit::widgetadaptor sframe {
      option -foo [foo]
      constructor args {installhull using frame}
  }

  The second case fails with

  invalid command name "foo"

  because, of course, [foo] exists in the master interp and not the
  compiler interp.

  In short, it's arguably the widgetadaptor definition that's making 
  the mistake (evaluating arbitrary Tcl code inside the compiler interp) 
  rather than Snit. Is it actually reasonable to expect arbitrary Tcl
  code to work there?


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

  For what it's worth, the list of core commands on which [clock] 
  depends is fairly long (unsurprising for a large module coded in
  Tcl).  I don't want to guarantee that the list will never expand,
  but I attach the current known dependencies. (On Windows systems,
  there is also a dependency on 'registry', not shown here.)
  File Added: commandlist


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

  Thanks, Jeff.  That does make sense, as it means global scope commands can also be available.  I'll take a look at it.

  Kevin, you're right, it's an odd place to call "clock".  I imagine it was intended to set a default option value to a timestamp, which (on the other hand) is a reasonable thing to do.  So it really ought to work.


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

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


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

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


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

  Logged In: YES 
  user_id=302287
  Originator: YES

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

  File Added: Registry


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

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


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

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

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


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

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


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

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


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

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


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  moved the destroy command to the per-connection section of the manual. this is consistent with the code.


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

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


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

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


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

  What platform and version of Tcl was this? 

  I tested it on Windows XP with ActiveTcl 8.5.0 - and the math module passed all tests.

  matchNumbers actually tests up to seven decimals (0.1e-6), but it still does not fail.

  The difference between the numbers is:
  0.707107 - 0.70710678118654757 = 0.22e-6 

  So the failure seems justified - hm, why doesn't it fail on Windows XP then?

  I will need to investigate further, but I am still interested in your platform


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

  Ok, the original system it failed in this manner was a plain Linux/Intel (32bit) box.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Actually no. On the boxes where I have tested tcllib I haven't seen any errors in math except for the beta-distribution thing which I reported a few days ago and you have already corrected. I guess that we can close this as 'out of date' or 'invalid'.


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

  Logged In: YES 
  user_id=1852298
  Originator: YES

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


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

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


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

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

  And egavilan confirms on the Tcler's chat:

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


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

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

  This looks to be a bug.

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

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

      ::struct::set size $myset

  Note the $

  Ditto for the 'empty' method.


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

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

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


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

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


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

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


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

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


login: juliannoble
username: juliannoble
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=598324
  Originator: YES

  Further testing indicates it's the result of a difference in the length of output from md5::md5

  -------------------------
  C:\Users\Administrator>tclsh
  % package require tcllibc
  can't find package tcllibc
  % package require md5
  2.0.5
  % md5::md5 {a$apr1$a}
  ☻♀=?▼~?ì?▼NLS
  -------------------------
  c:\home\Administrator>tclsh
  % package require tcllibc
  0.3.2
  % package require md5
  2.0.5
  % md5::md5 {a$apr1$a}
  ☻♀=Ö?▼~?ìÉ?▼NLSâ
  --------------------------


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

  I cannot reproduce this fault using 8.5.15 or 8.5.2. The md5 module has a fairly extensive set of test vectors and I've added the "a\$apr1\$a" string to the test suite but I find that it passes with all the available accelerated and pure-Tcl implementations.

  C:\opt\tcl\src\tcllib\modules\md5>tclsh
  % package require md5crypt
  1.0.0
  % md5crypt::aprcrypt a c
  $apr1$c$wkeW9CQT8XlL.qu2CHHbm/
  % set md5::accel(critcl) 0
  0
  % array get md5::accel
  trf 0 critcl 0 cryptkit 0
  % md5crypt::aprcrypt a c
  $apr1$c$wkeW9CQT8XlL.qu2CHHbm/
  %
  % md5::md5 {a$apr1$a}   ;# pure-Tcl
  ☻♀=Ö?▼~?ìÉ?▼NLSâ
  % md5::md5c {a$apr1$a} ;# critcl implementation
  ☻♀=Ö?▼~?ìÉ?▼NLSâ
  %


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

  Quick note that the different log-levels were/are intended to be this type suppression-levels.

  You seem to interpret them more as categories of messages, and wish to have an additional argument denoting what I would call the 'priority' of the message inside of its category.

  Do I understand that right ?

  If yes, then me asking you to look at the 'logger' package (same module of Tcllib) is superfluous, as it has the same type of categorization, and no priorities. What it does have is the ability to create multiple independent loggers (actually a tree), which allows us to give each package its own logger, with independent suppression of categories.

  Interestingly enough, when I worked on the cvs2fossil application (*) I did not use 'log', nor 'logger', but wrote a new system with exactly that kind of priority based system you seem to look for. It had no multiple loggers however, and no categories either. But it also made sure that code in leog messages was executed only if the message was actually to be printed.

  It might be interesting to take this RFE and merge it into logger, to get a system having all of multiple loggers, categories, and priorities.

  I am reassigning to Michael Schlenk, as he is the maintainer of 'logger', as I wish to get his opinion on this as well.


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

  Logger could do such additional suppression levels in a hackish way, by defining subloggers with numerical names, it would just need some syntax sugar to make it nicer.

  Simply changing the signature of the logging function to ${log}::<level> suppLevel msg would have the bad side effect that disabled suppression levels would still eat runtime when disabled.

  Its basically a decision how to setup your logging subsystem, the more simple log package doesn't allow you to create fancy output/suppression schemes, while loggger allows it with some tinkering.

  So yes, i think this RFE is a good idea and could be done with the current logger code with just small compatible changes.

  Michael


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

  I should note that IMHO this type of enhancement may warrant a change of the major version number, and this would allow us to complete redesign the API as we see fit. no hacks would be needed as we would be able to redesign everything from the ground up.

  Of course, if compatible changes allow us to support this we could go that route.

  OTOH, IIRC we have some other RFE for logger currently done hackish, maybe it is time for a redo. I do not remember what this change was/is/might be.


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

  Yes. There are more things in logger that could improve (e.g. the logger proc signature and some others) and a lot of the internals could be done nicer.

  I think it would also be good to unify to just one logging package and not two or even more.


login: mocallins
username: mocallins
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=931198
  Originator: YES

  Yes Andries, for sake of discussion I called them categories, simply because I wanted to refer to the suppression as a "level", but "priority" is just as accurate. 
  I did look at logger and just as you referenced it didn't provide a "priority"/"level" as well.

  Excellent to see that it wasn't just me thinking that we needed some enhancements.


login: petasis
username: petasis
mimetype: text/plain
icomment:
  File Added - 271523: test.tcl

  Logged In: YES 
  user_id=92283
  Originator: YES

  Please run the test.tcl script, to reproduce the problem. The file abox_graph_struct.txt must exist in the same directory.
  File Added: test.tcl


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

  I can confirm a crash in a tcl_panic in tcllibc.so giving the message 'array index out of bounds'. Is that the crash you are talking about?


login: petasis
username: petasis
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=92283
  Originator: YES

  Yes, this is the error message I have received. I am sorry I have forgotten to add it to the bug report.


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

  Aha. We have 2795 parallel arcs from node x to node y. Total number of nodes 26. The check I used to filter out duplicate result nodes is wrong, causing the filter to try and stuff all arcs into the result, way over the max of 26, so it it bombs in my assert. Yay defensive asserts otherwise this would have not been that easy to find. ... The filtering for -in is bad in the same manner. Fixing both makes the test script run fine. I am guessing that when I copied things from arc filtering to node filtering the adaption was not done right/fully.

  Ok, making test cases for this is easy.


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

  Fixed in head, with testcases. Reviewed the other filters, and they were ok.


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

  Confirmed the inconsistency.
  I see the same doc error in the code itself.
  Now fixed in the CVS head.


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

  The handling of hierarchical methods changed slightly between Snit 1.x and Snit 2.x, which explains why the error messages differ.  In each case, though, to delegate hierarchical methods you need to do something like this:

      delegate method {is *} to foo


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

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


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

  Logged In: YES 
  user_id=2072360
  Originator: YES

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


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



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

  Logged In: YES 
  user_id=2072360
  Originator: YES

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


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



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

  Logged In: YES 
  user_id=2072360
  Originator: YES

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

  File Added: yaml-0.2.1.tar.gz


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

  Logged In: YES 
  user_id=2072360
  Originator: YES

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

  File Added: yaml-0.2.2.tar.gz


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

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

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


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

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


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

  Thanks. Fix committed to CVS head. Version bumped to 0.3.1.


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

  The math::bigfloat::todouble procedure made use of tcl_precision to compute the number of significant digits.
  It used to be 12 or more in Tcl 8.4, but Tcl 8.5 made it invalid and defaults to 0, which I knew.
  I simply added a test to make use of 16 when tcl_precision is 0, and it will work fine.


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

  I am not able to confirm that. With the patch applied the testcase mime-3.7 in mime.test hangs and strategic output reveals that it is stuck in the infinite loop you wish to avoid.

  What operating system are you on ?
  Maybe that makes the difference between your non-loop and my oo-loop.
  I tried this on Linux.


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

  Meh. Retracting my statement. The mime-3.7 test case is bad in itself. mime-3.8 is a testcase for the same problem and doesn't run into the infinite loop with patch applied. In mime-3.7 the 'badmail1.txt' the given boundary is the terminating boundary, however it is not recognized because the parser newer saw an initial boundary. The patch now faking a terminating boundary cannot help there, its fake boundary will not be recognized either, hence the infinite loop.

  I think I may try to fake a bit more, i.e. set inP as if we had seen an initial boundary.


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

  The 'meaningful' variable 'x' comes from (IIRC), i.e. blame me. Should be 'linelength' or some such.

  2007-11-05  Andreas Kupries  <andreask@activestate.com>

  * mime.tcl (::mime::parsepart): Fixed [SF Tcllib Bug 1825092],
  * mime.test: as reported by Max Strobel
  * pkgIndex.tcl: <mstrhh@users.sourceforge.net>. The code parsing
  * mime.man: multiparts assumed that eol sequences are always two
    characters (cr+lf), this however may not be the case. This
    caused the parser to miscount the last line in a part and
    wrongly remove its last character from the part. Extended the
    testsuite, and bumped the version to 1.5.3.

  Attaching the patch I have sitting in my sandbox. I am not fully satisfied with it. While it avoids the loop some of the commentary in 631314 seems to indicate that I should also munge the mime-type of the new part, i.e. force application/octet-stream, whatever the headers claimed for it.

  The necessary updates to the testsuite are missing as well, however that it is more or less a formality.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 277826: mime-1961881-a.patch

  Logged In: YES 
  user_id=75003
  Originator: NO

  Updated the patch in my sandbox.
  Moved handling of missing starting boundary around.
  Added forcing to app/octstream and handled possibility that part is broken beyond parsability.

  File Added: mime-1961881-a.patch


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

  Accepted my updated patch. CVS head is now mime 1.5.4.


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

  Okay, I will look into this - it should be easy to fix :)


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

  I have corrected the man page. Thanks for noticing this


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  i dont believe the first 2 lines are needed since the example is static html, not ncgi output. I have fixed the ncgi::value call not matching the html name.


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

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

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

  Would that serve?


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

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

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

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

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

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

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


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

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

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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 278581: base64-tcllib-1-10.patch

  Logged In: YES 
  user_id=75003
  Originator: YES

  Original submitter of patch is gustaf neuman.

  File Added: base64-tcllib-1-10.patch


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

  An example script was submitted, but cannot be attached here, SF rejects it as too large even when max compressed (bzip2).


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

  Notes from further correspondence.
  (1) We can special maxlen 76 with different wrapchar, that case allows full-speed string map
  (2) RFC 2045, RFC 3548 section 2.1 state that MIME uses 76 by default, the 60 char default in tcllib is non-optimal.

  => Change default maxlen to 76 per mime.
  (4) As wrapchar default is \n this change will cause us to hit the zero-time special case (no reflow needed at all) most of the time, and for the remainder we get fast linear-time algorithms with this patch and per (1). No square-time at all.


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

  Negative -maxlen values ...
  Tcl implementation => The wrapchar sequence is added after _every_ regular coding character.
  Trf => The Reflow algorithm (current) will enter an infinite loop (string length can be reduced to at most 0, and will always be > maxlen, causing the loop to not terminate). The generated result will further not contain anything from the regular output, but only wrapchars. The commands extracting the regular result will return the empty string.

  The new reflow algorithm will not loop indefinitely, howver the result will be as bogus as before, only wrapchars, and nothing else.

  Definitely has to be checked. maxlen 0 is already bad. maxlen 1 is the smallest value we can work with.


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

  Ah, maxlen 0 is special, it means: Do not wrap at all. ... The new reflow code should special case that, the loop can be skipped entirely, only 'string map' to remove \n is needed.


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

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

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

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


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

  modified these "switch"es.

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


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

  Sample code again:

  # -----------------
  # working sample
  % set bb [huddle create a b c d] ; # create as a dict
  HUDDLE {d {a b c d}}
  % set cc [huddle create e f g h]
  HUDDLE {d {e f g h}}
  % set bbcc [huddle create bb $bb cc $cc]
  HUDDLE {D {bb {d {a b c d}} cc {d {e f g h}}}}
  % set folding [huddle list $bbcc p [huddle list q r] s] ; # create as a list
  HUDDLE {L {{D {bb {d {a b c d}} cc {d {e f g h}}}} {s p} {l {q r}} {s s}}}
  % huddle strip $folding ; # normal Tcl's notation
  {bb {a b c d} cc {e f g h}} p {q r} s
  % huddle jsondump $folding ; # dump as a JSON stream
  [
    {
      "bb": {
        "a": "b",
        "c": "d"
      },
      "cc": {
        "e": "f",
        "g": "h"
      }
    },
    "p",
    [
      "q",
      "r"
    ],
    "s"
  ]


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

  It took me while to understand the description.
  Well, I believe that I understand it now.
  So let me try to describe it in my own words.

  (1) Huddle provides a generic Tcl-based serialization format
  (2) The entries in that format are tagged with simple type information
  (3) The currently the known types are 'L' for list, and 'D' for dict.
  (3a) There are also 'l' and 'd', these I do not understand yet.
  (4) When converting huddle-notation to other serialization formats like
      JSON or YAML this type information is used to select the proper notation.
  (5) And when going from JSON/YAML/... to huddle their notation can be used to
      select the proper huddle type.
  (6) In that manner huddle can serve as a common intermediary format.
  (7) The nice thing about its notation that Tcl can read this format directly
      (list/dict commands) without the need for a special parser.

  Side note: Origin seems to be http://wiki.tcl.tk/21116


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

  Thank you for the kind description.
  That's right.

  Huddle provides a generic Tcl-based serialization/intermediary format.
  Currently, each node is wrapped in a tag with simple type information.

  huddle-format: >
    {HUDDLE {tag {huddle-node}}
  huddle-node: >
    {tag {huddle-node(content)}}
  each tag means:
    s: (content is a) string
    l: Tcl's list, each node is a string
    d: Tcl's dict, each node is a string
    L: list, each node is a huddle-node
    D: dict, each node is a huddle-node
  confirmed:
    - JSON
    - YAML(generally, but cannot discribe YAML-tags)
  limitation:
    - cannot discribe the aliase from a node to other node.


  I want to use the format/library for serializing to YAML/JSON streams.


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  File Added - 279039: huddle-0.1.1.tar.gz

  Logged In: YES 
  user_id=2072360
  Originator: YES

  supported for adding user-type/tag.
  removed simple container tags ("l", "d")
  add command "huddle set"
  add command "huddle remove"

  File Added: huddle-0.1.1.tar.gz


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  File Added - 279694: huddle-0.1.2.tar.gz

  Logged In: YES 
  user_id=2072360
  Originator: YES

  - add command "huddle combine"
  - add command "huddle equal"
  - add command "huddle append"
  - support inheritance for type-callbacks.

  I want to append the library to Tcllib.
  I already have replaced codes in the yaml-lib.(but not committed)

  Although I am going to put on the same directory as yaml-lib, may I commit for a while?
  File Added: huddle-0.1.2.tar.gz


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

  It uses in the yaml library now.
  It is in the same directory.


login: nicolascastagne
username: nicolascastagne
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1258423
  Originator: YES

  Note : I did not put any "category", since though I found the pb with the math package, I guess it is perhaps more general in tcllib.


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

  Safe base means that a number of commands are not allowed, and not provided. pwd and file are among them.
  math uses pwd and file to set up old-style lazy auto-loading of procedures.

  To use math in the safe base you have to reconfigure it, i.e. make pwd and file available, maybe in restricted form.
  Or the package has to be rewritten to not use auto-loading of its pieces.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I have tried a SafeBase interpreter - it works for a package like math::statistics, but it fails for math itself. The error message is uninformative: script error.

  This needs some further investigation


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Note the following in the original description
  > LOG: {ERROR for slave interp0 : invalid command name "pwd"} 
  pwd is a forbidden command in a safe interp.

  The problem is likely

  math.tcl:36:    variable home [file join [pwd] [file dirname [info script]]]

  and later

      if {[lsearch -exact $::auto_path $home] == -1} {
          lappend ::auto_path $home

  I am not sure why this extension of the auto-load path is required.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I tried to solve this by avoiding auto_path and auto_load for safe interpreters and simply
  sourcing the files. This does not work either. My suspicion is that [info script] does not
  return a valid file name, but I still have to check that - puts is not very helpful in safe
  interpreters, I probably have to alias it.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I got this one solved - sn error in my test case, rather than something very weird in the package management. As the repository is read-only at the moment, I include the changes 
  and the test case here:

  -- math.test --
  test math-12.1 {Safe Interpreter} {
      #interp create -safe safeInterp
      ::safe::interpCreate safeInterp
      interp alias safeInterp puts {} puts
      set result [interp eval safeInterp {
          package require math
          set result [math::cov 100 100 100 -100]
      }]
  } 200.0
  ----

  -- math.tcl --
      # Set up for auto-loading

      if { ![interp issafe {}]} {
          variable home [file join [pwd] [file dirname [info script]]]
          if {[lsearch -exact $::auto_path $home] == -1} {
     lappend ::auto_path $home
          }
      } else {
          source [join [lreplace [split [info script] /] end end misc.tcl] /]
          source [join [lreplace [split [info script] /] end end combinatorics.tcl] /]
      }


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

  I am accepting this with some modifications. Replaced the join/lreplace/split with file join/dirname. The only command which made trouble was [pwd], not the path manipulation commands. I.e. no reason to drop them as well. The use of / as path separator is also not robust, i.e. portable. On windows it might quite well be \.

  Tweak to the testcase: Destruction of the interpreter after we are done with it.

  Another tweak to math.tcl, when I am done with the release: Make the whole thing unconditional. No need to distinguish plain and safe interps, just have plain source their files as the safe will do, i.e. directly, not lazy.

  Committed to head, version 1.2.5.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  FWIW, I see troubles with test math-12.1.
  Several messages about inability to read
  paths ending in pkgIndex.tcl.  One of the
  testing interps is the release of 8.5.8, so I
  suspect this is really a problem in the math
  package (code or test).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok. Per talk with dgp on the chat based on his continued investigastions this seems to be a problem in Tcl's package.tcl file. See

  https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2910867&group_id=10894


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

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


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

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

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


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

  Well, it seems as if the exact fomrat of the stack trace changed in 8.6.
  The 'if ...' command seems to have been removed from it.
  This should require only updating of the testsuite.
  Very low priority.
  May be defered until at least 8.6b1 is out, i.e. when things are less in flux.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Recent work on struct::tree and its testsuite may have fixed this.

  See ChangeLog entry:


  2008-09-02  Andreas Kupries  <andreas_kupries@users.sourceforge.net>

  * tree.testsuite: Updated tests based on walk error stack traces
    to handle new differences between 8.4 and 8.5.

  * tree.testsuite.4417b84.txt: Moved the stacktraces to separate files
  * tree.testsuite.4417=84tcl.txt: for better readability of both the
  * tree.testsuite.4417a84tcl.txt: traces and the test using it.
  * tree.testsuite.4417a83critcl.txt:

  Please recheck. If it is not fixed it should however now be easy to add the proper stacktrace, now that the various forms are stored in their own files.


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

  Thanks. Committed the fix to the CVS head. Bumped package version to 2.0.7.


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

  Quick glance, the README looks to be outdated a bit (with regard to {expand} at least).
  One thing we can quibble with is the dependency on 'xml' aka TclXML.
  I would be more comfortable with a dependency on tDOM. Not a blocker however.
  Dependency on Tcl 8.5 is ok. Jeff's JSON package is nearly as well.
  The testsuites needs a bit of boilerplate to fit into Tcllib's framework.
  Have it in my sandbox now, will work on the integraton over the next days.
  Right now my first/only change was to convert it from DOS to unix EOL convention.


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

  Added the physical files to Tcllib.
  Modified the testsuites to have Tcllib's boiler plate.
  Added module to the installer.
  Notes...
  - The docs convert without error.
  - The testsuite has errors for me
  -- xsxp : I am guessing that this is due to differences in the xml package loaded (I have TclXML 2.6, and it is using the expat parser I think).
  -- S3loadkeys fails for me. Apparently the code assumes that S3-test.config is in the current working directory. Bad for tests, Tcllib runs them from the toplevel directory, and not the module directory.


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

  You are clobbering the built-in label command with the one from tile. A ttk::label has no option "-highlightthickness". Remove the "namespace import -force ttk::*" and it will work.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Yes, the namespace import ttk::* will break more than just tooltip, and is considered a non-portable operation now.


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

  Agreed, the package does 'creative writing' :(
  Fix is correct as well, and has been applied.
  The package version gas been bumped to 1.3.1.


login: flatworm
username: flatworm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1350198
  Originator: YES

  After reading bug 1178045 I fear I might overuse conversion to LDAPString in my code. Let me check and re-upload the fixed patch.


login: flatworm
username: flatworm
mimetype: text/plain
icomment:
  File Added - 284706: ldap.diff

  Logged In: YES 
  user_id=1350198
  Originator: YES

  Attached an updated patch with the logic regarding encoding of attribute descriptions and assertion values made more consistent on the source level.

  Also added more tests, comments made more clear and some procs renamed to better mirror their purpose.
  File Added: ldap.diff


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

  Accepted the patch with some minor changes to the test suit organisation.


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

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


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

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


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

  The value reported by GNU C is in agreement with Abramowitz and Stegun, so
  it seems reasonable to take that as a benchmark. The actual computation in Tcllib 
  is done via the TOMS-322 algorithm. I am not sure what the accuracy is of that 
  algorithm, but I will check this.


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

  Solved this: replaced the original algorithm by one due to George Marsaglia.
  It is more accurate and simpler (but less general, as the TOMS algorithm
  covers several statistical functions). Version for the package: 0.2.2


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

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


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

  Accepted the reasoning, extended set of named entities with apos.
  Committed to CVS head.
  This is now version 1.1.3.


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

  This was handled by having a header added by the website that returns a list of current bridge names. This is requested when you first login and fetches the current tkchat version and the lolcatz message and so on.


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=317958
  Originator: NO

  Since there is no -disabledbackground option for tablelist widgets, a disabled tablelist uses the normal background color at widget, column, row, and cell levels.  This is implemented with the aid of a text widget tag.  Under some circumstances, parts of the body text widget might lose this tag, thus giving rise to the erroneous behavior reported by Ralf.

  I have checked in a corrected version of the distribution file tablelistUtil.tcl.  This should fix the bug.


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

  Committed a fix to the CVS head. Package version 0.6.1.


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

  Commiitted a fix to CVS head. Package version 2.4.9.


login: sbron
username: sbron
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=37987
  Originator: YES

  Another race condition happened after switching to passive mode in an attempt to avoid the problem mentioned here. In that case the ftp package frequently throws an uncatchable error if the file does not exist:

  can't read "ftp(Start_Time)": no such variable
      while executing
  "if {$ftp(Start_Time) == -1} {
          set ftp(Start_Time) [clock seconds]
      }"
      (procedure "::ftp::HandleVar" line 5)
      invoked from within
  "::ftp::HandleVar 0 sock24"

  This happens when the control connection is closed, which cleans up the ftp array, before the data connection is closed. Then when the event handler for the data connection fires due to an eof situation it tries to access ftp(Start_Time), which no longer exists.

  It looks like some kind of mechanism is needed that can wait for certain events on the data connection before proceeding.


login: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  File Added - 289329: ctext.test

  Logged In: YES 
  user_id=1573661
  Originator: YES

  File Added: ctext.test


login: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  File Added - 289330: ctext.tcl

  Logged In: YES 
  user_id=1573661
  Originator: YES

  File Added: ctext.tcl


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

  I fixed this bug in the tcllib/tklib HEAD.  ctext is now at revision 3.2.  I used ctext::getAr and added 3 keys to the array used for storing information about ctext's per-widget state.

  So now this should all be handled by 3 catch {after cancel $configAr(...)}

  Please let me know if you experience further problems.

  Thank you for the unit test as well.  I'll have to see about getting that integrated.


login: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1573661
  Originator: YES

  Thank you for that bug fix.
  By the way, thank you for ctext !

  The suggested unit tests are the smallest possible amount of testing for the ctext package, that is : create/destroy. More tests (even if interactive) are available in the ctext_test*.tcl currently provided in the repository. Moreover, the tests are more testing the undo feature of the Tk text itself : this is because I discovered a bug in the Tk text, but I previously thought that it was a bug in ctext (I was wrong). The test ctext-1.2 is currently failing because of that bug (may be it is fixed in 8.5).

  I have one last question about the feature. Why exactly to delay the highlight after the insertion has been done ? Does that allow an improvment of the interactivity ? What kind of events may be to process between the insertion and the highlight ?


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

  Maybe duplicate existing underscores to quote them ?

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


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

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

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


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

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

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

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

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

      return [string map $subs $name]
  }

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


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

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


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

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

  What I'd like is a solution that:

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

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

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

     Snit_hmethod_4_a_b_c
     Snit_hmethod_5_a_b_c

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

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


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

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

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

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

  Now lets try this

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

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

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

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

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

  It looks relatively readable as well.


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

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


login: relaxmike
username: relaxmike
mimetype: text/plain
icomment:
  File Added - 291284: cursor.tcl

  Logged In: YES 
  user_id=1573661
  Originator: YES

  File Added: cursor.tcl


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

  for the missing variable the code would seem to preclude this error:

      variable RES
      set file [file normalize $file]
      FindResources $file
      if {![info exists RES($file,group,$name,members)]} { return -code error "no icon \"$name\"" }


  for the 3 element list or vista icon please reopen this bug or a new one and attach files which demonstrate the problems. this bug was submitted anonymously so I have no one to contact for more information. thanks


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

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

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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Added guard commands to the read2 and split2 procedures, extended testsuite. Bumped to version 0.7.1. Committed to head.


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

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

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


login: twylite
username: twylite
mimetype: text/plain
icomment:
  Upped the priority -- the implementation currently does not pass the NIST test suite for the AES algorithm.


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  As reported by Helmut both in private mail and on c.l.t., the bug was in his code, not in Tablelist.  The widget .__helpLabel, created by Tablelist, was destroyed by his script.


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Per the Changelog and commit messages this was fixed Aug 13, 2008 by Michael Schlenker.
  The relevant version of nameserv is 0.4.1.
  This version is available in the recently released Tcllib 1.11, through ActiveState's TEApot repository (You need the teacup application from ActiveState's ActiveYTcl distribution to access the repository), or by checking out the CVS head of Tcllib.


login: vonbane
username: vonbane
mimetype: text/plain
icomment:
  I was using 0.4.1 from the Activestate teapot.  I just looked in CVS and the "0" condition of the switch statement does not set oneshot.  I'm not good with cvs to see what was changed between 1.7 and 1.8 of nns.tcl but this problem was not fixed.

  Can you please look at this again?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ad 1. Cloning is essentially a serialize+deserialize operation. Using snit introspection it should be possible to automate basic support for this, maybe even in a snit::macro. Note, this implies that currently there is no such support in snit, AFAIK. Now further, if the object to clone is more complex, like using timers, sockets, files, i.e. any type of state which is not stored directly in the object, the basic clone will not be enough. For these cloning will need custom written support code which handles all the complex parts.

  Ad 1. The struct::{graph,tree} structures in Tcllib, while not based on snit, contain '(de)serialize' methods, fully custom written, and assignment/copy methods on top, even with support for copy during construction.

  Ad 2. No idea, defering to Will for that.

  Ad 3. No idea, defering to Will for that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Looking this over it seems that this is caused by the latest changes to the semantics of lassign/lrepeat in 8.6 ... TIP 323 (Do Nothing Gracefully) - http://tip.tcl.tk/323

  Background: Tcllib provides its own implementations if and only if the commands are not provided by the core. This means that for 8.5 and 8.6 these test check the behaviour of the core command, and not Tcllib's implementation.

  A question is, should Tcllib's implementation follow 8.6's lead ?
  Right now we have Tcllib code behaving identical for 8.4/8.5, but not 8.6
  If we follow 8.6's lead it would behave identical for 8.4/8.6, but not 8.5.

  IMHO we should stay with 8.5 behaviour. That way transition is easier. If you use 8.6isms do not expect it to work for 8.5 or 8.4+tcllib.

  So, the main alternative would be to disable these tests for 8.6, knowing that they test the core command and not Tcllib. With that reasoning disabling testing for 8.5 might make sense as well, despite currently behaving identical.


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

  Eric Melski
  The Other Tcl Guy
  ericm at interwoven.com


login: ericm
username: ericm
mimetype: text/plain
icomment:
  I replaced the aclocal.m4 file with tcl.m4 from the former config module, so
  the config directory is not requird.  This is not the best solution probably, but it will do for now.  A better solution would be to figure out how to make
  all the Tcl packages on SF reference the config module, just as they did
  when they all lived at Scriptics CVS.

  Eric Melski
  The Other Tcl Guy
  ericm at interwoven.com


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

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

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

  ....

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


login: redman
username: redman
mimetype: text/plain
icomment:
  'string equal' is not provided prior to 8.2, I'm going to use this instead:

  [string trimright $line] == "." 

  Now if only the CVS server would let me commit the files, this would be fixed.


login: redman
username: redman
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=106931

  Andreas Kupries reminded me that I hadn't checked this in...and so I tried and cvs on sourceforge seems
  to be working again.  Should be fixed now.


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

  One possible fix: Add '-disabledforeground' to the tkinclude
  'remove' list
  in entry.tcl:

      Widget::tkinclude Entry entry :cmd \
              remove [list -state -cursor -foreground
  -textvariable -disabledforeground]

  This avoids the problem under Tk 8.4, and is a no-op under
  earlier Tk versions.

  Probably not an ideal fix -- does anyone have any better
  ideas?

  Is it OK if I commit this change?


login: stevel
username: stevel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=2460

  jenglish asked
  > Probably not an ideal fix -- does anyone have any better
  > ideas?

  Not necessarily better, but I submitted a patch last year
  that fixes the problem. 

  See [ #402776 ] BWidget: support for Tk8.4 entry -state.


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


  Re: patch [ #402776 ] BWidget: support for Tk8.4 entry
  -state --

  am taking a closer look.  One issue: it changes the
  behaviour of the '-disabled'
  state (a -disabled  BWidget::Entry can be programmatically
  modified, 
  whereas a -disabled Tk::entry cannot; I've backed that part
  of the patch out.)


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

  OK, this has been fixed now.
  Files changed:
  entry.tcl : r1.14 -> r1.15
  Tested under Tk 8.3 and Tk 8.4


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  After a bit more play, I figured out it should be
  [list_begin enum]

  and with that additional change, it appears the doc then builds.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Uurps. These were all my bugs, and easily fixed. Would have been better had I validated the syntax before committing :( Fixes are now in the head.


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

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  I confirm this bug.

  Patch:
  entry.tcl Line 266:
  Original:
      if {[string equal $cmd "configure"] || [string equal $cmd "cget"]} {
  New:
      if {[string equal $cmd "configure"] || [string equal $cmd "cget"] || [string equal $cmd "invoke"]} {

  (this is not a standard option in tcl8.5 and thus must be treated by the BWidget mechanism)

  Thank you,
  Harald


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

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

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

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

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

  Added 1 tcltest to validate the new scenario.

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


  File Added: logger.diffs


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The 'jpeg' module has exif retrieval functionality as well.
  Does that work ?

  The 'exif' package has not been updated for anything in a long time, as there is no maintainer for it. The jpeg package on the other hand does have a maintainer (afaupell), should it not work with your images either.


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

  duplicate of 939532. also exif has been superseded by jpeg which does not suffer from this problem


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


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

  Thanks,


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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hello valli, thank you for your report.

  Is it possible for you to attach a snippet of Tcl code which demonstrates the problem ?
  Right now I am not fully clear on what you are doing, making it it difficult to reproduce what you are seeing.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I saw warnings when I generated it myself, but there was no additional information, so, them being
  warnings, I ignored them. The nroff generator apparently gives more info. Thanks, I will repair it.


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

  This issue must have been solved "somehow", as I can not reproduce it with the current documentation.


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

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

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

  My session logs

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

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


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

  /Ashok


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

  /Ashok


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

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

  /Ashok


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

  The crc32 algorithm includes a finalization step where the result of the algorithm is xor'd. To use it for chaining segments as you are trying to do you would need to undo the xor to feed the result from one step into the seed for the next.
  eg: crc32 -seed [expr {[crc32 $data] ^ 0xffffffff}] $moredata

  This is presented already in a more usable form using the Crc32Init/Crc32Update/Crc32Final methods which have been written for this kind of incremental checksum.


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

  The removal of the 'unset' is not required if the variables are initialized with 'variable'.
  Another instance of what is known as the 'creative writing' problem.
  See http://wiki.tcl.tk/1030

  Fixed in CVS head.


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

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

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

  The testsuite still expects that assign'


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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Did you possibly mean 'Keywords should _not_ be always required' ?

  The error is indirect. In the multi-file modes (like when processing a directory) dtplite will generate TOC and INDEX pages, using doctoc and docidx formats. The docidx format doesn't allow an empty index, so, if no page has keywords this error is triggered. If even one of the pages to be processed has keywords nothing happens.

  If dtplite is ordered to process only a single page then neither TOC nor INDEX are made, so the problem cannot occur then either.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed in CVS head. doctools::idx now accepts an empty index (only index_begin and index_end keywords). dtplite will pick that up automatically when the new version of this package is installed.


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


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

  kanryu6 applied this patch on 2009/04/17:

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

                  switch -- $state {


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

     info loaded
     package ifneeded Trf [package present Trf]


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


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

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

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

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


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Yes, this needs fixing - for the moment you can set the left margin for 
  the xy-plots via:

  plotconfig xyplot margin left $width_in_pixels


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Oops, try:

  plotconfig xyplot margin bottom $height_in_pixels

  The plotconfig command sets configuration options for the class of plots.
  So all subsequent XY-plots use that option.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Hm, I will definitely have to solve this one by querying the font metrics instead of 
  assuming some size.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  What does the command 'info loaded' report regarding loaded C packages ?
  crc can use a number of C extensions to accelerate its operation and knowing which is loaded should help us finding which of them leaks.


login: pedietz
username: pedietz
mimetype: text/plain
icomment:
  % info loaded
  % package require cksum
  1.1.1
  % info loaded
  % 

  No packages.

  This problem happens under 8.4.14 with tclllib1.1.10
  and 8.5.6 with tcllib 1.1.11.

  This is the entire program:
  package require cksum
  while { 1 } {
  set a [crc::cksum helloworld]
  }

  Run that.  Then in another shell do 'ps aux | grep tclsh'  and watch the number grow.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Phil, thank you for the additional information. With none of the accelerators loaded this definitely looks to be a problem within the cksum Tcl code itself.


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

  Fixed in CVS head. Bumped to version 1.1.3. The CksumFinal command missed the 'unset state' cleaning up the internal state token/array. I.e. the code generated thousands of tokens = array variables and never removed them.


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

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

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


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

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


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hi Stefan.
  Thank you for your report.
  Please note that the "jpeg" package in Tcllib has exif functionality as well.
  Can you check if that also fails on your image ?


login: stwitt
username: stwitt
mimetype: text/plain
icomment:
  Hello Andreas!

  The jpeg package works just fine on this foto,
  I got the EXIF info I wanted,

  That was a very helpful comment, thanks a lot!

  Best regards,

  Stefan


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok. I will then assign this to me and close as won't fix.

  Fact is, the 'exif' package has already been put on life-support, is being phased out.
  The next release of Tcllib will not install it by default (It can still be forced to be installed).
  And some time after that we will drop it entirely.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  My mind is bouncing around quite a bit over this idea, for several reasons. For instance, my initial thought was "yes - but having a persistent storage "data structure" that could be layered over any data structure would be better than just having a stack that had persistent storage".

  Thought two was "even neater - having a tcllib module that could be plugged in and that would maintain persistent storage for nearly all of a program would be neater - a checkpoint facility so that a program's state was maintained and when you opened it, things could be reset just as you left them" (understanding that there may be some things within an average program which could not maintain persistence).

  Then I thought "but couldn't you just create instead a mechanism that creates a "tie" between a database (such as sqlite) and an application, so that the information in the database appeared within the program as some sort of data structure, able to be read or written like a data structure instead of using select/update/delete sql statements".


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Looks good. I will have to find a place to put those AD specific things and write some tests for it. If nothing else i might put it at least inside the examples section.


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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the bug report.

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

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

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

  Best regards,
  Harald

  -Example script-
  lappend auto_path .
  package require BWidget

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

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


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


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

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

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

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

  The issue is solved by a more severe locking.

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


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

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

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


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

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

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


login: afaupell
username: afaupell
mimetype: text/plain
icomment:
  it appears mks is writing the very old style tar format. the tar package really only handles the posix ustar format. I will leave this open as a reminder to look at supporting the old format.


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Tried v0.5 from CVS as requested.  This change does untar the original test file. However, when the test file has multiple directories there are errors. This seems due to trouble distinguishing between ordinary files and directories as header(type) == 0 even for directories.
  attached is console snap showing one example of error
  also attached is test2-mks.tar which demos the error.
  There is a second look to the error that happens on my large file. I will describe that one if needed.

  BTW, I notice that the -glob option to ::untar does not appear in my ActiveState doc page.


login: royterry
username: royterry
mimetype: text/plain
icomment:
  Confirming the "fixed" closed modification now works for my two test cases.

  Thanks very much!

  Roy


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  while that change isn't incorrect, note that tcl allows its commands like info (and so forth) to be abbreviated at the point in the subcommand that it is unique.


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

  Excellent.  I had tested it out before reporting it and didn't notice any change.  That explains why.  thanks for the response!


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

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


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

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

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


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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Tweaked the documentation as proposed.

  Note: For Prim's algorithm I only stated the range of complexities, but not the exact complexity of our implementation. The problem is, I do not exactly know where our implementation lives, complexity-wise. The main influence is likely the struct::prioqueue implementation, and I have no exact idea about its complexity. On quick glance it seems to maintain a sorted list, I do not believe that it is a binary heap, fibonacci heap, or other similar structure.


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

  Fixed in the CVS head now. Although I used 'fconfigure' to make it more explicit that this requires binary settings.

  Regarding 'A Category Is Missing', the category 'jpeg' is quite present.


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

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

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

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

  No eval required, no quoting hell.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the patch.
  The -uniform option was introduced in tcl/tk 8.4, so I would like to make it conditional to this release version.

  I will look for it next week.

  Could you please provide a test script to check the new functionality ?
  (horizontal and vertical)


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  Here 's a test script. Note that -homogeneous only works for horizontal layout anyway.

  pack [ButtonBox .bb -homogeneous 1]
  .bb add -text A
  .bb add -text B
  .bb add -text C
  .bb itemconfigure 1 -text BBBBBBBBBBBBBBBBBB


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  Please don't consider Tcl/Tk 8.3 anymore! Including the patch conditionally will complicate the code instead of simplifying it. Note that 8.4 was released in 2002...
  Maybe you should ask advice from a TCT member on this, but I think that those who really want to stick with Tcl/Tk 8.3 (or older), can also keep using BWidget 1.8 !
  (In fact,  I even think this holds for Tcl/Tk 8.4, since also 8.5 is already almost 2 years old.)


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Koen,
  thank you for the patch and comments.

  I included the patch into cvs with a condition on tcl 8.3.

  I have posted a release strategy on "tcllib-dev" and nobody complained.
  I want to stay backward compatible for the 1.9 release at the end of this month.

  There is a 2.0 release planed end august to include additional ttk support.
  Within this release, the code < tcl 8.3 might be removed and will effectively lead to much clearer code.


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

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

  Thank you,
  Harald


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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hello Koen,
  thank you for the demonstration script and the patch.
  For me, it works very well and solves issues I have open since years.

  I have slightly modified the patch to keep as much lines unmodified as possible.
  In addition, the formatting is adapted to the environment.

  Could you please verify, if the current cvs works for you ?
  Does the entry in the changelog hit the point ?

  Regards,
  Harald


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  Hi Harald,
  I think the new CVS version is not completely right. But it's partly my fault: I wasn't aware that some of my earlier changes were already in CVS (submitted by Jos Decoster), so my patch was w.r.t. the 1.8 release instead of CVS head.
  Could you do the following:
  - Remove the <Configure> binding on $canvas. For this event, _frameConfigure is called from _resize. (Since $canvas is a user visible widget, you should not impose bindings on it.)
  - Remove the <Expose> binding. Its usage is discouraged in the Tk bind manual. I have replaced it with the bindings on <Map> and <Unmap>.

  Another note: I noticed that you use Windows-style linebreaks in the code (^M^L). Maybe it's better not to do that?

  Regards,
  Koen


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Hi Koen,
  thank you, corrected (after light tests).
  Please stay as critic as possible - also formatting, documentation etc.

  Thank you,
  Harald


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The proposal is to add:
      $path.e selection range 0 end
  after
      $path.e selection clear
  within function ComboBox::_select of file combobox.tcl.

  IMHO it is included in BWidget release 1.8 and in the current cvs.

  Please see the following patch reference where tests was made.
  (I did not test anything now)

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

  Is the parameter -exportselection 0 sufficient for you ?


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  After this E-Mail from Erik Leunissen:
  The lines commented out in the above snippet are the changes proposed by
  patch 981545. They do exactly as I propose in a user-configurable
  manner. Just tested with [ComboBox -exportselection 0].

  I definitely support patch 981545.

  Oh, and personally I'd prefer the default value for -exportselection to
  be "0". Maybe that this is a matter of taste ...
  -END-

  patch 981545 was commited to cvs.

  Thank you,
  Harald


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  > Also: graphops.test seems to depend on setup done
  > by graph.test, cannot run without. Fix.
  This part has been fixed as part of the GSoC 2009 integration.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  The current implementation has the advantage of looping over the list of values
  only once and it could be made to _update_ the current statistics. 

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

  Both methods are worth looking into ....


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

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


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

  Fixed. Found three places where 'subtract' was wrong, replaced by 'exclude'. One use of 'subtract' was ok, and left unchanged. Version bumped to 0.9.1.


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

  Fixed this issue - scalars were treated separately so that [dim] could report the correct dimension, but that special casing was used for row vecotrs as well.


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  I noticed that the latest CVS version already contains a protection against the <Leave> event being called twice, namely by catching {unset _saved}. But I think it is better to use an appropriate condition instead of simply using [catch].


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you, Koen !
  Patch integrated. Please check current cvs (this evening) if everything works for you.


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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  >> Unable to locate or load plugin "docidx" (ERROR for slave interp 1 : can not find channel named
  >> "stdout")

  Hm. This hints at changes to the handling of std channels in 8.6. It may affect all users of tcllib's pluginmgr package. Will have to determine exactly where the failing command comes from (The error message thinks that it is inside of the docidx_import.tcl plugin).


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  a) Visual representation:
  A line from the top of the tree widget window downwards to the first node was removed with the following log entry:

  2004-04-21  Jeff Hobbs  <jeffh@ActiveState.com>
      * tree.tcl (_draw_subnodes): Adjust the drawing of the line to the
      first root node to start at the vertical point (not go up). 

  Jeff explained further by E-Mail:
  The reason I made that change was to be visually compatible with Windows (older style, as new style is no lines) when you actually have sub-nodes (the [+] and [-] indicators).  The line to the top is then inconsistent with the way others draw.
  You could try and make that check contingent on whether subnodes exist, but I think that may seem odd. 

  b) tree -helpcmd patch
  Patch is ok, integrated in cvs, command added to docs.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Koen answered on tcl-devel:

  Ok, I already thought that the Windows style you were referring to always had exactly one top node, which is not the case for BWidget (where the real "root" node is actually invisible).

  I propose to make the line dependent on whether there are multiple top nodes. (Harald, the patch for that is below.) It seems we could agree on that, and I prefer it to an extra option (= extra documentation, which will probably difficult to understand without trying out.)

  --Koen


  Index: tree.tcl
  ===================================================================
  RCS file: /cvsroot/tcllib/bwidget/tree.tcl,v
  retrieving revision 1.59
  diff -b -u -r1.59 tree.tcl
  --- tree.tcl30 Jun 2009 16:17:37 -00001.59
  +++ tree.tcl24 Jul 2009 13:26:22 -0000
  @@ -1369,12 +1369,9 @@
           set yp $y1
           set y1 [_draw_node $path $node $x0 [expr {$y1+$deltay}] $deltax $deltay $padx $showlines]
       }
  -    if { $showlines && [llength $nodes] } {
  -if {$y0 < 0} {
  -    # Adjust the drawing of the line to the first root node
  -    # to start at the vertical point (not go up).
  -    incr y0 $deltay
  -}
  +    # Only draw a line to the virtual root node when there are multiple top nodes.
  +    set len [llength $nodes]
  +    if { $showlines && $len && !($y0 < 0 && $len < 2) } {
           set id [$path.c create line $x0 $y0 $x0 [expr {$yp+$deltay}] \
                       -fill    [Widget::getoption $path -linesfill]   \
                       -stipple [Widget::getoption $path -linestipple] \
  ---

  Jeff answered: Agreed.

  ---

  The upper patch is applied and committed.

  Thanks to all.


login: wordtech
username: wordtech
mimetype: text/plain
icomment:
  The patch can be tested with this code:

  package require BWidget

  Tree .t
  pack .t

  .t insert end root Foo -text Foo 
  .t insert end root Bar -text Bar
  .t insert end root Baz -text Bas

  bind .t <<TreeSelect>> {puts "foo"}

  The keyboard up-down buttons will print "foo" to standard output. 


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Dear Kevin,

  thank you for the patch. IMHO this is half-baken. I am not at all familiar to the tree widget, please help.

  The patch proposes to also bind up and down keys to the virtual event <<TreeSelect>>.

  The documentation says: Event <<TreeSelect>> fires if the selection changes. (documentation lacks the trivial fact, that it does not fire if selection changes by the select command).

  The selection does not change by the up-down key bindings. Only the current node changes. In consequence, <<TreeSelect>> is not fired - that is ok.

  There are IMHO multiple alternatives:

  1) Change the way keyboard navigation works:
  - if select mode is single, the keybard navigation will change the selection
  - if select mode is multiple, the space bar should toggle selection and not expand/collapse the tree. Tree expansion/collapse may be done with the +/- keys.

  2) Also fire the event <<TreeSelect>> whenn the current node changes.
  A more careful patch must be created to invoke
      event generate $path <<TreeSelect>>
  within
      proc Tree::_keynav
  each time, the current node changes.

  3) Create new event <<CurrentNode>> which is fired each time the current node changes.
  (similar to 2))

  The effect of the proposed patch may be achieved by two bind commands after widget creation. But key-right and key-left should also be used.

  Please comment.

  Thank you,
  Harald


login: wordtech
username: wordtech
mimetype: text/plain
icomment:
  Revised patch file moves <<TreeSelect>> event firing to keyboard navigation proc (_keynav) and adds right-left arrow. 


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  I think the new patch is ok, except that it misses the first part of the "down" case in the switch statement.

  Harald, I think the Tree widget does not have single/multiple selection modes like the listbox. I found some references to it in the source code, but it seems to be incomplete and there is no API to use it.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you Koen,
  what do you think of using "select" methods inside key navigation instead of the current stuff. Does the current node and selected node make any sense ?

  Thank you,
  Harald


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  Harald,
  I don't understand what you mean with "select" methods. Currently, the _keynav procedure contains [selection set] commands. That seems ok to me.
  Looking at the source code, I think the current_node stuff does not make any sense. It tests for [info exists selectTree::selectCursor], which is never set. Even the namespace does not exist. (Unless there is some cleverly obfuscated code where it is set -  I've not tested it.)
  Koen


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

  Thank you,
  Harald


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  You are absolutely right. The use of that particular variable is deprecated (there is no need for such a table anymore). The procedure must be revised. I will look into this.


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

  Fixed in version 0.6.2 (in CVS repository). 

  Instead of a table for the Student's t distribution use the inverse Toms-322 algorithm.


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

  After reviewing, I've decided to doc note that synchronous dialogs will always withdraw.  Otherwise trying to get the feedback that a -command wanted to not withdraw looks icky.


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

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


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

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


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


login: mic42
username: mic42
mimetype: text/plain
icomment:
  This could be an effect of TLS/Tcl bug.
   http://sourceforge.net/tracker/index.php?func=detail&aid=1945538&group_id=10894&atid=110894

  I'll look at the other suggestions.


login: zbynek-hubinka
username: zbynek-hubinka
mimetype: text/plain
icomment:
  This works quite well for me:

  Before line 627, which contains "vwait [namespace which -variable $handle](message,$messageId)" in ldap.tcl insert some timeout, e. g. "after 50" or so. It helps when the server is significantly delayed, doesn't matter why. Should be incorporated to next patchlevel of tcllib (the current version is 1.14 recently). 


login: kchansen
username: kchansen
mimetype: text/plain
icomment:
  Posted this as potential bug to TCL sourceforge:

  ID:
  #2848176
  Link:
  https://sourceforge.net/tracker/?func=detail&aid=2848176&group_id=10894&atid=110894

  Response is that since V8.2 this is designed behavior.

  CRC Tcl implementations need to be rewritten to behave correctly with new wide support.

  If no one has the time let me know and I'll submit a proposed fix.

  I elevated the priority to 9 because the current code generates incorrect 32-bit results with the Tcl implementations.


login: kchansen
username: kchansen
mimetype: text/plain
icomment:
  Believe this can be fixed by simply changing the initial value for "v" when originally computing signmask from "1" to "-1":

  Change from:
          for {set v 1} {int($v) != 0} {set signbit $v; set v [expr {$v<<1}]} {}

  To:
          for {set v -1} {int($v) != 0} {set signbit $v; set v [expr {$v<<1}]} {}

  This guarantees that signmask will always be negative and that "~signmask" will always be a non-negative low-order bitmask.


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

  Thank you reporting the bug.

  For me, it does not freeze. It just does not display. But a console window is still responsive. Actually, it is moved out of the screen.
  > winfo geometry .tst
  290x1035+695+-6007

  I will try to fix it.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The issue was, that "winfo reqheight" was used as real height.
  The real height is not jet known, because the window is not jet mapped.
  When mapped, the size is bound on the screen size which highly reduces the height in this case (reqheight was around 16000).

  The estimated value is now bound on the screen size.

  The patch was committed to utils.tcl in cvs.

  Thank you,
  Harald


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Renamed 'LexNormalize ' to 'lexnormalize' and documented it.
  Version bump to fileutil 1.14.
  Committed to CVS head.


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Another problem -
  fileutil::stripPath c:/temp/foo/bar c:/temp/foo\\bar
  generates a Tcl error as it executes a file join with no arguments.


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Below is an alternative implementation that I think fixes both above problems. But note the DANGER comment about other platforms. And only tried on 8.6 though I believe should work with 8.4

  ---
  proc ::fileutil::stripPath {prefix path} {
  # [file split] is used to generate a canonical form for both
  # paths, for easy comparison, and also one which is easy to modify
  # using list commands.

  # Convert \ -> /
  set prefix [file join $prefix]
  set jpath [file join $path]
  set prefix_len [string length $prefix]
  if {[string equal -nocase -length $prefix_len $prefix $jpath]} {
      set jpath_len [string length $jpath]
      # Optimize for common case where path is a prefix
      if {$jpath_len > $prefix_len} {
  # DANGER DANGER - is path separator after a join (above)
  # a "/" on ALL platforms ? True on Win, Unix and OS X. Others?
  if {[string index $jpath $prefix_len] eq "/"} {
      return [string range $jpath [incr prefix_len] end]
  }
      }
      if {$jpath_len == $prefix_len} {return "."}
  }
  return $path
  }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  I added a different patch. Basically adding a space between ${prefix} and the '*', to account for the separation of the list elements returned by 'file split'. This should fix the basic issue.

  Not sure if that helps with the ...\\bar case as well.

  I still have to test this on windows. Unix had the same basic issue, there my patch is a fix.

  Note: It is better to attach changes to the report by 'add'ing files. Inlined code as you provide in your comments gets badly formatted.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed. Both issues. Committed to head, with extended testsuite. The \\bar issue was fixed by moving the 'string equal' after the file split, forcing comparison of the canonical list representation of the paths, without an for- and backward slashes. Version bumped to 1.14.1.


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

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

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

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

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

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

      $p plot data $x $y
  }

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

  Clearly this must be checked


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Added a patch for comm.tcl which replaces lindex/lreplace with Word0, a procedure emulating the 'lindex <list> 0' behaviour pre Tcl 8. I.e. takes the first word of a list, assuming that this word is well-formed, the remainder of the list does not have to be well-formed.

  Passes comm's testsuite.

  Please check in your environment as well.


mimetype: text/plain
icomment:
  Downloaded and installed the patch and reran the scenario that caused the crash. The patch appears to fix the problem.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks for the feedback, and glad to know that it seems to work in your environment as well.
  I will commit the change ASAP, hopefully today.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  I printed the values of ln_Gamma(a+1), ln_Gamma(a), ln_Gamma(b) and the constituent terms term1 and term2 (on Windows XP). The problem is very likely caused in the case:

  a, b = 1000, 1

  a very uncommon distribution, however the test case should be dealt with properly.

  The terms term1 and term2 turn out to be 6.216 and -803.11. So the script is trying
  to take the exponent of -797 (approximately). We should change the expression
  to:

  set t [expr {$term1+$term2}]
  if { abs($t) < 200 } {
     return [expr {exp($t)}]
  } else {
    return 0.0
  }

  (This is a rather safe limit: exp(-200) is roughly 1.0e-87 - and the smallest number that
  can be represented is exp(-744) = 5.0e-324)

  I will fix this


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks. Please do not forget to bump the version number of the package as well. Bugfix => patchlevel.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  [14:33]colinaku, reported md5 bug 2906306
  [14:33]colinit's strange because it's happening on *close* not open.
  [14:34]akuFirst, what is underneath the md5 ? Plain Tcl, or one of the accelerators ? (Trf, tcllibc)
  [14:34]colinHow do I find out?
  [14:34]akuinfo loaded tells which shared libs are loaded, that is one indicator
  [14:35]akuThere is also some array in md5 which tells exactly
  [14:35]colin|{/usr/lib/tcl8.6/Mk4tcl/Mk4tcl.so Mk4tcl} {/usr/lib/tdbc1.0b13/libtdbc1.0b13.so Tdbc} {/usr/lib/sqlite3.6.19/libsqlite3.6.19.so Sqlite3}
  [14:35]colinso it would appear to be the plain tcl version
  [14:35]colinshame, I want the accelerated one 
  [14:35]akuOk, no accels loaded, should be the plain Tcl => IIRC this uses a channel internall to process a file => Pat Thoyts has written this code.
  [14:36]colinleave that for another day.
  [14:36]colinok.  patthoyts, seems to be a strange bug in md5.  It would appear that the file has been closed already.
  [14:36]akuI will paste this part of the chat into the bug and then reassign
  [14:36]colinwhen it comes to be closed under ::md5::md5 -file
  [14:36]colinok.


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


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

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

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

  Thank you,
  Harald


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


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


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks Thomas.

  I have now run this code against the json.test testsuite in Tcllib, and it reports one failure, for the 'menu' test case. The others all pass.

  The JSON it fails on is

  {"menu": {
      "id": "file",
      "value": "File:",
      "unival": "\u6021:",
      "popup": {
          "menuitem": [
                       {"value": "Open", "onclick": "OpenDoc()"},
                       {"value": "Close", "onclick": "CloseDoc()"}
                      ]
      }
  }
  }

  See the attached file X.log for the stacktrace and error message. It basically expected ',' or '}', and got a ':'. I do not know if the test input is wrong, or your code missing something.

  Please check.


login: thomasmaeder
username: thomasmaeder
mimetype: text/plain
icomment:
  Thanks for testing! I had forgotten the 'u' in Unicode character literals ('\u6021').

  I have just (2009-12-10 09:48) attached the fixed json.tcl


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

  The revised json.tcl passes the test suite. Committed to head with slight modifications (changed a few '==' to 'eq' because they were string, well character, comparisons, and 'eq' is better for that, as it doesn't check if the arguments are numeric or not, as '==' does).

  The new version number is 1.1.


login: eee
username: eee
mimetype: text/plain
icomment:
  The problem here is the handling of invalid data. The email declares itself to have a content type of "text/plain; charset=us-ascii", and a content transfer encoding of "quoted-printable". However, there are FormFeed characters and eight-bit "smart quotes" characters imbedded in both the headers and the body of the message.

  This error occurs at line 1574 of mime.tcl, when mime::getbody tries to decode what it thinks is quoted-printable data read from a file, and it looks like the same would occur at line 1639 if the invalid data were passed to mime::initialize as a string. Hmm, looks like it could be triggered at line 806 too? In all cases, it's calling a command "quoted-printable -mode decode" that appears to be coming from the Trf package.

  I'm really not sure what the correct way to handle something like this should be.


login: eee
username: eee
mimetype: text/plain
icomment:
  The mime module does document the behavior on error, and since the input was invalid and erroneous, the mime module was behaving as documented.

  In the general case, and especially when dealing with hostile input such as arbitrary email, the application needs to account for the possibility that invalid input will cause an error, and the application needs to handle the error in some manner, such as offering the user the raw content of the email.


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

  Accepted. Changes committed to CVS. I am not sure if my code is correct for nroff. If not, just open a bug.


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


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

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


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


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

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

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


login: tomk
username: tomk
mimetype: text/plain
icomment:
  That is a really nasty case. Your proposal makes sense in terms of continuing the parse but I'm a little confused by the "Erroring out is undesirable...". It seems to me that you should error out. If the using proc needs to test the html then it can capture the error with a catch and decide what to do.
  tomk


login: dvrsn
username: dvrsn
mimetype: text/plain
icomment:
  There are two reasons why I said error-ing is undesirable.  

  First, because the documentation doesn't suggest that it can throw an error due to badly formed html.  (It raises errors for incomplete html, but that is an intentionally raised error).  If an error like this was detectable and raised as "insane html" or something like that, and this was documented, that might be ok.  Unbalanced braces or incorrect number of arguments gives no clue as to the nature of the error.

  Second, an error being raised in this case would allow partial parsing, but only up to the point of the error.  This malformed html is roughly comparable to line noise, where there's a glitch somewhere in the middle but after that things can continue.  But raising an error doesn't let things continue, even if the caller wanted to do so.  A document can be made completely unparsable by having this malformed string at the beginning.  


login: tomk
username: tomk
mimetype: text/plain
icomment:
  OK, I agree with your comments. After reading the docs for the command it's it looks like your interpretation for the string is the only one that will work with the defined interface. Including a "/" in the tag doesn't make sense because it should be detected and returned as a flag in the callback. Thus, you really only have one chose.


login: dvrsn
username: dvrsn
mimetype: text/plain
icomment:
  The cause behind this bug and duplicate 3504018 is that the trnasformation into a command stream is done by a pair of regexps, and when the param value (i.e., tag attributes) of a null end tag construct looks like html, it gets reparsed by the second regexp, making things break in interesting ways.

  The first regexp handles NET cases, resulting in commands that make it look like a opening tag followed immediately by a closing tag.  It can be changed to actually rewrite those tags to be an opening tag followed by a closing tag, and then have the normal tag regexp reparse it intentionally instead of accidentally.  The effect is the same, but the mechanism prevents already formed commands from being changed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Re: " It can be changed to actually rewrite those tags to be an opening tag followed by a closing tag"

  Do you have a patch for this change, per chance ?


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

  Just do it again if you get an error. However, you are using this wrong and will leak arrays if you run this alot. Re-read the manual page and pay attention to 
  "Once you have finished, you should use [cmd cleanup] to release all resources. The default port is [const 37]."

  See the example too. You get a token and you should use that to check for errors before trying to use the time value.
  if {[time::status $tok] ne "ok"} {
    puts "something bad: [time::error $tok]"
    ...retry with next server...
  }


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


login: anonymous
mimetype: text/plain
icomment:
  The quoting around all values is unnecessary; it is sufficient to simply require that a value (string, number or bareword) is parsed as a list of length 1.


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

  Fixed. The string internally (seen by the receiver) is "{puts \\}" and not handling \\ on its own caused misdetection of a "\}" at the end, instead of the proper end of the word.

  comm version 4.6.2.


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

  Changed code to detect the situation and throw a more properly looking error ('Not enough data to process padding'). This is now version 2.4.2 of base64.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed as proposed, committed to CVS head. Package version bumped to 1.0.3.
  One issue left: Can you provide us with a small snippet of code which demonstrates the failure ? I would really like to extend the testsuite as well, to catch this in the future.


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


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

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

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

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

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

  After iteration 16 there will be different Xi values.

  Example for the salt:

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

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

  Regards

  Zbigniew Diaczyszyn


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


login: tomk
username: tomk
mimetype: text/plain
icomment:
  Andreas,
  A trigger on ::argv would be a simple solution and I wouldn't think there would be bad side effects. I've modified ::argv in several applications and followed it with an update of ::argc. I don't think a trigger on ::argv would break mine or similar code. My personal feeling is I don't care if the change is made or not.
  tomk


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


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


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

  The patch was tested by Robert Karen.

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

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


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

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

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


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

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The issue was the see method, which showed only the text and not an eventual present icon or window.
  The attached fix resolves the issue.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Sorry, it is bindText, not bindTag:
  - Script -
  pack [ListBox .l -selectmode single]
  .l insert end list:#auto -text 111
  .l insert end list:#auto -text 222
  .l insert end list:#auto -text 333
  .l configure -width 10
  proc p {args} {puts "p $args"}
  .l bindText <Button-1> p
  - End -
  After the binText method invocation, mouse selection will not work any more.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The issue was, that bindText/bindImage mathods interfere with the internal selection bindings.
  The attached patch decouples the bindings.
  The Patch runs against release 1.9.0. The patch of Bug 2995969 is also included.
  It concerns some identical lines and they would be exclusive otherwise.


login: danckaert
username: danckaert
mimetype: text/plain
icomment:
  It is not surprising that bindText <Button-1> does not work, since there is already a binding for <Button-1>.
  The normal workaround is to add a "+" to the binding:

  .l bindText <Button-1> +p

  That solves the issue for me.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The patch contains a number of other changes beyond what is described in this bug.
  Can you explain ? (Changes to binary scan, file handling, int/float differences).


login: a_kovalenko
username: a_kovalenko
mimetype: text/plain
icomment:
  Umm, sorry, almost all of them are safely ignored, many are redundant and many depends on newer Tcl than ico.tcl itself. Sorry again, I should have prepared a cleaner patch. 

  Float->int replacement doesn't alter semantics for icon dimensions that are multiples of 8. It was added during a vain attempt to track down the size calculation problem. The same can be said about [open] flags ("b" is redundant as soon as -encoding and -translation are set in a later code) and [binary scan] ("u" flag is more convenient than format %u and &0xFFFF, but, alas, it increases required Tcl version).

  The only thing making sense, of those other changes, is commenting out a check for [file exists] in writeIcon: ICO backend is able to create files from scratch, so the file doesn't _have_ to exist (I should report it as a separate bug and attach a separate patch, of course). 

  As of other changes, please drop them out.


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

  Ok. Done. Version is 1.0.5. See my attachment for the final patch I committed to CVS head. Please check that it works for you. If not, reopen the bug.


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

  (*) I am using the SafeBase for that.


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

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


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


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

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


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

  Yes. The uuid::uuid command gives the interactive interface. So [uuid::uuid generate] produces a nice string suitable for human eyes. The internal command [uiuid::generate] is the programming api and returns the raw binary version. This is to avoid people dehexing the hexified version when they want to reformat it or check it or whatever.


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

  Thanks for reporting. These links are repaired by replacing tug.org with ctan.org; they probably predate the registration of the ctan.org domain.


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

  Patch applied in CVS, in asn 0.8.4. and some tests added.

  Sorry it took soo long (guess the copy of your patch in the pki module can go now).


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  to see yaml-1.1
  http://yaml.org/spec/1.1/#id928558
  in the Literal Block Scalar, 
  # comment
  lins are ignored.


login: mpr8
username: mpr8
mimetype: text/plain
icomment:
  #-lines that are otherwise treated as comments (i.e. ignored) should not be treated as comments but literal. In your implementation, those lines completely go missing, but shouldn't. That's my point.
  To cite: "The literal style is the simplest, most restricted and most readable scalar style. It is especially suitable for source code or other text containing significant use of indicators, escape sequences and line breaks. In particular, literal content lines may begin with a tab or a “#” character."


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  hmm...

  I find a mistake that should'nt ignore "# comment" just next of "|",
  for example,

  |
    # comment
    literals
    literals
   # ignored as comment

  but other problems has been left there?

  Please show me the complete examples for the specification.


login: mpr8
username: mpr8
mimetype: text/plain
icomment:
  If I understand you right: You think, that lines beginning with # (regardless of indentation level) should be ignored. But that's plain wrong (according to the specification). In your example (that's only readable by e-mail; for other readers: first three content lines are indented by 2 spaces, fourth line is indented by 1 space), the first line prefixed with # is part of the content, the second is of course treated as comment (because it falls out of indentation level). This applies in general to all literal scalar #-lines, regardless where (first line or not) they show up. In my posted real-life complex example (http://yaml.org/ypaste/674/; compare with parse tree to the left) all #-lines are on the same indentation level as all other scalar lines, so they may not be treated as comments, they're part of the scalar content. It would help a lot if you would admit that those lines aren't comments (and start fixing the implementation). ;)

  What do you mean with "Please show me the complete examples for the specification."?


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

  Tested with Tcllib 1.15, Tcl 8.5.11, on Linux (Ubuntu 11.04, 64bit).
  I am unable to reproduce the problem.


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


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


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


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

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

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

  That will take a bit more time.


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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  First step, made tests in 7 files properly independent, using tcltest v2 abilities.

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

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


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

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

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

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


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

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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Ok. I have started looking into this.

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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


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

  format would be similar how the msgcat package handles things.


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

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

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


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

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


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

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

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

  comm version 4.6.2.


login: arjenmarkus
username: arjenmarkus
mimetype: text/plain
icomment:
  Done. I have split up the code into two procedures (analyse-Kruskal-Wallis and group-rank)
  and added a toplevel one, test-Kruskal-Wallis, to get the same type of interface as the other
  test procedures (namely: a decision result, rather than numerical data)


login: lars_h
username: lars_h
mimetype: text/plain
icomment:
  Not wrong number of arguments, but wrong command called; it should have been math::numtheory::isprime. Also, 127 turns out to be too small to test what was meant to be tested.

  Fixed in CVS.


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

  Ditto for the applications 'nns' and 'nnslog'.
  Fix for all committed to head.


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


login: pointsman
username: pointsman
mimetype: text/plain
icomment:
  Well, I also stumbled over 2treeCallback some days ago. And thought: that whole proc isn't an example for good code.

  That starts with unusual coding style:

      if {"$slash" == "/"} {

  The quotes around $slash aren't wrong in the sense of being a bug, sure. But the experienced tcl programmer get disturbed for an eye blink and unexperienced tcl programmers may get confused and may assume some special magic.

  And goes on with superfluous code, within the first non-comment lines of the proc:

      if {$textBehindTheTag != {}} {
          set text [mapEscapes $textBehindTheTag]
      }

  Too sad, $text isn't used anywhere later on in the proc.

  This all is harmless for the question "is the result of the proc
  correct", sure.

  The code cited by the originial poster is not, but not only in the case of the PRE element.

  An example is pretty easy (here done with an other element, to show that we talk about a more general problem):


  package require struct::tree
  package require htmlparse

  struct::tree resultTree1
  htmlparse::2tree "<p>foo <b>bar</b> baz</p>" resultTree1

  struct::tree resultTree2
  htmlparse::2tree "<p>foo<b>bar</b>baz</p>" resultTree2

  if {[resultTree1 serialize] eq [resultTree2 serialize]} {
      puts "Identical HTML fragments"
  } else {
      puts "HTML fragments differ."
  }

  This script returns "Identical HTML fragments", which doesn't look quit right. 

  Well, sure, the proc does what it does. In the words of the manual: "[It] takes an HTML string and converts it into a tree containing the logical structure of the parsed document." This is a vague description of what should happen (or, otherwise around, what one should expect to get out, if used).

  But as it is now, the user get neither the whole unmodified PCDATA content of the html input string nor the PCDATA with white space condensed in the ususal way by an HTML browser (css white-space value "normal") nor the PCDATA with white space handled in any other of the ways the css attribute white-space knows ("pre", "nowrap").

  That result my be meant by "logical structure of the parsed document" but it at least makes 2tree useless for everyone which want to parse an html document to render it in so way (to pdf, rtf, ...).

  At a minium a word about the strange white space handling of the current proc within the documentation is necessary.

  Adding a special case for the PRE element into this weird white space handling - as the originial poster proposes - may help for a small range of real word problems but in general makes things even worser, in my opinion.

  The easiest would be, to remove the whole line: no white space stripping at all of the PCDATA contents. Sure, this burden the consumer of the result tree with the white space handling, but at least it then has a chance to get it right, while it now hasn't any chance to get it right because it gets it already mangled. If nobody will be do more, I would for sure at least do that: remove the line.

  A more elaborated white space handling would for sure be convenient in a lot of cases. If someone writes one, it would still be a good feature, to be able to get the whole unmodified PCDATA, if needed (by an option).

  A natural candidate for how an elaborated white space handling should work is the css white-space attribute value "normal", that means, all white spaces (spaces, tabs, line breaks) condensed into a single space.

  Beside all that, the special handling of some auto-closing HTML tags does just work by accident, if ever.


login: martinlemburg
username: martinlemburg
mimetype: text/plain
icomment:
  Thanks to Rolf Ade going into details.

  I would prefer that the htmlparse package would preserve all whitespaces, not modifying the content to return really only the logical structure of the given document!

  I as user of HTML data have to care for this, knowing that some tags have a special whitespace behavior, knowing that CSS rules modify the whitespace behavior, but NOT the logical structure of the document.

  So my proposed change would be to remove all whitespace handling (replacing several whitespaces by a space and trimming trailing whitespaces) and to document this in the man page, to make sure, that the package user knows, that the contents are really not changed!

  Regards,

  Martin


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

  This seems to be a duplicate of bug
  https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1724818&group_id=12883

  That bug has been fixed in the CVS head and is slated for release with Tcllib 1.14 (next week).


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the bug report and the test script.
  Could you please post your tcl version (and source).
  Does it only happen for the menu item with purple background or for all of them ?

  Thank you,
  Harald


login: wordtech
username: wordtech
mimetype: text/plain
icomment:
  It appears that mainframe.tcl in the BWidget source tree sets the background of Tk menus by checking for $tcl_platform(platform), and assigning traits if the platform returns "unix."  It really should use [tk windowingsystem], because while tcl_platform(platform) returns unix on MacOSX, the UI framework is not X11. 

  The diff below appears to fix the problem:


  --- mainframe-orig.tcl2010-11-09 09:36:05.000000000 -0500
  +++ mainframe.tcl2010-11-09 09:36:49.000000000 -0500
  @@ -518,7 +518,7 @@
   }
       }
   
  -    if {![Widget::theme] && $tcl_platform(platform) == "unix"} {
  +    if {![Widget::theme] && $tcl_platform(platform) == "unix" && [tk windowingsystem] !="aqua"} {
   set menuopts [list -background [Widget::getoption $path -background] \
     -borderwidth 1]
       } else {


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

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


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


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


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


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


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

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


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  Could you please provide the exact Tablelist version?  The official tklib5.0 release includes Tablelist 10.0.1, but I am not sure you refer to the *initial* tklib version 5.0, because that is already nearly two years old.

  This bug was present in some earlier Tablelist releases, but was fixed in version 4.7.  Unfortunately, it appeared again in Tablelist 5.0, but was fixed in the most recent version 5.2.  For this reason, please run your script with Tablelist 5.2 and let me know whether it still exhibits the problem (it shouldn't).


login: tombert
username: tombert
mimetype: text/plain
icomment:
  The package index tells 4.10.1
  I've checked the CVS sources now ... there have been a lot of changes. My problem was only that I wanted to get a tagged version. So my question: Is it safe to take the latest CVS source?
  thx


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  The latest CVS source is identical to the one contained in the most recent Tablelist version 5.2 (see www.nemethi.de).

  I am somewhat surprised to hear that you found this bug in Tablelist 4.10.1.  Could you provide a simple script helping me to reproduce the problem?

  Also: Does your script behave as expected when using Tablelist 5.2?


login: tombert
username: tombert
mimetype: text/plain
icomment:
  I was adding a second row to my table while hovering with the mouse over it ... maybe it's related to the tooltip I'am using ... I'am using it without a problem for a year now and can't reproduce - so I only had a look into the code and made a few assumptions ...


login: nemethi
username: nemethi
mimetype: text/plain
icomment:
  A closer look at the body of the tablelist::addActiveTag proc in the distribution file tablelistBind.tcl reveals that in this case findTabs does assign a valid value to both arguments tabIdx1 and tabIdx2.  Actually, the additional condition making this sure is that data(dispId) doesn't exist (i.e., that all newly inserted rows have already been displayed).  This is, however, checked in tablelistWidget.tcl, before invoking the addActiveTag procedure.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the feed-back.
  The version with the wrong version number was around one hour online, sorry for that. I suppose, it is already fixed so no action needed here.
  Andreas wrote, that the correct version is on teapot.

  Sorry,
  Harald


login: guardus
username: guardus
mimetype: text/plain
icomment:
  Better workaround:

      proc ::fileutil::GLOBF {current} {
          global tcl_platform
          if {[file type $current] eq {link}} {
              set tgt [fullnormalize $current]
              if {![file readable $tgt]} {
                  return {}
              }
              # At least in Windows XP, a junction can point to same name as a file.
              # This will create a glob error below.
              if {$tcl_platform(platform) eq {windows}} {
                  if {[file isdirectory $current] != [file isdirectory $tgt]} {
                      return {}
                  }
              }
          }
      ...


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


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

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

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

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

  Regards,
  Harald


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

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

  I will reassign the bug report to TkLib


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

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


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

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


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

  Tcllib does not contain an "http" package.
  There are "html" and "htmlparse".

  And the "autoproxy" package in the http subdirectory.

  ... Ok. The 'Bugs' Tracker had category 'http :: autoproxy', but none of the others.
  This is now fixed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  This belongs to the Tcl core, pretty much. that is which provides 'http'.
  Still, assigned to Pat, as he is the guy handling 'http'.


login: karll
username: karll
mimetype: text/plain
icomment:
  I've uploaded a file that contains a patch to provide the -compress switch for the tcl 8.5 version.


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

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


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

  Ok, the .gz file was the only file which was short, and I have re-uploaded it now.
  NOTE: It may still be necessary to download it multiple times, as it seems that even now, about 20 hours after re-upload, some of the mirrors still have short files. At least one mirror is ok tough, returning the full file (5319952 bytes, md5 5bc9567b3a61884716a908d5295d7105).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  A bit more info, the checksums:

  a5133b5380e5ae71faf1c6712a3b11ba  tcllib/1.13/README-1.13.txt
  f2553e4834555b206726461e4600813e  tcllib/1.13/tcllib-1.13.kit
  4625574b88a65031ecf0a0fd7e33764d  tcllib/1.13/tcllib-1.13.tar.bz2
  5bc9567b3a61884716a908d5295d7105  tcllib/1.13/tcllib-1.13.tar.gz
  272f91778ba43e43abe6dea3531062b2  tcllib/1.13/tcllib-1.13.zip

  The Files manager shows this data as well, behind the (I) button of each file.


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

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

  Here are the questions and the preliminary answers:

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

  -- A1 --
  It is a good point.

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

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

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

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

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


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

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


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

  PT=pt

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


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

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

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

  Continuing...


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Confirmed. Looking at the larger stacktrace this seems to be happening while the string channel is constructed. Looking further I find that the events constructor is not called. It seems that I have to chain them manually with 'next', 'oo' is not doing it for me. This may affect all the classes.

  Continuing...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Yes, "tcl::chan::memchan" was also affected, as was "tcl::chan::variable". The other classes did the proper chaining. Very likely a copy-pasta error during development.


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

  Fully agreed on both bug and fix.
  The fix is now in the CVS head.
  Package version bumped to 1.3.3.
  Testsuite extended.


login: duquette
username: duquette
mimetype: text/plain
icomment:
  Aha!

  uri::split and uri::join are presuming that the fragment *precedes* the query.  But it can't, I think, because the fragment is handled by the user agent, and isn't properly part of the URI at all, whereas the query most certainly is.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Accepted. Although the option will take the text of the banner, and not be a callback.
  Note that some parts of the banner stay hardwired, namely status code (220), server-address, and the timestamp.


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Fixed. Thanks for the report. The docs at tcllib.sf.net are updated manually and happen when I remember to ping Joe English about this. I'll ping him.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you for the report.

  I suppose, you thought about the text "Base colors" and "User colors".

  They are missing in the language files. For a german translation, you could add this to lang\de.rc:

  ! --- symbolic names of label of SelectColor dialog ----------------------------

  *baseColorsName: Grundfarben
  *userColorsName: Benutzerdefinierte Farben

  I will make the translations of German languages and initialise the rest to english.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Committed to CSV branch bwidget.

  Please feel invited to provide translation for da, es, fr, hu, nl, no, pl for the subchapter head strings "Base colors" and "User colors".


login: prezso
username: prezso
mimetype: text/plain
icomment:
  This is a button text in the font.tcl:
  set but [button $colf.button -command $script -text "Color..."]


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Reading helps - file font.tcl, not color.tcl.
  Added new translation key "colorPickerName" and its translations.

  Comitted to CVS sticky tag bwidget


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Fixed and tested with:
   Widget::theme 1
   pack [Label .l -text ABC]
   .l configure -foreground yellow


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Trying to remember this may have been done as a primitive form of a path jail, i.e. to keep absolute paths within the basedir assigned to the user. I'll have to check this a bit more however.


login: rkeene
username: rkeene
mimetype: text/plain
icomment:
  --- ftpd1.2.5/ftpd.tcl(revision 2177)
  +++ ftpd1.2.5/ftpd.tcl(working copy)
  @@ -1301,7 +1301,7 @@
   
       set path [file join $data(cwd) $filename]
   
  -    if {[file exists $path]} {
  +    if {[::ftpd::Fs exists $path]} {
           if {[::ftpd::hasCallback authFileCmd]} {
               set cmd $::ftpd::cfg(authFileCmd)
               lappend cmd $data(user) $path write
  @@ -1358,7 +1358,7 @@
       }
   
   
  -    if {![catch {::ftpd::Fs rename $data(renameFrom) $path} msg]} {
  +    if {![catch {::ftpd::Fs rename $data(renameFrom) $path $sock} msg]} {
           unset data(renameFrom)
       } else {
           unset data(renameFrom)


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

  Fixed in CVS head. Plus a fix in ftpd::fsFile::fs (branch 'rename', sock -> outchan).


login: fvogelnew1
username: fvogelnew1
mimetype: text/plain
icomment:
  I have provided this report AND the bug fix quite some time ago now.

  What does prevent it to be included in the source code?


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

  Applied suggested fix.
  re: your comment - someone needs to notice the bug and do the work. Feel free to become a maintainer.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Already fixed by Andreas Kupries on Oct 26 2010:
  http://tcllib.cvs.sourceforge.net/viewvc/tcllib/tcllib/modules/http/autoproxy.man?r1=1.10&r2=1.11


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

  Reopening. Now its called 'Blocke' in the code.
  Note the trailing 'e'.

  Side note: This and the chi-squared fix warrant a bumping of the package's patchlevel.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thank you addressing this always annoying issue.
  For me, I required another window size to show the effect, but I know it. I never liked, if the scrollbar jumped back to 75% after having pulled it to 100%.

  There was a patch by private E-Mail


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Summary of private Mails about the attached patches:

  -Ideas by WC-
  Date: Fri, 17 Jun 2011 11:05:29 +0200
  From: Wojciech Kocjan
  I just filed a bug so I don't loose the example. I investigated the
  issue and have been wondering - would it make sense to just allow
  configuring smooth scrolling?

  It would make sense since with 8.5, smooth scrolling is also the case
  for other widgets.

  Do you think it makes sense? Do you think it makes sense for both tree
  and list? Do you think it can pose any problem?

  Do you know of any other solution that would resolve the Windows issue
  without such a rework?

  -About the first patch-
  Date: Fri, 17 Jun 2011 17:04:48 +0200
  From: Wojciech Kocjan <wojciech@kocjan.org>
  It expands region by number of pixels needed below list - i.e. if size
  is 163px (without borders), deltay is 25, then I am adding 13px
  because this is how much is needed below the list and will be shown if
  you move all the way down.

  -Modified patch by Koen Danckaert-
  -------- Original-Nachricht --------
  Date: Tue, 21 Jun 2011 17:57:15 +0200
  From: Koen Danckaert
  I basically agree with the patch, but I think it can be simplified.

  The original version already contained code to increase the scrollregion, but this code can be considered wrong since it did not work. So I would leave out that part and replace it by the new code.

  Also, the int() conversions are not needed because they already operate on integer arguments?

  With a bit more code refactoring I arrived at the attached patch, which works for me. Note, line numbers are different because I still work with BWidget 1.9.0, and I only did the Listbox part (not Tree).

  -Modified patch by WC-
  -------- Original-Nachricht --------
  Date: Wed, 22 Jun 2011 16:51:18 +0200
  From: Wojciech Kocjan
  Yes, that fix worked jut fine. Attached is patch against 1.9.4.

  -HaO-
  I specially like, how exact the scrollbar "jumps" now, if the scrolling region is at the end and the window is resized. Good work !
  Fix committed, thank you all !


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Oh, I have made an error and applied the wrong patch.

  For me, the patch has the following issues:

  1) the space below the last entry is far to much for me. (see attached foto)
  2) scrolling down to the end and resizing the window to get smaller:
    did keep the last row in view before.
    This is not the case any more.

  Could you reinvestigate the patch, please ?


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Koen and Wojciech reevaluated:
  - extra space (felt by me) is ok
  - resizing and keep last row was not related to the patch.

  Bug closed, thank you all,
  Harald


login: takatsuki
username: takatsuki
mimetype: text/plain
icomment:
  Sorry, I just found a copy-paste error in my patch. In:

  proc ListBox::_init_drag_cmd { path X Y top } {
   set path [winfo parent $path]
    set ltags [$path.c gettags current]
   set item [lindex $ltags 0]
   if { [string equal $item "item"] ||
      [string equal $item "img"] ||
      [string equal $item "win"] } {
          set item [ListBox::_get_node_name $path $id]

  $id is not defined, it should be 

  set item [ListBox::_get_node_name $path]

  Or 

  set item [ListBox::_get_node_name $path current]

  Sorry for that.


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


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

  Fixed in CVS head, as part of the fix for 3312880 (where it was in the inlined patch).


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

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


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

  Thank you for the report ...
  Fixed in CVS head now.
  ChangeLog:

          * memchan.tcl: Fixed missing initialization of 'content' instance
            variable. Bumped to version 1.0.2.

          * variable.tcl: Fixed missing invokation of superclass
            constructor. Fixed missing initialization of linked 'content'
            variable, if not existing. Fixed missing import of linked
            variable into the event handling. Bumped to version 1.0.2.

          * cat.tcl: Removed bogus invokation of superclass constructor,
            there is no such. Bumped to version 1.0.1.

          * facade.tcl: Added missing logger requirements, dropped bogus
            call to superclass constructor. Bumped to version 1.0.1.

          * std.tcl: Fixed command scoping issues, and dropped bogus call to
            superclass constructor. Bumped to version 1.0.1.


login: kanryu6
username: kanryu6
mimetype: text/plain
icomment:
  Thanks for reporting.

  I fixed the problem, at huddle-0.1.5 .
  I committed this at the tcllib repository.

  enjoy! :)


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

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

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


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

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

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

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


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

  Fix committed to cvs head. Version bumped to 0.2.4.

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


login: droll
username: droll
mimetype: text/plain
icomment:
  It is right that some tests of the TEPAM module require Tk. I understand that there may be targets on which Tk is not available. I will modifiy next week the relevant tests in a way that they are only executed when Tk is available.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  I am unable to confirm this. Using a self-build Tcl 8.5.11 with memory debugging (--enable-symbols=all) and the attached modified test script I see the current and maximum allocations rock solid at their values, without any increase.

  I tried this with pure-Tcl md5crypt, and md5crypt accelerated via tcllibc. The latter I ran to the full million, the former only to 1000 rounds, gives that it is much slower.

  Output after completions:
  % ../../../DTest/8.5/Install/Debug/bin/tclsh8.5 ./trial
  8.5.11
  1.1.0
  *
  1009:   m703050 834514^C

  % ../../../DTest/8.5/Install/Debug/bin/tclsh8.5 ./trial
  8.5.11
  1.1.0
  *       /home/aku/Projects/Tcllib/0.Releases/1.14/Base/modules/tcllibc/linux-x86_64/tcllibc.so Tcllibc
  999999: m683191 750032


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

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

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


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


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

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

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

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

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


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

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

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


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

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

  We now have 10 year certs, at 1024 bit.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thank you. Is this the
  http://en.wikipedia.org/wiki/International_Bank_Account_Number
  ? (As you gave no reference I googled for IBAN and found the above).

  Do you have test cases as well, per chance, i.e. examples of correct and incorrect IBANs ?


login: maxjarek
username: maxjarek
mimetype: text/plain
icomment:
  Yes, this is International_Bank_Account_Number. I attach new version function when i include references. I attach also test script for test correct iban numbers for some countries. I have only examples of correct IBANs.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thank you. I have integrated this new version with the previous one, extending the range of checks a bit. I also moved some of the fixed values into type variables and simplified an expression, the check itself (nested expr is superfluous).

  One of the ibans in your tests is actually not correct, it seems:

                     PL78102030170000270200618694
  becomes  102030170000270200618694 PL78
  becomes  102030170000270200618694 2521 78
      % 97 == 46 != 1
  (Confirmed using 'bc'). Spaces in the numbers just for clarity.

  I will take that as a test case of an incorrect number.


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

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

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

  -Harald


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


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


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

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


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


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


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


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


login: rkeene
username: rkeene
mimetype: text/plain
icomment:
  This functionality is a part of pki 0.4 (not yet in tcllib).  The only part that is not there yet is encrypting the output.


login: rkeene
username: rkeene
mimetype: text/plain
icomment:
  pki 0.5 ( http://www.rkeene.org/devel/pki/pki-0.5.tar.gz ) now supports emitting password-protected private keys -- feature request complete.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Does this mean that the change/code has been committed to the Tcllib Fossil Repository ?
  If not, then this is not truly done, and should not be closed.
  I am willing to do this, if necessary.


mimetype: text/plain
icomment:
  something i realized after a few tests.  The key set is not always generated with the equal amount of bits specified, and that is what causes the problem at the time of the signing.

  Something that may patch the problem (not the actual fix) would be to recalculate the bitlenth using the way parse_key proc does and set retkey(l) to that value before returning the set of values at the end of the generate proc.


mimetype: text/plain
icomment:
  I uploaded a different algorithm that works for me, still slow on the prime search on bigger keys (2048)

  hope it helps


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Committed: http://core.tcl.tk/tklib/info/a6173e19d4
  Pushed.
  Bad that this was closed as fixed with the fixes just attached, and not actually committed :(
  See also patch 3607261.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Does  a good usecase exist for an empty servicename?

  If not, i would simply document that servicename may not be empty and add a check for that. Otherwise some more work is needed to enable empty names.


login: heinrichmartin
username: heinrichmartin
mimetype: text/plain
icomment:
  I would have considered the root service the default for all other ones. This seems easier than many non-empty roots...
  A message usecase might be during cmdline param checks.
  Any workaround like "logger::init _" does not provide inheritance.

  But I see, that it might be much more work.
  Preventing the infinite loop should be the primary goal :-)


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

  Added some new tests and a new error code for this.

  Empty names or names that are just : or ::: etc. now raise an error on init.

  The idea of a global logger to ease the setup is surely a good thing, but using the empty logger for that would be a little difficult with the current style.


login: mic42
username: mic42
mimetype: text/plain
icomment:
  Good catch. The default loglevel wasn't propagated for the lowest level loggers.
  Fixed with 0.9.2 (in cvs).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thank you. Fixed in the CVS head now.
  Bumped version number to 1.9.
  Kept the 8.4-ism you had patched out and made the package require Tcl 8.4 instead.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The valid YAML
      x: [ "a": "b", "c": "d" ]

  is mis-translated as          {x {a b c d}}
  It should be translated as {x {{a b} {c d}}
  I.e. the value x is mapped to is a sequence of pair-mappings, not a plain sequence.


login: tmmenezes
username: tmmenezes
mimetype: text/plain
icomment:
  The bug is located at:

  proc ::crc::crc-ccitt {args} {
      return [eval [list crc -impl [namespace origin CRC-CCITT] -seed 0xFFFF]\
                  $args]
  }

  and can be fixed by appending '--' at the end of all the options, and before $args:

  proc ::crc::crc-ccitt {args} {
      return [eval [list crc -impl [namespace origin CRC-CCITT] -seed 0xFFFF --]\
                  $args]
  }


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

  Typically tcl commands use "--" to indicate the end of option processing. If you always add this before the data parameter then you can avoid this problem in many commands that accept options (for instance, switch is best used as 'switch -exact -- $option { .... }').
  However, it is also quite simple to handle a final data parameter that happens to have a leading hyphen. This was fixed previously for crc32 and other tcllib functions. I've applied the same fix here. In the meantime - use '--'.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Some questions after reading the code:

  Your rotext seems to disable interactive editing (i.e. anything done through the bindings), and allow non-interactive (programmatic) editing. Is that right ?

  Is this based per-chance on some code on the Tcler's Wiki (http://wiki.tcl.tk) ?
  If yes, that are the page numbers ?

  Note that an alternative way of doing a rotext is wrap around text and disable the 'insert' and 'delete' method, without touching the bindings . This will disable all editing, interactive and programmatic. The latter can then be restored by providing differently named methods for programmatic access.


login: daapp
username: daapp
mimetype: text/plain
icomment:
  > Your rotext seems to disable interactive editing (i.e. anything done
  > through the bindings), and allow non-interactive (programmatic) editing. Is
  > that right ?

  Yes, you are right.

  >
  > Is this based per-chance on some code on the Tcler's Wiki
  > (http://wiki.tcl.tk) ?
  > If yes, that are the page numbers ?

  I write this code myself, but idea is so simple, so may be wiki contains simular code.

  >
  > Note that an alternative way of doing a rotext is wrap around text and
  > disable the 'insert' and 'delete' method, without touching the bindings .
  > This will disable all editing, interactive and programmatic. The latter can
  > then be restored by providing differently named methods for programmatic
  > access.
  >

  I saw such alternative code on the Tcl wiki, but my idea was leave text api as is, just disable interactive editing. Example, in my application I have one text widget for code editing, one other text widget for viewing this code after some preprocessor. Also, I found this widget useful in some other situations.

  P.S: may be it will be good to add my code  to widget::scrolledtext, but this at your discretion.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Accepted, and committed to CVS head.

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

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


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

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

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

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


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

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


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

  I concur, that is a var name typo. Fixed in CVS head.
  Side note: modules/pt is the successor to the grammar_peg and grammar_me modules.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The cause of the change is, I suspect, a change in textutil:

  * adjust.tcl (::textutil::adjust::undent): Fixed whitespace regexp
  * adjust.man: which lost the tab character. Rewritten to make it
  * pkgIndex.tcl: less likely to happen again. Bumped to 0.7.1.

  That was a last-second change just before releasing 1.14. I fixed a bug which had caused a leading \t to not be removed by the 'undent' command. So, the expected result is wrong and the new actual result is right, the \t gets removed, now.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Documentation updated on CVS.
  Thank you for reporting!

  Technically, it would not be a big issue to make -selectfill r/w but IMHO this is not very important.


login: wkechel
username: wkechel
mimetype: text/plain
icomment:
  Agreed, I also checked for it when looking for the reason why selectfill did not work, so I already added code to configure to handle it properly, but I decided as well that setting the options during creation is fine.


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

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Dear Wolfgang,
  thank you for the bug report.
  I am sorry, IMHO the report is not adequate because it uses the widget not the way it is documented.
  You should use the frame returned by "getframe" to place any childs in.

  Please do:

  set sw [ScrolledWindow .t.s -auto none]
  set cw [$sw getframe]
  text $cw.t -width 10 -height 4

  ---
  Or am I missing something?
  Regards,
  Harald


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


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


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

  Please update files entry.tcl and combobox.tcl

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


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Patch looks ok.
  Would be helpful if a demonstation script would be provided.

  Committed to csv.

  Thank you, Wolfgang !
  Harald


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


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

  Revision [6205def19e5f9a12f1ea7e896d578ae695efb6aa].
  Pushed.

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  And we have to put '-no-apps' into the targets 'install-doc' and 'install-libraries', to prevent them from trying to install things beyond what they are supposed to install.


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

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


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Attached a patch (unified diff) of a possible fix for this.
  Please test.
  If possible please provide a small test script demonstrating the issue also.
  Something I can add to the package's testsuite.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Very good initiative.
  I caused that (by a bwidget release), but don't know how to fix it.

  Any clues welcome,
  Harald


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Unfortunately I do not know either. As far as I know SourceForge automatically takes the last release of anything as the download link, and that it can't be overridden, except by another release.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  I recently added the Tcllib 1.15 release, yet SF still displays bwidget 1.9.6 as the latest.
  I have no idea what is going on here with SF.


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


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


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

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

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

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

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


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

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

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

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


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


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

  This seems to be an issue with Tcl 8.5 or higher, where errorCode will be left unset until the first actual error, caught or not.

  Committed revision  [ea86982e87].


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The aes::aes command already accepts a (currently undocumented) option -- (double-dash) which stops option processing and forces interpretation of data, even if starting with a dash. See line 532, about 10 lines after where you patched.

  Is that good enough for your case (plus documenting this option) ?


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

  Decided to accept the change, as it should be pretty much backward compatible.
  Additionally documented the option -- also.
  Version bumped to 1.1. (Visible API change).
  I am lucky that this package does not have C accelerator code requiring the change also.
  That said, getting some C code here for speed would be nice.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Accepted with some changes:
  - New version is 0.8, as this is a new feature, i.e. backward compatible API extension. Not a bugfix.
  - The argument is called 'delMode' instead of 'forceDel'. The original name evokes a boolean flag, which the argument is not.
  - The default value is "auto" for the existing behaviour.
  - The new behaviour is activated for delMode == "always".
  - Added a test case.
  - Because of the use of "ne" ("eq" respectively) version 0.8 requires Tcl 8.4 instead of 8.3.


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

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


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

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


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

  Applied the patch, extended testsuite. Bumped version to 1.8.2.
  Committed. Pushed. (Fossil repository setup working).


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

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


login: cwjolly
username: cwjolly
mimetype: text/plain
icomment:
  Sorry I should have included the prior Bug # searching for it was not as obvious as I had thought. 
  Here it is : 3147481


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

  Thank you. I am closing this one as a duplicate then, and handle the changes under the original report.


login: twylite
username: twylite
mimetype: text/plain
icomment:
  Proposed fixes pushed to branch bug-3601370-td.

  In combination with the Tcl tcltk-man2html fixes it looks like the only remaining issues are invalid copyright statements:

  expander: COPYRIGHT: merge-copyrights: unrecognised format: Copyright (c) William H. Duquette, http://www.wjduquette.com/expand
  namespacex: COPYRIGHT: merge-copyrights: unrecognised format: Copyright (c) 200? Neil Madden (http://wiki.tcl.tk/12790)
  namespacex: COPYRIGHT: merge-copyrights: unrecognised format: Copyright (c) 200? Various (http://wiki.tcl.tk/1489)
  smtpd: COPYRIGHT: merge-copyrights: unrecognised format: Copyright (c) Pat Thoyts <patthoyts@users.sourceforge.net>
  soundex: COPYRIGHT: merge-copyrights: unrecognised format: Copyright (c) ????, Algorithm: Donald E. Knuth

  I think it would be a good idea for the doctools checker to include a check that the manpage name does not contain spaces, and to warn if the copyright statement has an inappropriate format.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  New revision on the branch: [6606f5686a].

  Added check to manpage_begin, reject spaces in
  title. Message catalogs extended with new warning 'mptitle' for
  spaces in the manpage title. The french catalog contains the english
  text, and needs a translation.

  For the copyright check I would need a nice regexp, or two.

  Even without that check, and the missing french translation of my change I see no trouble to merge this into the

  tcllib-1-15-rc

  branch and work in that.


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

  Merged into the release branch now. Bumped version to 1.4.14. Closing. Reopen or create new bug for the missing french translation of the new warning message, and/or the regexes to check for issues with copyright lines.


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


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

  If yes, please attach here.


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


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

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

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


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

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


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

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

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

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

  Regards,
  Frank Gover


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


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

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

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

  Regards,
  Frank Gover


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

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

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

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

  Please test. (I already did, using examples/canvas/citygrid.tcl, see the new statements it has).
  After it passes muster I will merge to trunk and release branches.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks Pietro. I will work on getting this into the code in the next days.
  And I am glad to hear that the %D formatting is a fix too.

  (I guess that the %D formatting is also affected by the TZ, in the inverse manner to the iso parser, thus canceling the TZ).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Revision [343787b53ab6a48bf6f0c15032d808d16f7a3862].
  Pushed.
  Version in Fossil now is 0.5.


login: exgerhardr
username: exgerhardr
mimetype: text/plain
icomment:
  allow_comments - 0

  File (patched version) added:  imap4-0.5.tgz
  Content: ChangeLog, imap4.man, imap4.tcl, pkgIndex.tcl
  Bug repaired.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Gerhard, how does the attached tarball compare against the changes I made?
  See https://core.tcl.tk/tcllib/ci/343787b53a?sbs=0
  Also, contact me by mail so that I can re-create a dev account for you at the fossil repository.


login: exgerhardr
username: exgerhardr
mimetype: text/plain
icomment:
  Andreas, basically all your changes are included in my tgz, but in addition a bug is repaired (which was never reported).
  I've added a diff (imap4-0.51.patch) against your version 0.5 (https://core.tcl.tk/tcllib/ci/343787b53a?sbs=0), so this patch only removes the bug now. 


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Thanks Gerhard.
  Reviewing the change it seems that the bug could only trigger for bad data, when trying to report that problem.
  That explains why we have not seen it before, nobody had bad data, it seems.
  And without a test suite at all where error could be forced it was never detected.

  Ok. Accepted.
  Revision [b3a3d726b1].
  Pushed.
  Version bumped to 0.5.1.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Problem confirmed. Aslo confirmed that it does not appear for Tcl 8.5.
  First hypothesis that the ensemblification of the "namespace" command in8.6 may play a role.

  hephaistos:(506) ~/Projects/Tcllib/tcllib > ../1.TestSupport/8.5/Install/bin/tclsh8.5
  % info commands name*
  namespace
  % namespace ensemble exists ::namespace
  0

  hephaistos:(507) ~/Projects/Tcllib/tcllib > ../1.TestSupport/8.6/Install/bin/tclsh8.6
  % info commands name*
  namespace
  % namespace ensemble exists ::namespace
  1

  Side note for the curious.

      ./sak.tcl validate

  does not run the per-package testsuites per se, that is done by

      ./sak.tcl test run


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hah. The problem is the line immediately before, the 'namespace delete ::tcl'.
  In 8.6, with namespace ensemblified the implementations of the namespace methods are in that name, and deleted. At which point the namespace command is broken and gone.

  I think, I should not kill the ::tcl namespace in 8.6. It has started to contain necessary commands.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Fixed.
  Committed: https://core.tcl.tk/tcllib/info/367195678d
  Pushed.

  Thank you for the report.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hm ... Oh! For Tcllib 1.15 I modified the "json::write" package to not quote "/" characters as "\/" anymore.
  While legal as per JSON syntax it is not really necessary.

  Compare {\"is\":\"/
  Versus  {\"is\":\"\\/

  This is "just" a case of the testsuite requiring an update. Not a bug in the package.
  And me forgetting to run the full testsuite after all the changes going into the release.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Bah. Nothing weird about it. It is essentially just a debug command left active in the math-12.1 test case.
  Committed: http://core.tcl.tk/tcllib/info/77088c0306
  Pushed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Confirmed
  variable  - modules/virtchannel_base
  string    - modules/virtchannel_base
  zlib      - modules/virtchannel_transform
  coroutine - modules/coroutine

  The standard way of fixing things is add the prefix "tcllib_" to the manpages in question.
  (We already have several others so fixed).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Committed: http://core.tcl.tk/tklib/info/a6173e19d4
  Pushed.
  See bug 3458158 for the actual changes chosen.
  Apparently a long-existing fix to the problem which was never committed, just attached to its bug.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Fixed: http://core.tcl.tk/tcllib/info/f42362cde9
  Version of struct::queue bumped to 1.4.5.
  Merged: http://core.tcl.tk/tcllib/info/97d8e58276
  Pushed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hm. Will have to search where the code comes from. 
  "configure" is a generated file.
  Patches to it make no sense because the next time it is generated from configure.in (and tclconfig.m4, etc.) the change will be gone. Will have to grep where the sources for this line are.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Extended testsuite, problem confirmed.
  lassign is unfortunately Tcl 8.5+ and this package is Tcl 8.2+.
  Going with direct check for empty input.
  Extended testsuite passes.
  Committed: https://core.tcl.tk/tcllib/info/0a9faf2cbe
  Pushed.
  Version 1.2.1 of package 'ip'.
  Thank you.


login: droll
username: droll
mimetype: text/plain
icomment:
  allow_comments - 1

  This has been fixed in TEPAM 0.4.1 that has been commited on March, 25th, 2013.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Confirmed. I will talk to the original author (Donal Fellows) about this.
  It might be that he simply wrote the example wrong. Especially as the
  following code does work, using 'singleton' in place of 'class'. 

  ooutil::singleton create example {
      method foo {} {self}
  }

  puts [[example new] foo]
  puts [[example new] foo]

  Note: Given that the package is named "oo::util" (with ::) I will rename
     ooutil::singleton
  to oo::util::singleton
  shortly.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Thanks for the patch.
  I applied it now, with changes.

  See branch "apn-dtplite-kwlinks", revision http://core.tcl.tk/tcllib/info/44d847703f
  Please test if my changes still work for you.

  (1) Fixed your bug-fix in "HeaderSetup", added comments explaining the conditions.
  (2) Disabled "IdxWrite" when no keywords were found.
       This means that not only the navbar links are gone, but the essentially empty "index.html" as well.
  (3) Consolidated the check into a proc [HaveKeywords].
  (4) Got rid of the superfluous "kwpresent" flag. We need only "kwid".


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Thanks, will try it out. 

  The reason for the extraneous kwpresent was that with -merge option I was finding kwid always empty. Perhaps I was looking in the wrong spot.

  Will try your changes and let you know.

  /Ashok


login: apnadkarni
username: apnadkarni
mimetype: text/plain
icomment:
  Just tried it out, with and without keywords, with and without -merge option, and seems to work as desired in all cases. Thanks!


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  Committed: http://core.tcl.tk/tcllib/info/7593991c41 (Updates to collateral, bumped version to 1.1).
  Merged: http://core.tcl.tk/tcllib/info/c148f532c8
  Pushed.
  Completed.


login: teopetuk
username: teopetuk
mimetype: text/plain
icomment:
  Well, given that the other app in tklib is called 'bitmap-editor', I'd choose something like 'diagram-processor'.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  allow_comments - 1

  New name: diagram-viewer
  Committed: http://core.tcl.tk/tklib/info/f294879b5c
  Pushed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Is it possible to provide us with a small script demonstrating how to cause the problem, i.e. crash ?


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  I uploaded a small script which reflects a very minimalized version of what is going on in my program. The program runs in a infinite while loop pausing for 60 seconds then rechecking for new files. The program runs continuously. I had a log with the error in it and unfortunately deleted it. It's actually not hard crashing but instead throws a "error" msg with a trace back to the close statement. Since this trace is really not helpful, as it's not really an error in my code, it seems more reasonable to catch this event and pass a more appropriate error msg and not dump a code trace.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Hm. The script looks ok. I will try to reproduce this with some fake ftp server and files.

  (Note: I am uncomfortable with simply putting in a catch without understanding why the close threw an error. It feels too much like simply plastering over hole without killing the termite which created it).

  A pity that you deleted the log already, or I would have asked for the relevant part of it.
  Do you remember what the error message was ? (close has several conditions where it can throw an error, with distinctive messages).


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  Ya, I don't remember what the exact error was. I will change things back to the original state and see if it will fail again. Once I have a log I will upload it.


login: guitarzar
username: guitarzar
mimetype: text/plain
icomment:
  allow_comments - 1

  I'm closing this. I think the following was happening: The connection was open, files being transferred, connection was broken by external forces, my app then tried to close the connection but it was already close. This triggered an error. The catch on your close included dumping the error info and we got an odd dump of stuff from a different catch being done in my app that made it look like my app was crashing. I have now utilized your -output option to redirect your output to a proc and I also added clearing the ::errorInfo var to my app so the odd dump is not longer involved. I think this is basically a false alarm. Sorry about that.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  No problem, and glad to hear that you figured it out.
  A bug where I have not to do anything is the best kind of bug ;)


login: aku
mimetype: text/plain
icomment:
  I can confirm for head of Tcllib.

  I do note something for the case not using the -in option, something you may have overlooked. The result of decrypting is terminated with a \000 character. When using the -in option the garbage comes after the same \000 character.

  I am not sure if that is intentional or not. Because of that the output is not identical to the original input even when not using the -in option.

  Investigation in progress.

  ---

  Ok, we are in ECB mode, which always pads input to 16 bytes.
  And the issue in Chunk was, if nothing was read, it still generated a padded chunk of 16 \0's from that and then decrypted it. The result was the garbage seen.
  Short-circuiting on length 0 fixes the error.

  ---

  Fixed. Committed. Pushed.
  Revision: [eb0e6a2524]


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Better quoting would be

  set ProcName [uplevel 2 [list info command $ProcName]]"

  in case proc name contains spaces.


login: droll
username: droll
mimetype: text/plain
icomment:
  Stephen,
  Please check my comment I posted on May 21. For me this issue is already fixed in the newest package that is inside the Fossil repository (revision 0.4.1 from March 25th). Please confirm.
  Thanks,
  Andreas


login: blacksqr
username: blacksqr
mimetype: text/plain
icomment:
  I have downloaded version 0.4.1 from fossil.  It passes the test script and I have put it into my application where it works fine.  I consider the issue closed.


login: aku
mimetype: text/plain
icomment:
  It has been confirmed that TEPAM revision 0.4.1 of the Fossil repository (http://core.tcl.tk/tcllib/dir?ci=07518949a0ede378&name=modules/tepam) fixes already this issue.


login: aku
mimetype: text/plain
icomment:
  I have no idea about the intent of the package author here, and have to defer to him. Re-assigning the bug to the author.


login: aku
mimetype: text/plain
icomment:
  Added 303 to the set of status codes returning a location error.
  Revision: [f5f8b6a8ec]
  If a different error is wanted, or a different way of handling
  please re-open and specify 'understand' more exactly.


login: haneef
username: haneef
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=109670

  I am not sure what has happened but I thought I had a few 
  comments when I submitted the patch. In any case, the 
  submitted patch contains enahncements to the tabbed 
  notebook widget such that the tabs now support a bevel. The 
  patch also includes the doc changes, change to the demo.

  If there is something wrong with the patch please let me 
  know. My registered email address with SF was broken. It 
  should be fixed now.

  Regards,
  Haneef


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  The use of "string equal" makes this version of tcllib dependent on Tcl 8.4.
  Do we want this (already) ? 


login: ericm
username: ericm
mimetype: text/plain
icomment:
  [string equal] has been around since 8.2.  I think it's fine to require at least 8.2.  In the future, tcllib may require the latest stable release, which is fine too.  Users who need an older version can get an older version.

  We might want to make the dependence explicit, however, with a [package require Tcl 8.2].

  Eric Melski
  The Other Tcl Guy
  Interwoven, Inc
  ericm at interwoven.com


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Yes, this is noted in a different report here too, see
  #232017.
  I would accept the patch and add it to the CVS, but it is
  currently assigned to Scott Redman (It doesn't show here,
  but in the list of Bugs).


login: stevel
username: stevel
mimetype: text/plain
icomment:
  Patch Code - Modified - New Version

  Also added synonym "-bg" for -background (required by ComboBox mega-widget)


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  I used a slightly different fix that will accept normal or 
  enabled (actually only worries if "disabled" is passed 
  in).  This is in 1.3.1.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Both smtp and mime package come from Marshall T. Rose and he
  developement this way, i.e. in the same directory. They also
  depend on each other.

  As about the category list, I guess it was forgotten to
  extend this.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Ok, I now know why smtp is not part of the list of packages
  in the full package index: It is a consequence that mime and
  smtp are in the same directory. The main Makefile.in in
  just  assumes that the list of directories below modules is
  equal to the list of packages in tcllib.

  For now I madee a patch which adds smtp explicitly to the
  list of packages to list in the main package index.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  See patch #411422.
  Also added categories for the missing and new packages in
  tcllib.


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=86324

  The latest edition of listbox.n correctly documents the
  option as "-listvariable" (as of 2000/08/25).  The BWidget
  code is OK.

  I added a bwidget category for bugs in the tcllib project.

  Eric Melski
  The Other Tcl Guy


login: vincentdarley
username: vincentdarley
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=32170

  I see the same problem -- a clean download of tcllib fails 
  to do anything with './configure' on Cygwin.  This seems to 
  be the usual issue where TEA is supposed to help everyone, 
  but instead fails miserably.  Can't we have a simple .tcl 
  file to install 'tcllib'.  It could easily list the set of 
  all packages included with a simple 'glob' and we'd never 
  have to mess with makefiles and configure scripts again.


login: das
username: das
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=90580

  on a linux box I managed to install from a cvs checkout by 
  doing the following in tcllib/

  ln -s . config

  and adding this mkinstalldirs script to tcllib/

  #! /bin/sh
  # mkinstalldirs --- make directory hierarchy
  # Author: Noah Friedman <friedman@prep.ai.mit.edu>
  # Created: 1993-05-16
  # Public domain

  # $Id: mkinstalldirs,v 1.1.2.1 2001/02/15 18:32:31 dgoddeau 
  Exp $

  errstatus=0

  for file
  do
     set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// 
  /g;s/^#/\//;p'`
     shift

     pathcomp=
     for d
     do
       pathcomp="$pathcomp$d"
       case "$pathcomp" in
         -* ) pathcomp=./$pathcomp ;;
       esac

       if test ! -d "$pathcomp"; then
          echo "mkdir $pathcomp"

          mkdir "$pathcomp" || lasterr=$?

          if test ! -d "$pathcomp"; then
            errstatus=$lasterr
          fi
       fi

       pathcomp="$pathcomp/"
     done
  done

  exit $errstatus

  # mkinstalldirs ends here


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  I've had the same problems since I started playing with the 
  TclLib CVS about a month ago.
  I used a standard linux box, tho with tcl8.4a3 installed in 
  my shell's root vs. the default install locations.
  It took me a while, but I finally got past this by opening 
  the configure file and removing the /config part of the 
  path call that was tripping it up.  After that mess, it 
  errored on looking for a mkinstalldirs file, which I fixed 
  by digging up a copy and sticking it in the src dir.

  At any rate, maybe it's just me, but there seems to be an 
  enormous lack of simple documentation with tcllib.  I 
  understand of course that it's still under development and 
  docs are not going to be complete for some time, but I am 
  refering to even the most basic of instructions as far as 
  installation and using the mkIndex & mkInstallScripts 
  files.  Obviously every machine is going to be a little 
  different, but it might not be a bad idea to put a hint or 
  two in the readme file next time you have 5-10 minutes 
  available.
  Aside from that, my only gripe is that the struct module 
  makes me painfully aware of my need to learn higher level 
  scripting/programming formats.  But alas, that's one "bug" 
  I KNOW won't ever make it on your "TODO" lists.  ;)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is something we can fix for "releases".

  But trying to fix this for plain checkouts
  will get us a lot of duplication for the
  stuff in the config directory.

  Alternate solution: A checkout script which
  retrieves all required parts ... 


login: lduperval
username: lduperval
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=40456

  Can this be fixed by putting an entry either in the README or the
  configure.in that says *where* to find the config directory? Ideally, it 
  should be part of the tcllib CVS repository then any other module
  which requires it would require a checkout of tcllib/config.

  I *still* don't know where to find it. Fortunately, someoen made a
  "mistake" in tklib and checked in the config directory. That's where I got a copy.


login: vincentdarley
username: vincentdarley
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=32170

  I can't believe this bug still hasn't been fixed.  Why oh 
  why do we want to make things so difficult for new users.

  This seems to be a recurring problem with Tcl.  I install 
  Tcl.  Now I want to install package 'X'.  I download X. But 
  now package X needs something else, 'Y'.  Unfortunately 
  there are no instructions telling me where to get Y, and I 
  wasn't informed when I downloaded X that I would also need 
  to download something else.

  The whole point of Tcl is to be easy and cross-platform and 
  nice, but it gets held back by completely ridiculous things 
  like a 'config' module being missing.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fix committed to CVS.
  tclpro/config is now duplicated in tcllib/config


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  I cannot confirm this as a bug on win2k. I'm attaching the
  test server script I ran on using Tcl 8.3.4 on windows 2000.
  I then used the MS command line ftp client to get test.file.
  The file transfer was successful.

  Please try using this example script and see if there is
  still a problem. As this is an anonymous bug - if I don't
  get any feedback within a week or so then I'll consider this
  bug closed.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  The two supplied examples appear the same, but perhaps the 
  user meant to type something else in.  I also don't see an 
  attached patch.  This needs to be better defined to be 
  fixed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Does the same thing happen in the "counter" module ?
  (One of the two modules supercedes the other, the other
  is deprecated. Brent knows which is which).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Note: stats is definitely deprecated. Please try the 
  counter module and see if it contains the same problem.


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=68433

  This is a bug in the ftpd package: it's generating an
  incorrectly formatted multi-line reply.

  I've update ftpd.tcl (r1.11 -> r1.12) as above to generate a
  single-line reply.
  (This may not be entirely correct, as '$f' may itself
  contain newlines, but it fixes the immediate problem.)

  According to RFC959 section 4.2 "FTP Replies", multi-line
  replies must be indicated with a hyphen after the status
  code, and the last line of the reply must begin with the
  status code followed by a space, e.g.:

  puts $sock "500-Copy failed:\n$path\n$f\n500 blah."


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The wiki page http://mini.net/tcl/693.html
  lists some applications with partial IMAP
  support built into them.

  We can start from these.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Your help is appreciated.

  An incomplete codebase for imap4 was committed today to the
  CVS head of Tcllib here at Sourceforge. The author is
  Salvatore Sanfilippo. Contact information can be found in
  the code. This code is not ready, is has not even a package
  index, nor version number. It is however something which can
  definitely be used for testing, debugging and
  experimentation in general.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  This is using the 'pipe' command from Tclx. As such it
  doesn't meet the requirements for tcllib that it should not
  rely on compiled extensions.

  If there is a method for substituting the 'pipe' command
  with something else when Tclx is not available then this
  looks like a fine candidate for the control module of tcllib.

  Comments?


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  dups 429384.  Thoyts notes that it uses the TclX pipe 
  command, so an alternative implementation is needed.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I will compare this to the MD5 speedup patch done by Donal
  Fellows before committing.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 7671: 1.diff

  Logged In: YES 
  user_id=75003

  Attached the final patch, speeding up base64 and md5, adding
  sha1.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 7493: 0.diff

  Logged In: YES 
  user_id=75003

  Here is the patch. Moving the line causes my emacs to not
  recognize it anymore, pity. So I see it as better to remove
  it completely.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 7494: 1.diff

  Logged In: YES 
  user_id=75003

  Ok, next version of the patch,removing the faulty line in
  md5.n, report.n and struct/matrix.n too.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Next version of the patch, made after running the newest
  frink, v2.1.3, against tcllib. This cut down on the number
  of bogus 'missing final return' quite good.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 7675: 8.diff

  Logged In: YES 
  user_id=75003

  Final patch, frink 2.1.5, new sha1, changed md5, base64.


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=86324

  * tree.tcl: Corrected keyboard navigation so that open/close
  commands are invoked when right/left arrows are used to
  open/close
  nodes, patch from [Bug #435097].  Also corrected keyboard
  navigation on right arrow press; previously only opened
  closed
  nodes that had children, but should always open nodes,
  regardless
  of whether it has children.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  I believe these were addressed by Jos' patch 483838 applied 
  to 1.4.0cvs.


login: bach
username: bach
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=98533

  I found the place where to set the focus. I've attached the new passwddlg.tcl (taken from nightly cvs)


login: bach
username: bach
mimetype: text/plain
icomment:
  File Added - 7806: passwddlg.tcl

  Logged In: YES 
  user_id=98533

  Darn, Opera didn't attach the file the first time, sorry.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This seems to contain a backward incompatible
  change, the removal of "-editable", right ?

  What was the effect of the removed option ?


login: bach
username: bach
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=98533

  Nope, there was no -editable option for the passwddialog,
  just a -passwdeditable.

  Just on the contrary, the changes re-enable the -editable
  option
  for the login LabelEntry (I don't know why it was removed in
  the first place), and renames this to -logineditable for
  consistency.

  Step by step explanation:

  The login field inherits its options from a standard
  LabelEntry with the line

    Widget::bwinclude PasswdDlg LabelEntry .frame.lablog

  and then removes some of its feature in the following line

    remove [list -command  ***-editable*** -justify -name
  -show -side ... 

  The -editable (which I emphasized by asterisks) happens to
  be among them. So, by removing -editable from the remove
  list, -editable is in fact reinstated.

  Then, by adding the -editable to the 'prefix' line tells
  BWidget to rename the -editable for the login entry to
  -logineditable by prefixing 'login' to -editable.

    prefix [list login -editable -helptext -helpvar -label
  -text \ ... 

  This is to achieve consistency with the existing
  -passwdeditable option.

  So, this change is fully backward compatible.

  The full patch (including the change to focus setting) are
  in the uploaded file. The changes discussed above (in the
  very first lines of the file) are accompanied by a change
  that sets the focus to the login entry or passwd entry
  depending on the respective editable flag (search for 'bach'
  in the code, it's around line 119).

  Salut,
        Bastien


login: bach
username: bach
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=98533

  I couldn't reproduce this in the CVS version from 21.06.2001. Please specify the version you used.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I used wish 8.4a3 (ActiveTcl 8.3.3.3) and the
  current head of bwidgets (Sep 6, 2001). The
  demo executed correctly.


login: bach
username: bach
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=98533

  Followup: a thread on clt gave this workaround (I've put a
  feature request
  at the bottom):

  On Thu, 28 Jun 2001 09:17:19 GMT, Jos Decoster
  <decoster@retarget.com> wrote:   
  >The ListBox and Tree are drawn in a canvas. In the 1.2.1
  release, this canvas  
  >was create with the path-name you supplied. In the current
  CVS release, first a
  >frame is created with class ListBox or Tree (to better
  handle option database  
  >stuff) and in this frame a canvas is
  packed:                                   
  >[...]                                                                          
  >You could try to
  use:                                                          
  >                                                                               
  >       bind .t.c <ButtonPress-3>
  {foo}                                         
  >       bind .l.c <ButtonPress-3>
  {bar}                                         

  This works, put I'd prefer not to use BWidget internal
  naming schemes.
  So I'll request a new command for tree.tcl and listbox.tcl:

        .t getCanvas
        .l getCanvas

  like the 'getFrame' command from panedwindow.tcl.

  Salut,
          Bastien


login: norganos
username: norganos
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=418919

  perhaps bind them to .tree.c or .list.c, the canvas itself? 
  i just know, that i had something similar, that worked 
  after i binded it to the canvas...


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  This bug was assigned to me, but I'm not responsible for adding 
  mclistbox to sourceforge. Someobody else did that and added
  the configure script. I don't even know if that version is
  the same as the 
  version I maintain (though it probably is, as I haven't
  fixed any bugs
  in mclistbox in ages).

  There has been a tiny bit of interest in putting this in
  tklib, but I 
  don't have the time to do it right now. I guess we should ping 
  whomever put the code in tcllib originally.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  I'm fairly sure those are necessary, and their parentage is 
  also necessary due to limitations with how things might 
  otherwise communicate.  As this is really just a problem 
  interactively, the only thing really needed is a better way 
  to filter out that stuff.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10811: 439016.diff

  Logged In: YES 
  user_id=75003

  Enclosed an updated patch. I added nroff documentation for 
  the two functions,  reformatted the tcl code to adhere to 
  the general style of tcl (indentation) and braced several 
  expressions for speed.

  Test question: What happens if I feed a string already 
  containing tabs in some positions to tabify ? Are these
  taken into account when replacing spaces ? I believe not.

  Algorithm question: Why does it work backward through a 
  line ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Two more testcases showing that tabifyLine does not handle 
  existing tabs properly.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10891: 439016.diff.1

  Logged In: YES 
  user_id=75003

  New patch containing a corrected version of tabify.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Larry, you have tested tcllib using tcl8.4aXX from the CVS. 
  This interpreter had some changes in the error messages 
  thrown for illegal # arguments for procedures.

  The errors in the testsuite should go away if you use a Tcl 
  8.3.3 interpreter.

  Making the testsuite robust against such changes is 
  difficult.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9753: 440051.diff

  Logged In: YES 
  user_id=75003

  The reference is #440046.
  Added patch fixing the problem.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10896: 440064.diff

  Logged In: YES 
  user_id=75003

  Patch updated to current tcllib, also changed to unix EOL 
  convention.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  This has been added to 1.4.0cvs, but undoc'ed for the 
  moment.  '.' is used, as that should be sufficient for 
  getting color info.  The only time that won't work is in a 
  multi-screen situation where . is on another screen, and 
  that screen uses a different visual (very rare).


login: deery
username: deery
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=278157


  P.S. OK... I could have sworn I tested my fix correctly, 
  but Wish now complains about the (obviously) missing curly 
  braces. The workaround should read:

      fconfigure $chan -translation { binary crlf }

  -- AH.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Actually I cannot see a reason for the binary on the input 
  side either. It should be auto. I.e. lenient if the server 
  doesn't do the EOLs correctly. I'll have to query Scott 
  Redman about this, I guess.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Scott's answer is that MS Exchange will not work without 
  the translation binary. Maybe this server expects LF only 
  for commands. Is there a way to identify MS Exchange 
  server, maybe through some string in their greeting ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9182: tcllib.3.diff

  Logged In: YES 
  user_id=75003

  Added a patch to fix this problem and also [443619] and 
  [443645]. The patch also fixes some unreported bugs 
  introduced by the change to a faster RETR: The fast code 
  does not EOL-translation on the incoming data and also does 
  not unstuff .-stuffed lines. Both is done now, courtesy of 
  [string map].

  Side note: Translation "binary" _is_ required, or we will 
  miscount the number of bytes read and try to read more than 
  the server is sending, hanging the command and thus the 
  calling script.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Yes, see revision 1.8 of the code. But this is already in 
  tcllib 0.8. Whatever, using LIST is a viable workaround.
  We should be lenient with the server and what is returned 
  by it.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  added to 1.4.0cvs.  Note that this would have worked 
  already using the 2 item list "F1 F1".


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=68433

  This looks reasonable to me.

  Files changed: mainframe.tcl : r1.8 -> r1.9


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Added patch containing manpages for base64, cmdline and 
  fileutil. ftp is not done yet.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Just saw that ftp has documentation, HTML based.
  See "modules/ftp/docs" ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10710: ftp.n

  Logged In: YES 
  user_id=75003

  Here is manpage for ftp. I used the HTML documentation as 
  template for the first sketch and then reworded it to make 
  it sound better, less stilted and more clear.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This patch is incomplete. The testcase profiler-5.1 fails, 
  because it expects a scalar 'enabled' and not an array.

  Working on this now. Always adapt and extend the testsuite 
  for new features too!


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9808: p.diff

  Logged In: YES 
  user_id=75003

  Here is the new patch. It changes the version from 0.1 to 
  0.2 too.


login: dkf
username: dkf
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=79902

  The problem is that [format] (and [binary format] too) use
  Tcl_GetIntFromObj when they would actually be better off
  using Tcl_GetLongFromObj. Unfortunately, the Tcl core is not
  that clean about the difference between these two, and most
  developers do not have a platform which differentiates
  between them (making it a bit tricky to develop fixes.)  :^(


login: dgp
username: dgp
mimetype: text/plain
icomment:
  File Added - 11019: sha1.test

  Logged In: YES 
  user_id=80530

  Now that Tcl Bug 219223 has been fixed in Tcl 8.4a4
  and Tcl 8.3.4, the errors in the sha1 package on
  64-bit platforms can be clarified.  Attached is the
  output of the sha1 test suite on a 64-bit platform.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  After TIP 72, this bug (or something similar) 
  appears on all platforms.  Try the test suite.


login: dkf
username: dkf
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=79902

  Bother! Can't attach a patch here!  Pasting instead (email
  me if you want an unmangled version):

  Index: modules/sha1/ChangeLog
  ===================================================================
  RCS file: /cvsroot/tcllib/tcllib/modules/sha1/ChangeLog,v
  retrieving revision 1.5
  diff -u -r1.5 ChangeLog
  --- modules/sha1/ChangeLog      8 Feb 2002 06:05:20
  -0000       1.5
  +++ modules/sha1/ChangeLog      20 Feb 2002 09:51:56 -0000
  @@ -1,3 +1,8 @@
  +2002-02-20  Donal K. Fellows  <fellowsd@cs.man.ac.uk>
  +
  +       * sha1.tcl (initK,sha1): Force 32-bit interpretation
  of constants
  +       larger than INT_MAX on 32-bit processors, due to
  TIP#72.
  +
   2002-02-07  Andreas Kupries 
  <andreas_kupries@users.sourceforge.net>
   
          * Version up to 1.0.2 to differentiate development
  from the
  Index: modules/sha1/sha1.tcl
  ===================================================================
  RCS file: /cvsroot/tcllib/tcllib/modules/sha1/sha1.tcl,v
  retrieving revision 1.5
  diff -u -r1.5 sha1.tcl
  --- modules/sha1/sha1.tcl       8 Feb 2002 06:05:20
  -0000       1.5
  +++ modules/sha1/sha1.tcl       20 Feb 2002 09:51:57 -0000
  @@ -97,7 +97,7 @@
                  0xCA62C1D6
              } {
                  for {set i 0} {$i < 20} {incr i} {
  -                   lappend K $t
  +                   lappend K [expr {int($t)}]
                  }
              }
          }
  @@ -180,11 +180,11 @@
   
          # initial H buffer
   
  -       set H0 0x67452301
  -       set H1 0xEFCDAB89
  -       set H2 0x98BADCFE
  -       set H3 0x10325476
  -       set H4 0xC3D2E1F0
  +       set H0 [expr {int(0x67452301)}]
  +       set H1 [expr {int(0xEFCDAB89)}]
  +       set H2 [expr {int(0x98BADCFE)}]
  +       set H3 [expr {int(0x10325476)}]
  +       set H4 [expr {int(0xC3D2E1F0)}]
   
          #
          # process message in 16-word blocks (64-byte blocks)


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  This patch restores correct operation on 32-bit
  platforms.  Still broken on 64-bit.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  To be precise, I see these test failures
  on Linux/Alpha:

  sha1 1.0.2 (pure Tcl)

  ==== sha1-2.1 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  ffffffffa9993e364706816affffffffba3e25717850c26cffffffff9cd0d89d
  ---- Result should have been (exact matching):
  a9993e364706816aba3e25717850c26c9cd0d89d
  ==== sha1-2.1 FAILED


  ==== sha1-2.2 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  ffffffff84983e441c3bd26effffffffbaae4aa1fffffffff95129e5ffffffffe54670f1
  ---- Result should have been (exact matching):
  84983e441c3bd26ebaae4aa1f95129e5e54670f1
  ==== sha1-2.2 FAILED


  ==== sha1-3.1 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffffc0044907cf645a436be66354b3dcb7efffffffff9303abb
  ---- Result should have been (exact matching):
  fbdb1d1b18aa6c08324b7d64b71fb76370690e1d
  ==== sha1-3.1 FAILED


  ==== sha1-3.2 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffff74c1c66ffffffffb6e5089bffffffffc85144c242d5b6a869e4efd1
  ---- Result should have been (exact matching):
  4c883e9bc42763641bba04185d492de00de7ce2c
  ==== sha1-3.2 FAILED


  ==== sha1-3.3 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff8754ab89ffffffff8e5c5bad7875ccf6ffffffff9177cc85fffffffff3dc8d68
  ---- Result should have been (exact matching):
  a905e79f51faa446cb5a3888b577e34577ef7fce
  ==== sha1-3.3 FAILED


  ==== sha1-3.4 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff9d4ac438ffffffffac6a9629ffffffff90d9d10dffffffffed60d04cffffffff88184cce
  ---- Result should have been (exact matching):
  369e2959eb49450338b212748f77d8ded74847bb
  ==== sha1-3.4 FAILED


  ==== sha1-3.5 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  7769bcdaffffffffe977b8731c8be7f3ffffffffd370300e4ba6b57b
  ---- Result should have been (exact matching):
  2660aeeccf432596e56f8f8260de971322e8935b
  ==== sha1-3.5 FAILED


  ==== sha1-3.6 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff8fb2eba3ffffffff945e91a8ffffffffb21478523535a8aa16695b74
  ---- Result should have been (exact matching):
  170523fd610da92dd4b4fb948a01a8365d66511a
  ==== sha1-3.6 FAILED


  ==== sha1-3.7 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffffad0202a8ffffffffe9c108f713620267fffffffff0e38586ffffffff80c745b7
  ---- Result should have been (exact matching):
  5154473317173f66212fc59365233ffd9cbaab94
  ==== sha1-3.7 FAILED


  ==== sha1-3.8 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffff82a5587fffffffff3abe5b8fffffffff0b4c383ffffffff988fd352ffffffffbbfc4493
  ---- Result should have been (exact matching):
  9e08393f6ac829c4385930ea38567dad582d958f
  ==== sha1-3.8 FAILED


  ==== sha1-3.9 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff92f662d9ffffffff923dfeb63636ae4fffffffff85226fa66b9cd7ce
  ---- Result should have been (exact matching):
  6541c34492618a052c12cb9f88fb795d97595b34
  ==== sha1-3.9 FAILED


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  Those test failures were based on a broken Tcl
  (see Tcl Bug 52690).

  Here's the real failures:
  sha1 1.0.2 (pure Tcl)

  ==== sha1-2.1 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  ffffffffa9993e364706816affffffffba3e25717850c26cffffffff9cd0d89d
  ---- Result should have been (exact matching):
  a9993e364706816aba3e25717850c26c9cd0d89d
  ==== sha1-2.1 FAILED


  ==== sha1-2.2 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  ffffffff84983e441c3bd26effffffffbaae4aa1fffffffff95129e5ffffffffe54670f1
  ---- Result should have been (exact matching):
  84983e441c3bd26ebaae4aa1f95129e5e54670f1
  ==== sha1-2.2 FAILED


  ==== sha1-3.1 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffffc0044907cf645a436be66354b3dcb7efffffffff9303abb
  ---- Result should have been (exact matching):
  fbdb1d1b18aa6c08324b7d64b71fb76370690e1d
  ==== sha1-3.1 FAILED


  ==== sha1-3.2 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffff74c1c66ffffffffb6e5089bffffffffc85144c242d5b6a869e4efd1
  ---- Result should have been (exact matching):
  4c883e9bc42763641bba04185d492de00de7ce2c
  ==== sha1-3.2 FAILED


  ==== sha1-3.3 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff8754ab89ffffffff8e5c5bad7875ccf6ffffffff9177cc85fffffffff3dc8d68
  ---- Result should have been (exact matching):
  a905e79f51faa446cb5a3888b577e34577ef7fce
  ==== sha1-3.3 FAILED


  ==== sha1-3.4 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff9d4ac438ffffffffac6a9629ffffffff90d9d10dffffffffed60d04cffffffff88184cce
  ---- Result should have been (exact matching):
  369e2959eb49450338b212748f77d8ded74847bb
  ==== sha1-3.4 FAILED


  ==== sha1-3.5 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  7769bcdaffffffffe977b8731c8be7f3ffffffffd370300e4ba6b57b
  ---- Result should have been (exact matching):
  2660aeeccf432596e56f8f8260de971322e8935b
  ==== sha1-3.5 FAILED


  ==== sha1-3.6 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff8fb2eba3ffffffff945e91a8ffffffffb21478523535a8aa16695b74
  ---- Result should have been (exact matching):
  170523fd610da92dd4b4fb948a01a8365d66511a
  ==== sha1-3.6 FAILED


  ==== sha1-3.7 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffffad0202a8ffffffffe9c108f713620267fffffffff0e38586ffffffff80c745b7
  ---- Result should have been (exact matching):
  5154473317173f66212fc59365233ffd9cbaab94
  ==== sha1-3.7 FAILED


  ==== sha1-3.8 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  fffffffff82a5587fffffffff3abe5b8fffffffff0b4c383ffffffff988fd352ffffffffbbfc4493
  ---- Result should have been (exact matching):
  9e08393f6ac829c4385930ea38567dad582d958f
  ==== sha1-3.8 FAILED


  ==== sha1-3.9 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ffffffff92f662d9ffffffff923dfeb63636ae4fffffffff85226fa66b9cd7ce
  ---- Result should have been (exact matching):
  6541c34492618a052c12cb9f88fb795d97595b34
  ==== sha1-3.9 FAILED

  Note the underlying problem appears to be that the
  sha1 package assumes all arithmetic is modulo-2^32.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  hmmm... I guess those look the same don't they?
  ^$#*&#$& ./config.site file!

  OK, *Here*'s the real test failures:

  ==== sha1-2.1 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  d5b4f54ca9993e36e86031f24706816aa1834873ba3e2571281e6df67850c26c98fdf6ae9cd0d89d
  ---- Result should have been (exact matching):
  a9993e364706816aba3e25717850c26c9cd0d89d
  ==== sha1-2.1 FAILED


  ==== sha1-2.2 sha1 FAILED
  ==== Contents of test case:

          ::sha1::sha1 $msg
      
  ---- Result was:
  a6b14ada84983e449153c7871c3bd26ee1f36da4baae4aa1e91ed56ff95129e561738f02e54670f1
  ---- Result should have been (exact matching):
  84983e441c3bd26ebaae4aa1f95129e5e54670f1
  ==== sha1-2.2 FAILED


  ==== sha1-3.1 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  dd0aac2fe7ad10bdc4ddbc4482b71c3c6f12b75887cd945543829e3113b4f2a6e2f1ad0526c48ef3
  ---- Result should have been (exact matching):
  fbdb1d1b18aa6c08324b7d64b71fb76370690e1d
  ==== sha1-3.1 FAILED


  ==== sha1-3.2 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  5a17b268d0e2fa7f2dac78a9561a86c0bf542b56d80f08539e0dc83f2e401cb464e53e7768b82066
  ---- Result should have been (exact matching):
  4c883e9bc42763641bba04185d492de00de7ce2c
  ==== sha1-3.2 FAILED


  ==== sha1-3.3 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  ea0fbc027c29d69390261ca758438a1c2f8ed3364849b033fa9a35cdcacc8a423c2dec038000cdf2
  ---- Result should have been (exact matching):
  a905e79f51faa446cb5a3888b577e34577ef7fce
  ==== sha1-3.3 FAILED


  ==== sha1-3.4 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  cc3ff427d2fbf753a1628cb921ab822b6b6bd9e34426b6e0f56f5309c5a1a77fab50fb292f23dd17
  ---- Result should have been (exact matching):
  369e2959eb49450338b212748f77d8ded74847bb
  ==== sha1-3.4 FAILED


  ==== sha1-3.5 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  1d2da43db1f9a7df97a8aba8f0bb6ccd9559b9da2e1496d7f77aa4e787acf95c47d5421a8ba82409
  ---- Result should have been (exact matching):
  2660aeeccf432596e56f8f8260de971322e8935b
  ==== sha1-3.5 FAILED


  ==== sha1-3.6 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  94a6b3c391128572ab943424d5c29d4ca1b9844afa746148dfc1bd81e2e704ddba1093e1f73eb2c
  ---- Result should have been (exact matching):
  170523fd610da92dd4b4fb948a01a8365d66511a
  ==== sha1-3.6 FAILED


  ==== sha1-3.7 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  6622b6be347a00eca598a3ba0ed2e4dd5e865a18b7413715b88aac85bbaff3d587886185c4b6807
  ---- Result should have been (exact matching):
  5154473317173f66212fc59365233ffd9cbaab94
  ==== sha1-3.7 FAILED


  ==== sha1-3.8 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  f10225d437a408968c2974b33bc2592c9b3b22a533f5ffa2f8defaa449114f19e7a418edab76fadc
  ---- Result should have been (exact matching):
  9e08393f6ac829c4385930ea38567dad582d958f
  ==== sha1-3.8 FAILED


  ==== sha1-3.9 hmac FAILED
  ==== Contents of test case:

          ::sha1::hmac $key $text
      
  ---- Result was:
  45e5a8199154232cdacc219d0f5bdf14929d2b0e1e4afad1a0ee7246a413b9965a408dca976eacb
  ---- Result should have been (exact matching):
  6541c34492618a052c12cb9f88fb795d97595b34
  ==== sha1-3.9 FAILED


login: dgp
username: dgp
mimetype: text/plain
icomment:
  File Added - 18170: 64.patch

  Logged In: YES 
  user_id=80530

  Yes, 32-bit register arithmetic assumption was the
  culprit.  Here's a patch that fixes things.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  The documentation is also out of date, also
  reporting on 1.0 instead of 1.2.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Do you have a patch for this ?

  Or alternatively can you give me an idea how to do the 
  special processing ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I should have scrolled down. Maybe I do need a coffee in 
  the morning :)


login: dkf
username: dkf
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=79902

  It seems mystifying to me; have you checked that it is not
  an [encoding] problem? If the problem really is a 64-bit
  nasty, it might be fixable with a quick [expr {...&0xff}] in
  the right spots to trim all the offending bits...


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  More data:  I see these test failures in a Tcl 8.3.3
  and in a Tcl 8.4a2 interp.  I do not see them in a
  Tcl 8.4a3 interp.

  More magical corrections from the Unicode update?

  Anyhow, a [package require Tcl 8.4] might eventually
  take care of this.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=240

  I don't see this bug anymore with tcl8.4.  It does seem to
  produce different results for the first failed test on x86 

  Test de caract=FFres accentu=FFs : =FF =FF =FF =FF et
  quelques contr=FFle=s =22=5B=7C=5D()=22

  and my linux ppc (unsigned char) machine:

  Test de caract=C3res accentu=C3s : =C3 =C3 =C3 =C3 et
  quelques contr=C3le=s =22=5B=7C=5D()=22


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  If this package needs Tcl 8.4 to work
  correctly. lets just add [package require Tcl 8.4]
  and declare victory.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Better solution, IMHO: Add known bugs section to mime 
  manpages and add info about this problem.

  Forcing the large set of 32-bitters to switch to 8.4 for a bug 
  hitting only the small 64-bit crowd is not so good IMHO.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Man page is extended now with section about known bugs, 
  and this item was filed.

  Modding down, no other change for the 1.4 release.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Apparently. No test failures for me on a x86_64 platform as
  well. Across Tcl 8.[2345].


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Thanks.

  I had the changes to pop3 ready (deery's items) by 
  yesterday evening and will commit these first (I had fixed 
  the pkgIndex.tcl as part of the changes, but not the docs) 
  and then apply yours, after suitable merging ...


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9757: 448634.diff

  Logged In: YES 
  user_id=75003

  Updated the patch to fit into the
  recent changes of the pop3 module.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  This is a problem with BWidget itself and not the ActiveTcl 
  distribution. The procedure is missing in 'color.tcl' as 
  downloaded from SourceForge.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9384: bwidget.449276.diff

  Logged In: YES 
  user_id=75003

  Added patch fixing the problem.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  Note that the control module is now created.
  Addition of this command and others will be
  taken up later.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  It would be nice to have a semaphore package, such that
  one could direct all callbacks to trigger semaphores.
  This way, even if a pacakge does not support a "wait any"
  mechanism, the semephore package could trap all callbacks
  and provide a wait any mechanism.

  this technique could be used for
  - file events
  - http::geturl
  - email::send
  - timers
  ... the list goes on.
  Anyone could thus create a package with callback, and not
  have to reveal internal variables for use with a waitany
  command. The semaphore package could then provide a waitany
  on its internal variables and there would not have to be any
  breaching of encapuslation.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  Do you have a reference for precisely what you mean
  by a "semaphore" ?  Would that be an alternative to
  wait-for-any, or something to have in addition to
  wait-for-any?


login: erempel
username: erempel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=304001

  Yes, FR 454718 is what I was talking about.
  To explain a little further...
  If a wait-any concept is added to TCL, it would be very useful, but only to implimentations
  within a given package. If a user of many packages wished to wait for one of many package
  call to complete, and only had the wait-any method available to them, they would be required
  to know the variables in each package that they should wait on. In my opinion, any requirement
  for unpublished vairable names within a package is a violation of the intent of the package construct.

  I think that a better approach would be to have a consolidated wait-any *package* that can be
  invoked (signalled) by a call-back from an underlying package. This way, the developer would not
  be required to know about internal variables, they could use a wait-any concept, and they could wait
  for one of any event accross a number of packages.

  Furthermore, developers of new packages need only impliment a call-back, and this would fully support
  a multi-package wait-any method. No other special consideration need be done by the package developer.

  Just my thoughts on this.

  Evan,


login: kenstir
username: kenstir
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=246646

  I would agree that a general wait-for-any package would be more useful, and would make it easier for a 
  client to avoid breaking encapsulation.  However, I propose moving forward with this implementation 
  anyway, because:

  * the proposed alternative, the Semaphore package (in FR 454718) does not exactly manage semaphores, 
  in the meaning of Solaris sem_wait(3R) and sem_post(3R).  The API just does not seem finished and working 
  and tested.

  * the proposed Semaphore package does not solve the wait-for-any problem, which this package has 
  solved.  Thus, this work is necessary anyhow, and we merely disagree over the eventual package layout.  
  Future package could use this wait-for-any implementation.

  * a general purpose callback mechanism would be difficult at best to get widely deployed.  The http and 
  fileevent applications mentioned are already well established in the core Tcl distribution.  To retrofit them to 
  use a general purpose mechanism would require volunteers and wide buy-in.  It would require design and a 
  detailed audit to ensure no existing code would break as a result.  Such an effort does not seem 
  cost-effective to me.

  * a client could avoid breaking encapsulation using the existing APIs together with this API.  That is, a 
  client could register a callback with the http package, set a client-specific variable, and wait for that 
  variable, avoiding the use of the undocumented $token(status) variable.


login: erempel
username: erempel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=304001

  Kenstir stated:
  * the proposed alternative, the Semaphore package (in FR 454718) does not exactly manage 
  semaphores, in the meaning of Solaris sem_wait(3R) and sem_post(3R).  The API just 
  does not seem finished and working and tested.
  -------------------
  I'm not sure what documentation regarding Solaris that you were reading, but the proposed
  semephore package does adhere to the functional description of sem_wait(R3) and sem_post(R3)
  of the Solaris man pages.

  There may be some difficulty in a threaded TCL environment, but that was highlighted in the
  FR 454718.

  ------------
  Kenstir stated:
  * a client could avoid breaking encapsulation using the existing APIs together with this API.
  That is, a client could register a callback with the http package, set a client-specific
  variable, and wait for that variable, avoiding the use of the undocumented $token(status)
  variable.
  -----------------
  I think that you were using this as an example of how the wait-for-any would work, and it is
  also an excelent example of how the semephores would work. Your description of how
  you could make a callback routine that modifies its own variables and then use wait-for-any to
  wait for these variables, is basically the way that a semephore package would work.
  The wait-for-any command is merely a more convenient way of implimenting a semephore
  package. The package would be better off standard, rather than requiring that everyone
  impliment thier own. Since http, fileevents, timers and many other tcl packages use callbacks,
  there would not need to be *any* change to any code, just the way that we use the code.
  See below how the already existing http package could be used and waited for via the
  semephore package.

  --- example TCL ---
  set afterName [after 10000 Semephore::Signal timoutName]
  set URLToken [http::geturl $someURL -command Semephore::Signal]

  if {[Semephore::Wait *] == timeoutName} then {
    http::reset $URLToken timout
  } else {
    after cancel afterName
    processHTTP $URLToken
  }

  The bottom line here is that I was trying to stimulate a waiting package for the
  TCL Standard Library. I did not wish to make any changes to the core TCL code, since this is the feature
  request for tcllib.

  I was hoping that since the semephore package was so small and straight forward that it would be
  easy for TCLers to extend to handle threaded tcl and include it in tcllib. I think that we agree that
  in TCLs current state, waiting for one of many call-backs or events is difficult.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Raising the priority of the item because its inclusion in the 
  upcoming release was proposed in the Tcllib-devel mailing list.

  Supporting or contrarian statements should be made on the 
  referenced mailing list for public discussion.


login: lingnau
username: lingnau
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=65359

  For some reason SourceForge won't let me attach the
  files to this report. I've put them on
  http://anselm.our-isp.org/tcltk/fileinput.tar.gz
  for the time being. Sorry!


login: lingnau
username: lingnau
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=65359

  Andreas is right. Here is a trimmed-down version that
  uses »continue« in place of »fileinput::nextfile« and
  »break« in place of »fileinput::close«.

  Feel free to put this into the »fileutil« package if
  you think it ought to go there. I think its scope is
  somewhat different from the other commands in that package (which attempt to clone Unix commands) but
  it's no big thing to me. Remember that you will have
  to either change the name of the »foreach« command
  or else change the »namespace export« in fileutil.tcl
  or chaos will ensue.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9758: fileinput.tar.gz

  Logged In: YES 
  user_id=75003

  Retrieved the trimmed-down version from Anselm's website 
  and attached it here.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I had a look at some TclX commands now (for_file, 
  for_recursive_glob, 'scan*'-commands) and come
  to the conclusion that it might be better to take
  these and include them in tcllib. Partially they
  are already written in Tcl. They just need btter 
  names. With them it is possible to write the 
  submitted 'fileinput' in maybe 10 lines of tcl.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9797: 449531.diff.2

  Logged In: YES 
  user_id=75003

  Added patch which adds not 'fileinput' but two lower level 
  commands ripped from TclX which can be used to 
  create 'fileinput'.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  In the near future we should also add pure-tcl versions of 
  the scan-commands coming with TclX.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The tcllib/ChangeLog records only high-level changes.

  Changes to the individual modules are recorded in their
  own ChangeLogs, see for example modules/base64/ChangeLog


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  Committed workaround.  Leaving bug open, because the
  real fix is to stop accessing Tk internals.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I see six places invoking this command. We cannot use 
  [<widget> invoke] as that bypasses even processing. The 
  only way I see to get around using internal is to use 
  [event generate] to explicitly simulate a mouse click.

  Which is a bit ironic because "tkButtonInvoke" was written 
  exactly to simulate a click on the button with the mouse 
  when the button is invoked through the keyboard. It is 
  exactly this for which the command is used here in the 
  example, but we are not allowed to do so as it is declared 
  private.

  Question: Do we have plans to make parts of the ::tk 
  command public ?


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  increased priority. as 8.4 release approaches this is more
  important.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  report no longer valid.

  FAQs moved from the tcllib
  project to the tcl project, it seems.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The FAQ is now in thc Tcl project. closing as outdated. Don 
  created a new report there.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 9810: comm.tar.gz

  Logged In: YES 
  user_id=75003

  Enclosed a version of comm updated for inclusion into 
  tcllib (tests, namespaces, ...).


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I do not understand the part about the missing "default way 
  of coordinating the callbacks".

  What do you mean by 'coordinating' ?

  Later you say 'ability to wait on any number of call backs 
  is desirable'. 

  If I undertand you correctly you want to start, say several 
  http requests, and then perform an action after _all of 
  them_ have reported back via the callback you gave them ?

  Can you give me an example script how to use this ?

  Note: It might have been better to attach the above 
  implementation as a file instead of inlining it into the 
  message itself. See the "check to upload and attach file" 
  checkbox and entry items below, after the followups.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530


  I think there are many related ideas here.  Tcl's variable
  and command traces, Tk's widget bindings, the Notifier
  class in [incr Tcl] that Michael McLennan described at
  the latest Tcl/Tk conference, as well as some internal
  code we use on the OOMMF project.  I think this semaphore
  idea is similar too.

  They all have in common the notion of registering a callback
  script to be evaluated later when something happens.  It
  would be a worthwhile exercise for someone to make an
  inventory of these techniques and what they share in common
  and how they differ.  My impression is that the
  implementations are very different, even when the purposes
  are quite similar.

  Perhaps there's a fundamental capability to be extracted
  out and used by all?


login: erempel
username: erempel
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=304001

  Sorry for the long delay.

  By "default way of coordinating callbacks", I mean that 
  currently, if I am using two packages that have callback 
  facilities, I must write my own code to wait on them at the 
  same time. There is currently no mechanism in TCL to invoke 
  asynchronous routines and wait for the one that completes 
  firsts. I must wait for one routine specifically, and then 
  wait for the other routine. If I wait for the wrong one, 
  the following processing timeline is the result.

  1. Start asynchronous routine A (completes in 5 seconds)
  2. Start asynchronous routine B (completes in 2 seconds)
  3. Wait for routine A to complete (5 second idle time)
  4. Process the result of A (2 seconds)
  5. Wait for routine B to complete (0 seconds idle time)
  6. Process the result of B (2 seconds)

  Total time = 5 sec idle + 4 sec processing = 9 seconds.

  I would like to do

  1. Start asynchronous routine A (completes in 5 seconds)
  2. Start asynchronous routine B (completes in 2 seconds)
  3. Wait for routine A or B to complete (2 second idle time)
  4. Process the result of B (2 seconds)
  5. Wait for routine A or B to complete (1 second idle time)
  6. Process the result of A (2 seconds)

  Total time = 2 idle + 2 process + 1 idle + 2 proc = 7 sec

  If A and B are from the same package, this is usually easy, 
  provided that the author build a "wait any" function.
  If A and B are from different packages, I must invent some 
  way to handle this -> semaphores.


  The general concept is that I want to be able to wait for 
  any of the callbacks, without knowing which one will 
  respond first, or possibly waiting for any one of a 
  particular type of callback, again without knowing which 
  one will respond first.

  An example is something like

   http::geturl $A ... -command Semaphore::signal
   http::geturl $b ... -command Semaphore::signal
   timer::set "120 seconds" -command Semaphore::signal

   for {set x 1} {$x <= 3} {incr x} {
     set completed [semaphore::wait *]
     switch -glob -- $completed {
       ::http* { ... }
       ::timer* { ... }
       default { error "Unknown completed semaphore 
  $completed" }
     }
   }

  This way, we don't get stuck on waiting for a response from 
  a web server response, and we can determine timeouts. I 
  realize that the http::geturl has a timeout option, 
  however, the order in which you wait for them to complete 
  becomes critical. With thus structure there is no need to 
  build timeouts into all routines such as ftp, email, http, 
  database, socket listening etc., and one does not have to 
  wait for specific events to finish resulting in the ability 
  to continue processing as soon as the first one completes.

  The above code is very safe, but one could wait on 
  semaphores of the format ::http::* or any other format.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949

  Semaphore , as a package name, concerns me as
  it can have more than one meaning.  On POSIX based
  machines, there is a kernal based IPC data structure
  called a semaphore,

  Given that both uses of the term are common, what
  would be the best way to disambiguate the issue?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Enclosed a bug fix. The problem seems to be that conversion 
  from mouse location to row does not work for an unmapped 
  listbox. Added some code to retrieve the first visible 
  column and use that for the conversion.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 10222: namespace.cdiff

  Logged In: YES 
  user_id=81875

  Hmm ... this has happened second time that no patch file was
  uploaded. I guess it has to do with some bug in netscape
  browser.
  Hopefully it will upload this time.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  File Added - 10224: namespace.cdiff

  Logged In: YES 
  user_id=81875

  I just realized that my earlier patch had some unwanted
  changes for profiler.n file. So, I am re-submitting the
  patch after deleting that part.


login: dgp
username: dgp
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=80530

  Looks good to me too, but I'm gonna leave acceptance up
  to each maintainer.  Assigning to the first package.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Deleted - 10222: 

  Logged In: YES 
  user_id=75003

  We currently have here no exact maintainer structure as the 
  one for Tcl itself. Taking the item.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I do not understand this report.

  What exactly was tried, what happened,
  what was expected to happen ?

  A reference to the mentioned google
  search would be nice. Same for example
  scripts demonstrating the problem.


login: nobody
username: nobody
mimetype: text/plain
icomment:
  Logged In: NO 

  Noticed the same behaviour. Take two listboxes fill one
  leave one empty. Then do DND from full to empty => kaboom.

  This seems to fix it.. (hope the patch doesn't get garbled
  here)

  diff -u -w -b -B -r1.4 listbox.tcl
  --- listbox.tcl 2001/06/11 23:57:04     1.4
  +++ listbox.tcl 2001/11/01 09:40:14
  @@ -1034,7 +1000,7 @@
       }
       $path.c delete drop
       set data(dnd,scroll) ""
  -    if { [llength $data(dnd,item)] } {
  +       if { [llength $data(dnd,item)] || ![llength
  $data(items)]} {
           if { [set cmd [Widget::getoption $path -dropcmd]]
  != "" } {
               return [uplevel \#0 $cmd [list $path $source
  $data(dnd,item) $op $type $dnddata]]
           }


login: klaren
username: klaren
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=364921

  Hi,

  Here's the clarification (sorry I didn't post this earlier,
  was very busy..)

  Take two Listboxes one filled one empty. Both dropenabled
  etc. attempt to drag items from filled one to empty one 
  -> dropcmd not called.
  Add one item to the empty one repeat procedure
  -> dropcmd is called (expected behaviour)

  Small snippet:

  ---snip---
  package require BWidget

  proc drophandler { args  } {
          puts "Drophandler $args"
  }

  set left [ListBox .l -dropenabled 1 \
          -dragenabled 1 \
          -dropovermode wp \
          -droptypes { LISTBOX_ITEM { move {} } } \
          -dropcmd drophandler ]

  set right [ListBox .r -dropenabled 1 \
          -dragenabled 1 \
          -dropovermode wp \
          -droptypes { LISTBOX_ITEM { move {} } } \
          -dropcmd drophandler ]
  grid $left -row 0 -column 0
  grid $right -row 0 -column 1

  $left insert end test1 -text bla1
  $left insert end test2 -text bla2

  # Notice that now dragging items from left to right the
  drophandler is not
  # called...

  # But if you uncomment the following line it will be called.
  #$right insert end test3 -text bla3
  ---snip---

  Cheers,

  Ric


login: klaren
username: klaren
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=364921

  Hi,

  I noticed a problem with my previous patch. It is now
  possible that dropcmd is called with an empty third argument
  (the 'where' part).

  Here's a correction patch:

  --- listbox.tcl.origTue Feb 26 15:03:46 2002
  +++ listbox.tclTue Feb 26 15:06:58 2002
  @@ -1000,10 +1000,14 @@ proc ListBox::_drop_cmd { path
  source X 
   }
   $path.c delete drop
   set data(dnd,scroll) ""
  -if { [llength $data(dnd,item)] || ![llength $data(items)]}
  {
   if { [set cmd [Widget::getoption $path -dropcmd]] != "" }
  {
  -return [uplevel \#0 $cmd [list $path $source
  $data(dnd,item) $op $type $dnddata]]
  +# set sane default for the where part..
  +set where widget
  +if { [llength $data(dnd,item)] } {
  +# override when we got more accurate data
  +set where $data(dnd,item)
   }
  +return [uplevel \#0 $cmd [list $path $source $where $op
  $type $dnddata]]
   }
   return 0
   }


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Is the Tcl package 'scotty' known to the submitter ?

  See http://mini.net/tcl/691.html for description and
  references.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  It seems that tclhhtpd is composed out of several packages 
  including one for the core protocol handling. This is just 
  not documented.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  References
     http://python.sourceforge.net/peps/pep-0282.html
     http://www.red-dove.com/python_logging.html


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10420: tcllib.458011.diff

  Logged In: YES 
  user_id=75003

  Requirement of Tcl 8.2 is documented in the 'tree.n' 
  manpage. Added to requirement now to the code too.
  Documented limitations. Added verififcation.

  See enclosed patch.


login: bach
username: bach
mimetype: text/plain
icomment:
  File Added - 10369: lb_patch.txt

  Logged In: YES 
  user_id=98533

  *sigh* I should've learned by now to attach files and not to
  paste. Properly formated code is attached separately.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  As far as I am aware "stats" is deprecated.
  Assigned to Brent for verification.

  A first step would be to remove the deprecated module
  from the installation commands in the makefile.

  A second step would be to remove the files and add a README
  refering the user to the other module. Or to remove the 
  directory completely. The SF cvs supports this.


login: ericm
username: ericm
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=86324

  I don't think it's necessary to be quite so cautious with
  the deprecation and
  removal of the module.  Tcllib only just hit v1.0; I don't
  think we need to have quite the same rigorous procedures
  that the tcl core follows.  Just
  delete the deprecated module.  If you want to, add a
  "package ifneeded stats ..." to counter's pkgIndex.tcl, and
  maybe have it print out a warning
  on stderr that it's actually loading counter.  Let's try to
  keep tcllib nimble
  while we can.

  Eric Melski
  The Other Tcl Guy
  Interwoven, Inc.


login: lvirden
username: lvirden
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=15949

  Perhaps a compatibility tool could be made available in a
  seperate directory.  If someone needed the stat they could
  install it and references to stat would create aliases to
  the counter classes.


login: welch
username: welch
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=89720

  We should delete stats.
  When I changed it from "stats" to "counter" I left the old
  module in
  for a transition period, but that has long since expired. 
  There are
  no current releases of TclHttpd that depend on stats
  anymore.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10449: 459197.diff

  Logged In: YES 
  user_id=75003

  Added file containing the patch from the description.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Hm. Are the implementations of the ftp commands (ABOR, etc) 
  public API ? I thought not. They are accessed directly from 
  the other parts of the demon and I would not export them.


login: hemanglavana
username: hemanglavana
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=81875

  Perhaps not ... I wasn't sure abourt ABOR, etc so I just included them. 
  I am not also sure whether docRoot and fs are exported or not.
  If we refer to ftpd docs (http://tcllib.sourceforge.net/doc/ftpd.html) it provides only two
  two public APIs ::ftpd::server and ::ftpd::config.

  So, I will leave it upto the author/maintener to decide which APIs to export.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The author is/was Steffen Traeger who is interested
  in other things now and there is no official maintainer.
  (tcllib does not have such a big structure like tcl).

  Ok, I leave ABOR etc. out of the export, docRoot and fs in.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I guess that this applies to graph and tree, but not the 
  others (queue, stack), right ?


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Note that the 'exists' method is currently used to check
  the existence of nodes (tree, graph) and arcs (graph).

  We have to find a different name.


login: davidw
username: davidw
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=240

  Yes, how about:

         graphName arc get arc ?-exists key?

  or -keyexists or something of that ilk.  I think 'get' is a
  reasonable place to put these subcommands.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 10793: 460230.diff

  Logged In: YES 
  user_id=75003

  Ok, I created a new submethod 'keyexists' for tree nodes, 
  graph nodes and graph arcs. Attached the patch implementing 
  them, their documentation and additional testcases.


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=68433

  Since I can't find a description of what [formatCode]
  is supposed to do or any implementation, I've removed
  it from the docs.

  (html.n: r1.15 -> r1.16)


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Interface change, this means an update of the major version 
  number for this module and tcllib as a whole. The following 
  is a keyword I will use to mark such items so that I can 
  find them later through a search.

  MAJOR_VERSION_UPDATE


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I have made up my mind about this and decided to reject the 
  proposed change. I want to keep the interface to the [find] 
  command simple, consistent and without hidden surprises 
  (KIS). Changing the "formatting" of the paths in the result 
  based upon a special value for the "basedir"ectory does not 
  meet my criteria for KIS.

  I believe that is the responsibility of [find] to return a 
  list of found paths in a uniform format and that of the 
  calling application to decide if a non-standard formatting 
  is required and to apply it.

  Given that I make the counter proposal to write a command 
  [stripPwd] instead which strips the current working 
  directory from a path, if the path is inside of the CWD. 
  Another command could strip N elements from the beginning 
  of a path, N an argument of the command. Both of these can 
  be used by the application to create the desired effect.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The simple approach to fix the bug proposed here is
  incorrect. The variable "request_uri" does not contain the
  same information as "env(REQUEST_URI)". Perform the change,
  execute the testsuite and see testcase ncgi-11.2 fail.

  The correct fix is to check again for the existence of
  "env(REQUEST_URI)" and use "env(SERVER_NAME)" if it doesn't
  (exist).

  See attached the patch.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  File Added - 11352: 465210.diff

  Logged In: YES 
  user_id=75003

  Enclosed the patch containing the full fix.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Hm. Atleast the BWidgets module has its own released tar 
  files. mclistbox and widgets could go together as a tklib. 
  tclbench as it is right now is quite developer centric, 
  especially in handling. I would not add it to the tcllib 
  release in this state. It needs a bit of cleanup to make it 
  easier to use. tclapps could have its own release too.


login: techentin
username: techentin
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=43494

  Are you sure that's a good idea?  I thought we were going to 
  leave Tk packages out of tcllib, and put them in some future tklib.  
  The package structure is separate for each of the different 
  directories.

  But now I see that Jeff created tklib as a package parallel to 
  tcllib.  And it would also appear that almost everything in the 
  tcllib cvs is tagged with tcllib-1-1-0.  But would it make sense 
  to have  several different directories all in the same tcllib.tar.gz?  
  Can I package and release that as tcllib-1.1.0, when it will include 
  a lot of new stuff?  How do I number the BWidget library directory 
  name?  Tcllib-1-1-0 is quite a few changes newer than 
  bwidget-1-3-1.

  I was really expecting the maintainers of mclistbox, tclapps, tclbench, 
  and widget to eventually mark a new release with whatever number 
  was appropriate for that package, and I could then release a separate file.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  I have implemented logging to a file with an entry in the
  Options dialog to specify the file name. The filename is
  saved along with the other options and will be reopened for
  appending upon restarting tkchat.

  I think the logging to a window is handled by the show
  console menu item. At least this deals with it for Window
  platform.

  Yes, andreas - I have used tcllib log to accommodate levels.
  option menu is on the dialog too.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  The userinfo dialog has been in for a while.
  I don't think I'm ever likely to deal with images though.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  What are you after here? It already persists the user
  settings. Recent versions can log the chat but there is not
  much point (IMO) in reloading the old loggged chat.

  ??


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  I believe it did not at the time I submitted this. Yes, I 
  believe I was after persistence of user preferences. We can 
  close this request.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  We can now search within the text in the chat by entering
  "/?<regexp>"


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  I have just checked CVS version 1.12 (15/Oct/2001) and under
  Windows I can copy text from the main chat window and paste
  it into the posting window.

  If this is still a problem, what platform? Or are you just
  after adding the menu items for these operations?


