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

Debugging Flow #4181

Closed
agentcooper opened this issue Jun 15, 2017 · 11 comments
Closed

Debugging Flow #4181

agentcooper opened this issue Jun 15, 2017 · 11 comments
Labels

Comments

@agentcooper
Copy link
Contributor

I am using Visual Studio Code with vscode-ocaml extension. ./bin/flow is compiled using make build-flow-debug (see also: #4177).

.vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "OCaml",
      "type": "ocamldebug",
      "request": "launch",
      "program": "${workspaceRoot}/bin/flow",
      "console": "internalConsole",
      "stopOnEntry": false,
      "arguments": [
        "${workspaceRoot}/local-test"
      ]
    }
  ]
}

local-test/test.js:

// @flow

const a: number = 'z' + 'd';

Debugging main seems to work:

screen shot 2017-06-15 at 15 28 09

However If I set a breakpoint somewhere in src/typings/, for example statement.ml, inside variable_decl function, then the breakpoint is skipped.

I suspect this is because of the server-client architecture - actual type checking happens inside a different process.

Is there any good way around this?

@kogai
Copy link

kogai commented Aug 20, 2017

I faced the same problem and I didn't solve it.

For the reference, I tried flow check command.
It seems to be checking type at foreground, but when using ocamlbuild with settings like below,
debugger responds with cannot connect to debugger at 127.0.0.1 error: No such file or directory.

{
    "program": "${workspaceRoot}/bin/flow",
    "arguments": ["check", "path/to/mycode.js"],
}

The error occurred at spawn function in hack/utils/daemon.ml(yes, debugger worked properly), and I guess that the error related to spawning server process.

@kogai
Copy link

kogai commented Aug 26, 2017

Still examining, but it seems to get some progress.

As I guessed at the comment above, the problem caused by some process that created behind flow.

Then, I try out arguments "--max-workers" that described with Maximum number of workers to create (capped by number of cores)

I don't understand it in detail, but it seems related to some process behind flow.
So, I modified my settings like follows and executed ocamldebug.

{
    "program": "${workspaceRoot}/bin/flow",
    "arguments": ["check", "--max-workers", "0", "path/to/mycode.js"],
}

And the result looks as I expected.
At least it can execute flow according to breakpoint and process exit normally.

@villesau
Copy link
Contributor

villesau commented Oct 21, 2018

@agentcooper @kogai have you tried to get debugger working with OCaml Debugger? I can get the debugger working with simple example using ocamlc -g helloworld.ml but with Flow pretty much nothing happens, only the loading sign appears below debug menu.

@villesau
Copy link
Contributor

villesau commented Dec 11, 2018

Looks like ocaml debugger runs roughly this kind of command: ocamlrun bin/flow check my-own-test/test.js --max-workers 0, when running the flow with ocamlrun the program throws

Fatal error: unknown C primitive `unix_waitpid'

Maybe this is the culprit?

E: When downgrading ocaml from 4.06.0 to 4.05.0, the error changes to:

Fatal error: unknown C primitive `caml_floatarray_create'

E2: When removing _build and running the make build-flow-debug from scratch with 4.05.0, the error is again

Fatal error: unknown C primitive `unix_waitpid'

E3:

After pulling the latest flow, the error changed to

Fatal error: unknown C primitive `Base_am_testing'

Any hints on how to fix this? would e.g @jbrown215 be able to shed a bit light on the Flow & OCaml debugging setup?

@jbrown215
Copy link
Contributor

I don't use the ocaml debugger, but flow has a few debugging commands that I use to debug type checker behavior. flow check --verbose-indent will show the full list of flows in __flow. The function that adds errors is called add_output, and it also logs when it is called with --verbose-indent.

@villesau
Copy link
Contributor

Nice, this probably already helps a lot, thanks for being so helpful!

@villesau
Copy link
Contributor

villesau commented Dec 15, 2018

Ok, got debugger finally working in VS Code!

Build command

make build-flow-debug

VS Code debugger config

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "OCaml",
            "type": "ocaml-debugger",
            "request": "launch",
            "program": "${workspaceFolder}/bin/flow",
            "console": "internalConsole",
            "stopOnEntry": false,
            "arguments": ["check", "${workspaceFolder}/local-test/test.js", "--max-workers=0", "--verbose-indent"]
          }
    ]
}
  • ${workspaceFolder}/local-test/test.js being the js file to check
  • --max-workers=0 apparently runs everything in single process
  • --verbose-indent Debugger works also without, but still very useful

Other requirements

I also recommend to install Merlin: https://github.com/ocaml/merlin

opam install merlin
opam user-setup install

This might be worth documenting to e.g Flow wiki or readme.

@kevinbarabash
Copy link

I would also suggest using --merge-timeout=0 as well to avoid timeouts.

@kevinbarabash
Copy link

@villesau thanks for the instructions. Being able to step through things is going to be a big help.

@STRML
Copy link
Contributor

STRML commented Sep 27, 2019

Thanks @villesau for such a useful comment.

I was unable to get mine running until I added to my user settings.json:

{
    "reason.path.ocamlmerlin": "_opam/bin/ocamlmerlin",
    "reason.diagnostics.tools": [
        "merlin"
    ],
    "editor.formatOnSave": true,
    "reason.codelens.enabled": true,
}

and to my debug configuration:

  /* start ocamlearlybird --server --port 4711 before running */
  "debugServer": 4711

I then run $ ocamlearlybird --server --port 4711 in the Flow directory before debugging.

@SamChou19815
Copy link
Contributor

Closing since none of our team member uses debuggers regularly, so we also have no ideas...

@SamChou19815 SamChou19815 closed this as not planned Won't fix, can't repro, duplicate, stale Mar 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants