Otwo 3081 #4
Open
Otwo 3081 #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…cepted as a trigger for the MIT license
…ld be in an architecture specific directory
popen() must be matched by pclose(), not fclose(). Every time we forked out to the `file` command line tool, we failed to clean up the resulting process. Since we sometimes did this thousands of times, the operating system became cranky and refused to open any more processes for us. Reboots ensued.
this is because the MAC optimizations only improve perf by about 5% in my tests and it makes debugging harder. Optimizing elsewhere to make ohcount fast for users. If you are developing for it and want to debug, remove the -O directives from the CFLAGS
Flex is not a language. Flex is a library which consumes MXML.
flash: any non-trivial use of actionscript, or
a Java import from the flash.* namespace
flex: any non-trivial inclusion of MXML, or
a Java import from the mx.* namespace
New gestalts for: silverlight mootools prototype yahoo ui (yui) dojo Implementing the silverlight gestalt requires parsing *.csproj files. There appears to be a bug in the ohcount C core. If you query the language_breakdowns of a source_file object, but that source_file happens to not contain any known languages, then the source_file.contents are reset to nil! I gave this bug a good long hunt, but I just couldn't find it. To work around this bug, *.csproj files are now counted as XML. It's a bit cheeky, but they really are XML, so it works out. Without this, the gestalt rule would explode because the contents are nil.
…et/gitroot/ohcount/ohcount
We are OK with ending the support with 1.8.7.
File extensions seems more reliable than emac line, as a javascript file can have a java emac mode.
RenderScript isn't implemented, so if a file matches the RenderScript detection it is just left as undetected.
Add support for Rust
When a string contains an escaped newline, the internal state gets out-of-sync with the source, leading to comments being incorrectly identified as code. Handle '\\' + newline specially in order to account for this.
Upgrade Ohcount to support ruby 1.9.x
The most significant change is that the perl script that generates HTML, especially with the "<!DOCTYPE html" heading, is now identified as HTML. This is due to differences in the libmagic database between CentOS 5 and Ubuntu 14. It may be possible to generate a different database, or modify the existing database to change the identification order. However, it is also worth acknowledging that, in the years since this code was first developed, it may be more correct to recognize a script that generates a complete HTML document as 'HTML', even if that script is written in something like perl.
Update Ohcount to work with Ubuntu 14
Objective_c comments always start with a /. The existing code matches the * character in the second column of a line to decide that a file is objective_c. This leads it to detect mathematica comments "(*" as objective_c comments.
Fix incorrect comment pattern for objective_c detection
Add Grace language
Expand Grace lang test cases
Add support for new language Mathematica
The original code in PR#23 did not consider multiline comments. We compared and copied the code from OCaml parser which has a similar comment structure and it worked. The existing test files in test/expected_dir & test/src_dir needed fixing for some mismatch in whitespace characters and expected lines.
When octave comments were nested within mathematica comments, the parser incorrectly detected the file as Octave. To fix this we moved around an If/Else block which placed mathematica at the bottom of the conditional. We have also tried adding mathematica comments within Octave comments to see if the reverse was true. We found that Octave parsing worked correctly without any further change in code.
Fix mathematica comment parsing
The existing parser counts multiline ampl comments as code. Added parser tests.
Add support for AMPL language
…to johnkeeping-fix-shell
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.