alexwl / haskell-code-explorer

Web application for exploring and understanding Haskell codebases
MIT License
509 stars 20 forks source link

Client #32

Closed rikvdkleij closed 5 years ago

rikvdkleij commented 5 years ago

Cool project!

Is it possible to have a client which reads the indexed data?

This project could maybe be alternative solution for intero and so making the IntelliJ Haskell plug-in also work for Cabal projects.

alexwl commented 5 years ago

Thanks!

It is certainly possible to have a client that reads the indexed data.

Currently, the only client is a web application, so the output format of the indexer (haskell-code-indexer) is optimized for serving over HTTP: one gzipped JSON file for each indexed Haskell module; the code that saves the data to disk is here https://github.com/alexwl/haskell-code-explorer/blob/74f92973b71fa1c897d46cff6597ade883cb9b11/app/Indexer.hs#L118-L135 It is possible to add an option to the indexer to save the output in a form more suitable for reading by external applications (e.g., one binary file).

I think it is worth noting that the indexer does not support incremental reindexing, so I'm not sure if it is feasible to use the data from the indexer in IntelliJ Haskell plugin.

rikvdkleij commented 5 years ago

It is possible to add an option to the indexer to save the output in a form more suitable for reading by external applications (e.g., one binary file).

Also, the interface of client should have options to request which kind of info and which location (e.g. filepath/module name, rownr and columnnr) (I took a quick look on the uncompressed indexed data but could not find e.g. the type of an identifier.)

I think it is worth noting that the indexer does not support incremental reindexing, so I'm not sure if it is feasible to use the data from the indexer in IntelliJ Haskell plugin.

I do not know if that would be deal-breaker. Have to find out... Is is doable to make support incremental reindexing?

Something else, when I ran the indexer the first time, it was automatically building cabal-install while the cabal binary of the right version was on the path.

alexwl commented 5 years ago

Here is an example of JSON with the data: https://haskell-code-explorer.mfix.io/files/amazonka-cloudsearch-domains-1.6.0/.haskell-code-explorer/test%252FTest%252FAWS%252FCloudSearchDomains.hs.json (the Haskell module: https://haskell-code-explorer.mfix.io/package/amazonka-cloudsearch-domains-1.6.0/show/test/Test/AWS/CloudSearchDomains.hs)

The root JSON object has the following attributes:

For example, information about "tests" function:

{
  "isExported": true,
  "idType": {
    "components": [
      {
        "tag": "Text",
        "contents": "["
      },
      {
        "tag": "TyCon",
        "name": "TestTree",
        "internalId": "4"
      },
      {
        "tag": "Text",
        "contents": "]"
      }
    ]
  },
  "locationInfo": {
    "packageId": {
      "name": "amazonka-cloudsearch-domains",
      "version": "1.6.0"
    },
    "tag": "ExactLocation",
    "moduleName": "Test.AWS.CloudSearchDomains",
    "startLine": 23,
    "endLine": 23,
    "modulePath": "test/Test/AWS/CloudSearchDomains.hs",
    "startColumn": 1,
    "endColumn": 6
  },
  "nameSpace": "VarName",
  "internalId": "0",
  "details": "VanillaId",
  "sort": "External",
  "occName": "tests",
  "externalId": "amazonka-cloudsearch-domains-1.6.0|Test.AWS.CloudSearchDomains|Val|tests",
  "demangledOccName": "tests"
}

Type of an identifier is the value of idType attribute.

Is is doable to make support incremental reindexing?

It is hard to say at the moment (I need to investigate this). I guess it would require significant changes in the indexing process.

Something else, when I ran the indexer the first time, it was automatically building cabal-install while the cabal binary of the right version was on the path.

I think cabal-helper didn't find the appropriate version of Cabal library.

From cabal-helper documentation (http://hackage.haskell.org/package/cabal-helper):

Since we do not want to bind the user of a development tool which utilises this library to a specific version of Cabal we compile the code which interfaces with the Cabal library's API on the user's machine, at runtime, against whichever version of Cabal was used to write the on disk information for a given project.

If this version of Cabal is not available on the users machine anymore, which is fairly likely since cabal-install is usually linked statically, we have support for compiling the Cabal library also. In this case the library is installed into a private, isolated, package database in $XDG_CACHE_HOME/cabal-helper so as to not interfere with the user's package database."

rikvdkleij commented 5 years ago

Closing this issue because I think it's get too complicated for integration with IntelliJ. It has to work out-of-the-box in various environments.

Thanks for answering my questions!