This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-27
Channels
- # ai (4)
- # beginners (102)
- # boot (216)
- # cider (20)
- # cljs-dev (9)
- # clojure (130)
- # clojure-russia (4)
- # clojure-spec (9)
- # clojure-uk (11)
- # clojurescript (59)
- # core-async (2)
- # cursive (10)
- # datomic (51)
- # figwheel (1)
- # flambo (3)
- # hoplon (2)
- # luminus (1)
- # om (17)
- # om-next (4)
- # onyx (2)
- # perun (2)
- # re-frame (79)
- # ring (5)
- # ring-swagger (9)
- # rum (3)
- # schema (3)
- # specter (9)
- # untangled (3)
- # vim (1)
@nonrecursive about tests, I have noticed that the pod in boot-test
really slows things down probably because it is running in a pod
it looks like the pod is cold/new every time but it is weird, as checking the code shows a simple call to :refresh
: https://github.com/adzerk-oss/boot-test/blob/fa0dcc54e846f24d17356b0a11bb156cd07f0771/src/adzerk/boot_test.clj#L90
@micha so im kinda just lost now, still trying to make a restartable server, dont know why this is being so difficult, clearly missing something
@flyboarder what's up?
well, I removed the pod stuff as it was distracting
(fileset-diff nil some-fileset)
returns some-fileset
so you're good for the first iteration when the previous fileset atom will be nil
that way it will only happen when there are changed files of the type you're interested in
@micha edited, how can I make it non-blocking?
ok, hmm it starts the server but throws some random error when a file is changed
for the files which are served
line 9
java.lang.IllegalArgumentException: No value supplied for key: nodejs.out/app/users.cljs
hmm seems it doesnt like to rebuild files
weird!!!
hmm so rerunning the future causes that
So I switched from Leiningen to Boot in a project, and it's been working great so far. My team is now planning to start working on a ClojureScript UI, so I added Figwheel to our project. Everything works smoothly, except for this error, which from all of the archeology I've done about it has to do with an OS X library:
2016-12-27 10:33 java[61220] (FSEvents.framework) FSEventStreamStart: register_with_server:ERROR: f2d_register_rpc() => (null) (-21)
No, I'm just on my laptop at the moment
Hmm, I don't believe I do - let me check the file count in the directories I'm pulling in
So the src/
directory contains 123
files
Which I don't think is a lot, considering that contains a lot of DB logic, an events system, etc
But the resources
directory contains 390
files, most of it from an out/
directory that ClojureScript compiled to. I believe it contains all of the CLJS and Google Closure modules
I'm on OSX 10.12 and Java 1.8.0_77
Yeah, that's macOS Sierra - I'm wondering if the latest OS has something to do with it
sometimes it's just garbage printed to the screen but not actually interfering with the build
So it's not breaking my build, and I was okay with just ignoring the errors (a lot of them would pop up at once), but I then began to realize that Figwheel would intermittently fail to load new code after save
But I'm curios that you said ~20K files might cause stuff like this - is there a way for me to inspect the fileset and get a count of files that are being watched?
Whoa, way cool!
Sure! I set it conditionally, but my development environment looks like:
:source-paths #{"src" "test" "spec" "dev" "ui/admin"}
:resource-paths #{"resources"}
:dependencies dev-deps
There is also another possibility: after some searching I just found that Figwheel also uses FSEvents to trigger updates. If two processes are watching the same files, would that produce errors like the ones I'm getting?
yeah i think that could be it, i think there is a global throughput limit for fs events
Ohh, I see - figwheel is compiling to the resources
directory so my server can pick them up
So in a way boot is a lot like a virtual DOM for the filesystem?
the files in the filesystem from the fileset are actually just hard links into the immutable blob storage
so when you change a file's contents and replace a file in the fileset with your new modified version
well not atomically because it needs to delete the link and make a new link that points to the new thing
Very interesting - so if many events are fired at once, and some result in a change in a file's contents, boot has to react to each change and possibly hit a threshold?
I see
like if you're writing and deleting files before boot can process them things can get weird
like if you have a process that makes thousands of temp files in the project dirs and deletes them quickly
Gotcha - I'm messing around with the debounce time and also configuring figwheel to use polling, but I don't think it's going to solve the issue you laid out of stuff happening underneath boot
Hahaha
s/inotify/computers
Have you checked out https://facebook.github.io/watchman/ ?
like i pipe the stream of change messages to a tool that tails the files as they change and prints the lines to sdtout, and pipe that to a 0mq pubsub publisher
Ohh very interesting
it doesn't have an option to initilize by sending a modification event for all files in the dir
Ahh, I see - could you use another process to mock those events after scanning the directory and send to inotifytail
?
good point - I was thinking whichever one was being passed to inotifywait
. I'm not super well read on unix/pipes - but there may be a way to call a sequence of processes and pipe them both to another?
the inotify C api is pretty hairy, so i was thinking to have one program that just does that and exposes a stream of changes on stdout, but maybe i need to just make a nice c library and roll that into the tail program?
Yeah that does seem to be more unixy
@micha, have you looked at watchman? It does exactly that
The react native folks use it in the way you suggest, with success
It was already suggested
I guess it does add a pretty big Dependency
A question, when developing a boot library I would like the updates to the library to get reflected without having to restart the boot process in the example project. If I start my usual boot chain of commands in the example project with boot -c boot-react-native/boot-react-native
it understands when changes happens to the library and reruns the task in the example project. The invoked task itself does not seem to be updated with the new code though.
@vikeri I thought of that, I suppose with simpler libraries you could add the other project's src dir to your src
paths?
@vikeri the new code should be available to the task, maybe you need to rerun some code in there
does boot re-load jars if they've changed?
@micha Hmm ok, I tried adding :reload
here without success: https://github.com/mjmeintjes/boot-react-native/blob/master/example/build.boot#L28
Yeah, I wan’t to update the task here: https://github.com/mjmeintjes/boot-react-native/blob/master/src/mattsum/boot_react_native.clj#L235 and see the changed debug output in the next build in the example project.
so updating the function that returns the middleware (the task function) doesn't automatically create a new middleware and inject it into the pipeline
Hmm, something is wrong with boot-react-native
though, getting the error java.net.BindException: Address already in use
when I ctrl-c
then rerun the command.
Found the issue: https://github.com/adzerk-oss/boot-reload/pull/107
Does anyone else do this?
(defn b
"A convienence; accepts any number of values, converts them to strings, splits each
atring at whitespace, and passes the results to `boot`. This is usually easier and better
than making each argument an individual string."
[& args]
(apply boot (->> args
(map str)
(map str/trim)
(mapcat #(str/split % #”\s+”)))))
I’m building tools where I want to stay in the REPL due to startup time, so I want it easy to run commands.
e.g., (b “read-config -e production hosts -m phone write”)
rather than (boot “read-config” “-e” “production” “hosts” “-m” “phone” “write”)
.
You can also connect through nrepl and reeval the buffer
Now I got the (boot (dev))
from the repl working, but it still doesn’t seem to reload the external library even though I use boot -c boot-react-native/boot-react-native:0.3-rc3 repl
to start the repl.
@micha How do cleanup-fns work with several Boot "pipelines"? I tried adding cleanup-hook to repl task, and it seems that when I close task started in boot repl
, the cleanup hook is called even for the main repl
I think it would generally make sense that running (boot ...)
inside Boot would create "new cleanup-fns scope"
I guess currently cleanup-fns is global
The current implementation can cause problems with Boot-reload and other tasks using cleanup hook: boot dev
and running another reload
task from the repl will close one from dev
task
@juhoteperi perhaps the boot
function should establish a dynamic scope for cleanup handlers
@micha Yeah, that sounds good
if you make a future or run boot in another thread you can always add a cleanup handler to terminate it when your cleanup happens?
I am very close to a first stable version of boot-reload
+ figwheel
!
@richiardiandrea how is that going to work? In my experience boot-reload is more reliable than figwheel on lein. Does the reload part stays the same?
The client and some internals of boot-reload and boot-cljs (minor) will change
The reload code will stay the same and everything will still be dumped on the fileset only (no external mutable dirs)
@richiardiandrea pretty cool! Looking forward to it