On 30 January 2011 22:22, Jim Meyering <[email protected]> wrote: > ?? > Odd that you saw it that way.
A faulty assumption on my part. > Yours converted spaces-to-TAB: > http://cache.gmane.org//gmane/comp/gnu/grep/bugs/3455-001.bin Yup. > and so did mine (i.e., unchanged from your original): I wasn't expecting that, and didn't check. I thought you were undoing my unnecessary change, unnecessarily. So your patch must have been mangled (as you suggested), possibly by Emacs's whitespace-mode again (but I didn't think it was on by default in diff-mode), and it didn't apply to the trunk for me. Now I understand! So I'll pay closer attention next time I get a cleaned-up diff from you. Also, sorry I've not yet made any progress on my patch. I have however had a possible bright idea. I got to the point where I was unable to rewind the input stream when it was a pipe, and hence unable to pass the stream on to the decompressing veneer functions, because it lacked 5 bytes at the start. As per Paul Eggert's suggestion, I said I would try a version of my patch that fed data into a decompressor process, rather than using the libraries directly. But this would also solve my problem, as I could re-inject the first 5 bytes that I'd read to analyze the magic. So not only does Paul's suggestion look good for improving performance in decompressing (suitably large?) amounts of data on SMP machines; it also looks like the only simple way of working with pipes (the complex way, being, as I already said, to call the low-level decompression APIs myself, which I don't really fancy). So, how about I do another cut of my zio veneer library which uses decompressor processes as well as library calls? I can test comparative performance, and then worry about whether I can use just the out-of-process code, or whether some sort of further user selection is warranted (with a fallback to out-of-process decompression when stdin is a pipe). -- http://rrt.sc3d.org
