Fork me on GitHub
#boot
<
2015-07-06
>
mitchelkuijpers09:07:25

(cljs-repl)
Connection is null
Writing boot_cljs_repl.cljs...
#object[clojure.core$comp$fn__4495 0xea7623c "clojure.core$comp$fn__4495@ea7623c"]

mitchelkuijpers09:07:59

Hi I have a hard time getting the cljs-repl to work 😞

mitchelkuijpers09:07:51

I am using it with boot-reload could that have anything todo with it?

meow12:07:30

@mitchelkuijpers: I've got boot-cljs-repl working with boot-reload and am trying to squash remaining bugs. Can you post your boot.properties and build.boot files, here or on refheap?

estsauver13:07:45

Hey there, is anyone using Boot with cljs.test and karma?

martinklepsch13:07:10

@meow: if you feel inclined, a PR to tenzing with the updated repl stuff etc would be most welcome :)

meow13:07:22

I just updated boot-cljs-example to use the latest and greatest

meow13:07:30

@martinklepsch: I'd like to go from "0.1.10-SNAPSHOT" to "0.1.10" first.

meow13:07:06

I think the code needs some improvements and I want to make sure it's working for everyone.

micha13:07:31

:thumbsup:

meow13:07:33

Maybe the plan should be something like this. Make sure we've gotten the major bugs out so we can push a "0.1.10" version out the door to fix the problems everyone has been having. Then we migrate the dependency version checking out of boot-cljs-repl and boot-cljs and into boot itself. I believe @micha and @juhoteperi are on board with this. Then we can push out a "0.1.11" that's nice and solid.

meow14:07:07

Anyone have suggestions on the best way to develop a cljs library using boot? Specifically, I have a cljs app that I use boot to run that uses boot-cljs-reload, which works great. But now I moved some of my code into a shared library that I also manage using boot to do a build-jar and locally install. What I'm missing is the automatic recompile/reloading of my app when I change/reinstall the library. Suggestions?

meow14:07:36

Would be nice if I could maybe change my app dev classpath so that it picks up the library file right out of my local git repository.

meow14:07:16

Would be even nicer if watch picked up changes to the library file, just like it used to when it was part of my app.

juhoteperi14:07:52

@meow: checkout task should work for that

meow14:07:21

@juhoteperi: That would get me close, but I'd have to have that second boot process that was watching and rebuilding the jar file. Is there any way to avoid that?

meow14:07:11

I'm going to guess that there isn't...

juhoteperi14:07:29

I don't think so

meow14:07:52

And yet when this file was part of my app it was so easy.

juhoteperi14:07:59

And as the library boot process doesn'ẗ need to do cljs compile it should be quite fast

juhoteperi14:07:40

I even think this is better way, Leiningen checkouts work so that it adds the source paths of checkout lib to main project which causes loads of problems with configuration

meow14:07:28

It's just more steps that I have to take every time I work on this project because the library and app are being developed together.

meow14:07:36

What you describe as the Leiningen way was what I was thinking I might be able to do but, yeah, that might just create a different kind of headache for me.

juhoteperi14:07:52

I'm yet to test boot checkout so I don't know about the performance etc. but in theory I think it should work 😄

meow14:07:27

