This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (41)
- # boot (4)
- # cider (36)
- # cljsrn (9)
- # clojure (365)
- # clojure-dev (1)
- # clojure-dusseldorf (1)
- # clojure-nl (1)
- # clojure-russia (3)
- # clojure-spain (1)
- # clojure-spec (19)
- # clojure-uk (1)
- # clojurescript (159)
- # code-reviews (7)
- # core-async (51)
- # cursive (2)
- # datascript (1)
- # datomic (1)
- # emacs (5)
- # figwheel (3)
- # hoplon (18)
- # incanter (1)
- # lein-figwheel (1)
- # leiningen (3)
- # lumo (145)
- # off-topic (26)
- # onyx (21)
- # re-frame (2)
- # reagent (45)
- # rum (4)
- # uncomplicate (10)
- # untangled (23)
- # yada (6)
@hit023 not sure what you're interested in, re-frame is considered fairly sexy right now. Here is a TodoMVC example for re-frame: https://github.com/Day8/re-frame/tree/master/examples/todomvc A fun project might be porting that to re-natal, to run on ios or android, found here: https://github.com/drapanjanas/re-natal
the Readme for the Figwheel project has a pretty good flappy bird game you can study. There are also a few snake examples out there. There's a quantum tic tac toe. I'm trying to remember this great top down game someone made...
zetawar uses datascript as a DB in the browser, which is based on the Datomic architecture. Pretty good reference implementation there, I'd imagine.
@john to be honest I think web workers are a build tool concern. manually setting
CLOSURE_IMPORT_SCRIPTS does not work for
:advanced for example
basically you create a dedicated namespace for each worker, the bundle generation is handled for you
advanced, will it work with this bootstrap hack? https://github.com/bhauman/lein-figwheel/wiki/Using-Figwheel-with-Web-Workers
And I understand you can instantiate workers with a Blob of a JS file, rather than a JS file. So, potentially, that shim could be generated programmatically and used to load the worker.
I don't think the solution from figwheel is viable to be honest as it doesn't work for
yeah, figwheel doesn't appear to be built for this particular use case. I'm using weasel, which is not nearly as pretty atm
In fact, your solution is exactly what cljs tooling needed for workers. Worker files specifically generated by the tools.
This webworker repl thing is just a baby unicorn at this point. Might not pan out at all. There's some interesting potential though.
I haven't used the worker thing in a while, just noticed a bug I introduced recently.
js/setTimeout loop that ingests forms one by one. Before each form, it pulls all bindings, scope and necessary environment information out of an atom, evaluates the form, and then stores it's environment back in the atom. Whenever it sees something like a
defer, it branches a second
setTimeout loop. Whenever it sees an
await it pauses the loop and waits for the deferred item to resolve, then starting the eval loop again
(go (loop  (alt! interrupt ([_] :interrupted) input ([work] (when (some? work) (do-work work) (recur))))))
core.async doesn't translate past function boundaries though. So it couldn't make arbitrary code interruptible.
That also may be a lot of machinery for what will amount to one singular synthetic thread, but maybe plain
nextTick etc wouldn't be much better.
@john still no idea what your goal is. this is all JS so you are bound by the same rules.
@thheller If I create a timeout loop, which continuously spawns new timeout functions., where each one attempts to deref an atom and if it has "hi" it prints "hi"... If, while it's doing that, I reset the value of the atom to "hi", it will eventually print. There, we changed the value of the atom right underneath the logic of the loop. Not possible in the main loop. In the main loop, if you keep looking at the atom, it never changes. If you keep looking at the thing you want to change, it can't change. If a tree falls in the woods and somebody is right there to hear it, does it make a noise? Not in JS! You've gotta leave the woods and come back in again to even see if it's down.
true, there is no blocking in JS.
core.async makes things much much easier than a setTimout loop though
I don't think it's that expensive. Plus you could run it in a web worker, so it wouldn't put pressure on the main thread
core.async runs only if something is put on channels, if no channels are moving nothing moves
But it's not a "solution" you'd suggest to user. It would require a very engineered solution that produces a fake thread, which passes/threads a running CLJS execution context through the async loop.
if core.async has a channel currently waiting on information, checking a predicate against a signal, then core.async is going to check that signal source for new info every nextTick, I believe.
yeah, the overhead is checking to see if it needs to set up the work for next tick on every put
Checking to see if a particular atom has been changed... listening for browser clicks, whatever.
well, with the browser clicks, you can set call backs. But you can dereference atoms and access other sources from inside a go loop, besides just channels.
well this is interesting to me 😄 I’m writing my first cljs game and have channels for network msgs, vsync, etc
I'm not trying to say core.async isn't great. And core.async does make asynchronous operations appear synchronous within a block. I'm just wishing for this far fetched idea of a cljs min-runtime. But yeah, it'd run all the time.
tbh some of this is just to learn how it all works, so I’m overusing lang / lib features
not saying that core.async isn't useful for this, just not ideal. you can still do some amazing things
Well, if you put a 10 second job and send it down a channel to be handled asynchronously, that job won't hang the main thread for 10 seconds, right? So if it's too much pressure for a very large game loop, perhaps core.async could be used for offloading long running jobs, like you can do with setTimeout
well low latency and responsivness is a key thing for me, so if it feels latent I can hook directly into a reqanimation frame callback
@gazaxian also check out chromashift by chris granger: https://github.com/ibdknox/ChromaShift
And I believe he has a blog post or two somewhere on some methods he used to keep work below 16ms
Why when I run the tests by calling cljs.test/run-test or cljs.test/run-all-tests, at the end, I get the devtools disconnect, the page gets blank and I have to reload the page for it to start working again? Is this how running tests is supposed to work?
I've never seen that happen
So, essentially, Chrome.
@john why were you asking?
I was wondering if maybe you were using a less mainstream browser. I've never heard of the issue before.
In the RELP, I get:
Figured out. Doo was messing with it.
I'm trying do use ClojureScript on 'Bash on Ubuntu on Windows'. I'm getting this exception when trying
sun.nio.fs.UnixException: Bad file descriptor at sun.nio.fs.UnixNativeDispatcher.read(Native Method) at sun.nio.fs.LinuxWatchService$Poller.run(LinuxWatchService.java:318) at java.lang.Thread.run(Thread.java:745)
Successfully compiled "blah/blah/blah.js"
Any suggestions here?
did you do something that would move / rename / delete files while it was running?
iirc windows doesn't have the same rules for deleted/moved files that linux does, so this could be a bug that only shows up on windows systems (under linux, your file handle remains valid until you close it or exit, even if someone else removes or renames or moves the file)
@noisesmith No, I don't think so
I rebooted the system after the exception and tried again
Same result though
I wonder if it should be using LinuxWatchService there or if that is a sign of some issue?
I have very little experience using Linux
I saw two related issues
Both are closed