Forums : The Ohcount Project
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.synopsys.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
[GSOC] Integrating/Implementing Ragel
Do we want to do this in Ruby or C? As of right now I am leaning towards Ruby simply because I know how to do unit testing with it. Maybe we can work on porting it to C at a later time. Please give thoughts or feedback.
Well after doing some thinking, unit tests may not be necessary. They can be helpful at the beginning when testing data structures that hold information, but after that, everything will work fluidly.
I'm now considering using C exclusively.
...unit tests may not be necessary
Heh, you and me are going to throw down in The Octagon if you keep saying things like that :-).
At no point will Ohcount be allowed to be without unit test coverage. I'm flexible on how it happens, but it has to happen.
I agree that a completely C implementation would be best, but we need to maintain interop with the Ruby code that the rest of Ohloh is built on, and just speaking for myself I think Ruby is much easier to work with.
I admit that the boundary between Ohloh and Ohcount is hazy and not easily discernable from looking only at Ohcount code. For instance, lib/ohcount/sloc_info.rb is completely unused by Ohcount itself, but is required by Ohloh. If you're going to go for pure C in the Ohcount project, I'll need to do some cleanups and define the Ohloh/Ohcount interface more explicitly.
At the very least it sounds like you are going to need a test harness that exercises the Ohloh/Ohcount boundary, so I may have some work to do here.
Robin
Hi Mitchell,
I did some digging through our code to try to sort out the interface between Ohloh and Ohcount, and here's what I came up with.
There are three methods that Ohloh expects to be available within Ohcount:
Ohcount::Detector.binary_filename?()
This is a pretty simple method, and I don't think we need spend much brain power here.
Ohcount::Parser.parsetodir()
This method takes a source file and converts into a tree of code and comment files like the ones found in test/expected_dir/. There is no explicit unit test for this method, but it is indirectly used in nearly every language unit test inside verify_parse() so it is well-covered by Ohcount tests.
Ohcount::diffslocdirs()
This method takes two of the parse result directories created above, and generates a diff for each language. This method is not and is not used anywhere within Ohcount and is not covered by any test I can see in Ohcount.
Because parse_to_dir() is used within the Ohcount unit tests, I think it makes sense to keep this method within Ohcount. However, diff_sloc_dirs() is a little more fuzzy. It is used only by Ohloh, and is tested indirectly by the Ohloh tests. Either this method should move to Ohloh, or we should create a test for this method within Ohcount.
In general, parse_to_dir()and diff_sloc_dirs() are not particularly clean or fast methods, and I wouldn't mind if these methods got rebuilt in a better way.
All of this is of course slightly off-topic from your original question, which was whether a refactored Ohcount should have any Ruby in it. As long as we find a way to keep the three Ruby methods above working, or can find a new way to implement them, I'm not married to Ruby.