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

we've been using hoplon since like 2012 or so

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

yeah i remember the video, pretty cool

although it uses a react-style rendering loop

@naomarik: fedora/gnome

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

(I expected the Dropbox image to be inlined)

that's strange

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.

ah, this is a clue

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

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

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

if you paste the command line i can have a look

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

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

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…

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

cider is a mysterious thing to me

i plan to try spacemacs again soon though

i've been using vim

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

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(?).

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

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

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

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

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

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

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

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.

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

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

https://github.com/adzerk-oss/boot-cljs/wiki/Usage#options

Thanks @martinklepsch

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

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

thanks for the link, very useful

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".

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

(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)))

This might look familiar to you

That looks alright :)

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

good idea

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"

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

Error above sounds like it could be caused by various things

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

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

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

@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.

@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 ?

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

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

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

Hence the choice of words of ‘misleading’

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

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

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

(second one being me)

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

btw, I solved it using the runboot task from https://github.com/micha/multi-module-build/blob/master/build.boot

but it's considerably more involved

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

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

Thanks. I’ll have a look.

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.

what are you trying to do btw?

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

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.

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")}

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

Hmm, that doesn't seem to help : C

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

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

those are *not* on any classpath in boot

those belong to you alone, as the user

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

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

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

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

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

those are the directories that are actually on the classpath

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

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

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?

yes

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

haha yes i agree it's not obvious

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

because there are very few things analogous to pods

so there are some unfamiliar concerns

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

i believe this is unique to boot

so some things will be weird

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.

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

Sure

only tasks care about that distinction

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

so yes, docs

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

Ah. Same time

totes

Cool. Happy now.

i'll try to make a diagram

@cursork

a picture would be very useful for this

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

did you already update the wiki?

feel free to wikify at will

@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.

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

the pod is a lower level, simpler abstraction

the core pod is built on top of a normal pod

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

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

so the interface is inconsistent in that way

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.

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

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

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?

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?

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

@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

@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.)

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

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

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

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

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

pls take a look and feel free to correct

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

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.

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

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

so you can effectively remove dirs from the classpath this way

but not really of course

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

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

hm it's tricky

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

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

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

maybe a layered approach or something

break the harsh realities in stages

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.

yes!

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

haha it's maddening

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...

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

it was a frustrating experience

lol

trying to draw a picture of maybe

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!

but i'm not gonna go there just yet 😉

sounds interesting

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

is it a category theory thing?

I would look it up

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

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

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

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

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

what is that

explain like i'm five

ah right

@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

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

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

I gave a rough overview of the clojure concepts

eg. immutability/structural sharing

basically drew out the trie and showed how it worked

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

yeah probably

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

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

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

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

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

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

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

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

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

i guess AUFS is this more or less

that would be cool

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

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

I wonder if it's the same for others

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

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

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

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

that's actually the sign of a good design

vs. eg DI frameworks

or testing libraries

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

they have a huge surface area

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

javelin is a great example of a good design

javelin is easy to explain

thinking about it like spreadsheets makes it super simple

yes, because it resembles something that most people already know

bit imagine if spreadsheets didn't exist

and it follows the semantics

like the case of this fileset abstraction

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

yeah, have reached for that analogy

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

some people have not experienced that in any form

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

this should be a nonproblem

boot does require decent knowledge about clojure

thanks btw for the javelin praise, glad you enjoy 😄

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" #"^/" "") "/")) "")

@jaen: can you use sift :move?

i use it to add segments to my paths

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

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

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

Sure, no problem : )

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

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

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")}

{: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")}

Not sure what's up with that.

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

But not sure what to do about that : |

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?

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

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

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

@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.

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?

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?

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)"