[sonar-dev] No issues can be reported on sslr-squid-bridge on github; where should they be reported?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
fge
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[sonar-dev] No issues can be reported on sslr-squid-bridge on github; where should they be reported?

fge
Hello,

All is in the question.

Regards,

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] No issues can be reported on sslr-squid-bridge on github; where should they be reported?

Dinesh Bolkensteyn-2
Issues should be discussed on this very mailing list first.


On Fri, May 22, 2015 at 12:45 PM, Francis Galiegue <[hidden email]> wrote:
Hello,

All is in the question.

Regards,

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



fge
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] No issues can be reported on sslr-squid-bridge on github; where should they be reported?

fge
Hello,

On Fri, May 22, 2015 at 1:24 PM, Dinesh Bolkensteyn
<[hidden email]> wrote:
> Issues should be discussed on this very mailing list first.
>

OK, so here goes.

* First issue: AstScanner' .scanFile() vs .scanFiles() is counterintuitive

All that .scanFile() does is called
.scanFiles(ImmutableList.of(theArgument)); in turn, .scanFiles() will
.init() all visitors, which led to my early problem that checks were
registered more than once.

This means that you need to first collect all files into a Collection
before starting the scan; but this is very counterintuitive since the
way you currently do this basically requires on Guava, whose
Lists.newArrayList(...) can take an Iterable as an argument, which is
basically a result of fs.files(somePredicate). Which returns an
Iterable!

Therefore a natural way of doing it, which I tried at first was to:

    for (final File f: fs.files(predicate))
        scanner.scan(file);

Except no, it doesn't work that way, see above. This is not only
counterintuitive, but more cricitally _not documented_.

* Second issue: no existing hook to perform project-wise checks on
AstNodes; or if it exists, again, not documented

There is .leaveFile(). There is no .leaveProject().

I use the .leaveFile() hook so that I can, using a custom visitor,
associate all SourceFiles with an AstNode, which I need to compute
custom metrics, since those metrics depend on the AstNode of that file
_and all other project files_.

But that's a hack. I'd much rather a visitor allowed me to plug at the
project level directly so that I could just compute the needed metrics
(I do that too) and perform checks on the values of these metrics.

Currently I see no direct way of doing that.

Regards,
--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] No issues can be reported on sslr-squid-bridge on github; where should they be reported?

Dinesh Bolkensteyn-2
I am not sure to get exactly what your first issue is. Why does Guava & predicates come into play?
Indeed the SSLR Squid Bridge currently requires you to have a list of all files.

Regarding your second issue, you might have luck with init() and destroy()

FYI - on most plugins we are slowly transitioning away from AstNode and the from SSLR Squid Bridge (except for its rule annotation part).
My suggestion would be to not spend too much time trying to workaround its limitations, but rather to write your own logic in your plugin.

Kind regards,


On Fri, May 22, 2015 at 2:30 PM, Francis Galiegue <[hidden email]> wrote:
Hello,

On Fri, May 22, 2015 at 1:24 PM, Dinesh Bolkensteyn
<[hidden email]> wrote:
> Issues should be discussed on this very mailing list first.
>

OK, so here goes.

* First issue: AstScanner' .scanFile() vs .scanFiles() is counterintuitive

All that .scanFile() does is called
.scanFiles(ImmutableList.of(theArgument)); in turn, .scanFiles() will
.init() all visitors, which led to my early problem that checks were
registered more than once.

This means that you need to first collect all files into a Collection
before starting the scan; but this is very counterintuitive since the
way you currently do this basically requires on Guava, whose
Lists.newArrayList(...) can take an Iterable as an argument, which is
basically a result of fs.files(somePredicate). Which returns an
Iterable!

Therefore a natural way of doing it, which I tried at first was to:

    for (final File f: fs.files(predicate))
        scanner.scan(file);

Except no, it doesn't work that way, see above. This is not only
counterintuitive, but more cricitally _not documented_.

* Second issue: no existing hook to perform project-wise checks on
AstNodes; or if it exists, again, not documented

There is .leaveFile(). There is no .leaveProject().

I use the .leaveFile() hook so that I can, using a custom visitor,
associate all SourceFiles with an AstNode, which I need to compute
custom metrics, since those metrics depend on the AstNode of that file
_and all other project files_.

But that's a hack. I'd much rather a visitor allowed me to plug at the
project level directly so that I could just compute the needed metrics
(I do that too) and perform checks on the values of these metrics.

Currently I see no direct way of doing that.

Regards,
--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



fge
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] No issues can be reported on sslr-squid-bridge on github; where should they be reported?

fge
Hello again,

On Fri, May 22, 2015 at 2:45 PM, Dinesh Bolkensteyn
<[hidden email]> wrote:
> I am not sure to get exactly what your first issue is. Why does Guava &
> predicates come into play?

Predicates doesn't have anything to do with that; Guava does. Because
Guava allows you, via Lists.arrayList(...), to build a List<T> out of
an Iterable<T>.

And the way you obtain the list of source files is usually to query a
Sonar's FileSystem (which by the way should be renamed; there is
java.nio.file.FileSystem) .predicate() method as in:

    listOfFiles = Lists.newArrayList(fs.files(...))

and then operate on listOfFiles.

> Indeed the SSLR Squid Bridge currently requires you to have a list of all
> files.
>

Well, i realized that but only after it was "too late". I couldn't
figure out the behavior until I actually debugged the code.

Again: given a Sonar's FileSystem named fs, and a FilePredicate named
predicate returning all files, given that fs.files(predicate) returns
an Iterable, the natural reflex of a reasonably seasoned Java dev
would have been to do:

    for (final File file: fs.files(predicate))
        /* do something with file */

