> On Nov. 10, 2016, 11:45 p.m., Anand Mazumdar wrote: > > 3rdparty/stout/include/stout/gzip.hpp, lines 157-168 > > <https://reviews.apache.org/r/53366/diff/2/?file=1556463#file1556463line157> > > > > hmm, this is a little weird. Why can't this be just be a `bool > > failed()` similar to what we have for the decoders i.e., to me decoding > > seems similar to decompressing semantically?
Per our discussion offline, this evolved poorly as it turns out that there is no need to "finish" the stream. The intention then was for the caller to see if gzip considers the stream to be "finished", which means no more input is expected. However, I didn't update the method name so I'll update this to be a const method and we can call it "finished". - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/53366/#review155666 ----------------------------------------------------------- On Nov. 8, 2016, 4:22 a.m., Benjamin Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/53366/ > ----------------------------------------------------------- > > (Updated Nov. 8, 2016, 4:22 a.m.) > > > Review request for mesos and Anand Mazumdar. > > > Bugs: MESOS-6530 > https://issues.apache.org/jira/browse/MESOS-6530 > > > Repository: mesos > > > Description > ------- > > This enables incremental decompression of compressed input. > > > Diffs > ----- > > 3rdparty/stout/include/stout/gzip.hpp > b78a8a31204ee585f8e4a88eaefe7346faa46b8d > 3rdparty/stout/tests/gzip_tests.cpp > 814fb99da193cf950ba48817824acdabda2c2dfc > > Diff: https://reviews.apache.org/r/53366/diff/ > > > Testing > ------- > > Wrote a test for decompressing a byte at a time. Also ran this test manually > with random chunk sizes. > > > Thanks, > > Benjamin Mahler > >
