tag:blogger.com,1999:blog-62464411393683654892024-03-05T19:14:24.769-06:00Drakonite's Brain DumpThoughts, tips, and nonsensical ramblings on programming, gamedev, and who knows what.Anonymoushttp://www.blogger.com/profile/09862698118276784365noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6246441139368365489.post-11029380251783183062014-06-03T16:24:00.001-05:002014-06-03T16:24:19.334-05:00mercurial-server and hg extensionsAre you using mercurial-server for shared-ssh based hg hosting? Do you want to use extensions such as largefiles and projrc?
<br />
<br />
If so, you may be very familiar with the error message "ssh://hg@hostname/repo does not appear to be a largefile store".<br />
<br />
I spent more time than I'd care to admit trying to fix this, and was unable to find documentation explaining how to fix it.<br />
<br />
Well, here it is:<br />
<br />
mercurial-server is setup to ignore system and user hgrc files. It'll use the system hg extensions (/etc/mercurial/hgrc.d/hgext.rc) when init'ing the repo, but not for other operations.<br />
<br />
To enable extensions for mercurial-server you need to create a file in /etc/mercurial-server/remote-hgrc.d/ and add the extension list. For example I have a file /etc/mercurial-server/remote-hgrc.d/hgext.rc which contains the following:<br />
<br />
<br />
<blockquote class="tr_bq">
[extensions]<br />
<br />
hgext.largefiles=<br />
hgext.projrc=</blockquote>
<br/>
...Yep. that's it. Easy times. Unfortunately the problem is being unable to find documentation explaining this; in the end I had to read through the source code. Hopefully this post has saved you the effort.Anonymoushttp://www.blogger.com/profile/09862698118276784365noreply@blogger.com0tag:blogger.com,1999:blog-6246441139368365489.post-19490403479067156462014-04-20T19:44:00.002-05:002014-04-21T00:23:59.562-05:00Demonstrating GCC's signed int overflow optimization bug is non-conforming// When compiled in GCC with -O2, this causes an infinite loop<br />
<br />
<blockquote class="tr_bq">
#include <limits><br />
int main()<br />
{<br />
<span style="white-space: pre;"> </span>if( std::numeric_limits<signed int>::is_modulo )<br /><span style="white-space: pre;"> {</span><br /><span style="white-space: pre;"> </span>for( int ii=1 ; ii<0 ; ++ii ) { }<br /> }<br /><span style="white-space: pre;"> </span>return 0;<br />}</blockquote>
<br />
<br />
/*<br />
This has been heavily debated as to whether it's actually a defect, with many claiming it is not a defect due to the following line in the C++ spec:<br />
<br />
<blockquote class="tr_bq">"If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined."<br /></blockquote>
<br />
However, <span style="font-family: monospace;">std::numeric_limits<signed int>::is_modulo</span> clearly changes the argument, and is defined in the spec as:<br />
<br />
<blockquote class="tr_bq">True if the type is modulo. A type is modulo if, for any operation involving +, -, or * on values of that type whose result would fall outside the range [min(),max()], the value returned differs from the true value by an integer multiple of max() – min() + 1.<br /></blockquote>
<br />
By signed int being a modulo type in gcc's implementation of C++, it has a clear mathmatical definition and is required to wrap on overflow as most developers expect.<br />
<br />
I tested the following compilers (all targeting x86):<br />
- g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3<br />
- Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)<br />
- Visual Studio 2013<br />
<br />
GCC and Clang tests were compiled using standard 'safe' optimization level of -O2. Visual Studio test was compiled using the default optimization options for a Release build.<br />
<br />
All three compilers report signed int to be modulo in their implementation. Only GCC causes an infinite loop in the test code. (It is unknown whether Clang or VisualStudio can be made to exhibit similar bugs with non-trivial code). Visual Studio optimized out the entire loop initially; a printf was added in the loop for the Visual Studio test to prevent the loop from being removed in entirety.<br />
<br />
I believe this clearly demonstrates a bug in GCC. Either the oft quoted "signed int overflow is undefined" is incorrect due to signed int being modulo and GCC's optimizer is exhibiting incorrect behavior, or GCC's <span style="font-family: monospace;">std::numeric_limits</span> is incorrectly reporting signed int as being modulo.
*/Anonymoushttp://www.blogger.com/profile/09862698118276784365noreply@blogger.com0