Fork me on GitHub
#boot
<
2016-04-07
>
richiardiandrea01:04:30

I put this here because I don't know if it makes sense to actually add it to boot's util functions: https://github.com/boot-clj/boot/wiki/Snippets#add-previously-resolved-jar-to-the-fileset

richiardiandrea18:04:26

a question, is this correct?

(def deps #{['org.clojure/clojurescript "1.8.34"]}) => #'replumb.boot-cljs-src/deps
(:dependencies my-new-env) => [[org.clojure/clojurescript "1.8.34"]]
(count (pod/resolve-dependencies my-new-env)) => 8 (???)

richiardiandrea18:04:44

ok the answer is no, but am I missing something obvious?

richiardiandrea18:04:23

oh wait, right, transitive deps, that's what it is simple_smile

richiardiandrea18:04:31

Apologies 😉

sbrady18:04:29

Hi, wondering if there's a way to force boot to resync with the canonical directories from the repl? I can see a specific file in the boot cache that is behind the canonical file. I notice that there's a private sync-user-dirs! function in boot.core.

micha18:04:29

@sbrady: you could just save a file

micha18:04:34

doesn't matter which one

micha18:04:51

but the file you see as stale could be something else

micha18:04:19

the way to know for sure is do (println (slurp (io/resource "hello/foobar.clj")))

sbrady18:04:25

Yeah, I have problems with tools namespace refresh

micha18:04:43

the cache contains things that are not on the classpath too though

micha18:04:50

so it's easy to look at the wrong thing there

sbrady18:04:52

Yeah, I slurped the resource like you showed above

sbrady18:04:03

which double confirmed that it was out of sync

micha18:04:09

which OS?

sbrady18:04:19

which has problems

micha18:04:33

that uses a 3rd party fsevents polyfill

sbrady18:04:49

Yep, I do see that

micha18:04:57

because osx isn't supported in java yet

sbrady18:04:58

fsevents is awful

sbrady18:04:32

But would there be a function I could call to trigger the sync?

micha18:04:09

there isn't anything that's been tested to do that simple_smile

sbrady18:04:11

I have functions that call tns/refresh (in addition to other things) and would call a boot sync too

micha18:04:27

but that function you found is the place where it's done

sbrady18:04:34

I fine fishing in private vars simple_smile

micha18:04:52

did you see the wiki page about tnsrefresh?

sbrady18:04:13

vaguely...many moons ago

micha18:04:20

it doesn't address this issue but it might help

sbrady18:04:54

Yeah, looking at that now. I do employ that already.

micha18:04:27

if you can make a repro case for the osx fsevents issue that would be awesome

micha18:04:54

but it's probably too weird to reliably reproduce

sbrady18:04:08

I wish I could reliably reproduce it. I do have this issue: https://github.com/boot-clj/boot/issues/248

sbrady18:04:32

I imagine it's all part of the problems using fsevents

micha18:04:01

el captain?

micha18:04:40

there was a change i think related to fsevents where it sets a hard limit on how many event handlers you can create

sbrady18:04:46

I forget what codename is what...10.9.5 (I refuse to upgrade :) )

micha18:04:09

do you have a very large number of files being watched?

sbrady18:04:18

I guess I must

micha18:04:24

i guess you must have to get those warnings

micha18:04:32

but that seems like a likely cause

micha18:04:42

watches can't be created, so updates don't occur

sbrady18:04:59

Do you know if that limit is global or per process that is using fsevents?

micha18:04:23

i think it's global (based on rumors and hearsay)

sbrady18:04:41

Yeah, it's all hearsay. Very little good documentation in fsevents.

micha18:04:44

so one thing that could help you is to zip the files you're not working on into a jar

micha18:04:49

and add that to your classpath

micha18:04:11

you can do it with a little boot task

micha18:04:57

you can use the functions in the boot.pod namespace to add the jar to the classpath

sbrady19:04:29

oic...interesting

micha19:04:40

another option, if you need to process those files with boot tasks, is to sync them into a cache dir

micha19:04:45

so they aren't watched

micha19:04:59

that way you don't need to fish them out of the classpath

micha19:04:21

and boot has efficient ways to update and sync directories

micha19:04:46

you can then add the cache dir to the classpath with the functions in boot.pod if you wish

sbrady19:04:19

Yep, makes sense

sbrady19:04:26

thanks for that suggestion

micha19:04:48

if you find a good solution we might want to add it to boot or at least to the wiki

micha19:04:58

seems like a valuable technique

sbrady19:04:04

Sounds good...always striving for that perfect repl experience simple_smile

micha19:04:13

also i don't know if you saw the .bootignore file (or boot.core/bootignore)

