| Message ID | 4D71D071.4040403@msgid.tls.msk.ru |
|---|---|
| State | New |
| Headers | show |
On Sat, Mar 5, 2011 at 6:56 AM, Michael Tokarev <mjt@tls.msk.ru> wrote: > 05.03.2011 00:08, Corentin Chary wrote: >> On Fri, Mar 4, 2011 at 12:46 PM, Michael Tokarev <mjt@tls.msk.ru> wrote: > [] >>> The attached slightly different patch fixes both places and fixes >>> them for good (hopefully anyway). Runtime-tested for the tight >>> case, but honestly, I didn't wait for 2G of output ;) >>> >> Could you re-send it inline (not as an attachment), and CC Anthony ? > > What's wrong with using an attachment? The whole email can be > fed into patch(1) (or git-am, whatever) and either will do the > job. But here it goes, anyway, with one possible caveat - I'm > not sure anymore it will apply, since now I used cut-n-paste. It's easier for reviewer because it allow people to view and comment the code directly in a mail client. The prefered way to send patch is `git format-patch` and `git send-email`. If you use these two tools, you can be sure that all will be ok :).
05.03.2011 11:33, Corentin Chary wrote: > On Sat, Mar 5, 2011 at 6:56 AM, Michael Tokarev <mjt@tls.msk.ru> wrote: >> 05.03.2011 00:08, Corentin Chary wrote: >> What's wrong with using an attachment? The whole email can be >> fed into patch(1) (or git-am, whatever) and either will do the >> job. But here it goes, anyway, with one possible caveat - I'm >> not sure anymore it will apply, since now I used cut-n-paste. > It's easier for reviewer because it allow people to view and comment > the code directly in a mail client. I can usually easily review patches sent as text/plain attachments directly in my client. But granted, I tried to reply to my own email with attachment and Thunderbird does not show the patch text, -- it usually does. I'll investigate it. But the patch is shown inline as the rest of my email, so it's still easy to review it (but not comment on individual parts). In any way, this patch is too simple to comment on it. > The prefered way to send patch is `git format-patch` and `git > send-email`. If you use these two tools, you can be sure that all will > be ok :). Now please show me how I can use these tools when replying to a discussion and keeping other comments and thread flow. Yes sure this can be done, I can cut-n-paste all sorts of original message into the editor executed by git send-email, or even into command-line of git format-patch, but this is just too much work compared with regular reply in usual mail client and attaching a single file. The latter is much more productive and as easy to review and apply, the only difference is - as it turns out - in-line commenting, but I'll check this separately. What I miss in Thunderbird is a way to _insert_ content of a file into the message, -- a combination of cut-n-paste and attachment. With sufficient care I can keep tabs after cut-n-paste, but this is fragile. If I can solve inline- comments in attached patch that'll be ideal variant. And I think that the reasons you stated above are not sufficient to warrant re-sending this very patch as you asked me to do... ;) Thanks! /mjt
> Now please show me how I can use these tools when replying to > a discussion and keeping other comments and thread flow. Yes > sure this can be done, I can cut-n-paste all sorts of original > message into the editor executed by git send-email, or even into > command-line of git format-patch, but this is just too much work > compared with regular reply in usual mail client and attaching > a single file. The latter is much more productive and as easy > to review and apply, the only difference is - as it turns out - > in-line commenting, but I'll check this separately. Hi, You can use "git send-email --in-reply-to=<messageid>" to reply to a thread. > And I think that the reasons you stated above are not > sufficient to warrant re-sending this very patch as > you asked me to do... ;) Do not see any thing personal here, I'm just quoting http://wiki.qemu.org/Contribute/SubmitAPatch: "Send patches inline so they are easy to reply to with review comments. Do not put patches in attachments". I mainly asked yo to re-send it so Anthony has less chance to miss it if he is cc and if the patch is inline :), that's all. Thanks,
diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c index 2522936..87fdf35 100644 --- a/ui/vnc-enc-tight.c +++ b/ui/vnc-enc-tight.c @@ -868,8 +868,8 @@ static int tight_compress_data(VncState *vs, int stream_id, size_t bytes, zstream->avail_in = vs->tight.tight.offset; zstream->next_out = vs->tight.zlib.buffer + vs->tight.zlib.offset; zstream->avail_out = vs->tight.zlib.capacity - vs->tight.zlib.offset; + previous_out = zstream->avail_out; zstream->data_type = Z_BINARY; - previous_out = zstream->total_out; /* start encoding */ if (deflate(zstream, Z_SYNC_FLUSH) != Z_OK) { @@ -878,7 +878,8 @@ static int tight_compress_data(VncState *vs, int stream_id, size_t bytes, } vs->tight.zlib.offset = vs->tight.zlib.capacity - zstream->avail_out; - bytes = zstream->total_out - previous_out; + /* ...how much data has actually been produced by deflate() */ + bytes = previous_out - zstream->avail_out; tight_send_compact_size(vs, bytes); vnc_write(vs, vs->tight.zlib.buffer, bytes); diff --git a/ui/vnc-enc-zlib.c b/ui/vnc-enc-zlib.c index 3c6e6ab..e32e4cd 100644 --- a/ui/vnc-enc-zlib.c +++ b/ui/vnc-enc-zlib.c @@ -103,8 +103,8 @@ static int vnc_zlib_stop(VncState *vs) zstream->avail_in = vs->zlib.zlib.offset; zstream->next_out = vs->output.buffer + vs->output.offset; zstream->avail_out = vs->output.capacity - vs->output.offset; + previous_out = zstream->avail_out; zstream->data_type = Z_BINARY; - previous_out = zstream->total_out; // start encoding if (deflate(zstream, Z_SYNC_FLUSH) != Z_OK) { @@ -113,7 +113,7 @@ static int vnc_zlib_stop(VncState *vs) } vs->output.offset = vs->output.capacity - zstream->avail_out; - return zstream->total_out - previous_out; + return previous_out - zstream->avail_out; } int vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h)