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

Add watch mode support #202

Merged
merged 8 commits into from
Nov 10, 2024
Merged

Add watch mode support #202

merged 8 commits into from
Nov 10, 2024

Conversation

Tommypop2
Copy link
Contributor

@Tommypop2 Tommypop2 commented Aug 30, 2024

Closes #164

This PR is much bigger than I intended it to be, and clones data each time a file change is observed. This could possibly be removed by changing the underlying API, but I'm honestly not sure.

Also, on every individual file change, every file that matches the glob is recompiled. I did this for 2 reasons:

  • The compiler might take multiple files into account (didn't look into the actual compiler source code so wasn't sure if this was the case, and if it doesn't now, it might in the future)
  • If only the changed file is rerun, then the diagnostics for the rest of the project wouldn't be reprinted. This could maybe be solved by caching the last output for each file, and just reprinting that if the file hasn't changed

My current way of supporting the glob syntax is just by using the entry_points provided by get_entry_points. This seems to work pretty well, and reuses the work that needed to be done anyway to get the list of entry points. However, I'm not sure how efficient individually watching all the files is over many files.

If anything needs changing, let me know! Or if this approach is terrible I'm happy to close this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't particularly want to do this, since it required changing the internal checker code, but it seemed like the only way to get it to work as ownership is passed to the checker when it's passed in.

@kaleidawave
Copy link
Owner

Awesome, am back next week will have a closer look then.

@kaleidawave kaleidawave added enhancement New feature or request cli Command line interface labels Aug 31, 2024
@Tommypop2
Copy link
Contributor Author

Ok, thank you!

@kaleidawave kaleidawave added the ready Ready for next release label Sep 14, 2024
@kaleidawave
Copy link
Owner

Yes at the moment the checker doesn't support anything incrementally. In fact the web playground https://kaleidawave.github.io/ezno/playground and the LSP #22 run check_project on every keystroke (-some throttling). It can get away with it for the moment because the check process is fast. I want to work on some partial file and possible even local in a file rechecks, but it is quite low priority. So at the moment a watch mode that runs the check_project is good enough.

I will double check this and it will definitely be in the next release but that may be a while as currently a bit busy with things. Thanks for the addition though :)

@kaleidawave kaleidawave mentioned this pull request Sep 29, 2024
@kaleidawave
Copy link
Owner

kaleidawave commented Nov 10, 2024

Have got it compiling under WASM now. Will merge it later.

I think a sort of "initial" version would be good to include in the next release. I can't think of a good way to add a test for it ATM

@kaleidawave kaleidawave merged commit ae5de5d into kaleidawave:main Nov 10, 2024
6 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli Command line interface enhancement New feature or request ready Ready for next release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Watch mode
2 participants