But it does not work that way and it is _very_ counterintuitive.

>
> Regarding your second issue, you might have luck with init() and destroy()
>

But then how can I obtain, from .destroy(), the list of _all_ AstNodes
from _all_ files of the project?

> FYI - on most plugins we are slowly transitioning away from AstNode and the
> from SSLR Squid Bridge (except for its rule annotation part).
> My suggestion would be to not spend too much time trying to workaround its
> limitations, but rather to write your own logic in your plugin.
>

Well, that seems to be quite some task but then what is the path to the future?

Unfortunately, here I have time constraints. Note that I'll be happy
to help explore further routes, but right now I have the AstNodes
produced for all nodes, which works and contains everything I want,
and I basically need to use that.

And I do see that two of the most prominent language plugins out there
(ie, Java and JavaScript) don't, or they do so by implementing their
own classes over God knows what; I just can't wrap my head about what
each of these two plugins actually do, and I also happen to use a
LexerfulGrammarBuilder which fits my needs perfectly.

Regards,
--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] No issues can be reported on sslr-squid-bridge on github; where should they be reported?

Dinesh Bolkensteyn-2
OK I get your point now - to connect SonarQube's FileSytem API to the SSLR Squid Bridge scanFiles() - you need one call to Guava's Lists.newArrayList().

Coming back to your 2nd question, you don't want to have access to all AstNodes at once.
AstNode is very memory hungry object (keeping a reference to any AstNode in the tree will effectively keep the whole tree in memory)

So you'll have to find another way to write your rule: You can keep a state between init() and destroy(), and update it as you visit the various AstNode of your project.


On Fri, May 22, 2015 at 3:08 PM, Francis Galiegue <[hidden email]> wrote:
Hello again,

On Fri, May 22, 2015 at 2:45 PM, Dinesh Bolkensteyn
<[hidden email]> wrote:
> I am not sure to get exactly what your first issue is. Why does Guava &
> predicates come into play?

Predicates doesn't have anything to do with that; Guava does. Because
Guava allows you, via Lists.arrayList(...), to build a List<T> out of
an Iterable<T>.

And the way you obtain the list of source files is usually to query a
Sonar's FileSystem (which by the way should be renamed; there is
java.nio.file.FileSystem) .predicate() method as in:

    listOfFiles = Lists.newArrayList(fs.files(...))

and then operate on listOfFiles.

> Indeed the SSLR Squid Bridge currently requires you to have a list of all
> files.
>

Well, i realized that but only after it was "too late". I couldn't
figure out the behavior until I actually debugged the code.

Again: given a Sonar's FileSystem named fs, and a FilePredicate named
predicate returning all files, given that fs.files(predicate) returns
an Iterable, the natural reflex of a reasonably seasoned Java dev
would have been to do:

    for (final File file: fs.files(predicate))
        /* do something with file */

But it does not work that way and it is _very_ counterintuitive.

>
> Regarding your second issue, you might have luck with init() and destroy()
>

But then how can I obtain, from .destroy(), the list of _all_ AstNodes
from _all_ files of the project?

> FYI - on most plugins we are slowly transitioning away from AstNode and the
> from SSLR Squid Bridge (except for its rule annotation part).
> My suggestion would be to not spend too much time trying to workaround its
> limitations, but rather to write your own logic in your plugin.
>

Well, that seems to be quite some task but then what is the path to the future?

Unfortunately, here I have time constraints. Note that I'll be happy
to help explore further routes, but right now I have the AstNodes
produced for all nodes, which works and contains everything I want,
and I basically need to use that.

And I do see that two of the most prominent language plugins out there
(ie, Java and JavaScript) don't, or they do so by implementing their
own classes over God knows what; I just can't wrap my head about what
each of these two plugins actually do, and I also happen to use a
LexerfulGrammarBuilder which fits my needs perfectly.

Regards,
--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



fge
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] No issues can be reported on sslr-squid-bridge on github; where should they be reported?

fge
Hello again,

On Fri, May 22, 2015 at 3:27 PM, Dinesh Bolkensteyn
<[hidden email]> wrote:

> OK I get your point now - to connect SonarQube's FileSytem API to the SSLR
> Squid Bridge scanFiles() - you need one call to Guava's
> Lists.newArrayList().
>
> Coming back to your 2nd question, you don't want to have access to all
> AstNodes at once.
> AstNode is very memory hungry object (keeping a reference to any AstNode in
> the tree will effectively keep the whole tree in memory)
>
> So you'll have to find another way to write your rule: You can keep a state
> between init() and destroy(), and update it as you visit the various AstNode
> of your project.
>

Well, I don't really see a way around it.

Note that I am aware of the whole tree being in memory. But right now
I don't see another way to do it.

Well, I do, but how? For example, let's take a classical metric, Depth
of Inheritance Tree. This metric typically depends on all other files
in the project; I can't do otherwise since if I'm in the context/file
of class A and A inherits B and oh, by the way, I haven't done B yet,
I cannot calculate the DIT of A accurately (it will at least be that
of B plus one, notwithstanding the fact that A may inherit some other
class C which has an even deeper DIT than B).

Right now I do this by collecting all the ASTs of all files and
perform the metric calculation for each file by searching for relevant
nodes in the AST -- I do have an AST precise enough so that I can
compute this easily.

How to do it otherwise? As I see it it would mean having some sort of
builder object accepting some defined elements from the file currently
being parsed, then when all the files are parsed, .build() this object
and only then perform the checks. And this, for as many POJOs as
needed as there are metrics I want to compute. It just so happens that
I have an AST which allows me to compute them all.

And the AST of individual files is needed for checks anyway.

So, what do you recommend I do?

Regards,
--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Loading...