{"thread":{"id":"9039","subject":"bug in gitk on cygwin, v1.5.3-rc1","startedAt":"2007-07-14T19:02:05Z","lastAt":"2007-07-14T19:02:05Z","messageCount":1,"participants":["Mark Levedahl"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"47368","messageId":"46991DAD.9020005@verizon.net","threadId":"9039","inReplyTo":null,"subject":"bug in gitk on cygwin, v1.5.3-rc1","fromName":"Mark Levedahl","fromEmail":"mdl123@verizon.net","sentAt":"2007-07-14T19:02:05Z","receivedAt":"2007-07-14T19:02:05Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"Paul,\n\nThe previous bug I reported of gitk giving an error on Cygwin, and that \nyou addressed in 8c93917d23ec7ef998154a, now manifests itself \ndifferently in that all commits are not shown. For instance, \"gitk \nv1.5.3-rc1\" results in a display where the last shown commit is  9e026d3 \n(dated 205-09-26), the tag v0.99.8g is the penultimate shown, both are \nshown with white circles at the tip of their respective commit lines. \n12-15 previous commits are shown in the same way. The correct display of \ncourse begins with commit e83c51 on 2005-040-7.\n\nI have built a new tcl/tk package, using 8.4.15 sources, using POSIX + \nX-Windows under Cygwin, and using this tcl/tk package I get identical \n(assumed correct) results as I do on my fedora FC7 box. (Such a package \ncannot be introduced into Cygwin as the Tcl/Tk package there is the one \nthat supports the insight debugger, and the Tcl/Tk sources are \nintegrated into the insight debugger source tree).\n\nFurther investigation has shown that:\n\n1) The contents read in getcommitlines is identical (I logged from both \nversions and compared the results).\n2) The Posix-X windows version (and on Linux) in general reads 50,000 \nbytes at a time from the pipe, as would be expected from the line \"    \nset stuff [read $fd 500000]\"\n3) The normal Cygwin TCL version reads 3000 - 5000 bytes at a time, not \n50,000.\n4) gitk, prior to commit 8c93917, would throw an error when trying to \nlayout the row that now shows up as the last commit.\n\nSo, my suspicion is that the layout code gets ahead of the read loop, \nrequiring data for a commit not yet read in, and prematurely terminates \nthe graph rather than waiting for more data to be read in before \nattempting to continue the layout. Just a guess as I do not really \nunderstand the pseudo-threading you have written.\n\nMark Levedahl\n"}]}