Fork me on GitHub
#boot
<
2015-09-02
>
juhoteperi10:09:23

Eh, I tried to have circle ci run tests but boot show -d used over 4G of memory and build failed.

juhoteperi11:09:45

It worked on the second try 😮

martinklepsch12:09:50

@joelkuiper: have you tried boot-notify as a HUD replacement? https://github.com/jeluard/boot-notify

joelkuiper12:09:34

@martinklepsch: No I haven’t, thanks for the tip simple_smile that’s different from what figwheel does though, there you get an indication in the browser (also useful for monitoring the WebSocket conn)

martinklepsch12:09:32

yes I know, just thought that it’s actually not much different

pandeiro13:09:31

@juhoteperi: not a fix but as a workaround - if you run boot test help in the dependencies heading of circle.yml, wouldn't that download its deps?

pandeiro13:09:54

i am dealing with the same issue right now

pandeiro13:09:03

boot-http has the same thing

juhoteperi13:09:25

@pandeiro: Yeah that would work as workaround

pandeiro13:09:56

I have an --api arg to a task specified as type str but when I invoke boot mytask --api , it errors out saying ":api must be a string" -- what am I doing wrong?

martinklepsch13:09:24

@pandeiro: tried quoting?

pandeiro13:09:21

yep, quoting and not

pandeiro13:09:56

it's getting passed to (boot-cljs :compiler-options {:clojure-defines {'api ...}})

martinklepsch13:09:20

@pandeiro: can you paste your options vec

kirked14:09:44

@micha Would it be possible to plug in Ivy instead of Aether for dependency management?

martinklepsch14:09:53

@pandeiro: my guess is you’re missing the optarg: the 3. item here: https://github.com/boot-clj/boot/wiki/Task-Options-DSL#anatomy

martinklepsch15:09:19

Google’s Bazel site got a nice facelift: http://bazel.io/

onetom15:09:47

wondering how does it relate to nix... 😕

pandeiro19:09:18

@martinklepsch: you were right re: my issue btw; thanks simple_smile

martinklepsch19:09:44

@pandeiro: sweet simple_smile

martinklepsch19:09:53

@john_tollison: Gisting your build.boot file will help. Looks like your development task adds a dependency that’s not in any of the repos.

martinklepsch19:09:32

@pandeiro: the error message around that could be improved. If you’d log an issue that’d be awesome! simple_smile

john_tollison19:09:50

ok, that make me feel a little less clueless. I haven't logged any issues... I do this through github/boot-clj, issues, I guess? I'll try to do that later tonight as I don't have very long atm.

martinklepsch19:09:29

@john_tollison: sure, good luck! simple_smile

john_tollison19:09:16

any reason, off the top of your head that development would add a dependency, specifically when I add clj-firmata (arduino) library, BUT it's not an issue at the repl? What kinds of things is "development" likely to add?

martinklepsch20:09:24

@john_tollison: totally depends on your build.boot file

micha21:09:19

this is all i need in terms of environ

micha21:09:29

works across pods no problem

micha21:09:51

also 12 SLOC

rymndhng21:09:13

@micha: for your workflow, do you use uberjars — or do you always start apps using boot?

micha21:09:30

hi @rymndhng

micha21:09:45

we use uberjars for stuff like map reduce jobs and things like that

micha21:09:04

most things are dockerized with boot as the entry point

martinklepsch21:09:36

@micha: sweet!

rymndhng21:09:51

ah ok, cool. i was trying to muck with environ and boot the other day and I had a realization that if I put these env properties inside boot — I wouldn’t have gotten the same assertions if I were to start an uberjar, so I ended up sticking with environ + .lein-env + prismatic/schema

micha21:09:58

@martinklepsch: notice that even in cljs (env/def FOO) is getting the FOO env var at compile time from the environment or system properties

micha21:09:23

this is how we can configure our cljs applications from build.boot etc

martinklepsch21:09:32

@micha: yup saw that. wouldn’t use it from cljs though

micha21:09:40

similar to the google closure compiler vars you posted about

martinklepsch21:09:15

I think for the compiler to safely remove code things need to be marked as constants and that wouldn’t be the case here

micha21:09:33

oh interesting

micha21:09:40

there is const metadata i think

micha21:09:45

which could be applied here

martinklepsch21:09:53

Probably not enough

micha21:09:22

i guess my 5 vars will not be removed from my app, lol

martinklepsch21:09:31

emitted js needs to be something like this

/* @define {boolean} */
goog.define(“your-thing”, false)

martinklepsch21:09:05

5 vars will not be removed?

micha21:09:41

(def ^:const foo 123)

micha21:09:28

so you're saying it should emit goog-define for cljs?

micha21:09:40

i guess i don't understand what you mean about the tree shaking

martinklepsch21:09:40

It’s not doing that. Though in theory I’m thinking that something like ^const could map to the same emitted js as goog-define.

micha21:09:03

how would (def FOO "omg") interfere with tree shaking?

