I'm trying to add Ghostwheel to an electron project based on the leiningen template https://github.com/ducky427/electron-template/blob/master/README.md
However, I cannot figure out how to make it work, I don't see any messages in browser console, I tried to use cljs REPL but it still doesn't do anything. Did anyone have an experience of setting an electron clojurescript project adding Ghostwheel ?
Feel free to open an issue when you have a more concrete idea of where things are going wrong or specific errors (maybe with a repro repo)
https://clojurians.slack.com/archives/C06MAR553/p1543691655012600
Off the top of my head – check out the new release and try setting :report-output
to :repl
@clojurians.net I think your use of memoize on line 109 of utils isn’t doing what you hope it is doing…isn’t env going to be different at every call site?
also not a great idea to use memoize on a side-effecting body
seems like you probably want a more explicit cache, possibly with timestamp checks on the config file to decide to re-read it?
Yup, I agree that it's probably not doing much, I was playing around trying to figure out whether it makes sense to optimise that part and how, but I didn't want to put too much time into it before looking into how significant the impact would be on compilation time so I kinda left it like that. And I'm aware that this really isn't what memoize
is meant for. 🙂
I have to see if there's a performance impact and if there is, I don't know that it'll necessarily be because of the configuration file being reread repeatedly, because since that happens again and again in a very short period of time during compilation, I think chances are pretty good that any subsequent access during compilation will hit the filesystem cache.
Will look into it, do some benchmarks and then see if it's something worth pursuing.
well, hitting the system call layer at all is a fair impact, and hitting it at every def in the entire program is probably significant
okay, yeah, I'll definitely do some benchmarks, cause I don't have a great feeling about it either.
Thanks!
doing something like a simple throttle would be sufficient…load at most once every few seconds
that way it is never stale from one compile to the next, but prob only gets read once per compile
This sounds simple and effective, I like it.
so far so good on my port…working through incubator and adding >fdef
Great, let me know if anything blows up in unexpected places.
will do…so far it is working as expected, and I’ve been flexing it on tests to make sure it is catching things
Nice. I've tested a lot and the test suite is fairly comprehensive, but it's a big release, something may have slipped through the cracks.
So, this might be related to gw…I don’t think it was happening before…The tests I’m running is using maps and a thing called a Reconciler…
let me disable gw and see what happens
nvm…my bad
I'll do some benchmarking soon, but for now I just went ahead and did the simple cache: https://github.com/gnl/ghostwheel/commit/3db37e6204a88af782ee3da78153f3fdebe420bd
Thoughts?
I was working on this too 😜
If yours is better I'll take it 🙂
I was just testing it…let me send a PR in a min
So, I sent a PR, but I’m not sure it is fully working…I was trying to output messages about reloads, but I think since this is running in macros that isn’t the best idea….
basically checking the timestamp of the file
that has a little OS overhead, but no EDN parsing or file reading if the ts didn’t change
I’m out of time today, feel free to use it or not
Cool, thanks, I'll keep it open until I do the benchmarking, so we are not spending too much time poking blindly at the performance, and then I'll check which one's faster.
(and what the overall overhead of Ghostwheel is, general bottlenecks, etc.)
I'm done for today as well, let me know if anything else comes up. Thanks again for the feedback!