search for: sloccount

Had a curious question about how much of Linux (as a usable distribution, not just the kernel) is coded in each language. I can find some older or vague references without citation that Linux is largely coded in C and C++, with a fraction of a percent coded in other languages. While the source is available, I'm not sure how would one go about determining the percentage of CentOS coded in

Perhaps someone could come up with a list of different versioning software, list the pros and cons, and then we could vote? (Has anyone mentioned Bitkeeper yet? :-) -bw On 11/28/06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > I'm not sure if I just took HEAD or converted the whole llvm repo. > > Personally, I like darcs for the atomic theory of patches.

> I'm not sure if I just took HEAD or converted the whole llvm repo. > Personally, I like darcs for the atomic theory of patches. YMMV. I have used darcs to work with psi. It looks like a very clean design, but currently it is a very anemic implementation IMHO. I constantly find myself trying to find out how to do a relatively simple task. Git is fast and has a lot of features, but

...x? Is it just a matter of taking some tree/rtl form stuff and > emitting ppc code instead of x86 code? Basically a new code generator would need to be written. The current X86 code generator (ignoring the experimental instruction selectors) is about 8-9000 LOC (about 4800 SLOC, as reported by sloccount) in the lib/Target/X86 directory, which should give you an idea of how much work it currently is to implement a code generator. The X86 backend also has a bunch of little optimizations in it, so a simple code generator would probably be a lot less code. We are slowly working on developing tools t...

> > There are two problems with this: 1) there is no JIT for PPC yet, so > LLVM will use the interpreter (which is intolerably slow and has other > issues). 2) Spec compiles the executables in one place and them moves > them to another, but it only copies the shell script and not the > bytecode file, so you get that error message. > > The normal solution to this problem

Hello everyone, We are in the process of formalizing the governance model of the GlusterFS project. Historically, the governance of the project has been loosely structured. This is an invitation to all of you to participate in this discussion and provide your feedback and suggestions on how we should evolve a formal model. Feedback from this thread will be considered to the extent possible in