Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Haskell debugger implementation discussion #30

Open
kozer opened this issue Sep 14, 2021 · 6 comments
Open

Haskell debugger implementation discussion #30

kozer opened this issue Sep 14, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@kozer
Copy link
Contributor

kozer commented Sep 14, 2021

Haskell is a very strange language, and there is not an easy way to install the haskell-debug-adapter. There are not any binaries like hls has, so the only solution to install it is having stack or cabal-install and do the following:
stack install haskell-dap ghci-dap haskell-debug-adapter
and add the configuration to the dap.
The problem is that the end-user has to have a Haskell environment in place to run the above command and that the debugger will not end up in the path we have for other debuggers.

I m thinking of one of the following implementations:

  • Leave install and uninstall commands empty, just add the configuration (add info in the docs about that).
  • Run stack install haskell-dap ghci-dap haskell-debug-adapter ignoring the fact that the debugger will be on another location and considering that the user has already a properly haskell setup + add the configurations like the above implementation.

What are your thoughts on that?

@pocco81
Copy link
Owner

pocco81 commented Sep 15, 2021

I too had this internal conflict when writing the installers of some debuggers, because similar to how the debugger for haskell uses cabal-install or stack, the python one uses pip, the javascript one uses npm, and so on and so forth... Given this, I think the best we could do would be to add a "dependencies" section in the README for every debugger.

However, keep in mind that in the examples I gave above where DAPInstall uses dependencies such as npm for JSNode to install the debugger, they are being installed locally, because that's the whole point of DAPInstall; I personally don't know any Haskell, but if it's possible to download the debugger using stack or cabal-install locally, then feel free to PR the debugger :)

Also note that there are two types of dependencies: for installing and for the debugger. DAPInstall can handle the dependencies for the debugger (which is the case for the C debugger), but these ones like npm are expected to be on the users' machine.

@pocco81
Copy link
Owner

pocco81 commented Sep 15, 2021

Actually this is a very good idea. I'll add this (not the haskell debugger, the dependencies thing). We could specify the dependencies for every debugger and in the moment of installation assert whether they are installed or not.

@pocco81
Copy link
Owner

pocco81 commented Sep 15, 2021

Now debuggers can have "details" for storing this type of info. Here is an example with the jsnode debugger:

M.details = {
	dependencies = {"npm", "lol", "some_program", "git"}
}

Output:

image

Works well 👍

@kozer
Copy link
Contributor Author

kozer commented Sep 16, 2021

In haskell the package is installed locally but it has the following issues:

  • Local folder is .stack and I don't know if we can change that
  • Depending on ghc (imagine it something like node version) the debugger needs to be installed accordingly. So having 2 projects with 2 ghcs (lets say v1 and v2) we need to build debugger for both of them.
    And this is a problem.

@pocco81
Copy link
Owner

pocco81 commented Sep 17, 2021

Local folder is .stack and I don't know if we can change that

What do you mean by local folder? Local folder for what exactly?

So having 2 projects with 2 ghcs (lets say v1 and v2) we need to build debugger for both of them.

Perhaps we could ask them in the installer? Remember that the installer is nothing more than a shell script, so this is obviously possible.

And in the case of the configuration, we could use a helper function to fetch the according binary of the debugger according to the project at the CWD.

@pocco81
Copy link
Owner

pocco81 commented Sep 27, 2021

What do you think?

@pocco81 pocco81 added the enhancement New feature or request label Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants