Fork me on GitHub
#boot
<
2015-11-25
>
jaen00:11:17

If I want to have boot-reload reload files work with a remote PC then I have to use :ws-host option, right? Or is there anything else I need to use?

jaen00:11:33

I seem to get (client/connect "" {:on-jsload (fn* [] (presentation.frontend.core/app-reload!))}) in the file generated by boot-reload even though I've set :ws-host, so maybe something else is needed as well?

martinklepsch10:11:27

That doesn’t feel perfect though so I’d be curious about other suggestions simple_smile

jaen10:11:00

@juhoteperi: sorry to hassle you, but since you have the most code in boot-reload you could tell me what should I modify to get :ws-host working? I can't seem to find where that file with client/connect is generated.

juhoteperi10:11:55

@jaen: Not sure, perhaps there should be separate client address option

juhoteperi10:11:08

Or perhaps the client should use the current hostname

jaen10:11:51

My use case is I want reload to work on a different computer the boot is running on; I understood :ws-host option to be meant for that, but it doesn't seem to work. I'm happy to add this myself if it's simple, but I couldn't figure out how application.out/adzerk/boot_reload.cljs is generated so I could modify it.

jaen10:11:18

Nevermind, I've just rubber ducked myself

jaen10:11:48

It serialises forms in write-cljs! and the url is a return from start-server!, so I'll just have to make sure it returns the once with ws-host.

jaen10:11:37

I've been passing this option to cljs-repl all along. I'll show myself out '

jaen14:11:41

@martinklepsch: only merge-env! will work, not set-env, yes? In that case how should I avoid duplicate entries in dependencies? Just make them sets and union them?

jaen14:11:49

Though I guess I should preserver ordering, right?

martinklepsch14:11:25

@jaen: both are fine, ordering should be irrelevant

jaen14:11:42

Hm, I thought it didn't work when I used set-env, let me try again

micha14:11:27

i think the order of dependencies does matter

martinklepsch14:11:07

merge-env! won’t remove deps that are no longer in deps.edn

jaen14:11:23

Yeah, set-env! works as well from the REPL

jaen14:11:28

Then I must be doing tasks wrong.

jaen14:11:57

(deftask [] (update-dependenices!) identity) is not how I should do it, right?

jaen14:11:56

That update-dependencies! should be in the function I return (`identity` here), yes? Though I'm not sure what signature it should have

martinklepsch14:11:57

@jaen: with-pre-wrap

martinklepsch14:11:46

(deftask deps [] (with-pre-wrap fs (update-deps!) fs))

jaen14:11:07

No need to call commit! like in examples in wiki?

martinklepsch14:11:38

@jaen: commit! syncs fileset with filesystem, if fileset isn’t changed there is no need for commit.

jaen14:11:51

Right. I should probably read docs someday to not ask such stupid questions, I've been using boot a bit in the blind.

jaen14:11:46

How worried should I be with Warning: version conflict detected: commons-codec version changes from 1.6 to 1.10?

micha14:11:05

@martinklepsch: suppose you have two dependencies in your declared deps, A and B. A and B both depend on C, but different versions. aether will try to use the version of C (the transitive dep) that is "closest" to the declared deps, i.e. shortest path in the dependency graph. but if the path from your project to C via A and B are the same length, it will choose the one you declare first, i think

micha14:11:05

so if you have a lot of dependencies you can get unpredictable behavior if you use an unordered collection for the deps

micha14:11:32

boot1 in the very beginning used a map, so you could easily add and remove deps

micha14:11:45

i mean a set

jaen14:11:46

Yeah, I'll jsut use set-env! to overwrite the :dependencies key then.

jaen14:11:24

boot.user=> (require 'taoensso.carmine)

java.io.FileNotFoundException: Could not locate taoensso/carmine__init.class or taoensso/carmine.clj on classpath.
boot.user=> (merge-env! :dependencies '[[com.taoensso/carmine "2.12.0"]])
Warning: version conflict detected: commons-codec version changes from 1.6 to 1.10
nil
boot.user=> (require 'taoensso.carmine)

clojure.lang.Compiler$CompilerException: java.lang.IllegalArgumentException: No matching method: sha1Hex, compiling:(taoensso/carmine.clj:149:29)
     java.lang.IllegalArgumentException: No matching method: sha1Hex
boot.user=> 

jaen14:11:31

It's not as magic as I hoped, oh well

micha15:11:07

@jaen: you can't remove dependencies that have already been added to a classloader

micha15:11:49

that commons-codec jar had already been pulled in via transitive deps from a dependency you added earlier

jaen15:11:34

So there's nothing you can do apart from restarting in that case? Is this related to what you mentioned earlier that boot is a single JVM?

micha15:11:01

we use pods for this

micha15:11:24

especially with 2.5.0-SNAPSHOT you can do some things

micha15:11:59

like you can make a pod that has your existing deps with the carmine dep added, and it will resolve transitive deps against the full set ofdependencies, so it will choose the right one

micha15:11:16

then you can open a repl server in that pod

micha15:11:26

and connect to it and do things

micha15:11:38

basically dependencies are append-only

micha15:11:24

so in the clojure way, instead of mutating the core pod adding a dependency, you can create a new pod with the new dependencies

onetom15:11:11

@micha: i just tried to preload the datomic.api into boot-test and that way my test run time is: > 0.3s * on a 2.7GHz i7 MBP * using the recommended BOOT_JVM_OPTIONS * Clojure 1.7 * Java 8 * BOOT_VERSION=2.5.0-SNAPSHOT (i ran this test: https://gist.github.com/bostonaholic/30e31f4620804632d3c8)

jaen15:11:41

@micha: any examples of doing that anywhere? I guess not since it's so fresh, but doesn't hurt to ask.

martinklepsch15:11:52

@micha: have any thoughts wrt. java.io.File serialization? https://github.com/boot-clj/boot/issues/250

martinklepsch15:11:37

@onetom: is it super slow without the preloading?

onetom15:11:58

but let me try

martinklepsch15:11:17

@onetom: I think a PR to boot test to supply extra namespaces for preloading might be appropriate: https://github.com/adzerk-oss/boot-test/blob/master/src/adzerk/boot_test.clj#L48

martinklepsch15:11:26

@micha where with ideas I mean impl suggestions 😄

martinklepsch15:11:37

Could really use it right now simple_smile

micha15:11:00

yeah i want to make a thing

micha15:11:04

like cljson

micha15:11:10

but instead of clj->json

micha15:11:18

it does clj->java objects

micha15:11:26

which can be sent to pods

micha15:11:38

that will fix all the pod serialization problems

martinklepsch15:11:02

can’t we just use nippy or something similar for it?

micha15:11:25

not really

micha15:11:31

we don't want to serialize

onetom15:11:47

@martinklepsch: sure, we touched on this point briefly with micha a few days ago, but i consider it being beyond my capabilities to design such a feature well (since im not very fluent in resolve and namespaced symbols and such basic stuff yet)

micha15:11:53

nippy just serializes to byte array

micha15:11:17

we want to be able to pass objects that don't necessarily implement Serializable interface

martinklepsch15:11:21

@onetom: no need for resolve. just add an option to the test task, parameterize the init fn and add additional require calls for the namespaces supplied to the option: https://github.com/adzerk-oss/boot-test/blob/master/src/adzerk/boot_test.clj#L14

micha15:11:29

which nippy can't do because it uses java serialization

martinklepsch15:11:47

@micha: what kind of objects would that be?

micha15:11:54

java objects

micha15:11:09

anyway nippy would be slower

micha15:11:28

and integrating it into boot would be difficult

micha15:11:33

we'd have to fork it

micha15:11:48

because boot itself can't have a nippy dependency

onetom15:11:05

@martinklepsch: yes, without preloading it takes 1.5s instead of 0.3s... that's exactly what it takes to make me a fall into the tolerating category as https://en.wikipedia.org/wiki/Apdex defines it simple_smile

martinklepsch15:11:33

@micha: couldn’t we stuff that in the worker or so?

micha15:11:55

it would need to be serialized to get into the worker

micha15:11:17

defeating the purpose

micha15:11:57

it would just be more complicated, slower, and have less capability

micha15:11:22

because we don't want serialization, everything is happening in the same memory space

micha15:11:41

the problem we want to solve is that pods can't use clojure objects from other pods

micha15:11:29

i initially solved the problem using serialization because it was the easiest option

micha15:11:35

@martinklepsch: about the repl in other pods thing

micha15:11:44

you can use the boot.core/launch-nrepl function

micha15:11:04

also the repl task now has a --pod option

martinklepsch15:11:31

@micha: repl in other pods? I don’t remember chatting about that?

martinklepsch15:11:02

@micha: makes sense re serialization

micha15:11:25

you asked about an example? i thought you were talking about starting a repl in a pod

onetom15:11:48

we talked about repls in pods a few days ago...

martinklepsch15:11:54

not that I remember 😄

micha15:11:14

oh sorry, it was @jaen

onetom15:11:17

because i was trying to get into our jetty process to access our in-memory datomic db

micha15:11:32

@onetom: yep, you can now do it!

onetom15:11:58

@micha: maybe after u released 2.5 simple_smile we are using too many experimental stuff already. i'm yet to upload our example of a loop-tpl bug in hoplon-6.0.0-alpha11 simple_smile

jaen15:11:14

@micha: I see, but that's limited to just the REPL right now, yes? So it won't help me with Clojurescript compilation for example, right?

micha15:11:07

jaen: you probably want to use boot show -p to see how the commons-codec conflict arises

micha15:11:24

then account for that in your dependencies

micha15:11:35

using exclusions etc

jaen15:11:49

Hm, that's an idea for a workaround, but sooner or later I will end with multiple exclusions if I keep hot-updating dependencies like that. Not saying this has to be solved right now, but maybe that's an use case that could be considered for the future (so tasks would run in pods that can be killed to update deps). Such seemingly automagical dependency upgrade feels really cool.

onetom16:11:33

I just pushed this but no notification here 😕 https://github.com/adzerk-oss/boot-test/commit/7b4b48beca51424fddd3c58de4cc2b2335d29fd8 I can't remember if it's on purpose or not. @micha: Should I setup an slack webhook for the adzerk-oss github org or that would be too much noise here?

onetom16:11:49

i've added the hook, but the ping payload haven't arrived here 😕

micha16:11:43

i think it's probaly ok to have the hook, if it gets noisy we can remove it

onetom17:11:00

im super impressed with this rolling pod-pool solution, btw it's a serious relief for me simple_smile im trying to integrate boot-test with visual studio code now, because the test runner functionality in sublime was not really nice.

jaen17:11:05

@onetom: oh, visual studio code has support for Clojure?

onetom17:11:47

not much, but it has parinfer support for a few days now and the syntax highlighting is part of it

onetom17:11:03

i had to hack the default clojure extension though to register the .cljs.hl and .boot file extensions:

sed -i '' -e '/extensions/r/"extensions": [".clj", ".cljs", ".cljx", ".clojure", ".edn", ".cljs.hl", ".boot"],/' '/Applications/Visual Studio Code.app/Contents/resources/app/extensions/clojure/package.json'

jaen17:11:58

If someone writes a plugin to debug Clojure with it, it could probably be a nice editor for noobs to start out with.

onetom17:11:01

jaen: what do u use now to debug clojure?

jaen17:11:43

Cursive.

onetom17:11:20

i keep falling back to either prints if there is no good test suite setup, but otherwise if the test suite can ran individual tests then i prefer to just evolve a mini example in form of a test

onetom17:11:56

that way my debugging session can be persisted into the source code simple_smile

jaen17:11:39

I cannot into tests to be honest. And I find Cursive's debugger to be invaluable in helping me understand the code. When I get a random cannot cast to IFn I wouldn't be able to understand what happened if not for the debugger.

onetom17:11:26

i've learnt the most from test suites, so that's why i like them, but it's indeed quite hard work to produce good tests.

onetom17:11:39

im learning it for the ~4th year i think

jaen18:11:50

Yeah, testing is hard. The worse thing is it's hard enough for me that I usually go "meh, I'll try testing next time". Each time.

jaen18:11:56

Nice. So you can just keep that running in the background and test things as you go?

onetom18:11:16

yup. and u get almost instantaneous feedback. almost like u were in the repl, BUT a, you can edit with a lot more convenience b, you don't have to worry about what the current state is, because your test would rebuild it every time from scratch