You need to build Add.res, so it needs to be setup with the compiler etc. it’s probably easier if you try it in an actual project, where you have the compiler setup. But you should be able to run the exact command I ran and get output now that you’ve built the test project.
Add.res isn’t just a standalone file. I created it within the src folder of a rescript project I’m working on.
However, for the first two times I posted about the .exe not yielding meaningful output, I didn’t build the project.
For my last post (even though I did ask whether the rescript-vscode or any res files being passed to the .exe need to be compiled with npm run res:build) I went ahead and built the project that has Add.res and was still receiving an empty result.
edit:
Was just about to ask if the location of the .exe file matters (I was invoking it from where it was generated), but I thought about how you mentioned that it uses the rescript compiler artifacts, and figured perhaps there’s some code which uses the current directory path to try and find those.
(Actually, the issue was that I wasn’t executing the .exe command from the root of the project, not that the .exe wasn’t in the same location as the project which has Add.res)
It worked after I moved the .exe file to the root of the project which has Add.res:
{
“name”: “Add”,
“docstrings”: [],
“items”: [
{
“id”: “Add.add”,
“kind”: “value”,
“name”: “add”,
“signature”: “let add: (int, int) => int”,
“docstrings”: [“Doc comment with a triple-backquote example\n \n res example\\n let a = 10\\n /*\\n * stuff\\n */\\n \n”]
}]
}
3 Likes
Good stuff! Experiment away and let us know the results.
1 Like
Will do.
I will figure out how I might go about implementing the new features, and then after a plan of action is written down, I’ll post it here to doublecheck if there’s a better way of implementing it before I actually start writing code.
1 Like
Okay, here’s some things I noted while considering how things will look from a user’s perspective:
1. If the user hasn't installed @rescript/core as a dependency, then when they start the REPL, print a string recommending that they install it.
2. The user may .listmodules to display all of the available modules for which they may .browse or get type information
- ls node_modules/@rescript/core/src/ (and get the module names from all files with .res extension)
- Append to the resrepl internal state array for what modules are loaded.
So I can just maintain an array behind the scenes that appends successfully loaded user modules (and avoid having to parse the temp file for modules
the user imported from their local project).
Except.... for the case of user loaded modules, they introduce locally defined names into the global scope, so it would still be necessary to handle this.
(namespace collisions should still occur though?)
> .load Repl
> test()
TESTING!
Nope... in the case that both module A and B contain a test function, the latter one overwrites the first.
> .load A
> .load B
> A.x->Js.log
Module A's x
> B.x->Js.log
Module B's x
> x->Js.log
Module B's x
3. .browse Core__DataView
Outputs:
map (item => print(item.item)) "items"
Core__DataView.t
Core__DataView.fromBuffer
4. .t Core__DataView.fromBuffer (where the full module path is required to be specified to disambiguate? also, otherwise it will require transforming the output
of extractDocs into another form if wanting to support .t fromBuffer)
Outputs: "items"[1]."signature"
5. .doc Core__DataView.fromBuffer
Outputs: map (item => print(item.docstrings)) "items"
{
"name": "Core__DataView",
"docstrings": [],
"items": [
{
"id": "Core__DataView.t",
"kind": "type",
"name": "t",
"signature": "type t",
"docstrings": []
},
{
"id": "Core__DataView.fromBuffer",
"kind": "value",
"name": "fromBuffer",
"signature": "let fromBuffer: Core__ArrayBuffer.t => t",
"docstrings": []
},
...etc
}
I could use some feedback on whether it would be preferred to have to fully specify the module path to get type information on something or whether a similar behavior as to what occurs with the Module A module B example would occur if the repl allowed for getting type information without having to fully specify the module path.
Other than that, if there’s any more feedback or something I should pay special attention or care to while writing the code to implement these features, then that is welcome as well.
3 Likes