Fork me on GitHub
#boot
<
2017-01-17
>
vinnyataide02:01:31

can anybody help me out?

vinnyataide02:01:56

I don't know where this error come from

richiardiandrea02:01:17

it seems, but I am not sure of course some problem of versioning

seancorfield03:01:09

@vinnyataide I would delete your .boot folder (`C:\Users\Vinicius\.boot`) and try the command again. That should clear out any “bad” version of Boot and download the latest stable version again.

seancorfield03:01:52

@vinnyataide You probably also want to run boot -V (or boot —version) to see what version of Clojure and what version of Boot your system thinks it has installed.

vinnyataide03:01:28

thanks guys. I think this problem is resolved but another error has appeared

vinnyataide03:01:05

I think this is related to dependency conflict?

seancorfield06:01:52

@vinnyataide Hmm, that's normally just a warning in my experience... You can set the version of Clojure that Boot uses in your .boot/boot.properties file. You don't say what command you used that produced that error, nor what's in your build.boot file.

pesterhazy08:01:33

Working on my PR, https://github.com/boot-clj/boot/pull/549, the question came up where to put the launch-socket-server fn. I initially chose boot.core because that's where launch-nrepl is too. But @martinklepsch mentioned that boot.core may not be ideal as it isn't accessible from code running inside pods. If I had to pick a different namespace, which one should I choose? boot.util? A new one?

richiardiandrea15:01:44

@pesterhazy probably a new task with new package (by the way I can add you to powerlaces if you like)

pesterhazy15:01:23

@richiardiandrea sorry didn't catch the context

dominicm20:01:46

@richiardiandrea the random assets was mostly a comparison to boot reload which has a case for reload, which I think would be well replaced by a multi method or something

richiardiandrea20:01:41

oh ok, I think figwheel has some custom event handler hook in the client. not sure though. The nice thing is that the client is imported "as is"

dominicm20:01:49

@richiardiandrea ah, so it's just what Figwheel supports already?

richiardiandrea20:01:13

I think I have seen something, I don't know if it is exactly what you are asking though

richiardiandrea20:01:34

also, now we can add features to figwheel

richiardiandrea20:01:40

and have it in both 😉

richiardiandrea23:01:57

@geoffs Now that you are the reigning master of notifications, can I ask you a question? 😄

geoffs23:01:30

😂 sure!

richiardiandrea23:01:59

when you run a test and it is failing with notify -a, do you hear a sound?

geoffs23:01:48

Mmm, last time I checked it was still working...

geoffs23:01:19

You mean running tests with like 'watch notify -a test' right?

richiardiandrea23:01:23

I am using boot-alt-test this time, which one did you check against?

geoffs23:01:54

Oh, I haven't tried with alt test

richiardiandrea23:01:11

the success is playing right

richiardiandrea23:01:16

the failure does not

geoffs23:01:19

Does it throw an exception on failure?

geoffs23:01:39

That's what notify looks for

richiardiandrea23:01:50

I think that might be the problem

richiardiandrea23:01:31

ok thanks just wanted to double check again the I have this problem and you don't 🙂

richiardiandrea23:01:37

@geoffs is there a way to indicate failure other than throwing? I see why you would no want to throw and it might be good to another way to indicate failure

geoffs23:01:27

hmmm, you could have it set a warning. But that gets a different noise than the failure noise. At least it would be different than the success noise though

richiardiandrea23:01:35

uhm yeah this can be a good solution

geoffs23:01:55

I guess there could also be a failures var with an atom similar to warnings. I think the exception makes sense to me as the general "signal" a build failure mechanism...

geoffs23:01:20

also @richiardiandrea I think there is an option in boot-alt-test to throw an exception on failure

richiardiandrea23:01:16

yep I saw that, can be a workaround