This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-10
Channels
- # admin-announcements (1)
- # boot (464)
- # braid-chat (4)
- # cider (6)
- # cljs-dev (7)
- # cljsrn (1)
- # clojars (1)
- # clojure (26)
- # clojure-france (1)
- # clojure-japan (6)
- # clojure-russia (35)
- # clojure-uk (3)
- # clojurescript (25)
- # cursive (5)
- # hoplon (389)
- # om (20)
- # om-next (1)
- # onyx (5)
- # other-lisps (1)
- # overtone (9)
- # planck (12)
- # proton (7)
- # re-frame (10)
- # reagent (13)
- # ring (23)
- # spacemacs (11)
By the way now we have make test
:)))
Ah maybe boot
is not in the PATH?
'bout the failing build, maybe the Makefile needs little tweaking :)
Maybe boot test
actually is bin/boot test
I cleaned my ~/.m2
folder the other day and to my surprise our app triggered the download of 5 different versions of Clojure.
boot show -d
didn't show any other version than the explicitly specified 1.8.0
boot show -p
however showed the following:
[✔] org.clojure/clojure
✔ 1.8.0
org.clojure/clojure
org.clojure/clojurescript
✘ 1.7.0
com.andrewmcveigh/cljs-time
com.andrewmcveigh/cljs-time
hoplon/jquery-daterange-picker
org.clojure/test.check
✘ 1.5.1
binaryage/devtools
hoplon/castra
✘ 1.3.0
hoplon
I have the feeling that the downloads triggered while walking the dependency tree is a bit too eager...
My downloads looked something like this:
onetom@retinatom ~/e/appboard> boot dev
Starting reload server on
Writing boot_reload.cljs...
Started Jetty on .
...
Retrieving clojure-1.3.0.jar from
Retrieving clojure-1.6.0.jar from
Retrieving clojure-1.6.0.jar from
...
...
Retrieving clojure-1.5.1.jar from
Retrieving clojure-1.2.1.jar from
...
Retrieving clojure-1.4.0.jar from
...
There are 2 notable things in the output
1. why does 1.6.0 is there twice?
2. how come 1.2.1 & 1.4.0 doesn't appear in the output of boot show -p
?
@onetom: if you build from master you can see more information about what it's downloading
@onetom: I suspect that maybe some dependency uses a version range instead of a concrete version number, which is pretty much deprecated now
i just wanted to ask if i see it well that the date mentioned in the jar filename suggests it's just a february 2nd release
it takes 5 minutes to download all the dependencies w that version even on an otherwise decent internet connection because there are some misterious pauses between the downloads
there might be some setting in aether somewhere to disable downloading things when you resolve them
im also seeing ~30kbyte/s download rates in the activity monitor often while - mostly for files coming from maven central - i see 1+Mbyte/s
sure, i just noticed this when i cleaned by ~/.m2 folder and if it's downloading several versions of clojure then probably it might have other unnecessary downloads which hurts the overall boot experience...
if aether doesn't do it then probably it can only be done by reimplementing what aether does, right?
it might not actually work though, because some of the things are not as simple as they appear in maven world
which would be confusing for plain java deps i guess, if those would resolve to different versions than in a pure maven project
but if you have a separate set of functions for computing the dependency graph without downloading
right now if you tell boot to resolve-dependencies
you get back a data structure with all the info about the depdnecies
if you separate the the jars now you can't use that one function as the basis of all the other functions
i was just about to ask about this because i noticed 1.6 during install
(cd boot/pod && lein install)
...
Retrieving org/clojure/clojure/1.6.0/clojure-1.6.0.pom from central
i think it fetches a lot of pom.xml files because those are maybe the parent of other pom.xml files
btw, i wanted to try boot master without ruining the production deployment, so i thought i could just export env BOOT_LOCAL_REPO=~/.m2/test26 time make deps install
but obviously it doesn't work...
would it make sense to tell lein
where should it look for a maven repo if there is a BOOT_LOCAL_REPO env var?
honestly i dont really want to know either, because i hope it will be obsolete knowledge soon 😉
hmmm... i've just compiled the tip of master and when i run
pair@parrot ~/g/b/boot> ~/github.com/boot-clj/boot/bin/boot -V
Downloading ...
why is it trying to download that version?
i've cleared my i've just built it:
pair@parrot ~/g/b/boot> ls -lah ~/github.com/boot-clj/boot/bin/boot
-rwxr-xr-x 1 pair staff 6.3K Apr 11 01:14 /Users/pair/github.com/boot-clj/boot/bin/boot
i've even mv ~/github.com/boot-clj/boot{,.bak}
and cloned it again to make sure i have a fresh tree
so i have to manually trick it by deleting and recreating a "latest" tag pointing to the latest release
btw, does this look correct to u?
pair@parrot ~/g/b/boot> ~/github.com/boot-clj/boot/bin/boot -V
Downloading ...
Running for the first time, BOOT_VERSION not set: updating to latest.
Retrieving clojure-1.7.0.jar from
#
#Mon Apr 11 01:51:57 HKT 2016
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_VERSION=2.5.5
BOOT_CLOJURE_VERSION=1.7.0
ok, so newer versions of the boot binary will get the latest version of the boot.jar immediately?
so @micha, if I want to execute things in the core pod, and skip boot.main/-main
for boot.parallel
, I just need to set pod
specific stuff like verbosity right?
I can look into that
you know, the warning is in a delay
I am not sure why and if this can be a problem, thinking...
you mean parallel.boot
right?
actually everything is AOT-ed
from what I see
lol great
i will println to see ns and sym at that point
but well, probably they will match ah ah
after doing a pair@parrot ~/g/b/boot> rm -rf ~/.boot/ ~/.m2/repository/; time make clean deps install; env BOOT_VERSION=2.6.0-SNAPSHOT bin/boot -V
i can observe a bunch of clojure versions, but as it turns out some of them are just the pom files:
pair@parrot ~/g/b/boot> du -hsc ~/.m2/repository/org/clojure/clojure/*
12K /Users/pair/.m2/repository/org/clojure/clojure/1.2.0
12K /Users/pair/.m2/repository/org/clojure/clojure/1.2.1
16K /Users/pair/.m2/repository/org/clojure/clojure/1.3.0
16K /Users/pair/.m2/repository/org/clojure/clojure/1.3.0-beta1
16K /Users/pair/.m2/repository/org/clojure/clojure/1.4.0
16K /Users/pair/.m2/repository/org/clojure/clojure/1.5.1
3.5M /Users/pair/.m2/repository/org/clojure/clojure/1.6.0
3.6M total
Which is funny because there is no 1.8.0 though the ~/.boot/boot.properties refers to that..sure i have not run anything else, just boot -V
, but why clojure 1.6.0 is there though... 😕
@richiardiandrea: is it only tasks defined via deftesttask
that show the warnings?
ah, i see now:
pair@parrot ~/g/b/boot> ag 1.6.0
boot/aether/project.clj
16: :dependencies [[org.clojure/clojure "1.6.0" :scope "compile"]
boot/core/project.clj
16: :dependencies [[org.clojure/clojure "1.6.0" :scope "provided"]
boot/pod/project.clj
19: [org.clojure/clojure "1.6.0" :scope "provided"]
boot/worker/project.clj
18: :dependencies [[org.clojure/clojure "1.6.0" :scope "provided"]
@micha: let me double check that (also boot -vv
shows the stack trace) I have tried only that, but it is a macro calling deftask
sure, just seeing 7 different clojure versions make me think there is some problem somewhere but now im less worried after i saw they are not actually 7 complete clojure versions i was just hoping to clean it up somehow...
@micha silly question, resolve
always looks at the current pod right?
It basically tries to resolve in *ns*
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L4222
so now I am confused on what this check is trying to detect
https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/test.clj#L161
this is my deftesttask
, just invokes deftask
with a different body
in a new pod like you were saying yesterday...
anyways I am on it
deftesttask
is executed on the require in build boot...
yeah there is definitely some subtle issue
require
eventually calls clojure.lang.RT/load
like load-file
which makes a class loader
to answer you previous question, both deftask
and deftesttask
trigger the warning so we can exclude the latter macro
in the pod
*ns*
is probably the problem
which is set to the namespace it is evaluating in cause of the (ns ...)
on the top of the required file
so if I create two pods, and do (ns ...)
in both, should I get two separate clojure.lang.Namespace
objects?
I mean evaluate (ns boot.task.built-in-test)
for instance
I can try
no well require
-ing
but that line is called in boot.main/-main
many times through runboot
because we evaluate the script over and over now
let me try something
it doesn't reload the namespace if it's in there, unless you have :reload
in the require
yes but I am creating a new pod each time, and I agree (and it is doing it) that my require triggers every time
my concern is that the namespace objects are shared
yep, I am trying to do it, I will get back to you with a simple example
deftask boot.parallel/runboot was overridden
deftask boot.parallel/await-done was overridden
deftask boot.parallel/parallel-start was overridden
deftask boot.parallel/runcommands was overridden
oh really
ah I didn't notice that
that's weird
only those tasks?
that's a normal namespace...
I haven't touched anything else in the Makefile, so maybe we need something
I confirm that the actually are the same namespace object:
*ns* {:ns #object[clojure.lang.Namespace 0x1e6d22bf "boot.test-test"]}
existing {:ns #object[clojure.lang.Namespace 0x1e6d22bf "boot.test-test"], :name vars}
....then here the usual warning
I guess, "execute build.boot
is one deftask
, runboot is another
but they should be in separate pods
and indeed the ten -main
calls are creating ten namespaces:
print-ns! *ns* {:ns #object[clojure.lang.Namespace 0x76d5985f "clojure.core"]}
print-ns! *ns* {:ns #object[clojure.lang.Namespace 0x4f9d4366 "clojure.core"]}
print-ns! *ns* {:ns #object[clojure.lang.Namespace 0x29cae75 "clojure.core"]}
print-ns! *ns* {:ns #object[clojure.lang.Namespace 0x43ee2557 "clojure.core"]}
print-ns! *ns* {:ns #object[clojure.lang.Namespace 0x3b81cd42 "clojure.core"]}
print-ns! *ns* {:ns #object[clojure.lang.Namespace 0x33c16375 "clojure.core"]}
print-ns! *ns* {:ns #object[clojure.lang.Namespace 0x38827b7b "clojure.core"]}
print-ns! *ns* {:ns #object[clojure.lang.Namespace 0x4961e445 "clojure.core"]}
print-ns! *ns* {:ns #object[clojure.lang.Namespace 0x60101bc1 "clojure.core"]}
print-ns! *ns* {:ns #object[clojure.lang.Namespace 0x22f894f3 "clojure.core"]}
digging digging
@micha: hey so I am still struggling with getting my basic boot build to work haha
if you have a sec would you mind if I showed you me isolated repo that demonstrates what I am struggling with
I even removed compojure btw so that way I could try to isolate it completely
all i have is one handler that should just return a hiccup page, and then import a main.js file which lives in target/main.js
alright here is the repo: https://github.com/adam-r-kowalski/app-boilerplate.git
and that worked for you?
yeah just a catch all route
so what is the “/“ route doing different then mine?
it worked! your a genius, thank you!
so does boot repl vs boot repl -c make a big difference too?
so you just use cider-connect rather then cider-jack-in
and connect to the nrepl over whatever port it spits out
sorry guys don't want to interrupt 😄
ok yeah i just tried it and it seems to work
but I am still confused about the else clause for your routing
so essentially when it makes a request for anything besides root it will return js?
should I make a route for /main.js as the if clause and anything else should actually return index.html?
(-> (subs uri 1) ;; chop off the first character of the uri string, like "/foo" -> "foo"
io/resource ;; resolve the resulting uri from the classpath
slurp) ;; read the file from the classpath into a string
ahh i see
yeah I might check out bidi like what we were talking about yesterday. looks intereseting
anyway thanks again for all your help
yeah thats not a bad idea, and write my own simple router so i understand how exactly it works
you can make your own thing very straightforwardly and it will do like 90% of all you will ever need
the last 10% is the really tricky stuff, and something like bidi has a super well engineered abstraction for that
like getting params out of the uri right
but thats the thing I don’t really wan’t to make a rest api, I would rather just use websockets to talk back and forth
then the client should just look at the url and dispatch the correct view according to the specified route
it seems like i dont need a compilicating routing solution for that
yeah i know i just prefer how hiccup looks to how html does haha 😛
hmm interesting
so I would need a specific directory for hiccup files then have a boot task than takes every file there and renders to a string and into a html file in the target/ directory?
cool, but what if I actually need a backend anyway? I was hoping to use datomic for storage and then everytime something there is changed publish the changes over a websocket. then use datascript on the front end and immediately transact every change into the client db
so clients can essentially have a mini database containing all the datoms they care about
@micha it looks like resolve
actually proactively resolves a symbol even if def has not been call on it, still need to prove this sentence, which might be totally off the target 😄
so this is what happens before everything, and makes me think the check with resolve
is not a good one and we should use maybe getMapping
on the ns:
after (ns boot.task.built-in-test ...) {:ns "boot.task.built-in-test"], :pod 1}
before deftask with-meta-tests -- mapping of with-meta-tests null
before deftask with-meta-tests -- mapping of sift-with-meta-tests null
### evaluating (deftask with-meta-tests ...) *ns* {:ns "boot.task.built-in-test"], :pod 1}
maybeResolveIn sym with-meta-tests --- null
before resolve sym with-meta-tests -- .getMapping of with-meta-tests null
before resolve sym with-meta-tests -- .getMapping of sift-with-meta-tests null
after deftask with-meta-tests -- mapping of with-meta-tests #'boot.task.built-in-test/with-meta-tests
after deftask with-meta-tests -- mapping of sift-with-meta-tests null
### evaluating (deftesttask sift-with-meta-tests ...) *ns* {:ns "boot.task.built-in-test"], :pod 1}
after update-body *ns* {:ns "boot.task.built-in-test"], :pod 1}
### evaluating (deftask sift-with-meta-tests ...) *ns* {:ns "boot.task.built-in-test"], :pod 1}
##### maybeResolveIn sym sift-with-meta-tests --- #'boot.task.built-in-test/sift-with-meta-tests ##### this is wrong
before resolve sym sift-with-meta-tests -- .getMapping of with-meta-tests null
before resolve sym sift-with-meta-tests -- .getMapping of sift-with-meta-tests null
after resolve sym sift-with-meta-tests -- .getMapping of with-meta-tests null
after resolve sym sift-with-meta-tests -- .getMapping of sift-with-meta-tests null
existing-deftask# {:ns "boot.task.built-in-test"], :name sift-with-meta-tests}
deftask before warning {:ns"boot.task.built-in-test"], :pod 1}
deftask boot.task.built-in-test/sift-with-meta-tests was overridden
--- custom build.boot loaded {:ns "boot.user"], :pod 1} ---
note that no deftask
for boot.task.built-in-test
is evaluated before this excerpt
and this is all before build.boot
is loaded, as the last line shows
resolve
ends up calling clojure.lang.Compiler/maybeResolveIn
which I am still digging up to see how it resolve symbols
for some reason (findInternedVar *ns* sift-with-meta-tests)
--> #'boot.task.built-in-test/sift-with-meta-tests
but the def has not been called yet
which namespace? boot.parallel
?
(cd boot/core && lein install)
Compiling boot.cli
Compiling boot.task-helpers.notify
Compiling boot.core
Compiling boot.test
:got-here nil
Compiling boot.main
Compiling boot.git
Compiling boot.parallel
:got-here #'boot.parallel/runboot
:ns1 boot.parallel :ns2 boot.parallel
deftask boot.parallel/runboot was overridden
yes in that case yes
i am not an expert of AOT, shouldn't it compile it in the correct order?
here i see that boot.test
boot.parallel
and boot.task.built-in
are triggering boot.util/warn
, the rest of the namespaces don't
which again is weird to me ..
the trace at the top is coming from boot.test
then boot.cli
muted
then boot.task.built-in
with traces
if something is requireing boot.task.built-in now then i can see how it would cause the warnings
I think we have two problem there, I will try to solve the one above first ...
Hey micha, I found the docstring of ns-resolve
a bit disturbing:
Returns the var or Class to which a symbol will be resolved in the
namespace (unless found in the environment), else nil. Note that
if the symbol is fully qualified, the var/Class to which it resolves
need not be present in the namespace.
unless found in the environment?
got it
I feel like in the Shroedinger cat, I can't observe something because I am changing it while observing
@micha a question for you, maybe you know better
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L7034
isn't it interning the var there?
of course it is then found, maybe I don't read it properly
ah ok sorry, intern actually does not do anything
there's a moment where things change and i cannot narrow down when
### evaluating (deftesttask sift-with-meta-tests ...) *ns* {:ns #object[clojure.lang.Namespace 0x56078cea "boot.task.built-in-test"], :pod 1}
after deftesttask update-body (sift-with-meta-tests [] (boot.test/test-task (comp (sift :add-jar {(quote org.clojure/tools.reader) #".*"}) (sift :add-meta {#".clj$" :boot-test-tag}) (sift :with-meta #{:boot-test-tag}) (with-meta-tests))))
after deftesttask update-body *ns* {:ns #object[clojure.lang.Namespace 0x56078cea "boot.task.built-in-test"], :pod 1}
after deftesttask update-body sift-with-meta-tests -- .getMapping of with-meta-tests #'boot.task.built-in-test/with-meta-tests
after deftesttask update-body sift-with-meta-tests -- .getMapping of sift-with-meta-tests null
### evaluating (deftask sift-with-meta-tests ...) *ns* {:ns #object[clojure.lang.Namespace 0x56078cea "boot.task.built-in-test"], :pod 1}
maybeResolveIn sym sift-with-meta-tests --- #'boot.task.built-in-test/sift-with-meta-tests
(findInternedVar *ns* sift-with-meta-tests) --- #'boot.task.built-in-test/sift-with-meta-tests
before resolve sym sift-with-meta-tests -- .getMapping of with-meta-tests null
before resolve sym sift-with-meta-tests -- .getMapping of sift-with-meta-tests null
after resolve sym sift-with-meta-tests *ns* {:ns #object[clojure.lang.Namespace 0x56078cea "boot.task.built-in-test"], :pod 1}
after resolve sym sift-with-meta-tests -- .getMapping of with-meta-tests null
after resolve sym sift-with-meta-tests -- .getMapping of sift-with-meta-tests null
ah really
thanks for spotting it
you see above the .getMapping
is fine until the second ### evaluating ...
after deftesttask update-body sift-with-meta-tests -- .getMapping of sift-with-meta-tests null
### evaluating (deftask sift-with-meta-tests ...) *ns* {:ns #object[clojure.lang.Namespace 0x56078cea "boot.task.built-in-test"], :pod 1}
maybeResolveIn sym sift-with-meta-tests --- #'boot.task.built-in-test/sift-with-meta-tests
these three lines don't make any sense if the *ns*
is the same
the first is fine, the second still has not deffed anything
the third should return null
yep it should be like you say for each and every isolated pod
my lines are inside the same pod, requiring boot.task.built-in-test
no well sorry the output is messy, but it is evaluating once
but ok, I still need to dig
### evaluating (deftesttask sift-with-meta-tests ...) *ns* {:ns #object[clojure.lang.Namespace 0x56078cea "boot.task.built-in-test"], :pod 1}
yes look
(ns boot.task.built-in-test ...
(deftask ^:private with-meta-tests []
(deftesttask sift-with-meta-tests [] <- this one then calls deftask
just to explain, the problem are these three lines:
after deftesttask update-body sift-with-meta-tests -- .getMapping of sift-with-meta-tests null
### evaluating (deftask sift-with-meta-tests ...) *ns* {:ns #object[clojure.lang.Namespace 0x56078cea "boot.task.built-in-test"], :pod 1}
maybeResolveIn sym sift-with-meta-tests --- #'boot.task.built-in-test/sift-with-meta-tests
because I am still before defclifn
no def
has been triggered but the var is resolved
by maybeResolveIn
good idea
every thing is good, except I noticed that there was a particular way to apply alter-meta!
at the bottom, probably of defclifn
:
(let*
[G__1664 var__210__auto__]
(clojure.core/alter-meta!
G__1664
(clojure.core/fnil clojure.core/merge {})
meta__212__auto__)
G__1664)
so I commented out my alter-meta!
in deftesttask
and no warning!
also, no tests executed because I need to set meta for my boot.test
so still need to investigate
but there might be something there
I am putting meta
on the return of def
.........................................maybe not good
https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/test.clj#L167
yes that one
weeeeeellll
sorry about that 😉 I am trying if it fixes
hard to say, but alter-meta!
has a big !
so...
yes that's exactly my snipped above, I noticed that
that's why I decided to comment it out
I don't know, but not I see the description says "Atomically"
which is always a big warning
it is strange because def
returns the var
yeah...don't really have a clue about that actually, it would be sage to open a JIRA issue probably
wow i see no warnings!