[discussion] Improvements in existing analyzers and Additions

[inishchith]

This thread is for discussion related to

• Improvements in existing analyzer
• Addition of new analyzers under corresponding backends

[valeriocos]

Thank you @inishchith to open this issue. We could start commenting on possible improvements and additions to trigger discussions and evaluations. Maybe later we could create other issues to focus on specific tasks. Find below some ideas, anyone is free to share his own ideas (cc @jgbarah ).

too much python
The backends CoQua, CoDep and CoVuln rely on analyzers for Python. It could be useful to include analyzers that target other (popular) languages.

how to deal with multi-language repos
Some repos rely on more than one programming language (e.g. frontend and backend languages), so Graal could execute different analyzers when processing a repo. A similar approach has been already implemented for CoCom, which relies on cloc and lizard (triggered based on the extensions of the files processed by Graal). Another option could be to execute Graal several times, one per each programming language, this would allow the user to focus on a specific language.

analysis of configuration files
Nowadays configuration files are pretty popular, but currently Graal doesn't take them into account. For instance, some tools already exist to validate Docker file, while other tools inspect the content of docker containers to extract useful information about dependencies and vulnerabilities (cc @neglectos).

[jgbarah]

Thanks for the opportunity. I share @valeriocos concerns and ideas. One additional improvement could be to run some tool / heuristics on every file to infer its programming language. This would allow to skip binary files from analysis, but also target specific tools to specific files based on language, for example.

One option for this would be to use linguist, which is the tool GitHub uses for this matter.

[valeriocos]

@jgbarah what do you think to integrate linguist as a backend in graal ?

[jgbarah]

Not sure if as a backend, but it could be an idea.

The fact is that now I'm not aware of telling graal to say something like "if it is C, run this set of tools, if it is Python, run this other set, and if it is source code in any other language, run this one". linguist could help in this. Maybe by running lingusist first (as a backend), and based on the output from it, decide on the other tools to run...

[inishchith]

One option for this would be to use linguist, which is the tool GitHub uses for this matter.

@valeriocos Adding linguist as a backend would be really leveraged on as the project progresses. I would be interested in working on adding the backend support once i've some clarity over the idea and it's functioning.

The fact is that now I'm not aware of telling graal to say something like "if it is C, run this set of tools, if it is Python, run this other set, and if it is source code in any other language, run this one". linguist could help in this. Maybe by running lingusist first (as a backend), and based on the output from it, decide on the other tools to run...

@jgbarah That sounds interesting. I'm thinking something related to adding flags to restrict analysis on to specific languages. I'll add a more clearer Idea here after thinking this through.

[inishchith]

@valeriocos I'd like to some clarity over adding linguist as a backend. Let me know what you think :)
Thanks

Edit: sorry i by mistake, closed the issue. Have reopened it

[valeriocos]

Sure @inishchith , I'll have a look at it and go back to you in the next days. Thanks

[inishchith]

@valeriocos After understanding @jgbarah 's suggestion. I'm thinking we could integrate linguist as a backend ( analyzer for CoCom ) in order to infer the programming language used in a repository. And can be useful to implement metrics based on Percentage Programming Language of a software development repository with multiple languages in future.

Let me know what you think :)
I'd be interested in working through a solution.
Thanks

[valeriocos]

Thank you @inishchith , I like the idea! Let's see how to proceed :)

Why you would like to add linguist as an analyzer for CoCom instead of creating a new backend (e.g., CoLang) ?

AFAIU linguist returns the percentage of programming languages used in a repo, taking as input the path of the repo (or the snapshot at a given commit), which seems to be incompatible with the logic used in CoCom, which analyzes every file in a commit.

The new backend could rely on two analyzers, linguist and cloc, but in this case the latter would be executed on the full repo (instead of on a single file as done for the CoCom backend).

What do you think ?

[inishchith]

@valeriocos Thanks for the response.

Why you would like to add linguist as an analyzer for CoCom instead of creating a new backend (e.g., CoLang)?

Sorry, I missed something out there. I was thinking on the lines of inferring the programming language may only be useful in Code complexity analysis, whereas it can be extensible and useful to other backends as well, also the idea of adding an analyzer for CoCom backend doesn't fit well as you later said.

AFAIU linguist returns the percentage of programming languages used in a repo, taking as input the path of the repo (or the snapshot at a given commit), which seems to be incompatible with the logic used in CoCom, which analyzes every file in a commit.

Exactly! In that case, we should have a new backend ( CoLang, as you suggested )

The new backend could rely on two analyzers, linguist and cloc, but in this case the latter would be executed on the full repo (instead of on a single file as done for the CoCom backend).

Yes. This adds more clarity to the idea!.

@valeriocos @jgbarah Please let me know if can start working on this. We can have a discussion on the structure of the output produced and tests to be added once incorporating the new Idea in the corresponding PR.

[valeriocos]

Thank you for your prompt reply @inishchith !
+1 from my side, let's wait for @jgbarah 's feedback

Just an idea that popped up right now.
Maybe the work to be done for this new backend could be shared with other people interested in this proposal. Since you have already some experience in writing an analyzer, you could focus on writing the backend, while the analyzers could be done by others. It is possible that the development will be slower, but it can be a good experience for those ones involved.

[apoorvaanand1998]

Hi everyone, sorry for not being active in the discussions. College commitments are taking all of my time right now. As mentioned in the proposal, I'll be free from 16th and will work hard in thinking about CoLang as a backend