This task facilitates working on a project and its dependencies at the same
  time, by extracting the dependency jar contents into the fileset. Transitive
  dependencies will be added to the class path automatically.
  
  You'll need at least two boot instances---one to build the dependency jar and
  the other to build the project. For example:
  
      $ boot watch pom -p foo/bar -v 1.2.3-SNAPSHOT jar install
  
  to build the dependency jar, and
  
      $ boot repl -s watch checkout -d foo/bar:1.2.3-SNAPSHOT cljs serve
  
  to build the project with the checkout dependency [foo/bar \"1.2.3\"]."

micha14:07:15

pkobrien: the biggest difference between boot checkout and lein is that the boot one cleanly separates the checkout dep's build from your project build

micha14:07:26

your project just consumes a jar that changes over time

micha14:07:36

this is crucial when the checkout build is nontrivial

juhoteperi14:07:44

@micha: Does the checkout task jar unpacking for each build? Or only when jar has changed?

micha14:07:48

otherwise you have to essentially merge the two builds

micha14:07:58

only when the jar has changed

juhoteperi14:07:48

I'm trying to understand how the task sees when the jar file has changed

micha14:07:21

the jar is added to :source-paths

micha14:07:45

boot uses the aether machinery to resolve the jar and its transitive dependencies

micha14:07:57

it adds the transitive dependencies to the project deps

micha14:07:07

then it finds the checkout jar location in .m2

juhoteperi14:07:07

Ah the .m2 dir where the jar is?

micha14:07:15

and adds the .m2 dir to the :source-paths

micha14:07:29

and it explodes the jar into the fileset

micha14:07:38

so watch does what you expect

micha14:07:13

but separating the checkout build from the project build is a key thing i think

micha14:07:25

because this keeps your project build.boot pristine

juhoteperi14:07:30

Yeah I don't see a problem with that. Boot process takes so much less memory than leiningen etc. that running multiple boots shouldn't be a problem.

meow14:07:46

okay, so on the library side, right now I've been doing a build which is a comp of (pom) (sift) (jar) (install)

meow14:07:14

but there is a way to watch that and redo the install, right?

micha14:07:39

(watch) (pom) (sift) (jar) (install), no?

meow14:07:13

sweet - for some reason I thought there was something else in bootlaces

micha14:07:27

you can compose the watch task with anything

micha14:07:59

all it does is watch the project dirs and call the next handler when they chance

micha14:07:07

the next handler could be anything

meow14:07:32

gotcha - this boot stuff is really great

meow14:07:27

It really starts to become a vocabulary.

meow14:07:43

Like, I was going to add a task to my build.boot file but I just figured it would be easier to just do boot poly build if I want it to run one time and boot poly watch build if I want it to sit there rebuilding as I work.

meow14:07:44

No need to change my file and the more I learn the built-in vocabulary the easier it gets (and I do mean easier).

meow14:07:15

And I still like driving multiple projects from my one libary repo with one build.boot file as it is making it so much easier to keep in my brain.

meow15:07:03

Notice that I have one repo for cljs libraries and another repo for cljs apps.

meow15:07:13

So my repo approach is somewhere in between one monolithic repo and a separate repo for each.

meow15:07:55

I'm doing one shared repo for each type of code.

meow15:07:54

Now in my app build.boot I have this main task that I use:

(deftask dev []
  (comp (serve)
        (watch)
        (speak)
        (reload)
        (cljs-repl)
        (cljs :source-map true :optimizations :none)))

meow15:07:49

Not quite working for me with this:

(deftask dev []
  (task-options!
    checkout {:dependencies [[ion/cuss:"0.1.0-SNAPSHOT"]
                             [ion/poly:"0.1.0-SNAPSHOT"]]})
  (comp (serve)
        (watch)
        (checkout)
        (speak)
        (reload)
        (cljs-repl)
        (cljs :source-map true :optimizations :none)))

meow15:07:25

java.lang.RuntimeException: Invalid token: ion/cuss:

meow15:07:22

without the colons in the dependencies I got this error: clojure.lang.ExceptionInfo: No such namespace: ion

micha15:07:40

pkobrien: you don't need the colons, you just need to quote the dependencies vector

micha15:07:12

(task-options!
    checkout {:dependencies '[[ion/cuss "0.1.0-SNAPSHOT"]
                              [ion/poly "0.1.0-SNAPSHOT"]]})

micha15:07:46

man, we kind of nerfed the :dependencies thing in boot i guess

micha15:07:04

we should be accepting like

(set-env! :dependencies [[:ion/cuss "0.1.0-SNAPSHOT"] ...])

micha15:07:20

no reason to use a symbol if it's not going to be evaled

meow15:07:17

I've wondered why dependencies and require needed to be quoted.

meow15:07:04

So now my task mostly works, but I did get this error:

Checking out poly-0.1.0-SNAPSHOT.jar...
Checking out cuss-0.1.0-SNAPSHOT.jar...
java.io.IOException: Couldn't delete C:\Users\Patrick\.boot\cache\tmp\Users\Patrick\code\decomplect\ing\informing\4f8\7o
2s6s\cuss-0.1.0-20150704.164132-1.jar

meow15:07:56

Stopped it and restarted and no error.

meow15:07:33

I think this is related to some problem I saw in one of the issues about a timing problem on windows.

martinklepsch15:07:43

@meow: are you on windows?

meow15:07:54

So, changing my library file and saving it isn't triggering a reload in my app, because the watch process for building my library jar keeps erroring out

martinklepsch15:07:52

Are things mostly working though? :)

meow15:07:57

but my new use of boot poly watch build is borked

martinklepsch15:07:02

What's poly? 😊

meow15:07:16

poly is the library

meow15:07:25

and a task

martinklepsch15:07:53

I don't think I'll be able to help really, basically just hanging out w/ my iPad on a couch :D

meow15:07:54

Here is the error I'm getting:

C:\Users\Patrick\code\decomplect\ion [master +0 ~2 -0]> boot poly watch build

Starting file watcher (CTRL-C to quit)...

Writing pom.xml and pom.properties...
Sifting output files...
Writing poly-0.1.0-SNAPSHOT.jar...
Installing poly-0.1.0-SNAPSHOT.jar...
Elapsed time: 0.695 sec

java.io.IOException: Couldn't delete C:\Users\Patrick\.boot\cache\tmp\Users\Patrick\code\decomplect\ion\66g\gg42n1\poly-
0.1.0-SNAPSHOT.jar
                 io.clj:  426

martinklepsch15:07:27

Tried with -vv?

micha15:07:59

pkobrien: i don't know if this will help you, but i think these problems are fixed in windows 10

micha15:07:34

flyboarder dropped by on IRC and reports using boot on windows 10 with no problems

meow15:07:46

I'm stuck on an older machine at the moment, so windows 10 is not an option

martinklepsch15:07:48

In line 35 better use version

martinklepsch15:07:22

Not fixing anything but small typo could break things as they are

meow15:07:56

@martinklepsch: good catch - tyvm

meow15:07:57

so, funny enough, running with -vv seems to fix the problem, at least once

meow15:07:56

but then on subsequent saves of my source file I'm back to having nothing but errors

meow15:07:17

-vv doesn't report anything more useful than without it

juhoteperi15:07:16

@podviaznikov: Pegdown (and now Endophile) creates something like this:

(is (= [[:h1 [:a {:name "foo" :href "#foo"} "Foo"]]]
       (md2h/to-hiccup (mp "# Foo" {:extensions {:anchorlinks true}}))))

juhoteperi15:07:06

I wonder if it would be more useful it the header text was not wrapped in anchor

meow15:07:15

so, it looks like watch and build-jar are not going to work on my windows machine

juhoteperi15:07:27

@martinklepsch: I havent tried aside tag

meow15:07:33

which means checkout isn't going to work for me either

martinklepsch15:07:41

@meow: could it be that you're missing the install task?

meow15:07:54

at least watch and cljs and cljs-repl mostly work

martinklepsch15:07:04

Or is build = build-jar from bootlaces?

juhoteperi15:07:19

@martinklepsch: Might be good if you pinged sirthias in twitter about that, I asked him today to make a new release because anchorlinks is broken in release but fixed in master

micha15:07:57

pkobrien: maybe docker or vmware or virtualbox to run boot in linux?

meow15:07:11

build is (comp (pom) (sift) (jar) (install)) and it only breaks when I try to add watch

juhoteperi15:07:29

martinklepsch: Did you test pegdown directly or through endophile?

martinklepsch15:07:07

@juhoteperi: don't exactly remember tbh, probably through endophile

juhoteperi15:07:32

martinklepsch: Endophile is currently using historical version of pegdown. But I can reproduce the problem with latest version.

martinklepsch15:07:44

Also I had a hard time just figuring out how to install it into my local m2

juhoteperi15:07:56

sbt package && cp ....

martinklepsch15:07:07

@juhoteperi: yeah, I also tried master and whatnot

juhoteperi15:07:19

I think sbt only has build in command to install into local ivy repo

martinklepsch15:07:15

I found something that day, but don't remember now

juhoteperi16:07:20

Interestingly pegdown & parboiled don't really depend on anything where I think that error would come from

juhoteperi16:07:19

@martinklepsch: The problem is in endophile.

juhoteperi16:07:02

jtidy doesn't know about those tags

juhoteperi16:07:14

I'm not quite sure even why it's used there

micha16:07:31

yeah i don't use it in my pegdown thing

juhoteperi16:07:16

One comment test just broke when I removed tidy

micha16:07:17

pure ast approach

micha16:07:30

using the ever popular deep-bean

micha16:07:44

the very deepest of beans

micha16:07:52

lol @java

meow16:07:12

In my library build.boot I'm setting :resource-paths #{"src/ion/poly"} but when I run boot -vv poly build I see that boot is poking around into directory branches that I don't expect it to:

C:\Users\Patrick\code\decomplect\ion [master +0 ~3 -0]> boot -vv poly build
←[1;36mregistering src [:create :modify]
←[m←[1;36mregistering src\ion [:create :modify]
←[m←[1;36mregistering src\ion\cuss [:create :modify]
←[m←[1;36mregistering src\ion\poly [:create :modify]
←[m←[1;36msending change event
←[mSyncing project dirs to temp dirs...

micha16:07:06

pkobrien: you have "src" in there somewhere i think

juhoteperi16:07:16

@meow: bootlaces adds src to paths

micha16:07:19

i think bootlaces does that

meow16:07:23

I don't know what boot means when it says it is registering a directory, but why is it doing that for src and src\ion and src\ion\poly

micha16:07:48

yeah the workaround for you could be to just move that dir to "source" or something other than "src"

meow16:07:30

Yes, I did add bootlaces to the mix recently.

meow16:07:56

I don't like the sound of that.

meow16:07:55

bootlaces shouldn't do that

meow16:07:57

it seems to go against the philosophy of boot

meow16:07:39

And there is no way to configure it since it's just hardcoded in there:

(defn bootlaces!
  [version & {:keys [dev-dependencies]}]
  (merge-env! :resource-paths #{"src"})

meow16:07:33

Can't that be a parameter at least?

micha16:07:47

i mean bootlaces isn't supposed to be a general purpose library

micha16:07:56

it's a thing for adzerk to automate some stuff

micha16:07:11

it's our specific individual workflow

micha16:07:39

you could just undo it if you want

micha16:07:00

(set-env! :resource-paths #(disj % "src"))

micha16:07:17

or perhaps the bootlaces! function could take a flag option or something

meow16:07:24

@micha: but what it does is so useful

meow16:07:59

I mean bootlaces is useful and 99% generic, or so it seems to me - it certainly made it easy to push to clojars

meow16:07:18

I know the readme says to fork it, but that seems wasteful

micha16:07:25

yeah we could remove that part i guess

micha16:07:31

the (merge-env! ...) thing

meow16:07:21

I can understand it not being part of boot.core, but what it provides is surely fundamental for anyone writing a library

meow16:07:10

or writing boot tasks for general consumption, which is why it is used so much in the wild

meow16:07:36

cool that I can undo it, thanks for that code

juhoteperi16:07:16

Or maybe some clojars tasks could be introduced in boot core, then bootlaces wouldn't so necessary

micha16:07:15

deraen: yeah i think the functions for getting creds interactively and whatnot might be useful in boot core

juhoteperi16:07:03

Hah, I wrote my own html tidier for endophile tests 😄

juhoteperi16:07:21

9 lines with postwalk

meow18:07:36

Not to bash figwheel, but I must say I really don't like the idea of the ^:figwheel-always meta data.

meow18:07:18

I don't think source code should contain a tool-specific thing like that.

meow18:07:57

Especially since there's already an on-load event that can handle the same issue.

meow18:07:04

I just see that metadata in a lot of cljs apps and every time I think "But what about me? I use Boot. Don't you like me?" 😉

meow18:07:13

I mention figwheel because I just read the Quick Start guide to see if boot was missing any figwheel features and nothing really jumped out at me.

meow18:07:10

It looks like figwheel is more capable from one jvm where in boot we need two: one to serve the app and another for the browser repl.

meow18:07:18

Is there anything boot/boot-cljs/boot-cljs-repl is missing from what is possible with the current state of cljs tooling?

timothypratley18:07:42

I am still using figwheel because of the HUD, I find it useful.

timothypratley18:07:27

It has a little bit more information (warning and line number) than the boot voice, and leaves out the ridiculous stack traces of the console.

meow18:07:21

@timothypratley: good point, yes.

meow18:07:55

Just to be clear, I think figwheel is great. I'm just trying to make sure that boot is on an even playing field. I have no personal desire to work on a HUD. I mostly just want to make sure boot isn't broken any more when it comes to cljs, since the situation was in a bit of flux for a while there due to all the upstream changes.

juhoteperi18:07:49

Would be cool if non-tools specific parts (client) of figwheel could be separated and used with boot also

juhoteperi18:07:36

I remember bhauman looking into that (or in general, how easy it would be to create boot-figwheel)

timothypratley19:07:32

simple_smile cool FWIW boot has some major advantages I am really excited about it and am using it in some cljs projects and find it is better. Just mentioning the HUD because yeah I’m hoping bhauman or someone will port it simple_smile I think I saw a tweet or something that he was working on it while at Clojure West so haven’t looked further.

micha19:07:36

deraen: i couldn't really see what it would do

juhoteperi19:07:50

@micha: The figwheel client has to HUD parts etc.

micha19:07:05

oh, i see

micha19:07:14

does it use browser notifications api?

juhoteperi19:07:28

Nope, just a absolute positioned div or something like that

micha19:07:31

we could add that to the boot reload client of course

juhoteperi19:07:54

Sure we could implement everything ourselves

micha19:07:00

browser notification api would be the way to do it, right?

juhoteperi19:07:18

I doubt notifications can show complete stacktraces

juhoteperi19:07:09

But notifications + some DOM to show stacktracers would be cool

juhoteperi19:07:58

Does boot-reload have logic to skip reloads if build had errors? If cljs task has errors the next tasks won't be called?

micha19:07:16

yeah it skips reloads when exception is thrown

micha19:07:58

although reload task could of course catch the exception when it calls the next handler

micha19:07:08

and send info down the websocket pipe

micha19:07:12

and then re-throw

meow19:07:29

(serve) (watch) (checkout) (speak) (reload) (cljs-repl) (cljs)

meow19:07:54

should that instead be (serve) (watch) (checkout) (speak) (cljs) (reload) (cljs-repl)

meow19:07:37

I don't feel like I have a good handle on how these tasks could/should be ordered.

martinklepsch19:07:28

@juhoteperi: thanks dir looking into the pegdown stuff, makes perfect sense now that I see it. Had a hard time tracing down where that warning comes from :/

martinklepsch19:07:56

@meow: repl needs to be before compilation

martinklepsch19:07:07

It adds things to the compiled is

micha19:07:25

martinklepsch: i thnk we fixed that, maybe? the ordering?

micha19:07:45

i think it might be creating the cljs files before the pipeline is composed

micha19:07:56

maybe not, disregard me

micha19:07:17

i haven't used the cljs repl in a while simple_smile

meow19:07:53

I'm consistently getting errors using checkout: java.io.IOException: Couldn't delete one or more jar files

micha19:07:55

pkobrien: i think that's a windows issue where it doesn't let boot delete files when there are open input streams

micha19:07:38

a lot of java code relies on the finalization before garbage collection to close streams

micha19:07:59

and there isn't a reliable way to force garbage collection either

micha19:07:11

so i'm not sure how to fix that

meow19:07:50

@micha: well, I know way less than you do so I'll just live with it

meow20:07:29

does figwheel do an implicit/behind-the-scenes (require '[app.namespace]) thus allowing users of its repl to simply do in-ns 'app.namespace?

meow22:07:47

Check this out, though. Figwheel does do some work behind the scenes in its repl:

This REPL is a little different than other REPLs in that it has live compile information from the build process. This effectively means that you will not have to call (require or (load-namesapce unless it is a namespace that isn't in your loaded application's required dependencies. In many cases you can just (in-ns 'my.namespace) and everything you need to access will be there already.

meow22:07:22

I wonder if the same could/should be done for boot-cljs-repl?

meow22:07:42

I'm not sure if :analyze-path is what figwheel uses or not.