Fork me on GitHub
#clojurescript
<
2015-10-22
>
juhoteperi13:10:49

@bhauman: Should devcards work without Figwheel just by calling start-devcard-ui! and defining some cards? I'm seeing the UI but no cards.

chedgren13:10:48

deraen: Using Om?

chedgren13:10:08

deraen: nvm, i cant read

bhauman13:10:21

@derean the bottom of the readme gives the deets on how to use it without figwheel

bhauman13:10:22

@juhoteperi: one peice of it is that you have to have :devcards true in the compiler options

juhoteperi13:10:27

Well, now it started working, though I don't think I changed anything šŸ˜„

domkm18:10:12

Do Google Closure's logging facilities support accurate line numbers and source maps?

dnolen18:10:16

I doubt it since logging is mostly a dev time thing

dnolen18:10:24

but I havenā€™t checked this myself

dnolen18:10:16

and by dev time I mean that Google JavaScript devs probably donā€™t benefit from this so I would be surprised if this facility was there

dnolen18:10:32

also not sure how it would even work given JS has no reflective capability with respect to source locations at runtime

domkm18:10:24

I was hoping they might do something like this https://gist.github.com/bgrins/5108712 to keep line numbers

domkm18:10:28

Oh well, thanks

mfikes19:10:53

Is ā€œAOT ClojureScript libsā€ a thing? (Meaning the JavaScript, analysis cache, source maps, etc. included in the JAR for a given lib.)

thheller19:10:33

no and it really should not be

thheller19:10:00

it would only produces nightmares .. eg. jars compiled/created with different cljs version than you are using

thheller19:10:25

aka. invalid everything anyways

mfikes19:10:53

Right, that's true. I'm mentally noodling on a way to AOT Clojure macros in a ClojureScript lib so the lib is consumable by self-hosted environments.

mfikes19:10:26

I know today we only AOT the std lib

thheller19:10:58

FWIW I even hate that that exists ... I really don't see the point to it excepts headaches

thheller19:10:32

I think proper caching so things only get compiled when needed but by the user

thheller19:10:48

is far superior to doing it when packaging the jar

mfikes19:10:01

Yeah, the real underlying issue I'm noodling on is the fact that self-host is different than conventional ClojureScript with respect to macros, and what that means for lib consumption.

thheller19:10:13

yeah self-host is crazy complex

mfikes19:10:32

AOT is a less-than-ideal avenue to a solution. Was just wondering if it even existed.

thheller19:10:31

the cljs.core aot has some special hooks that enable it

thheller19:10:57

probably doesn't work for anything else

dnolen19:10:28

@mfikes: @thheller: I completely disagree with this assessment

dnolen19:10:50

as the dev cycles get longer AOT libraries becomes more and more attractive

dnolen19:10:20

ClojureScript codes bases are already crossing into the 20-30K area, and I would not be surprised if there are things people havenā€™t talked about publicly that are bigger than that

dnolen19:10:50

if all your deps are AOTed dev becomes instant

thheller19:10:52

yeah but you do not need to compile something twice if it sits in a jar

dnolen19:10:12

longer than 1min cold builds because of dependencies is not fun for anyone

thheller19:10:13

as files in jars don't change, only if you get another jar

thheller19:10:42

again the FIRST build, every following build can used the cached stuff

dnolen19:10:59

except for various reasons people have to blow away the cache

dnolen19:10:05

and some people just do it all the time to avoid headaches

thheller19:10:13

yeah well ...

thheller19:10:41

that means caching should be fixed

thheller19:10:47

not working arround the problem

dnolen19:10:54

in anycase AOTed stuff is not out the question in the long run

dnolen19:10:00

caching and AOT are just orthogonal things

dnolen19:10:05

unrelated both beneficial

dnolen19:10:11

conflating them is pointless

thheller19:10:25

I totally disagree there are sooo many issues with AOT

thheller19:10:39

:emit-constants, :static-fns, etc.

dnolen19:10:52

Iā€™ve said as much as Iā€™m going to say about the matter, itā€™s something to think about

thheller19:10:53

so if anything doesn't match you cannot use the AOT anyways

dnolen19:10:07

Iā€™ve just seen enough big code bases where I know itā€™s problem

dnolen19:10:10

and caching wonā€™t fix it

thheller19:10:30

I'd take that challenge with shadow-build ...

dnolen19:10:53

and realize that multi-billion dollar companies have not figured this out

thheller19:10:12

there are points where caching is not possible (ie. :emit-constants) but AOT isn't as well

