This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-06
Channels
- # architecture (8)
- # aws (2)
- # beginners (156)
- # boot (163)
- # cider (22)
- # cljs-dev (2)
- # cljsrn (11)
- # clojars (6)
- # clojure (328)
- # clojure-austin (7)
- # clojure-dusseldorf (10)
- # clojure-italy (2)
- # clojure-russia (19)
- # clojure-spec (178)
- # clojure-uk (86)
- # clojurescript (81)
- # cursive (17)
- # datomic (33)
- # funcool (40)
- # hoplon (8)
- # jobs (5)
- # klipse (13)
- # leiningen (1)
- # luminus (21)
- # off-topic (140)
- # om (49)
- # om-next (4)
- # onyx (29)
- # planck (5)
- # protorepl (2)
- # re-frame (58)
- # reagent (2)
- # remote-jobs (4)
- # ring-swagger (16)
- # testing (1)
- # untangled (26)
- # yada (27)
but it occured to me it might be possible to no-op the inotify calls with LD_PRELOAD
grepping through the boot code leads me to believe disabling watches there would be invasive
~/g/a/lbbasic➜ LD_PRELOAD=/home/alan/Desktop/libwrapinotify.so INOTIFY_DEBUG=true boot dev
DEBUG:inotify_init:157: inotify enabled
DEBUG:inotify_add_watch:165: inotify enabled
DEBUG:inotify_add_watch:165: inotify enabled
DEBUG:inotify_add_watch:165: inotify enabled
DEBUG:inotify_add_watch:165: inotify enabled
DEBUG:inotify_rm_watch:174: inotify enabled
DEBUG:inotify_rm_watch:174: inotify enabled
DEBUG:inotify_rm_watch:174: inotify enabled
DEBUG:inotify_rm_watch:174: inotify enabled
DEBUG:inotify_init:157: inotify enabled
DEBUG:inotify_add_watch:165: inotify enabled
DEBUG:inotify_add_watch:165: inotify enabled
DEBUG:inotify_add_watch:165: inotify enabled
DEBUG:inotify_add_watch:165: inotify enabled
DEBUG:inotify_add_watch:165: inotify enabled
I'm trying to figure it out from https://code.launchpad.net/~jamesodhunt/upstart/bug-1157713-inotify-test-failures/+merge/159334
gcc -c -fPIC wrap_inotify.c -o wrap_inotify.o
gcc wrap_inotify.o -shared -o libwrapinotify.so
so I managed to get boot to 'build' by returning an auto-incrementing counter! It spins CPU for a while, then core dumps. unfortunately, I think I have to do something fancier to get stdout/err to work again. If I just return a constant every time, it hangs.
This is a newbie question: How would I go about writing a task that executes some external program (say cc
) on a group of files with a particular extension (say .c
) and then transfers the compiled files (say .o
) onto the next handler?
@sonelliot you can use the show -f
task to see the tree of files in the fileset before and after, like this
if you don't want to do the diffing you can simply empty the temp dir before compiling and recompile everything
but it also is not correctly handling removed files, which you may want if you go the diffing route
there is a function that can give you the removed files:
(fileset-removed previous-fileset current-fileset)
you can then doseq
over the .c files from that fileset and delete the .o files from the temp dir
I think the diffing is a nice touch. Given a large enough code base you would probably want to do incremental compilation like make
does.
So the cc
function. Could you pass all of the .c
files to it at once? Like (apply sh (concat ["cc"] paths))
.
you could even have a dependency graph that figures out which object files need to be recompiled based on changes to header or source files etc
Would the cc
function then take the file contents and via stdin
? Or can it read the .c
file in the temp dir?
Another question. How can I exclude a set of extensions from the initial fileset? For example, I occasionally use Emacs .dir-locals.el
to customize my editor settings for certain projects. It's annoying that they end up target
.
didn't know about .bootignore
-- that should help with inotify issues on circleci as well I think
Does boot support mixed source projects like Leiningen? Something like javac
command?
would you guys accept a patch to disable registering inotify watches via env key? I'm thinking about just a one-liner if
surgery https://github.com/boot-clj/boot/blob/master/boot/worker/src/boot/watcher.clj#L62
@alandipert seeing stubwatch, why again can’t we stop using boot from adding watches willy nilly? 😄
what little hesitation i have about making changes like this comes from the fact that: why should we change, circleci is the one that sucks
@alandipert 😄 ah, I somehow thought there would be a fundamental issue somewhere
but it seems like this problem is common enough, and probably easy enough to address, that adding a flag to turn of watches is a good move
@alandipert that’s cool, never ran into the issue myself just found your stubwatch workaround interesting and somehow thought it’s the last option 😄
it seems crazy, but i think it's crazier that circleci runs builds with so few resources and in such an apparently weird environment
@alandipert re release: I made another PR https://github.com/boot-clj/boot/pull/561 and https://github.com/boot-clj/boot/pull/551 should probably also get merged before release
it makes me wonder if functions that take arguments lists for other functions or commands, as arguments
@alandipert right the varargs stuff made this a bit more convoluted that in had to be
@geoffs if you’re up for it you could rebase your notify fixes on master now and use dosh-timed
I have two tasks that are very similar and I want to re-use the option list:
(def opts [c foo bool “some docstring”])
(deftask task1 “docstring” ~opts …)
(deftask task2 “docstring” ~opts …)
Is this possible somehow?It seems I wanted to do something similar like in defproject
, but this is custom behavior:
https://crossclj.info/fun/leiningen.core.project/unquote-project.html
(defn opts [] '[c foo bool "some docstring"])
(deftask task1 "docstring" #=(opts) …)
since macros compose outside-in, vs inside-out like functions, you have to use either read-time eval or wrap them with another macro, to syntactically extend them
#=
is doing it with read-time eval, splicing in the form you want at read time, before macro expansion time
I want to use read-time eval then, I get unmatched delimiter though (the first defn was changed to def)
boot.user=> (defn args [] '[x y])
#'boot.user/args
boot.user=> (defn add2 #=(args) (+ x y))
#'boot.user/add2
boot.user=> (add2 1 2)
3
complete examplei think #= only takes op forms like (f ...)
, and it doesn't evaluate the arguments
not sure the exact limitations, just know it does funcalls OK... so the last time i used it, i made a function to return what i wanted
@martinklepsch @alandipert I will rebase and update my PR to use dosh-timed
. And I will definitely try it out on both Mac and Linux platforms to make sure it works 😄
also, once I figure out the details for how to invoke a random exe
on Windows, I'll add support for Windows visual notifications!
seems like stubwatch works locally, but it doesn't reliably fail on circle without it either. I'll try using it and see if anything happens.
i chatted w/ @micha a little about adding an env var or option, and consensus is env var and/or long-only option to boot
great! Yea, I think that's a bit cleaner. Circle has declined to resolve this on a rails-related issue, so I imagine there's some infra implications.
re --no-inotify
in general, it seems like cli flags hit boot.util
dynamic vars, eg boot.util/*colorize*
, and env/boot.properties are looked up by boot.App/config
? Do those streams ever cross?
ah, answered my own question, disregard, colorize?-system-default
looks it up via boot.App/config
, I'll follow that pattern.
glad we went through the LD_PRELOAD experiment because it makes it easy to see if the boot-level stuff is working.
agree, im just always more comfortable if we can get mac and windows ppl to at least try it