@danielsz: Might you anyway try to rename ~/.m2?

@andrewboltachev: I could, but it is wise to do that?

To try just on one project

@andrewboltachev: OK then, here I go.

@danielsz: Did it help?

Still downloading jars

Ah

Amazing how many jars are being downloaded with a fresh ~./m2

Sure. And it's size should be good too. In the meantime you might learn about ~/.m2

i think this is caused by maven_metadata.xml file in your repo

sometimes just removing that is enough to fix the issue

@micha: Oh, that's useful info.

@micha: So, isn't it (likely) ~/.m2 which is wrong?

that file is in .m2

aha

so removing .m2 will also fix the problem

but is worse, sure 😄

but each project has a metadata file

this is for the case where there are different maven repositories that have the same coordinate but the actual jar is different

like if foo/bar:1.2 in one repository is not the same as foo/bar:1.2 in the other

Did lein install or some other "local" operation likely broke it?

Interesting

so when you download or install a jar it remembers where the jar came from

so suppose you download foo/bar:1.2 from repo A

then in a different project you depend on foo/bar:1.2 but you don't have A in your set of repositories

that's when you start to get problems

i think snapshots can make these issues worse because they're sort of a special case

like the metadata isn't as rigorously maintained as with releases

i usually rm -rf just the dependency that is causing the problems in my .m2

So it weren't wise to rename ~/.m2

you just download the jars again, it doesn't harm anything

This is all useful. @tcrawley just said in the Clojure channel that I'm hitting a Clojars issue

https://github.com/clojars/clojars-web/issues/514

And that he'll deploy a fix tonight

Starting from a fresh ./m2 worked, but that was the nuclear option.

Is it Java's "directory watch service" that backends Boot's watch task? I were using Boot as a tool to do TDD (or other hacking, really) in Clojure: I have own script to bootstrap the new project, where I would be able to call "boot dev", and then make changes to core.clj and other files, and what were in main fn would be executing. There's how: https://github.com/andrewboltachev/clojure-tdd-example/blob/master/build.boot#L45 Sometimes I were hearing it speaking twice. And I'm confused why. The thing now is that I've played with WatchSerivce and now using it successfully enough in my one project. I noticed that vim sends series of events when saving files, while e.g. gedit does so, but for temporary file. Solution that I've found is this: http://dpaste.com/01MZ82K Are you doing suchlike thing in Boot or might consider to do (to prevent "double operation")?

boot does have a "debouncing" loop

in the watcher code

it's set by default to 10ms

you can increase that

I've seen that, yes

So... it would be the same effect?

i.e. when new event would appear, it will wait 10ms again for the next?

it uses a queue that it polls

it doesn't actually trigger any handlers until the polling timeout (10ms) is reached without anything new being put on the queue

every fsevent results in an item being added to this queue

well, queue... is that Java object?

yes

https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task/built_in.clj#L251

it's a LinkedBlockingQueue i think

So LinkedBlockingQueue yes

just above

so queue is something of "organizational" nature, not about watching files for changes?

exactly

the queue is for the debouncing

if you have a thing that modifies a file every say 50ms though

you will get weird results

because boot won't react to any filesystem changes while it's building

meaning while the watch task is running the pipeline

so those changes will be processed as soon as the build finishes

it start on the next one right away

so for example if you modify a file, and then your editor does something 50ms later

that results in a file being changed

even though the build that the watch task will run might take 1000ms to complete

that change that happened after 50ms isn't seen by the watch task yet

then when the build finishes it triggers again

not sure if i'm being clear or not

the go loop code you pasted above is doing the debouncing right?

(sorry, I were away) yes

Btw, as I see it now...

it would be crazy enough for Boot to do it on core.async blocks

is there a bug in the LinkedBlockingQueue stuff in boot?

i.e. much harder for users to make own tasks

uhm, don't know, the only thing is that it used to speak more than once

now speak is sometimes slient on success

only on fail it produces sound

the sound is played from a different thread

or on first success after fail

so that could be relevant

the speak task continues with the pipeline before the sound is actually finished playing

because it plays the sound in a future

so it's possible that boot could exit before the sound is played

or something else weird could happen

well, I have it watching

so nothing like exit is here

ah

https://github.com/andrewboltachev/clojure-tdd-example/blob/master/build.boot#L45

where main might me as easy as "Hello, world!"

when I change it to "Hello, Andrew!" I expect it to (1) make (exactly one) sound of success and (2) to print out the message and "Elapsed time" etc

and it doesn't do that?

it speaks twice?

and sometimes not at all?

Yes

It used to speak twice. I suppose that 'cause of big files

does increasing the debouncing time help?

ah, didn't try yet

well, I were thinking you'll get idea of my core.async version

it were actually first time me drawing time diagrams for programming

while designing it

so, anyway, what's source of FS events? it's just polling it, right?

i.e. no event source

and again, I just wanted to learn about your solution to suchlike probem, and these little issues — I don't know if they're important

'cause it's so exciting to learn others solutions

one bad thing about me is that I used to hang on Hoplon channels for long time, but switched to Om now 😕

haha no worries

the event source is the fsevents API, via the java watchservice for windows and linux, and via a 3rd party implementation for OSX

this is where the watching is started: https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/core.clj#L150-L164

boot always has its own filesystem watcher going, separate frh tasom the watch task

i mean "separate from the watch task"

great thanks! I didn't even see that code yet (while hacking into Boot a bit). I'll review that later then. Time to go now...

hallo hi hey--is there a way to add a directory to the resource path and have it not be watched on changes

@johanatan: no, not really

what is your use case?

node_modules 😛

ah yeah

how does node_modules trigger the watch task though?

if you do npm install you'd want the thing to rebuild, no?

otherwise the files in there wouldn't change i don't think

ah right, I was reading it as "and have no watchers on those dirs"