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

start-watch! on worst case with :configure #14

Open
geraldodev opened this issue Jun 21, 2023 · 4 comments
Open

start-watch! on worst case with :configure #14

geraldodev opened this issue Jun 21, 2023 · 4 comments

Comments

@geraldodev
Copy link

geraldodev commented Jun 21, 2023

Hi, Thank you for this project.

I'm using your code to start a project and have noticed that you are calling start-watch! during the :configure stage.

I'm using Ubuntu 20.04 with a six-core processor (12 threads) and 8 GB of RAM (modest RAM). When I delete the .shadow-cljs directory and start the process, two similar machines become unresponsive to the point where I have to power them off.

Here's what I did to resolve the issue: I moved the start-watch! call to the flush stage after the compilation is complete. This allows me to avoid the scenario where an initial build of shadow-cljs competes with CSS watching, causing the machine to hang.

Of course, you only need to start the process once, but your code already handles this scenario.

Regards,

geraldodev

@rschmukler
Copy link
Member

Hey there, thanks for sharing. I actually am working on a preview where the default watch is much smarter. Could you please try the latest version (pushed only to GitHub, so you'll need to use the SHA to test it) and see if the issue is resolved?

@geraldodev
Copy link
Author

The result would be the same for me, because the root cause is to call the tailwind jit and shadow-cljs when there is nothing on shadow-cljs side. start-watch! on the last week code is called on :configure which is the right thing to do, but I'm my machines not so good.

@rschmukler
Copy link
Member

@geraldodev I am not sure what to do about this issue. Do you think that it's worth moving it to a different stage, or is there something else we can do to avoid the issue? Happy to review / merge a PR; just not sure I can reproduce it on this side locally.

Alternatively, perhaps we just add a workaround to the readme?

Let me know what you think!

@geraldodev
Copy link
Author

You can close if you want. I reported because I used your code and had the issue, just for you to be aware and fix if you find its worth fixing. I'm not using temporary project, and not using compile yet. Here is the gist of the derived code I've spotted the issue with invoking on compile phase. https://gist.github.com/geraldodev/f2ff01250d9ce28bccf14f717cdd5df7
Thank you for this project.

Regards,

Geraldo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants