Fork me on GitHub
#boot
<
2016-02-26
>
micha00:02:50

@naomarik: yeah alan and I have been doing the spreadsheet thing for a long time

micha00:02:12

we've been using hoplon since like 2012 or so

naomarik00:02:34

dunno if you saw, chris granger has a talk where he essentially shows all these iterations of what he was trying to build and at the very end he essentially comes the the conclusion that he should be making something around spreadsheets

micha00:02:08

yeah i remember the video, pretty cool

micha00:02:27

although it uses a react-style rendering loop

alandipert02:02:26

@naomarik: fedora/gnome

seancorfield03:02:16

Here’s an interesting little Boot puzzle… If I fire up a REPL from the command line in my project I can happily run merge-env! to load dependencies over and over with no problems. If I fire up a REPL in Emacs (via CIDER, using the same Boot tasks), any attempt to run merge-env! throws this exception from deep inside aether: https://www.dropbox.com/s/p121pq6jk7a03r5/Screenshot%202016-02-25%2019.28.20.png?dl=0

seancorfield03:02:20

(I expected the Dropbox image to be inlined)

micha03:02:58

that's strange

seancorfield03:02:15

If I start a CIDER-enabled REPL server from the command line in my project and attach a CIDER-enabled REPL client from another folder outside the project, that still works — I can run merge-env! no problem. So it’s not the presence of CIDER, as far as I can tell.

micha03:02:39

ah, this is a clue

micha03:02:56

it must be something about the command line options cider uses when it starts boot

seancorfield03:02:37

Any suggestions on what to look for / how to track that down?

micha03:02:59

you can do ps auxwww |grep boot in the terminal to see what cider started

micha03:02:09

if you paste the command line i can have a look

seancorfield03:02:22

Just for giggles, I started a CIDER-enabled REPL server on the command line and tried to just M-x cider-connect to it in Emacs and still had this problem… So it definitely looks like CIDER/Emacs connection issue

seancorfield03:02:30

That command doesn’t show me a process when I just use M-x cider-connect against an existing REPL server...

seancorfield03:02:30

That’s what’s odd about this… I can have two clients connected to the same REPL server, one from the command line and one from Emacs, but I only get this exception when trying to use merge-env! from inside the Emacs connection…

seancorfield03:02:57

Even just (merge-env! :dependencies []) fails via the Emacs-connected client...

micha03:02:27

cider is a mysterious thing to me

micha03:02:39

i plan to try spacemacs again soon though

micha03:02:52

i've been using vim

escherize04:02:46

Hello boot people! Fabulous tool as usual. shoutouts to Tenzing, and the modern-cljs tutorial(#1-3) simple_smile

escherize04:02:32

I'm having a particular issue with a file... it's called app.cljs.edn, and afaik it's the way to pass compiler options to the cljs compiler for a certain file(?).

escherize04:02:09

Anyways, I have to restart my boot dev task, whenever I change that file.

richiardiandrea04:02:41

@escherize as far as I can tell you can have a working solution, producing main.js, with no cljs.edn at all

escherize04:02:10

That's true, but I want to use the js directory for js!

escherize04:02:03

As well as understand the design descision behind the .cljs.edn files. The learning material I've gone through doens't describe the philosophy there and I'm curious

richiardiandrea04:02:33

In this I case I am going to wait for an answer too ;)

escherize04:02:12

Thanks.. Yeah I actually got it working lately, but I'd love to see it update automatically (like most everything else! 🍾 )

escherize04:02:48

$ cat resources/public/js/app.cljs.edn
{:require [bheartl.app]
 :init-fns [bheartl.app/init]
 :compiler-options {:asset-path "js/app.out"}}

martinklepsch06:02:50

The idea behind cljs.edn files is that other tasks in the pipeline can modify them which would be impossible if they're just task options.

martinklepsch06:02:30

For example the repl and reload tasks do this. @escherize @richiardiandrea

martinklepsch06:02:22

I think there's a table in the wiki describing what configuration you can do in which place and I think I remember that you can actually put compiler options in both places

escherize07:02:11

Thanks @martinklepsch

escherize07:02:43

My wish is that those files don't seem to be reloaded, I can make a repo to show what I mean

escherize07:02:08

basically, once a *.cljs.edn file is loaded, any edits to it aren't picked up in the boot dev task

escherize07:02:43

thanks for the link, very useful

martinklepsch07:02:52

I know what you mean I think. I'm not sure if reloading of cljs.edn files is intended but I think it should work as long as you don't modify the file before you're calling "watch".

martinklepsch07:02:26

If you're modifying it the changed version will take precedence if I remember correctly

escherize07:02:48

(deftask run []
  (comp (serve :dir "target/public")
        (watch)
        (cljs-repl)
        (reload)
        (build)))

(deftask development []
  (task-options! cljs {:optimizations :none
                       :source-map true}
                 reload {:on-jsload 'bheartl.app/init})
  identity)

(deftask dev
  "Simple alias to run application in development mode"
  []
  (comp (development) (run)))

escherize07:02:17

This might look familiar to you simple_smile

martinklepsch07:02:41

That looks alright :)

martinklepsch07:02:07

You could try adding a task that prints the contents of the cljs edn file to see if changes are picked up

escherize07:02:57

the reason I suspect that it was'nt picked up is that i coppied the .cljs.edn file contents from modern-cljs, heard a (speak) error, and got this error every time I changed the require from modern-cljs.core:

adzerk.boot_cljs.util.proxy$clojure.lang.ExceptionInfo$ff19274a: No such namespace: modern-cljs.core, could not locate modern_cljs/core.cljs, modern_cljs/core.cljc, or Closure namespace "modern-cljs.core"

martinklepsch07:02:14

If it doesn't work with the code you have there I'd suggest figuring out where it breaks and opening an issue suggesting the behavior you think is better + pointers for implementation

martinklepsch07:02:12

Error above sounds like it could be caused by various things

escherize07:02:00

That's true, but that was the only place that that synmbol existed in the project

escherize07:02:05

I'll definately have a look, thanks for your help @martinklepsch !

cursork10:02:24

How does :source-paths work with pods? My assumption from the docs is that I can specify a different :source-paths in the env for a pod? But that doesn’t seem to work. Fairly minimal example here: https://github.com/cursork/boot-source-paths/blob/master/build.boot

dm310:02:42

@cursork, nope, this seems to be a common problem point. Pods only look at :directories and :dependencies. It's like there are really two types of environments: Core env with :source-paths etc. and Pod env with :directories and :dependencies only.

cursork10:02:42

@dm3 thanks. I’m not sure how that lines up with "Isolated – pods can be created with arbitrary dependencies and classpaths” from https://github.com/boot-clj/boot/wiki/Pods ?

cursork10:02:03

And the fact that make-pod is meant to take a standard boot env? Docs might be misleading?

dm310:02:20

It doesn't lie - you get isolated :directories - classpath and :dependencies - the dependencies

dm310:02:42

but it's mighty confusing that changes to :source-paths and other dirs don't get propagated

cursork10:02:45

Hence the choice of words of ‘misleading’ simple_smile

cursork11:02:18

"Creates a new pod with the given boot environment env and returns it.” - implies to me I can use any standard env key.

dm311:02:47

yep, I think some sort of Pod env and Core env abstraction will get added

dm311:02:10

as you're the third person this week running into the same issue

dm311:02:16

(second one being me)

cursork11:02:32

Haha. Well. It feels good to not be the only one?

dm311:02:31

but it's considerably more involved

dm311:02:56

another option is to construct the :directories for the pod by yourself

dm311:02:39

runboot creates a pod which runs the whole new Boot environment inside

cursork11:02:44

Thanks. I’ll have a look.

cursork11:02:24

In the medium term I’ll probably just have my task run outside of pods, as that works. You lose all the advantages of pods of course, but I’m worried about sinking too much time in to being clean if the API doesn’t really support what I want to do.

dm311:02:13

what are you trying to do btw?

cursork11:02:27

I have UI tests in a separate directory to normal tests and they’re run by switching the classpath and running tests as normal.

cursork11:02:40

Is there a way to get a docs update… Since it’s a wiki page, it’s not going to be a PR? Just something that says that the env you pass to make-pod only respects changes to :directories and :dependencies would be great.

jaen12:02:10

Maybe I'm blind, but here goes nothing - is the usual modus operandi of boot-cljs-reload to pass filesystem path for reloading? I want to use it for reloading an app inside PhoneGap/Cordova, so it doesn't have access to the host filesystem, yet I get messages like

{:type :reload, :files ("/home/jaen/projects/xxx/mobile/target/public/assets/javascripts/application.out/xxx/mobile/application.cljs" "/home/jaen/projects/xxx/mobile/target/public/assets/javascripts/application.out/xxx/mobile/application.js.map" "/home/jaen/projects/xxx/mobile/target/public/assets/javascripts/application.out/xxx/mobile/application.js" "/home/jaen/projects/xxx/mobile/target/public/assets/javascripts/application.out/xxx/mobile/core.js")}
sent over websockets. Any way to ask it to give relative path?

jaen12:02:33

I imagine I could pwd and set that as asset path, but maybe there's some config option I'm missing?

jaen12:02:33

Hmm, that doesn't seem to help : C

micha12:02:57

@cursork: i think the confusion is over :source-paths and the classpath

micha12:02:11

:source-paths are directories in your project where your project files live

micha12:02:26

those are *not* on any classpath in boot

micha12:02:33

those belong to you alone, as the user

micha12:02:52

if those were on the classpath then task would be modifying or deleting your source files!

micha12:02:21

so there are two separate concepts: your source files that you want to have on the classpath and the actual classpath

micha12:02:46

boot copies your files into its own temp file store and puts *those* directories on the classpath

micha13:02:05

so if you do boot show --env you can see the :directories key

micha13:02:19

you'll see it has a set of anonymous temp dirs associated with it

micha13:02:29

those are the directories that are actually on the classpath

micha13:02:26

so giving a pod your project source directory is useless, because the worker in the pod should not be allowed to look in your project directories or touch anything in there

micha13:02:45

instead you configure the pod to use the temp dirs, which is the :directories key

cursork13:02:07

Well. That’s true I guess. But the effect of setting :source-paths with set-env! is to make those files available in those temp directories, no?

cursork13:02:44

I don’t think it’s an unreasonable misunderstanding to think the same effects might happen when making pods?

micha13:02:08

haha yes i agree it's not obvious

micha13:02:35

but i don't think it's really complicated, just not what you'd expect

micha13:02:51

because there are very few things analogous to pods

micha13:02:04

so there are some unfamiliar concerns

micha13:02:27

like the separation of your project files and the working set / classpath

micha13:02:33

i believe this is unique to boot

micha13:02:44

so some things will be weird

cursork13:02:05

I get that. I think on a superficial level I’d like things like :source-paths to have the intended effect. But I don’t know what that involves, and it’s likely there are big problems I don’t know about… So I’d more like something in the pods documentation saying that you change the classpath using :directories and the dependencies via :dependencies and that nothing else really has an effect? Since you explicitly state you are passing a normal boot env in… I expected all the normal effects.

micha13:02:05

yeah i mean there is no benefit to the distinction between source and resource for pods

micha13:02:13

only tasks care about that distinction

micha13:02:28

so i think it's best to not sugar coat it and add a mocking layer

micha13:02:45

so yes, docs

cursork13:02:46

So maybe just an extra sentence or two in the docs?

cursork13:02:51

Ah. Same time simple_smile

cursork13:02:07

Cool. Happy now.

micha13:02:22

i'll try to make a diagram

micha13:02:45

a picture would be very useful for this

mobileink13:02:14

@cusork @micha: sorry to but it, but i was thinking about this after my lesson with micah yesterday 😉

micha13:02:46

did you already update the wiki?

micha13:02:13

feel free to wikify at will simple_smile

mobileink13:02:43

@cursork, @micha: man, just woke up and cannot type. sorry to butt in - was thinking :source-paths does not really mean source paths, it means "marked with features [+IN,-OUT] after the initial snapshot is taken to create the initial fileset, which is a different concept. if you think of it that way then the meaning of :source-paths has little to do with the paths it lists, they're just parameters into a (purish) function, and there are no "source paths" once the initial fileset is created.

cursork13:02:58

Indeed. But one can also see a pod as a ‘fresh start’, where you’d go through the same initial process again.

micha13:02:03

the pod is a lower level, simpler abstraction

micha13:02:12

the core pod is built on top of a normal pod

micha13:02:30

the simplest abstraction of the classpath is a set of directories and jar files

micha13:02:04

and you're right, we do accept the :dependencies vector rather than just a set of jar file paths

micha13:02:15

so the interface is inconsistent in that way

mobileink13:02:16

true, i guess i was thinking of pods as already living in a purely bootish world where the initial fs is already there. so fresh start would mean fresh within that world, no relation to outside world (actual filesystem). i think.

micha13:02:57

but i think the main distinction is that your project files have no relation to any pod

micha13:02:15

the files they contain are copied to different directories that are managed by boot

cursork13:02:53

Yep. I understand exactly where you guys are coming from. But I needed to gain a little bit more 'boot knowledge’ to do so. It’s non-obvious to those not immersed in boot. Or at least I think so?

mobileink13:02:57

btw i notice that the Boot-Environment wiki page says that :resource-paths and :source-paths will be on the cp. does that need to be rewritten?

micha13:02:39

yeah to be precise i guess you could say that the files in there will be copied to directories on the classpath

mobileink13:02:02

@cursork: that's my experience. took me about a week to start to feel comfy. but i think it is possible to explain it in simple terms for newbies - project for a blog, someday

cursork13:02:12

@mobileink: yeah, I got comfy with most of boot quite quickly. This was my first time delving a bit deeper in to pods (changing classpath, etc.)

micha13:02:50

one issue with the :source-paths thing is that all of the directories in :source-paths are reduced to a single temp directory on the classpath

micha13:02:14

like if you have 100 dirs in :source-paths, the files in those dirs will all be in the same directory in boot's classpath

micha13:02:33

this is because once you add a directory to the classloader you can't remove it

micha13:02:57

so boot starts the main pod with a single directory to contain all input files

mobileink13:02:40

edited :resource-paths and :source-paths doc at https://github.com/boot-clj/boot/wiki/Boot-Environment

mobileink13:02:56

pls take a look and feel free to correct

micha13:02:16

the interesting thing about having the single directory in boot's cp is that you can add or remove source-paths

cursork13:02:18

Yeah. But it seems that when you set-env! a new directory is created with all the sources? Avoiding the normal purely additive classloader behaviour.

micha13:02:45

@cursork: no, that just sets up a thing to copy files from the new dir into the same single temp dir

micha13:02:22

so when you remove a dir from :source-paths it just stops copying files from that dir into the single boot cp dir

micha13:02:38

so you can effectively remove dirs from the classpath this way

micha13:02:41

but not really of course

micha13:02:00

but you can see how :source-paths isn't really the same thing as :directories

mobileink13:02:49

should the docs say that the :*paths should not be considered part of the env? even though they are specified within set-env! in build.boot

micha13:02:26

hm it's tricky

micha13:02:44

maybe we should implement :source-paths and :resource-paths for pods

mobileink13:02:45

or more correctly: the k-v pairs like :source-paths #{"srs"} are part of the env but that does not mean that the contents of "src" are

micha13:02:02

yeah it seems like it might be more confusing for new users

micha13:02:15

maybe a layered approach or something

micha13:02:24

break the harsh realities in stages simple_smile

mobileink13:02:51

yeah, its really key to understanding the whole thing, in a way: you manipulate stuff "on the surface" with your code but that gets translated into behind-the-scenes work - with tmp dirs/files now, but it could also be different impl, like datomic.

mobileink13:02:13

its fun to try to come up with a really transparent way of explaining boot. i'm convinced its possible, cause i think the core idea really is simple in the end

micha13:02:26

haha it's maddening

mobileink13:02:02

well, i've got some ideas, hope to find time for a blog post this weekend, then we'll see if i'm overly optimistic...

micha13:02:18

like one time someone who spoke a different language asked me what the word "maybe" means

micha13:02:30

it was a frustrating experience

micha13:02:07

trying to draw a picture of maybe

mobileink13:02:31

try "coinduction" - that's the other thing i'm currently working on. believe it or not i think it's the way to explain boot!

mobileink13:02:02

but i'm not gonna go there just yet 😉

micha13:02:04

sounds interesting

micha13:02:44

i studied math in college but i'm not familar with coinduction

micha13:02:05

is it a category theory thing?

jethroksy13:02:51

I would look it up

jethroksy13:02:01

but wikipedia says it's too difficult for people like me to understand

micha13:02:34

i'm scared to look it up becxause i have to go to work

micha13:02:54

i'll end up in mathworld for the next 5 hours

jethroksy13:02:58

I had a really hard time explaining boot to someone with no clojure experience

jethroksy13:02:52

so a ELI5 for boot would be cool (but possibly impossible)

micha13:02:05

what is that

jethroksy13:02:14

explain like i'm five

mobileink13:02:20

@micha: it emerged in logic, cat theory and compsci at different times - I'll be posting a blog about it sometime soon, it's extraordinarily cool

mobileink13:02:49

suggestion for :*-paths: deprecate them in favor of sth like (with-role #{"src"} {:input true :output false}), like with-meta.

alandipert13:02:43

@jethroksy: did you break through eventually? if so, how?

jethroksy13:02:15

I gave a rough overview of the clojure concepts

jethroksy13:02:23

eg. immutability/structural sharing

jethroksy13:02:36

basically drew out the trie and showed how it worked

jethroksy13:02:11

i don't think there's a way from going 0 -> boot without going through clojure

alandipert13:02:42

yeah probably

alandipert13:02:34

although i wonder if filesets aren't explicable starting with shell commands and by pointing out some things about them

alandipert13:02:48

like the fact that they don't "return" anything, and what if they did

alandipert13:02:30

i dunno, i leave a wake of perplexed students in my 5+ years of clojure overenthusiasm

jethroksy13:02:34

I'm not sure if there's a "right" way to think about filesets

alandipert13:02:35

i'm in no place to propose any teaching method lol

jethroksy13:02:27

I think of the fileset as just an immutable reference to files

jethroksy13:02:06

so idk what "don't return anything" actually refers to

alandipert14:02:41

like that rm doesn't return a new fs with the file removed, it mutates the implicit global fs

alandipert14:02:09

that would be kind of cool actually, an actual command line that was fileset-backed

alandipert14:02:49

i guess AUFS is this more or less

jethroksy14:02:21

that would be cool

jethroksy14:02:02

I feel like I don't actually understand anything until I look at it's internal implementation

jethroksy14:02:19

and then formulate based on that my "theory" of how it works

jethroksy14:02:38

I wonder if it's the same for others

jethroksy14:02:56

nothing goes into my head when someone tries to force a model into it

alandipert14:02:45

i feel that way also, although i think clj is one of the things i've gone furthest with without knowing how it works

alandipert14:02:51

like i couldn't sit down and write a HAMT, or the STM

alandipert14:02:06

i know vaguely the affordances, and that's enough to be super productive

dm314:02:14

that's actually the sign of a good design

alandipert14:02:27

vs. eg DI frameworks

alandipert14:02:37

or testing libraries

alandipert14:02:49

things with (sometimes) tremendous conceptual overhead that are dead-simple to implement

dm314:02:02

they have a huge surface area

alandipert14:02:34

i was thinking recently about how libraries like these compare to like... my postgres driver library

dm314:02:11

javelin is a great example of a good design

jethroksy14:02:26

javelin is easy to explain

jethroksy14:02:38

thinking about it like spreadsheets makes it super simple

dm314:02:42

yes, because it resembles something that most people already know

jethroksy14:02:44

bit imagine if spreadsheets didn't exist

dm314:02:48

and it follows the semantics

jethroksy14:02:00

like the case of this fileset abstraction

jethroksy14:02:10

the closest analogy is... a git repo maybe?

alandipert14:02:42

yeah, have reached for that analogy

dm314:02:06

you have to relate it to immutable state somehow, which depends on a student

dm314:02:16

some people have not experienced that in any form

alandipert14:02:21

yeah the backstop is "you could not step twice into the same river"

jethroksy14:02:45

this should be a nonproblem

jethroksy14:02:56

boot does require decent knowledge about clojure

alandipert14:02:22

thanks btw for the javelin praise, glad you enjoy 😄

jaen14:02:28

Sorry to interrupt, but :asset-path is kinda confusing me. It's supposed to be stripped from each file that's reloaded. I have paths like /public/assets/javascripts/application.out/xxx/mobile/application.js and I don't want that /public/ part at the start. It seems, according to the code of send-changed! a string "//public" should remove it, that is the following works in REPL:

(clojure.string/replace "/public/assets/javascripts/application.out/ourhub/mobile/application.js" (re-pattern (str "^" (clojure.string/replace "/public" #"^/" "") "/")) "")
but the websocket still sends files with /public/ at the front. I can't understand where I'm wrong '

mobileink14:02:08

@jaen: can you use sift :move?

mobileink14:02:39

i use it to add segments to my paths

jaen14:02:34

But I don't want to move anything, they are in the right place.

jaen14:02:41

They should be in target/public/… and I serve the contents of target/public and I want to let boot-cljs-reload know, that the files are relative to target/public

mobileink14:02:43

ah, ok. sorry, can't help with boot-cljs-reload (yet)

jaen14:02:54

Sure, no problem : )

jaen14:02:09

I don't have any problem locally, but when I try to do it cross-device it's kinda wonky.

jaen14:02:41

Okay, I am dumb as hell - those paths are relative, so it should've been public.

jaen14:02:00

But it's still weird. It now works on another PC as it should, but inside the emulator it doesn't. For some reason both browser get what I expect through the websocket:

{:type :reload, :files ("/assets/javascripts/application.out/xxx/mobile/application.js.map" "/assets/javascripts/application.out/xxx/mobile/application.cljs" "/assets/javascripts/application.out/xxx/mobile/application.js" "/assets/javascripts/application.out/xxx/mobile/core.js")}
but the emulator gets something else (at the same time):
{:type :reload, :files ("/home/jaen/projects/xxx/mobile/target/public/assets/javascripts/application.out/xxx/mobile/application.js.map" "/home/jaen/projects/xxx/mobile/target/public/assets/javascripts/application.out/xxx/mobile/application.cljs" "/home/jaen/projects/xxx/mobile/target/public/assets/javascripts/application.out/xxx/mobile/application.js" "/home/jaen/projects/xxx/mobile/target/public/assets/javascripts/application.out/xxx/mobile/core.js")}

jaen14:02:04

Not sure what's up with that.

jaen14:02:51

Oh, I see, the issue is from the browser I get http: for procotol, from the emulator I get file:.

jaen14:02:57

But not sure what to do about that : |

jaen15:02:38

Ok, shouldn't :set-protocol depend on the protocol :asset-host option has and only if that is not set, then on the window.location.protocol?

jaen15:02:08

I don't know if it's the proper solution (I don't know what's the intent behind switching on protocol there) but this helped - https://gist.github.com/jaen/beee2c02b59674b81cdc

jannis16:02:52

@martinklepsch: Is cljsjs/boot-cljsjs expected to work with boot 2.5.5?

jannis16:02:03

I was just trying it with a JS library that I want to integrate in a project of mine and I think it fails pulling in clj-http: https://gist.github.com/Jannis/67837ce259dd5068a018

jannis16:02:44

@martinklepsch: I cloned boot-cljsjs and made it depend on [clj-http "2.1.0"] (the latest version) and that gets past the error. I have no idea how compatible the two versions are overall though.

hlolli23:02:24

Is there any obvious reason for why I can't connect to boot (cljs-repl) from cider-connect, if I give right port? It starts connecting but then I get timeout. Or is there a better way to connect to repl started via boot?

hlolli23:02:09

Ok problem found, boot-cljs-repl was set at 0.2.0 but is currently at 0.3.0 maybe @martinklepsch could update the template for tenzing?

hlolli23:02:56

no this actually wasn't the reason, sorry for talking to myself like that.... "nrepl-send-sync-request: Sync nREPL request timed out (op clone id 1)"