Archive for May, 2010
GCC using C++
Monday, May 31st, 2010 | Opensource, Software Development | Comments
I got this news http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html and it puzzled me a bit: you have the system C compiler depending on C++, making in fact it no more self hosting.
That alone makes me thing whoever decided and whoever requested that is next to suicidal. GCC is known for having _quite_ a shaky C++ standard library AND ABI, as in having at least an incompatibility every major version and sometimes even with minor ones.
I do dislike C++ usage mostly on this basis, let alone the fact is a language overly large, with not enough people dabbling it properly, let alone being proficient.
There are already compilers using C++, one that many people find interesting is llvm. It doesn’t aim to be a system compiler and it’s not exactly self hosting.
Many already stated that would switch to llvm clang front-end once it reaches full maturity (now freebsd proved that this level has been pretty well archived), I didn’t consider to fully switch to it just because it concerned me the fact it depends on C++ and how easy is to have subtle yet major breakages in that language implementations.
llvm people look to me way more capable of managing C++ than GCC ones and I saluted with please the fact they already have a libc++ implementation.
Back about being suicidal, if I have to pick between people that did well on C++ and people that botched many time on the same field, who would I pick?
The current discussions in the GCC mailing list are about C++ coding style, which features to pick and which to forbid, rearchitecture the whole beast to use a “proper” hierarchy and such, basically some/(many?) want to redo everything with the new toy. That makes me think again that llvm will be a better target for the next months/year.
I hope there are enough GCC developers and/or concerned party that will fork gcc now and keep a C branch. Probably having a radical cleanup and refactor is a completely orthogonal issue and should be done no matter they’ll pick C++ or C as their implementation language, GCC has lots of cruft, starting from their bad usage of the autotools.
Mercurial “git grep” equivalent extension
Thursday, May 6th, 2010 | Computer Science | Comments
As we are used to git when working on mercurial we miss a lot the “git grep” command as “hg grep” doesn’t really do the same thing. So we managed to quickly create a mercurial extension to add the hgrep command to hg which behaves a bit like git grep.
import itertools, os, os.path def hgrep(ui, repo, what, **opts): files = [] status = repo.status(clean=True) for f in itertools.chain(status[0], status[1], status[4], status[6]): files.append(os.path.join(repo.root, f)) os.system("grep %s %s" % (what, ' '.join(files))) cmdtable = {"hgrep": (hgrep, [], "[what]")}
To have the “hg hgrep” command and make it work just save it as hgrep.py in your python modules path and add it to ~/.hgrc inside the extensions section like:
[extensions] hgrep =
Then you will be able to run “hg grep what” inside a mercurial repository and it will find each file at its current state that contains what you were looking for giving you the complete absolute path to the file.
Search
Archives
- January 2012
- November 2011
- October 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- September 2010
- August 2010
- July 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- October 2008
- August 2008