sbrady19:04:17

So very elusive though

micha19:04:36

you can use that to have boot ignore files in the source and resource dirs

micha19:04:47

might be handy for your problem

sbrady19:04:00

Yeah, I forgot about that

kenbier21:04:06

I am trying to write a test to check that a macro expands to an expected list, using core.test. For some reason the arg of macroexpand is not being evaluating, and it just being returned.. Has anyone ever seen this before?

kenbier21:04:14

I am wondering if this is a boot issue or core.test issue

micha21:04:37

@kenbier: can you paste an example please?

kenbier21:04:50

(deftest well-formatted-usecase [] (let [output (macroexpand '(defusecase foo :default with good-policy [x] "Foobar"))] (is (= output '(. foo clojure.core/addMethod :default (clojure.core/fn [x] (clojure.core/if-not (clojure.core/apply good-policy [x]) (throw adstage-report-center.use-case/unauthorized-exception) "Foobar")))))))

micha21:04:53

boot shouldn't change the way clojure expands macros

kenbier21:04:21

i didnt think so, but i saw awhile back someone posted a similar issue with lein

micha21:04:33

is defusecase available in that namespace?

micha21:04:44

like without a namespace alias?

kenbier21:04:46

let me share the result of the test

kenbier21:04:21

(ns adstage-report-center.use-case-test (:require [adstage-report-center.policies :refer [good-policy bad-policy]] [adstage-report-center.use-case :refer [defusecase malformed-usecase-message]] [clojure.test :refer :all] ))

kenbier21:04:38

FAIL in (well-formatted-usecase) (use_case_test.clj:9) expected: (defusecase foo :default with good-policy [x] "Foobar") actual: (. foo clojure.core/addMethod :default (clojure.core/fn [x] (clojure.core/if-not (clojure.core/apply good-policy [x]) (throw adstage-report-center.use-case/unauthorized-exception) "Foobar"))) diff: - [defusecase nil :default with good-policy [x] "Foobar"] + [. nil clojure.core/addMethod :default (clojure.core/fn [x] (clojure.core/if-not (clojure.core/apply good-policy [x]) (throw adstage-report-center.use-case/unauthorized-exception) "Foobar"))]

kenbier21:04:00

you can see the result of the test is just the list i passed in 😕

micha21:04:25

that's what you would see if the name defusecase is not refered into the namespace where you're running the test

micha21:04:13

hm no, i misread

micha21:04:22

that's what you're expecting the thing to expand to?

kenbier21:04:05

if i pull out that equality fn into a def and eval it, it returns true

micha21:04:12

why do you expect it to expand to itself?

micha21:04:01

i must be confused, but it looks like the test output is expecting to see (defusecase ...

micha21:04:41

like the test seems to be printing that the actual value is correct

micha21:04:47

but the expected value is not

kenbier21:04:08

hmm really?

kenbier21:04:46

if i eval the macroexpand it expands to the second expression. thats how i got the expression

micha21:04:53

expected: (defusecase foo :default with good-policy [x] "Foobar")
 actual: (.
          foo
          clojure.core/addMethod
          :default
          (clojure.core/fn
           [x]
           (clojure.core/if-not
            (clojure.core/apply good-policy [x])
            (throw
             adstage-report-center.use-case/unauthorized-exception)
            "Foobar")))

kenbier21:04:48

yeah expected is the first expression in my is block, no? which is why i think its just returning the list rather than expanding it.

micha21:04:49

i read it like that's what output is expected to be equal to

micha21:04:16

and the actual value is what ouput actually equals

micha21:04:51

the diff is the difference between what the test harness expected the value to be and what the value actually was

micha21:04:48

this is also strange to me because the is macro doesn't know about output or that big list

micha21:04:07

wouldn't it just be seeing if the expression is true or false?

micha21:04:36

i suspect you are actually running a different version of the test somehow

micha21:04:50

if you throw an exception in there does it show it?

micha21:04:03

just to make sure you're not looking at stale test code somehow

kenbier22:04:03

@micha sorry, was offline for a bit

kenbier22:04:00

im using the clojure 1.8, so i dont think its old.

micha22:04:17

i mean if you're changing things in the repl or reloading namespaces

kenbier22:04:21

i bound the macroexpand to a var in the ns, and referenced it in the deftest, and it worked

kenbier22:04:46

which leads me to believe deftest is doing some weirdness involving how it handles macroexpansion

micha22:04:03

are you using boot-test?

micha22:04:28

that should be creating a new pod, so it's not an issue with stale code then

micha22:04:51

like each time the tests run they get a fresh pod to run in

kenbier22:04:03

yeah i restarted the repl to be sure

micha22:04:58

interesting