Skip to content
This repository
Fetching contributors…

Cannot retrieve contributors at this time

file 74 lines (62 sloc) 2.81 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
# BW-DB

A database approach to EclipseFP and buildwrapper

## Goals
- find all usages of a symbol
in particular project
in workspace
- open a module anywhere in the workspace

-> enables
- haskell sensitive searches
- haskell sensitive renames
- remove unused packages in dependencies

## BuildWrapper
BuildWrapper can already provide usage info on one file
- load a single file and dependant in the API
- get AST and generate JSON
- stores it in .bwinfo file
-> but we need it at the project level since
- we cannot be sure every file has been opened in the editor
- reusing that function file by file, restarting buildwrapper and a new GHC session will be too slow

### Project resolution
- for each cabal component
- find "start" modules
- Main for executables and tests
- All exposed modules for library
- load start modules in GHC API
- get all modules from module dependency graph
- for each module
- get AST and generate needed information
package, module, symbol -> all locations used

### File resolution
- when a file is saved, get the info for that file and save it

### Error handling
- if the project doesn't build, we won't get all modules
- can we still get some info?
- when the project finally builds, we need to get all new files info (files after the last modified file)
- cabal build already gives us that

So ->
- no info for project: get info for everything
- file saved: get info for file
- project built: get info for all built files

How do we get the info?
- along the bwinfo file for each file?
- json result?

## Eclipse

### Database solution
The database will be on the Eclipse side to not have a long running process to manage. Use an embeded database
- SQLLite: same as scion-browser, need native layer, probably more cumbersome
- do it in scion-browser (additional tables) performance? Fact that we keep references to local files problematic?
- Derby/HSQLDB or other pure java implementation: provide jar in plugin, less headaches

### Info
need module + package to resolve duplicates?
versioning of packages?
maybe important for local projects (do we reference the project or an older version)
file in Eclipse -> file id so that we can easily delete all info pertaining to one file
package + module -> unique module id + file where defined (for local modules)
-> get all modules from package
-> need to get local modules from name and then get package
-> can list all modules for project: module where package=cabal name and defined file exist
-> several Main for one project can exist!! -> need component name for main
module id + name -> unique symbol id + definition (for local symbols)
symbol id -> usages (file in Eclipse format (project + path), line span)
module id -> usages (import/export)
Something went wrong with that request. Please try again.