micha21:09:08

dead code elimination

martinklepsch21:09:36

not interfering, more that you cant remove dead branches from (if FOO …) (given FOO would be boolean)

martinklepsch21:09:21

Closure compiler just doesn’t support it.

micha21:09:28

how would it ever be able to do that though?

micha21:09:38

you need to annotate the var as constant, right?

martinklepsch21:09:09

Interestingly they also have a @const annotation

alandipert21:09:49

const seems like the winner, since if you tell the compiler FOO doesn't change then it can shake fof the else clause of that if at compile time

micha21:09:25

ah so goog-define is what you want then, i think?

martinklepsch21:09:17

Yes, probably. I guess the difference between constants and defines is that defines can be overridden via compiler-options at compile time

alandipert21:09:39

seems like the gclosure docs don't really account for what we can do, which is emit consts programmatically via macro

martinklepsch21:09:36

yeah. I’d be curious if ^const actually allows dead branch removal

alandipert21:09:05

i'm curious if it works on locals also

alandipert21:09:20

i suppose locals should already be const

martinklepsch21:09:55

@alandipert: what do you mean with locals?

alandipert21:09:32

like (function() { var x = 123; return function() {x = 321}})() is a possible thing in js

alandipert21:09:52

but locals aren't mutable in cljs, you can only mutate what they point at

alandipert21:09:40

i would imagine when you can return functions that can mutate variables "liveness" analysis is not entirely possible in all cases, but it seems like cljs would have an edge

alandipert21:09:57

since the locals never leak out of the closure, only their values at a point in time

alandipert21:09:22

anyway i'd be very surprised if david hasn't already shaved this yak simple_smile

martinklepsch21:09:53

(def ^const ^boolean my-const false)

(if my-const
  (js/console.log "my-const is true")
  (js/console.log "my-const is false"))
both console.log calls are in the advanced build.

alandipert21:09:30

is @const annotation emitted by cljsc?

martinklepsch21:09:46

I’m stupid sorry

martinklepsch21:09:09

It’s ^:const but ^boolean

martinklepsch21:09:27

Syntax is easy in lisp languages, you know?

alandipert21:09:51

in most of them, yes 😉

micha21:09:32

goog-define doesn't work for me at all with :advanced

martinklepsch21:09:35

So, @const is not emitted but dead branch is removed 😄

micha21:09:39

it emits like

martinklepsch21:09:11

if there’s a semi after the comment, update cljs

micha21:09:26

/** @define {string} */;

goog.define("foo.core.FOO", "omg");

micha21:09:22

interesting

micha21:09:58

i doubt that gcl can optimize anything with = in the if predicate

martinklepsch21:09:40

yeah I think it’s only for easy boolean stuff

micha21:09:47

(when (= FOO "omg") (.log js/console FOO))

Ob.a("omgz","omg")&&console.log("omgz");

martinklepsch21:09:53

even for the goog-define defined things you need ^boolean (for now)

micha21:09:08

yeah and booleans in the environment is nonsense

martinklepsch21:09:33

well, depends what you want to use them for

martinklepsch21:09:55

but yeah after compile time they’re not relevant

micha22:09:30

rube goldberg machines when it's such a simple problem

micha22:09:38

people make it way more complicated than it needs to be

micha22:09:51

all you need are keys and values, both strings

micha22:09:12

getting super fancy with env vars is not helpful

micha22:09:43

like clojure has vars already that are filled with features

micha22:09:02

get it out of env and into there and then you're good to go

micha22:09:05

using functions

martinklepsch22:09:06

fwiw the ^:const annotation isn’t even needed to remove the dead branch in the above example.

martinklepsch22:09:35

@micha: I was just hypothetically thinking about using them to strip dead code where booleans are handy.

martinklepsch22:09:48

I like that little env thing simple_smile

alandipert22:09:02

i did a lil experiment with local consts,

// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// @output_file_name default.js
// ==/ClosureCompiler==

function foo() {
  /** @const */ var pi = 3.14
  return (function(x) {
    pi = x;
    return pi;
  });
}

var f = foo(); //f is a function
alert(f);      //f is never called but we still get a warning about multiple assignment

alandipert22:09:09

without pi = x the code becomes alert(function(){return 3.14});

alandipert22:09:37

so, it appears to be really good at knowing when things are const automatically

martinklepsch22:09:13

how do you compile this example? is there some handy cli scripty thing?

alandipert22:09:16

very useful lil app

alandipert22:09:22

i think the guy who wrote the closure book made it

martinklepsch22:09:23

@micha: you should brag about the sloc in the readme 😄

micha22:09:11

@martinklepsch: lol

martinklepsch23:09:43

@micha: quick thought: when doing def it looks up the symbol you gave it without ns, but when you alter-var-root you need the fully qualified thing. Maybe that’s worth documenting.

micha23:09:30

@martinklepsch it should resolve the var in the namespace that calls the macro, no?

micha23:09:12

Ah documenting, I see now :)