Re: Release date for Privoxy 3.0.24
Ian Silvester <[email protected]> Fri, 22 Jan 2016 08:26:55 -0500
| Newsgroups | gmane.comp.web.privoxy.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============6746916060706215767== Content-Type: multipart/alternative; boundary="------------010409090809020506050401" This is a multi-part message in MIME format. --------------010409090809020506050401 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2016-01-22 08:03, Fabian Keil wrote: > Ian Silvester <[email protected]> wrote: > >> On 2016-01-21 13:48, Fabian Keil wrote: >>> Ian Silvester <[email protected]> wrote: >>>> These may still >>>> not be unique in their first 4 bytes (though they're significantly more >>>> different than the raw ids); I'll admit I don't understand the comment's >>>> talk of a "debuggable value in the first 4 bytes" - do you think it >>>> simply means a unique value in those 4 bytes? And what is so important >>>> about the first 4 bytes of the value from a debugging perspective? >>> While I'm having trouble parsing the comment as well, I interpret it similarly. >>> I assume David meant to write "discernible" or "distinguishable" or something >>> like this and was using a 32 bit system which is relevant for the "4 bytes" part. > [...] >> I wrote that comment. 'debuggable' literally meant just that. If >> you wanted to attach gdb, for example, you'd want to know which process >> ID to attach to... but of course we're talking about threads, not >> processes. So debuggability is actually moot here. >> >> The idea was simply to make the thread ID look somewhat presentable as a >> number, and still have a reasonable chance of not colliding with another >> similarly truncated thread ID (in Privoxy). The Mach kernel has a very >> chatty thread ID, so I was just trying to reduce clutter in the log. >> >> - David >> >> >> >> Thanks for the input David! >> >> So the upshot is that we don't need to worry about debuggability (I'll >> modify the comment appropriately) and only need to ensure no numbering >> collision whilst indeed making the log more readable. >> >> Fabian, given the style of the raw ids (e.g. 7fff78fb5000) the '% 1000' >> has the effect of simply stripping the least significant three digits, >> which are always 000. This alone then does not affect the uniqueness of >> the IDs. e.g. 7fff78fb5000 becomes 7fff78fb5, right? > Nope: > > fk@r500 ~ $perl -e 'printf("%x\n", 0x7fff78fb5000 % 1000);' > 3c8 > > To strip the least significant three hexadecimal digits, which indeed > would not change the uniqueness if they are always zero, you would have > to divide by 16 to the power of three: > > fk@r500 ~ $perl -e 'printf("%x\n", 0x7fff78fb5000 / 16**3);' > 7fff78fb5 Yes, apologies. I had a moment of clarity as I fell asleep last night and realised I'd have to eat crow (as they say in North America) this morning! Your post beat me to my direct apology. We're tagged now so I won't make any change yet, but unless anyone prefers otherwise I suggest we go with the division by 16**3 and drop the absolute function - the ids are not pretty but at least they're guaranteed unique. Cheers, Ian -- My PGP public key <http://diem.serveftp.net:8080/IanSilvesterPGPPublicKey.asc>. --------------010409090809020506050401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 2016-01-22 08:03, Fabian Keil wrote:<br> <blockquote cite="mid:[email protected]" type="cite"> <pre wrap="">Ian Silvester <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On 2016-01-21 13:48, Fabian Keil wrote: </pre> <blockquote type="cite"> <pre wrap="">Ian Silvester <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote: </pre> <blockquote type="cite"> <pre wrap=""> These may still not be unique in their first 4 bytes (though they're significantly more different than the raw ids); I'll admit I don't understand the comment's talk of a "debuggable value in the first 4 bytes" - do you think it simply means a unique value in those 4 bytes? And what is so important about the first 4 bytes of the value from a debugging perspective? </pre> </blockquote> <pre wrap="">While I'm having trouble parsing the comment as well, I interpret it similarly. I assume David meant to write "discernible" or "distinguishable" or something like this and was using a 32 bit system which is relevant for the "4 bytes" part. </pre> </blockquote> </blockquote> <pre wrap="">[...] </pre> <blockquote type="cite"> <pre wrap=""> I wrote that comment. 'debuggable' literally meant just that. If you wanted to attach gdb, for example, you'd want to know which process ID to attach to... but of course we're talking about threads, not processes. So debuggability is actually moot here. The idea was simply to make the thread ID look somewhat presentable as a number, and still have a reasonable chance of not colliding with another similarly truncated thread ID (in Privoxy). The Mach kernel has a very chatty thread ID, so I was just trying to reduce clutter in the log. - David Thanks for the input David! So the upshot is that we don't need to worry about debuggability (I'll modify the comment appropriately) and only need to ensure no numbering collision whilst indeed making the log more readable. Fabian, given the style of the raw ids (e.g. 7fff78fb5000) the '% 1000' has the effect of simply stripping the least significant three digits, which are always 000. This alone then does not affect the uniqueness of the IDs. e.g. 7fff78fb5000 becomes 7fff78fb5, right? </pre> </blockquote> <pre wrap=""> Nope: fk@r500 ~ $perl -e 'printf("%x\n", 0x7fff78fb5000 % 1000);' 3c8 To strip the least significant three hexadecimal digits, which indeed would not change the uniqueness if they are always zero, you would have to divide by 16 to the power of three: fk@r500 ~ $perl -e 'printf("%x\n", 0x7fff78fb5000 / 16**3);' 7fff78fb5</pre> </blockquote> <br> Yes, apologies. I had a moment of clarity as I fell asleep last night and realised I'd have to eat crow (as they say in North America) this morning! Your post beat me to my direct apology.<br> <br> We're tagged now so I won't make any change yet, but unless anyone prefers otherwise I suggest we go with the division by 16**3 and drop the absolute function - the ids are not pretty but at least they're guaranteed unique.<br> <br> Cheers,<br> <br> Ian<br> <br> <br> <div class="moz-signature">-- <br> <a href="http://diem.serveftp.net:8080/IanSilvesterPGPPublicKey.asc">My PGP public key</a>.</div> </body> </html> --------------010409090809020506050401-- --===============6746916060706215767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 --===============6746916060706215767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ijbswa-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ijbswa-developers --===============6746916060706215767==--