Unsupported scheme error when using “ls” command on a Java package










1















I am working on a function that gives a list of code volume per package in for a Java M3. This function looks like this:



public list[int] calculateSizePerComponent(M3 model)
set[loc] packages = packages(model);
list[int] componentSizes = ;
for(package <- packages)
list[loc] classFiles = [x
return componentSizes;



I use the following function to calculate the amount of lines of code (volume) in a Java compilation unit (which works for other examples):



public tuple[int linesOfCode,int blankLines,int commentLines] getLinesOfCode(loc location) 
int linesOfCode = 0;
int blankLines = 0;
int commentLines = 0;
bool incomment = false;

srcLines = readFileLines(location);
for (line <- srcLines)
switch(line)
case /^s*//s*w*/: commentLines += 1; // Line preceded by '//'
case /((s*/*[ws]+*/)+[sw]+(//[sw]+$)*)+/: linesOfCode += 1; // Line containing Java code containing any amount of comments. Example: code /**comment*/ code /**comment*/ code
case /^s*/*?[ws?@]**/$/: commentLines += 1; // Line containing single line comment: /*comment*/
case /s*/*[ws]**/[sw]+/: linesOfCode += 1; // Line containing a comment, but also code. Example: /**comment*/ code
case /^[sw]**/s*w+[sw]*/: incomment = false; linesOfCode += 1; // Line closing a multi-line comment, but also containing code. Example: comment*/ code
case /^s*/**?[^*/]*$/: incomment = true; commentLines += 1; // Line opening a multi-line comment, Example: /**comment
case /s**/s*$/: commentLines += 1; incomment = false; // Line closing a multi-line comment, Example: comment*/
case /^s*$/: blankLines += 1; // Blank line
default: if (incomment) commentLines += 1; else linesOfCode += 1;


return <linesOfCode,blankLines,commentLines>;



However, package.ls seems to return results that have a wrong scheme. Due to this, I get the following error at the readFileLines call:



|std:///IO.rsc|(14565,775,<583,0>,<603,43>): IO("Unsupported scheme java+package")
at *** somewhere ***(|std:///IO.rsc|(14565,775,<583,0>,<603,43>))
at readFileLines(|project://Software_Evolution/src/metrics/volume.rsc|(1911,8,<49,26>,<49,34>))
at calculateSizePerComponent(|project://Software_Evolution/src/metrics/componentsize.rsc|(1996,38,<64,16>,<64,54>))
at getComponentSize(|project://Software_Evolution/src/metrics/componentsize.rsc|(267,1112,<15,0>,<42,1>))
at $root$(|prompt:///|(0,30,<1,0>,<1,30>))


When I println the location, I get the following:



|java+package:///smallsql/database/language/Language.java|


This is incorrect, because this is a java compilationunit and not a package. How do I get the lines of code in this file?










share|improve this question


























    1















    I am working on a function that gives a list of code volume per package in for a Java M3. This function looks like this:



    public list[int] calculateSizePerComponent(M3 model)
    set[loc] packages = packages(model);
    list[int] componentSizes = ;
    for(package <- packages)
    list[loc] classFiles = [x
    return componentSizes;



    I use the following function to calculate the amount of lines of code (volume) in a Java compilation unit (which works for other examples):



    public tuple[int linesOfCode,int blankLines,int commentLines] getLinesOfCode(loc location) 
    int linesOfCode = 0;
    int blankLines = 0;
    int commentLines = 0;
    bool incomment = false;

    srcLines = readFileLines(location);
    for (line <- srcLines)
    switch(line)
    case /^s*//s*w*/: commentLines += 1; // Line preceded by '//'
    case /((s*/*[ws]+*/)+[sw]+(//[sw]+$)*)+/: linesOfCode += 1; // Line containing Java code containing any amount of comments. Example: code /**comment*/ code /**comment*/ code
    case /^s*/*?[ws?@]**/$/: commentLines += 1; // Line containing single line comment: /*comment*/
    case /s*/*[ws]**/[sw]+/: linesOfCode += 1; // Line containing a comment, but also code. Example: /**comment*/ code
    case /^[sw]**/s*w+[sw]*/: incomment = false; linesOfCode += 1; // Line closing a multi-line comment, but also containing code. Example: comment*/ code
    case /^s*/**?[^*/]*$/: incomment = true; commentLines += 1; // Line opening a multi-line comment, Example: /**comment
    case /s**/s*$/: commentLines += 1; incomment = false; // Line closing a multi-line comment, Example: comment*/
    case /^s*$/: blankLines += 1; // Blank line
    default: if (incomment) commentLines += 1; else linesOfCode += 1;


    return <linesOfCode,blankLines,commentLines>;



    However, package.ls seems to return results that have a wrong scheme. Due to this, I get the following error at the readFileLines call:



    |std:///IO.rsc|(14565,775,<583,0>,<603,43>): IO("Unsupported scheme java+package")
    at *** somewhere ***(|std:///IO.rsc|(14565,775,<583,0>,<603,43>))
    at readFileLines(|project://Software_Evolution/src/metrics/volume.rsc|(1911,8,<49,26>,<49,34>))
    at calculateSizePerComponent(|project://Software_Evolution/src/metrics/componentsize.rsc|(1996,38,<64,16>,<64,54>))
    at getComponentSize(|project://Software_Evolution/src/metrics/componentsize.rsc|(267,1112,<15,0>,<42,1>))
    at $root$(|prompt:///|(0,30,<1,0>,<1,30>))


    When I println the location, I get the following:



    |java+package:///smallsql/database/language/Language.java|


    This is incorrect, because this is a java compilationunit and not a package. How do I get the lines of code in this file?










    share|improve this question
























      1












      1








      1








      I am working on a function that gives a list of code volume per package in for a Java M3. This function looks like this:



      public list[int] calculateSizePerComponent(M3 model)
      set[loc] packages = packages(model);
      list[int] componentSizes = ;
      for(package <- packages)
      list[loc] classFiles = [x
      return componentSizes;



      I use the following function to calculate the amount of lines of code (volume) in a Java compilation unit (which works for other examples):



      public tuple[int linesOfCode,int blankLines,int commentLines] getLinesOfCode(loc location) 
      int linesOfCode = 0;
      int blankLines = 0;
      int commentLines = 0;
      bool incomment = false;

      srcLines = readFileLines(location);
      for (line <- srcLines)
      switch(line)
      case /^s*//s*w*/: commentLines += 1; // Line preceded by '//'
      case /((s*/*[ws]+*/)+[sw]+(//[sw]+$)*)+/: linesOfCode += 1; // Line containing Java code containing any amount of comments. Example: code /**comment*/ code /**comment*/ code
      case /^s*/*?[ws?@]**/$/: commentLines += 1; // Line containing single line comment: /*comment*/
      case /s*/*[ws]**/[sw]+/: linesOfCode += 1; // Line containing a comment, but also code. Example: /**comment*/ code
      case /^[sw]**/s*w+[sw]*/: incomment = false; linesOfCode += 1; // Line closing a multi-line comment, but also containing code. Example: comment*/ code
      case /^s*/**?[^*/]*$/: incomment = true; commentLines += 1; // Line opening a multi-line comment, Example: /**comment
      case /s**/s*$/: commentLines += 1; incomment = false; // Line closing a multi-line comment, Example: comment*/
      case /^s*$/: blankLines += 1; // Blank line
      default: if (incomment) commentLines += 1; else linesOfCode += 1;


      return <linesOfCode,blankLines,commentLines>;



      However, package.ls seems to return results that have a wrong scheme. Due to this, I get the following error at the readFileLines call:



      |std:///IO.rsc|(14565,775,<583,0>,<603,43>): IO("Unsupported scheme java+package")
      at *** somewhere ***(|std:///IO.rsc|(14565,775,<583,0>,<603,43>))
      at readFileLines(|project://Software_Evolution/src/metrics/volume.rsc|(1911,8,<49,26>,<49,34>))
      at calculateSizePerComponent(|project://Software_Evolution/src/metrics/componentsize.rsc|(1996,38,<64,16>,<64,54>))
      at getComponentSize(|project://Software_Evolution/src/metrics/componentsize.rsc|(267,1112,<15,0>,<42,1>))
      at $root$(|prompt:///|(0,30,<1,0>,<1,30>))


      When I println the location, I get the following:



      |java+package:///smallsql/database/language/Language.java|


      This is incorrect, because this is a java compilationunit and not a package. How do I get the lines of code in this file?










      share|improve this question














      I am working on a function that gives a list of code volume per package in for a Java M3. This function looks like this:



      public list[int] calculateSizePerComponent(M3 model)
      set[loc] packages = packages(model);
      list[int] componentSizes = ;
      for(package <- packages)
      list[loc] classFiles = [x
      return componentSizes;



      I use the following function to calculate the amount of lines of code (volume) in a Java compilation unit (which works for other examples):



      public tuple[int linesOfCode,int blankLines,int commentLines] getLinesOfCode(loc location) 
      int linesOfCode = 0;
      int blankLines = 0;
      int commentLines = 0;
      bool incomment = false;

      srcLines = readFileLines(location);
      for (line <- srcLines)
      switch(line)
      case /^s*//s*w*/: commentLines += 1; // Line preceded by '//'
      case /((s*/*[ws]+*/)+[sw]+(//[sw]+$)*)+/: linesOfCode += 1; // Line containing Java code containing any amount of comments. Example: code /**comment*/ code /**comment*/ code
      case /^s*/*?[ws?@]**/$/: commentLines += 1; // Line containing single line comment: /*comment*/
      case /s*/*[ws]**/[sw]+/: linesOfCode += 1; // Line containing a comment, but also code. Example: /**comment*/ code
      case /^[sw]**/s*w+[sw]*/: incomment = false; linesOfCode += 1; // Line closing a multi-line comment, but also containing code. Example: comment*/ code
      case /^s*/**?[^*/]*$/: incomment = true; commentLines += 1; // Line opening a multi-line comment, Example: /**comment
      case /s**/s*$/: commentLines += 1; incomment = false; // Line closing a multi-line comment, Example: comment*/
      case /^s*$/: blankLines += 1; // Blank line
      default: if (incomment) commentLines += 1; else linesOfCode += 1;


      return <linesOfCode,blankLines,commentLines>;



      However, package.ls seems to return results that have a wrong scheme. Due to this, I get the following error at the readFileLines call:



      |std:///IO.rsc|(14565,775,<583,0>,<603,43>): IO("Unsupported scheme java+package")
      at *** somewhere ***(|std:///IO.rsc|(14565,775,<583,0>,<603,43>))
      at readFileLines(|project://Software_Evolution/src/metrics/volume.rsc|(1911,8,<49,26>,<49,34>))
      at calculateSizePerComponent(|project://Software_Evolution/src/metrics/componentsize.rsc|(1996,38,<64,16>,<64,54>))
      at getComponentSize(|project://Software_Evolution/src/metrics/componentsize.rsc|(267,1112,<15,0>,<42,1>))
      at $root$(|prompt:///|(0,30,<1,0>,<1,30>))


      When I println the location, I get the following:



      |java+package:///smallsql/database/language/Language.java|


      This is incorrect, because this is a java compilationunit and not a package. How do I get the lines of code in this file?







      java rascal






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 15 '18 at 17:01









      Simon BaarsSimon Baars

      740919




      740919






















          1 Answer
          1






          active

          oldest

          votes


















          1














          Step by step analysis:




          • package.ls works because first the logical URI is resolved by the registry "name server" to an actual physical folder on disk. If that is indeed a directory then .ls has the right semantics and you get back a list of files in that folder.

          • the loc |java+package:///smallsql/database/language/Language.java| actually points to a file and not even a compilationUnit.

          • something unintended is going on with the construction of the child locations, it takes the old logical location of the folder and simply concatenates the name of the child file "Language.java", but that does not make sense.

          • I fixed this bug in the current master, and an unstable release is forthcoming in a few minutes

          • but you can also work around this by first resolving the package location to a physical location: resolve(package).ls should do much better.

          PS: the regular expressions are rather error prone, and you might have to deal with a lot of corner cases. I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC.






          share|improve this answer


















          • 1





            oops. I reverted the bugfix because some downstream regression tests failed on the CI. have to take some time to look into that; in the meantime please use the workaround.

            – Jurgen Vinju
            Nov 15 '18 at 21:55











          • Thanks for this extensive answer. Rascal is awesome :-).

            – Simon Baars
            Nov 16 '18 at 23:03











          • Concerning this: I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC., can you point me to some sources on how to derive the SLOC without deriving the actual source lines in the source files? I indeed have some issues with my regexes.

            – Simon Baars
            Nov 16 '18 at 23:05






          • 1





            I would look at the definition of the m3::AST.rsc for Java in the library, each node has a field with its source position. You know how many lines the entire method has and which lines each statement and expression covers. Etc. Can't do your homework but that gives a hint. Also in Lang::standard are example syntax definitions for comments and whitespace, you could make an "island parser" with those. Or finally you might extend the Java 4 parser in Lang::Java to cover your dialect and count the whitespsce and comments on those trees. Many options, that is also Rascal. Pick what you like best

            – Jurgen Vinju
            Nov 17 '18 at 7:02










          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53324500%2funsupported-scheme-error-when-using-ls-command-on-a-java-package%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          Step by step analysis:




          • package.ls works because first the logical URI is resolved by the registry "name server" to an actual physical folder on disk. If that is indeed a directory then .ls has the right semantics and you get back a list of files in that folder.

          • the loc |java+package:///smallsql/database/language/Language.java| actually points to a file and not even a compilationUnit.

          • something unintended is going on with the construction of the child locations, it takes the old logical location of the folder and simply concatenates the name of the child file "Language.java", but that does not make sense.

          • I fixed this bug in the current master, and an unstable release is forthcoming in a few minutes

          • but you can also work around this by first resolving the package location to a physical location: resolve(package).ls should do much better.

          PS: the regular expressions are rather error prone, and you might have to deal with a lot of corner cases. I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC.






          share|improve this answer


















          • 1





            oops. I reverted the bugfix because some downstream regression tests failed on the CI. have to take some time to look into that; in the meantime please use the workaround.

            – Jurgen Vinju
            Nov 15 '18 at 21:55











          • Thanks for this extensive answer. Rascal is awesome :-).

            – Simon Baars
            Nov 16 '18 at 23:03











          • Concerning this: I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC., can you point me to some sources on how to derive the SLOC without deriving the actual source lines in the source files? I indeed have some issues with my regexes.

            – Simon Baars
            Nov 16 '18 at 23:05






          • 1





            I would look at the definition of the m3::AST.rsc for Java in the library, each node has a field with its source position. You know how many lines the entire method has and which lines each statement and expression covers. Etc. Can't do your homework but that gives a hint. Also in Lang::standard are example syntax definitions for comments and whitespace, you could make an "island parser" with those. Or finally you might extend the Java 4 parser in Lang::Java to cover your dialect and count the whitespsce and comments on those trees. Many options, that is also Rascal. Pick what you like best

            – Jurgen Vinju
            Nov 17 '18 at 7:02















          1














          Step by step analysis:




          • package.ls works because first the logical URI is resolved by the registry "name server" to an actual physical folder on disk. If that is indeed a directory then .ls has the right semantics and you get back a list of files in that folder.

          • the loc |java+package:///smallsql/database/language/Language.java| actually points to a file and not even a compilationUnit.

          • something unintended is going on with the construction of the child locations, it takes the old logical location of the folder and simply concatenates the name of the child file "Language.java", but that does not make sense.

          • I fixed this bug in the current master, and an unstable release is forthcoming in a few minutes

          • but you can also work around this by first resolving the package location to a physical location: resolve(package).ls should do much better.

          PS: the regular expressions are rather error prone, and you might have to deal with a lot of corner cases. I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC.






          share|improve this answer


















          • 1





            oops. I reverted the bugfix because some downstream regression tests failed on the CI. have to take some time to look into that; in the meantime please use the workaround.

            – Jurgen Vinju
            Nov 15 '18 at 21:55











          • Thanks for this extensive answer. Rascal is awesome :-).

            – Simon Baars
            Nov 16 '18 at 23:03











          • Concerning this: I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC., can you point me to some sources on how to derive the SLOC without deriving the actual source lines in the source files? I indeed have some issues with my regexes.

            – Simon Baars
            Nov 16 '18 at 23:05






          • 1





            I would look at the definition of the m3::AST.rsc for Java in the library, each node has a field with its source position. You know how many lines the entire method has and which lines each statement and expression covers. Etc. Can't do your homework but that gives a hint. Also in Lang::standard are example syntax definitions for comments and whitespace, you could make an "island parser" with those. Or finally you might extend the Java 4 parser in Lang::Java to cover your dialect and count the whitespsce and comments on those trees. Many options, that is also Rascal. Pick what you like best

            – Jurgen Vinju
            Nov 17 '18 at 7:02













          1












          1








          1







          Step by step analysis:




          • package.ls works because first the logical URI is resolved by the registry "name server" to an actual physical folder on disk. If that is indeed a directory then .ls has the right semantics and you get back a list of files in that folder.

          • the loc |java+package:///smallsql/database/language/Language.java| actually points to a file and not even a compilationUnit.

          • something unintended is going on with the construction of the child locations, it takes the old logical location of the folder and simply concatenates the name of the child file "Language.java", but that does not make sense.

          • I fixed this bug in the current master, and an unstable release is forthcoming in a few minutes

          • but you can also work around this by first resolving the package location to a physical location: resolve(package).ls should do much better.

          PS: the regular expressions are rather error prone, and you might have to deal with a lot of corner cases. I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC.






          share|improve this answer













          Step by step analysis:




          • package.ls works because first the logical URI is resolved by the registry "name server" to an actual physical folder on disk. If that is indeed a directory then .ls has the right semantics and you get back a list of files in that folder.

          • the loc |java+package:///smallsql/database/language/Language.java| actually points to a file and not even a compilationUnit.

          • something unintended is going on with the construction of the child locations, it takes the old logical location of the folder and simply concatenates the name of the child file "Language.java", but that does not make sense.

          • I fixed this bug in the current master, and an unstable release is forthcoming in a few minutes

          • but you can also work around this by first resolving the package location to a physical location: resolve(package).ls should do much better.

          PS: the regular expressions are rather error prone, and you might have to deal with a lot of corner cases. I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 15 '18 at 21:23









          Jurgen VinjuJurgen Vinju

          4,120920




          4,120920







          • 1





            oops. I reverted the bugfix because some downstream regression tests failed on the CI. have to take some time to look into that; in the meantime please use the workaround.

            – Jurgen Vinju
            Nov 15 '18 at 21:55











          • Thanks for this extensive answer. Rascal is awesome :-).

            – Simon Baars
            Nov 16 '18 at 23:03











          • Concerning this: I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC., can you point me to some sources on how to derive the SLOC without deriving the actual source lines in the source files? I indeed have some issues with my regexes.

            – Simon Baars
            Nov 16 '18 at 23:05






          • 1





            I would look at the definition of the m3::AST.rsc for Java in the library, each node has a field with its source position. You know how many lines the entire method has and which lines each statement and expression covers. Etc. Can't do your homework but that gives a hint. Also in Lang::standard are example syntax definitions for comments and whitespace, you could make an "island parser" with those. Or finally you might extend the Java 4 parser in Lang::Java to cover your dialect and count the whitespsce and comments on those trees. Many options, that is also Rascal. Pick what you like best

            – Jurgen Vinju
            Nov 17 '18 at 7:02












          • 1





            oops. I reverted the bugfix because some downstream regression tests failed on the CI. have to take some time to look into that; in the meantime please use the workaround.

            – Jurgen Vinju
            Nov 15 '18 at 21:55











          • Thanks for this extensive answer. Rascal is awesome :-).

            – Simon Baars
            Nov 16 '18 at 23:03











          • Concerning this: I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC., can you point me to some sources on how to derive the SLOC without deriving the actual source lines in the source files? I indeed have some issues with my regexes.

            – Simon Baars
            Nov 16 '18 at 23:05






          • 1





            I would look at the definition of the m3::AST.rsc for Java in the library, each node has a field with its source position. You know how many lines the entire method has and which lines each statement and expression covers. Etc. Can't do your homework but that gives a hint. Also in Lang::standard are example syntax definitions for comments and whitespace, you could make an "island parser" with those. Or finally you might extend the Java 4 parser in Lang::Java to cover your dialect and count the whitespsce and comments on those trees. Many options, that is also Rascal. Pick what you like best

            – Jurgen Vinju
            Nov 17 '18 at 7:02







          1




          1





          oops. I reverted the bugfix because some downstream regression tests failed on the CI. have to take some time to look into that; in the meantime please use the workaround.

          – Jurgen Vinju
          Nov 15 '18 at 21:55





          oops. I reverted the bugfix because some downstream regression tests failed on the CI. have to take some time to look into that; in the meantime please use the workaround.

          – Jurgen Vinju
          Nov 15 '18 at 21:55













          Thanks for this extensive answer. Rascal is awesome :-).

          – Simon Baars
          Nov 16 '18 at 23:03





          Thanks for this extensive answer. Rascal is awesome :-).

          – Simon Baars
          Nov 16 '18 at 23:03













          Concerning this: I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC., can you point me to some sources on how to derive the SLOC without deriving the actual source lines in the source files? I indeed have some issues with my regexes.

          – Simon Baars
          Nov 16 '18 at 23:05





          Concerning this: I'd use a real parser generated from a syntax definition for Java, or use the syntax trees which already produced by M3 via the Eclipse compiler to compute the SLOC., can you point me to some sources on how to derive the SLOC without deriving the actual source lines in the source files? I indeed have some issues with my regexes.

          – Simon Baars
          Nov 16 '18 at 23:05




          1




          1





          I would look at the definition of the m3::AST.rsc for Java in the library, each node has a field with its source position. You know how many lines the entire method has and which lines each statement and expression covers. Etc. Can't do your homework but that gives a hint. Also in Lang::standard are example syntax definitions for comments and whitespace, you could make an "island parser" with those. Or finally you might extend the Java 4 parser in Lang::Java to cover your dialect and count the whitespsce and comments on those trees. Many options, that is also Rascal. Pick what you like best

          – Jurgen Vinju
          Nov 17 '18 at 7:02





          I would look at the definition of the m3::AST.rsc for Java in the library, each node has a field with its source position. You know how many lines the entire method has and which lines each statement and expression covers. Etc. Can't do your homework but that gives a hint. Also in Lang::standard are example syntax definitions for comments and whitespace, you could make an "island parser" with those. Or finally you might extend the Java 4 parser in Lang::Java to cover your dialect and count the whitespsce and comments on those trees. Many options, that is also Rascal. Pick what you like best

          – Jurgen Vinju
          Nov 17 '18 at 7:02



















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53324500%2funsupported-scheme-error-when-using-ls-command-on-a-java-package%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Top Tejano songwriter Luis Silva dead of heart attack at 64

          ReactJS Fetched API data displays live - need Data displayed static

          政党