This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-14
Channels
- # adventofcode (20)
- # arachne (11)
- # beginners (53)
- # boot (342)
- # cider (54)
- # cljs-dev (39)
- # cljsrn (4)
- # clojure (78)
- # clojure-brasil (2)
- # clojure-italy (5)
- # clojure-nl (4)
- # clojure-quebec (1)
- # clojure-russia (90)
- # clojure-sanfrancisco (4)
- # clojure-spec (55)
- # clojure-uk (27)
- # clojurescript (170)
- # core-async (1)
- # core-logic (1)
- # css (1)
- # cursive (8)
- # datomic (83)
- # dirac (5)
- # hoplon (24)
- # lambdaisland (1)
- # lein-figwheel (23)
- # midje (2)
- # off-topic (1)
- # om (4)
- # om-next (7)
- # onyx (74)
- # proton (1)
- # protorepl (22)
- # rdf (2)
- # re-frame (105)
- # reagent (15)
- # ring-swagger (3)
- # rum (4)
- # slack-help (17)
- # spacemacs (14)
- # untangled (62)
- # vim (4)
- # yada (18)
(with-pass-thru _
(time (Thread/sleep 1)))
@domkm this works for me@domkm what in particular would you like to benchmark?
@martinklepsch how much time is spent in each subtask or inside a macro that is called by a task. I'll try your code tomorrow. Thanks :)
Hi, I don't know why, but when boot-reload tries to reload stuff, it doesn't use the right path?
It's supposed to load from project-dir/target/main.out/stuff
But it loads from project-dir/main.out/stuff?
@martinklepsch by the way, why do you see sometimes (with-pass-thru _ ...)
and sometimes (with-pass-through [_] ...)
?
@abstruselyarcane it shouldn't read from target though
that's not how it's supposed to work
the binding form [_]
vs _
is a legacy thing. Why there are two names for the same thing I don't know 😄
I'm using electron, and cljs is compiled with asset-path pointing to target/main.out
so _
is preferred?
It's based on this project: https://github.com/martinklepsch/electron-and-clojurescript
@abstruselyarcane normally boot-reload reads from the resources and doesn't need to be made permanent in target/
not sure if electron makes things different
hmm, but I want it to reload the new js
and compiled js lives in target
The electron stuff is a bit different but really the main stuff shouldn't get reloaded @abstruselyarcane
wait, why would you be reading from resources?
Hmm, can you take a look at the electron-and-cljs project I just pasted and see why that works?
My boot file is pretty much the same with minor modifications
But the whole point of using reload is to reload the new js when there's new js
Or am I misunderstanding the whole buildchain entirely?
@abstruselyarcane in Electron theres a main process and the renderer
The renderer stuff gets reloaded the main stuff requires an electron restart.
Yeah, but the renderer, when reloading, reads from the wrong place
Can you paste a diff of your modifications? (if you create a snippet you can choose "Diff" for proper highlighting)
The only modifications I made are add a set nrepl port and devtools preload to the renderer
I just cloned the repo and it's all working as it should.
It's working on my machine too, I don't know why the exact same thing isn't working for this project
did you read the readme? It's important that you start electron like this electron target/
Yeah, I'm starting electron correctly
(i.e. don't omit the trailing slash)
Everything works except for reload
@abstruselyarcane if you can put your project up somewhere I can take a quick look
Wait, I'll push the latest version up
Don't mind the readme, its outdated: https://github.com/IsaacKhor/project-factual/blob/master/build.boot
This looks like it might be related: https://github.com/adzerk-oss/boot-reload/issues/64
Hmm, adding :asset-path "target/main.out"
to reload doesn't change anything
@abstruselyarcane try adding a boot.properties
file
That's strange
boot -V > boot.properties
and then make sure you use at least Clojure 1.8.0 and Boot 2.6.0
Hmm, I'm on boot 2.7
There shouldn't be any differences between those 2, as far as reload is concerend, right?
Shouldn't but 2.7 is relatively new so wouldn't hurt to try 2.6 just to be safe
Ok, ill try 2.6
Also are you 100% you don't have any uncommitted changes in your repo?
Wait, is there a global boot.properties somewhere that overrides everything eles?
project specific ones have highest priority
I just changed it properties to 2.6 but -V still reports 2.7
I found it, it's at ~/.boot/boot.properties
Are you kidding me? the local version is mispelled
That's why
local version?
Local to the project
That doesn't make it any clearer to me, sorry 😄
There's the global prop file at ~/.boot/boot.properties
and the local at prj-dir/boot.properties
There was a typo in the local one
And yes, it seems like migrating to 2.6 fixed it
Lemme look thru the changelog for 2.7
Hmm, don't see anything that should change this behaviour in the changelog
I don't want to be stuck on 2.6 forever...
2.7 is out for less than 2 days, I think there will be a solution 😉
Should I file this under boot or reload?
It looks like it's reload's fault
@abstruselyarcane I'd also suggest filing under boot-reload
I can reproduce the issue with 2.7.0 btw
Good, it's not just my machine
Ty, I'll open an issue on reload
What's the difference between reload and figwheel?
@abstruselyarcane I also just reproduced with this repo which might be a more minimal case to provide in the issue: https://github.com/martinklepsch/electron-and-clojurescript
I also reproduced this with the electron-and-clojurescript
Oh, didn't know the bot reports on new issues
I had following boot.properties in my project dir:
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.9.0-alpha14
BOOT_VERSION=2.6.0
and it was working wellAfter changing BOOT_VERSION
to 2.7.0 now I am getting following warning:
Classpath conflict: org.clojure/clojure version 1.8.0 already loaded, NOT loading version 1.9.0-alpha14
and 1.8.0 is used for my project
What does -V say?
@piotrek what is the output for boot -V
?
boot -V (with 2.6.0):
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.8.0
BOOT_VERSION=2.6.0
boot -V (with 2.7.0):
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.8.0
BOOT_VERSION=2.7.0
So how can I change clojure version to 1.9.0-alpha14 (property from boot.properties doesn’t work apparently)
Hmm, if you change in the prop file -V still shows 1.8?
https://github.com/boot-clj/boot/commit/9a66940c9d7afb6c1760e7c373476fbd4e24ddf3 introduced that warning message, and has two issues mentioned in the commit that may provide more context
@piotrek I think you can set the version thru environment variables; try looking at the docs
@abstruselyarcane env var works fine - but boot.properties doesn’t...
@piotrek it's just a new warning for an existing situation
It means that one of your dependencies wanted to bring in 1.9
Which could cause a problem if that dependency uses a feature of 1.9
You can figure out which dependency with boot show -p, and eliminate the warning with an exclusion
@alandipert It was a direct dep of my project
How could I configure hoplon and boot-cljs tasks to generate html/js files under a specific directory under target? I would like to server that sub-directory via http server in my clojure app in the same project and I don’t want to server everything from my classpath but only a specific dir
you can also just make a middleware that allows access only to HTML js, css, and images
Whenever I save the hoplon page (with (page “public/index.html”)
) and that page is reloaded in my browser, I can see an error in the console:
GET
(anonymous) @ core.cljs:113
hoplon$core$merge_kids @ core.cljs:112
G__9737__2 @ core.cljs:4120
G__9737 @ core.cljs:4122
(anonymous) @ core.cljs:48
cljs.core.Atom.cljs$core$IWatchable$_notify_watches$arity$3 @ core.cljs:4246
cljs$core$_notify_watches @ core.cljs:675
cljs$core$reset_BANG_ @ core.cljs:4287
cljs.core.swap_BANG_.cljs$core$IFn$_invoke$arity$4 @ core.cljs:4306
cljs$core$swap_BANG_ @ core.cljs:4291
hoplon.core.set_appendChild_BANG_.this$.appendChild @ core.cljs:144
goog.net.jsloader.load @ jsloader.js:214
popAndLoadNextScript @ jsloader.js:133
goog.net.jsloader.loadMany @ jsloader.js:139
adzerk$boot_reload$reload$reload_js @ reload.cljs:47
adzerk$boot_reload$reload$reload @ reload.cljs:80
(anonymous) @ client.cljs:37
G__11572__3 @ core.cljs:10037
G__11572 @ core.cljs:10146
(anonymous) @ client.cljs:59
goog.events.EventTarget.fireListeners @ eventtarget.js:284
goog.events.EventTarget.dispatchEventInternal_ @ eventtarget.js:381
goog.events.EventTarget.dispatchEvent @ eventtarget.js:196
goog.net.WebSocket.onMessage_ @ websocket.js:426
reload.cljs:54 Load failed: Jsloader error (code #0): Error while loading script
My task def is following:
(deftask
dev-repl
"Dynamic dev repl"
[]
(comp
(repl :server true)
(watch :verbose true)
(notify)
(hoplon)
(reload :on-jsload 'page.index/reload)
(cljs :compiler-options {:parallel-build true})
(refresh)))
I run it, I connect to the repl server and start my app serving resources from “public” directory on classpath
@piotrek you will need to configure various other tasks to know about the public directory
with hoplon especially there is not really a need to package the frontend in the same jar as the backend
in which case we don't care about it serving other files because we already have them on the disk 🙂
But I would love the correct order of the following tasks: - repl - samestep/boot-refresh - watch - notify - hoplon - boot-reload - boot-cljs-repl - boot-cljs
I guess I would need to configure other tasks to handle it correctly or just use that middleware per your advise
if you're going to be deploying your application to "the cloud" you won't want to serve the html and js and stuff from a jetty server anyway
It will be rather small so I would like to keep it simple - so probably just a small jetty server with both backend and frontend
Shameless plug 🙂 🎉 https://github.com/confetti-clj/confetti
For now thanks to @micha’s advice I was able to use :hoplon/page “public/index.html” along with ring resource middleware (with root set to “public”) and boot-reload task with :asset-path set to “public” - the warning is gone
Hi all,
If I declare a dependency in my build.boot
on org.clojure/clojure "1.8.0"
and then also include a couple of 3rd party Jars that have a dependency on an older version of org.clojure/clojure
, then I will have a dependency conflict (as beautifully displayed with boot show -p
).
If I include :exclusions ['org.clojure/clojure]
in my build.boot
then my understanding is that the version of org.clojure/clojure
included with each of the 3rd party Jars will be excluded. My question is will the 3rd party Jars therefore use the version of org.clojure/clojure
I have specified (1.8.0)?
@mf the answer is: yes
even without the exclusions, if you have a direct clojure dependency, it 'wins'
the difference is that you'll see some warnings. since it's frequently helpful to know that libraries you depend on expect a different version of clj, and so might behave differently or break when they run against the version of clj you specified
@alandipert that makes sense, thanks!
oh, the other related concept is the version of clj specified in boot.properties
that's what actually determines the version of clj that boot uses
which may or may not be relevant to your project... it depends on whether or not boot is the entrypoint to your application
but it will determine the version of clj that tasks use when you're in the 'build phase'
does that make any sense? i very probably need to improve how i describe that hehe
@alandipert Yes boot is the entry point for my project. So if I understand correctly the version of clj specified in boot.properties
will supersede the version I specify in the build.boot file?
that's correct
correct. the other situation is, you use boot to produce a jar
which runs in a non-boot environment like tomcat
tomcat doesn't have boot.properties or maven stuff, it just knows about the classes in your jar
and if you didn't specify a clojure dependency in your build.boot, it wasn't packaged in the jar, and so tomcat probably explodes
and here's a trick to never really worry about it, and always just use whats in boot.properties or the boot default: (set-env! :dependencies [['org.clojure/clojure (clojure-version)]])
yeah. probably bad to do unless you have a project-local boot.properties
, but that's always good to do
kewil
@alandipert Slightly more general dependency question if I may: If two 3rd party dependencies use different versions of a lib e.g. org.clojure/core.match
and my boot project doesn't have an explicit dependency on org.clojure/core.match
. Will each of the 3rd party Jars get their specified version of the lib?
@mf nope... 1 will win, and which one is nondeterministic
so you have 2 options in this situation, which is the worst one you can be in
the worst case is, neither is compatible with the other's dependency
in that case it's impossible to solve
and you need to send a PR to one of the projects
however
pods can be used, if boot is your entrypoint
pods let you run a set of dependencies in isolation
so then, you can use multiple dependencies, as long as they're used in different pods
So would you say it's pretty common for people to recognise a dependency conflict between Jars, and preemptively combat potential incompatibilities by using Pods?
i would say in most cases, i figure out how not to cause the problem
then next, i see if i can send a PR to one of the offending projects to fix it there
then pods, if i'm in a hurry or those didn't work
Take my example of core.match
. Jar A may be dependent on a specific feature available in the latest version
oh yeah, it's kind of a non-answer
but i meant like... figure out how to do what i want without using either A or B
the next step after that tho is to choose explicitly, by setting as a local dep, a version of core.match that satisfies both deps
pods come in when there isn't a version that works for both
Do you have any OS projects in mind that you could point me to, that use Pods for handling this?
@mf i don't actually. i was in the predicament once, using a lib that dependened on AWS sdk, when i also depended on different version of AWS Sdk
it was an sqs veneer in clj
to fix i just called sqs apis directly instead of using the wrapper lib that brought in the problematic dep
i don't think there are any examples because this is something that happens in applications usually, not libraries
but you can learn the mechanics of pods from libraries that use them
@alandipert thanks for the info
no prob
@alandipert is there any way to declare that my app depends on a version of a lib greater than a specific version? e.g. > 0.8
I can see it making more sense if you own the dependency and have a really amazing memory or something
if you really want to do it there is a good intro here https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN401
Yeah I'm more interested in learning what the best practices are with regards dependencies
that's one really nice thing about maven vs. what i've experienced with ruby and npm etc
like if you resolve your dependencies today and you get some tree of dependency versions
you can resolve those same dependencies a year from now and get exactly the same tree back
sounds abit like the approach with https://nixos.org/nix/
there are cases of course where an artifact needs to be deleted, like for legal reasons (intellectual property, etc)
so if your program works with some library of version X today, it will get the same artifact when it resolves version X next year or 10 years from now
Thanks @alandipert @micha for the excellent info
most of the dependency hell situations arise from build-time dependencies conflicting with project dependencies
Thats nice to hear, To be honest I was seeing Maven as Java eco-system component to be afraid of
I wonder why maven is so slow compared to boot...really...isn't dep resolution the same (both using aether
)?
@richiardiandrea boot aggressively caches aether results
oh ok that makes total sense
you know I am pondering whether I can actually write a aether
server using boot
it would be useful also for builds that are faster to startup, like cljs
builds, but still need to resolve dependencies
yep I actually do this all the time
using boot-cp
before
there is a tool called calvin-cljs
for node.js builds that has a very interesting approach, all javascript 😉 https://libraries.io/npm/calvin-cljs
I tried it, but dep resolution is not actually faster
so I was wondering whether a server with aggressive caching would be beneficial
uhm, maybe, not very familiar with that, I will explore the option 😉
it's assumed that you don't care about new versions of things that appear while boot is running
like if you have a boot repl and you resolve some deps, it'll cache that so you would not "see" a new version that is pushed to maven
oh got it, that's good to know
not that it matters during dev time I guess actually, so the choice seems sound to me..
so ok the proxy server is Nexus 🙂
as many Java things it looks blooooated ah ah
but this is interesting: https://support.sonatype.com/hc/en-us/articles/213464098-What-are-the-requests-that-Maven-3-x-sends-when-deploying-artifacts-
so there is a redeploy, but needs to be explicitly enabled it seems
that's good
good point
also, I really don't like all this output in the console, and I wonder if you can disable it
oh there is a mvn -q
, still very verbose 😄
no no I am unfortunately dealing with maven
@richiardiandrea: redeploy is used when you have staging repos. That's how http://oss.sonatype.org works - you deploy, and it goes to a staging repo. You can then redeploy to that staging repo as much as you want, but must explicitly depend on that repo if you want to use those artifacts. Once you are happy with what you have in staging, you "release" it to maven central, where it becomes immutable
yes I was familiar with that part, I was just wondering if it makes sense to create an alternative server for faster resolution from JS
trying to understand how much work would be to have a node.js
build tool
ah, I didn't read any of the backlog before your http://sonatype.com link, sorry :)
no probz 🙂
@erwin hey thanks for the windows fixes! were you able to test on windows?
not yet 😕 sort of tested it by swapping the code a bit around and relied on the appveyor build. If you want, i can test it on Windows, but I will have to create a VM or use AWS. Probably can do that tomorrow in the morning.
that's cool
yeah, or maybe we can find someone with windows at hand to try it
it would just be really nice for a human with windows to actually see it not explode
of course, it's exploding now, so
perhaps we just merge and make 2.7.1 and then see
I can make something happen tomorrow, I actually have a new colleague now with a windows laptop and we use boot in our build so I think its work(tm)
that would be awesome
https://ci.appveyor.com/project/Deraen/boot/history PR 537 in fact fixes Boot on Appveyour
I previously thought that the CI configuration was broken
Ah, and the appveyour status is shown on github, cool
@juhoteperi excellent, where do you see it displayed on github?