mfikes19:10:54

If we did have AOT, and it extended to macros, producing things like foo$macros.js, that could lead to a strange way for self-hosted environments to consume libs that would not otherwise be possible to consume owing to the use of Clojure macros that can't compile as ClojureScript. Not a well baked thought, but that was my reason for asking about it. :)

dnolen19:10:42

to be clear Iā€™m a fan of the existing model provided by Maven and :classifier here

dnolen19:10:49

you should always ship source

dnolen19:10:03

but :classifier ā€œaotā€ is nice

dnolen19:10:39

@mfikes: in your case I could imagine :classifier ā€œaot-cljsā€ or something like that.

mfikes19:10:53

@dnolen: I don't even think AOT macros would work... If some Clojure macro invokes some crazy Java code at compile-time there's no way AOT could produce equivalent JavaScript for self-host use

dnolen19:10:53

@mfikes: right thereā€™s going to be stuff that doesnā€™t work, but thatā€™s a barrier thatā€™s not worth crossing anyway

dnolen19:10:18

most stuff like that is tooling stuff and Iā€™ve already expressed by deep skepticism about recreating all the tooling we already have again in JS

bensu19:10:48

@dnolen: @mfikes (sorry to jump in) I agree with the tooling on the JVM side, but I think bootstrapped cljs has promise when it comes to "cleaning up" js tooling (grunt, gulp) which I find unbearable.

bensu19:10:56

I imagine a node based workflow to produce/wrap node based frontend tooling.

bensu19:10:12

e.g., asset management

thheller20:10:05

I don't get why people fear the JVM so much šŸ˜›

thheller20:10:19

running CLJS on other hosts is great

thheller20:10:33

but compiling it?

bensu20:10:14

my problem with the JVM is that I have an old machine which freezes if I have 2 JVMs running

bensu20:10:43

so, tooling-wise, I want stuff to be more light weight

bensu20:10:07

but moore's law (or whatever is left of it) might take care of that

thheller20:10:46

must be a really old machine simple_smile I have 8 JVMs running + IntelliJ without hickups

blissdev20:10:57

how much ram ooc?

thheller20:10:20

well I have to admit ... starting a new JVM sucks .. that takes way too long simple_smile

thheller20:10:06

how do om/reagent/other-cljs-react-wrapper users deal with the fact that passing callbacks breaks shouldComponentUpdate since it never (= prev-props next-props)?

dnolen20:10:09

they don't

thheller20:10:29

so just render everything every frame?

dnolen20:10:33

but Om Next is not a render from the root model anymore so I think not a big deal for Om Next

dnolen20:10:09

I canā€™t imagine this was ever a problem for Reagent programs that use Ratoms

thheller20:10:33

well if you render A for whatever reason, that embeds B and passing a callback to it ... rendering A will now always cause B to render

thheller20:10:34

trade-offs everywhere ...

dnolen20:10:36

but re-rendering is just not something to be concerned about IMO

dnolen20:10:42

especially if the underlying thing can minimize it

dnolen20:10:05

@thheller: that said another thing is that Clojure(Script) already has a solution to this problem.

dnolen20:10:37

but generally speaking you want re-renders to occur if views or callbacks change

thheller20:10:48

well the optimization would be to not re-render B

thheller20:10:08

no the callback doesn't change

thheller20:10:12

identical callback

dnolen20:10:20

except you donā€™t know the callback didnā€™t change

thheller20:10:29

but fn don't compare equal

dnolen20:10:35

thereā€™s no way to prove that

dnolen20:10:43

because Mathematics tells you this simple_smile

thheller20:10:25

well ... if I pass :onChange (fn [new-value] (js/console.log "got new value")) I consider this as didn't change šŸ˜‰

thheller20:10:44

of course things are more complex than that

thheller20:10:37

ok ... enough with my worrying about stuff ... it probably doesn't matter if everybody just ignores this

stopa21:10:48

@thheller: you can always define the function somewhere, and pass it in, that way the reference will always be the same. Unless I misunderstood

thheller21:10:02

yeah but I need to pass args

thheller21:10:47

partial or equivalent

thheller21:10:48

React seems to suggest passing this.theCallback.bind(this) but I have nightmares about .bind

thheller21:10:02

and also no args

thheller22:10:28

probably overthinking it but works for me šŸ˜‰

dnolen23:10:24

Om 1.0.0-alpha4 released, unions in queries now supported

dnolen23:10:30

bunch of bug fixes too