Fork me on GitHub
#clojurescript
<
2015-08-03
>
dnolen01:08:05

@martinklepsch: can you be more specific?

a.espolov08:08:01

@dnolen: David i understand that cljs is now available to eval?

dnolen08:08:37

@a.espolov: did you read the post? simple_smile

dnolen08:08:36

covers the release

a.espolov08:08:12

but in your post I haven't found any example code, only working version)

a.espolov08:08:25

It is not difficult to educate?)

dnolen08:08:51

@a.espolov: other people can work on the documentation bits

dnolen08:08:23

it’s really not for normal usage, at this point still requires somewhat advanced understanding of ClojureScript to work through potential issues

dnolen08:08:17

@a.espolov: if you still want to try it yourself than read through cljs.js there are examples at the bottom of the source file.

joelgluth09:08:14

Extreme cljs noob question: what is the current state of the art for using figwheel from emacs? The last set of instructions I found suggested that NREPL-and-clojurescript was in a state of flux, and indeed :figwheel { :nrepl-port foo } did not work as expected.

joelgluth09:08:30

Or is figwheel no longer The Thing?

Petrus Theron10:08:50

Trying to set up sente for my http-kit project. Followed the readme, but getting a bunch of Invalid frame header errors in console on connection:

WebSocket connection to '' failed: Invalid frame header

dnolen10:08:47

@joelgluth: figwheel works great tons of people use it. Getting anything ClojureScript related working with Cider still seems like an exercise in extreme patience.

joelgluth10:08:02

Thanks for the heads-up - it's definitely cool. I'm making do with running lein figwheel from an Emacs shell with paredit at the moment and it's getting me where I need to go simple_smile

Petrus Theron10:08:34

Having a hard time getting sente to work on an http-kit project where the front and backend run on different ports (3010 and 3011, respectively). Is there some CORS magic I need to be aware of, or perhaps something to do with CSRF tokens? I see the following console error:

XMLHttpRequest cannot load . No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '' is therefore not allowed access.
However, I have CORS middleware set up as:
(wrap-cors :access-control-allow-origin cors-allow-origin
      :access-control-allow-methods [:get :put :post :delete])
, which the sente handshake seems to be bypassing. So I tried returning CORS headers explicitly in ajax-get-or-ws-handshake-fn, but no luck. Feels like there should be a simple solution. Any help would be appreciated!

mcgivernsa11:08:48

what is cors-allow-origin ?

Petrus Theron11:08:35

@mcgivernsa: (def cors-allow-origin [#"(https?://)localhost(:\d+)?"])

Petrus Theron11:08:11

@mcgivernsa: I tried adding another entry for #"(ws://)localhost(:\d+)?", but same cors error.

rauh12:08:19

@petrus: It looks like you don't set the Access-Control-Allow-Origin in your HTML response

mhuebert13:08:41

step by step, I’m making headway w/ cljs.js simple_smile. I’m now able to evaluate inside an existing namespace in my project by loading its analysis cache (as @dnolen describes for ‘cljs.core here: https://github.com/clojure/clojurescript/wiki/Optional-Self-hosting). I can use def'd and referred vars, however a macro (eg. go) causes a Cannot read property 'findInternedVar' of null error in cljs$analyzer$macroexpand_1. code: https://github.com/mhuebert/cljs-bootstrap-async/blob/master/src/foo/core.cljs#L48 stacktrace: https://gist.github.com/mhuebert/9db93548eb29566094d6#file-stacktrace-eval-go-L7 there’s obviously a lot I don’t understand about how cljs.js works - I must be missing something with how macros are loaded/run.

dnolen13:08:08

@mhuebert: yeah that approach will not and cannot work

dnolen13:08:34

you need to wrap your head around the fact that the thing that generates the bootstrapped thing … is not the bootstrapped thing at all

dnolen13:08:12

just because you require go for the build, this won’t supply go for runtime macroexpand

Petrus Theron13:08:16

I'm fighting a weird ClojureScript code reload issue. On initial load, my cljs app is semi-broken with no errors, but as soon as I touch a particular utility file and the code reloads, my app works. I'm using boot with reagent and re-frame, but I don't know if this problem is me being an idiot (most likely), some swallowed compilation error or something particular to boot 😕.

dnolen13:08:32

@petrus getting familiar with how to make builds w/o lein or boot can help determine where the issue lies.

Petrus Theron13:08:38

I found my bug!

Petrus Theron14:08:41

My bug was keyword namespace mangling. I was doing this:

(let [resp-key (keyword (str (name path) "/response"))]
    ... ;; do stuff with resp-key)
However, if path is :users/load, then resp-key would become :load/response instead of :users/load/response as I expected. By reloading the code, the most recent keyword would override my re-frame handlers simple_smile.

Petrus Theron14:08:39

Can keywords in clj/cljs contain multiple slashes, i.e sub-namespaces?

mhuebert14:08:28

@dnolen: it makes sense to me that the two things are separate. I didn’t understand that the analysis cache would include everything except macros. So the necessary step seems to a *load-fn* to supply the source files requested when evaluating (:require-macros [cljs.core.async..]). since core.async.impl/ioc_macros.clj imports java.util.concurrent.locks Lock, is it even possible to use core.async macros in bootstrapped cljs?

dnolen14:08:28

@mhuebert: the analysis cache isn’t about code

dnolen14:08:03

it’s just to populate the compiler state so validation, optimization, and static access to var info works

dnolen14:08:49

macros cannot exist there

mhuebert14:08:38

@dnolen: I see. is it correct to say that when I load the analysis cache of a namespace in my build, the compiler state becomes ‘aware’ of it?

dnolen14:08:02

the issue is that for code size reason we don’t put this information into the generated JavaScript

dnolen14:08:10

it’s erased

dnolen14:08:38

so in order to know what pre-compiled JS files “means” you need to load an analysis cache for it

dnolen14:08:49

unless of course you compile / analyze the ClojureScript source directly

dnolen14:08:36

but that’s of course much slower than just eval’ing the JS and reading a cache

dnolen14:08:19

so analysis cache’s are completely inert - just data, they don’t represent anything executable

jballanc14:08:32

out of curiosity, what’s the current status of tools.emitter.{jvm,js} and the potential of moving ClojureScript to using something like that?

dnolen14:08:03

@jballanc: probably not going to happen

dnolen14:08:33

but that doesn’t really pass any judgement on the utility of such projects

jballanc14:08:25

Cool…was mostly just curious from the perspective of extending ClojureScript to other back-ends (Lua, in particular)

jballanc14:08:45

…especially now that we’re self-hosting

jballanc14:08:29

seems easy enough to patch emit* and friends directly, but wanted to make sure there wasn’t a more “formal" mechanism in the plans for the future

mhuebert14:08:27

@dnolen: for a macro, then, reading .clj source directly is the only way to use it

mhuebert14:08:10

& so core.async macros will need some work before they can be read in cljs.js

dnolen14:08:49

@jballanc: bringing other backends is a possibility but really there’s hardly any need to formalize emit*

dnolen14:08:21

very little in cljs.compiler is reusable

dnolen14:08:27

@mhuebert: it may I haven’t really thought much about cljs.core.async.macros in this context.

jeremyraines15:08:31

has anyone had trouble getting a repl working in Cursive for a figwheel project? I am following the directions here:

jeremyraines15:08:43

and it works, but after a minute or so it quits, saying: "No nREPL ack received". Also, for the minute or so that the prompt is displayed, I can't click into the window (this may be just me not understanding intellij)

wildermuthn16:08:40

I wrote an article yesterday, "Clojurescript and the Blub Paradox.” Would love to get informed criticism/feedback before I release it into the wild. No doubt I’ve made some mistakes or misassumptions! http://wildermuthn.github.io/2015/08/02/clojurescript-and-the-blub-paradox/

mikepence16:08:14

well-written. dunno about comparing enthusiasm for lisp with being ‘religious’ since religious to me has implications of elevating a flawed way of thinking absent rational analysis. simple_smile

jeremyraines16:08:18

I like the contrasting lists of problem solving steps. I'd love to see comparisons like that over a whole host of languages/problems. "See this, and my mind goes there"

mikepence16:08:13

the thing I have not seen much about — though I guess I could Google — is integration between cljs and javascript. Is it easy/trivial?

mikepence16:08:29

one of the biggest value props of cljs is that these many many js libs are there to be used.

antishok16:08:27

@wildermuthn: enjoyed reading it, thanks. typo in "intelligable" simple_smile

dnolen16:08:32

@jeremyraines: you are skipping a step. It says what REPL option to use

dnolen16:08:21

@mikepence: random JS libs aren't that important due to Google Closure Library

dnolen16:08:51

For the others integration for the popular ones exist http://cljsjs.github.io

dnolen16:08:54

@wildermuthn: I'm not huge fan of the Paul Graham Blub narrative :) I think it makes people defensive about their existing tools

jeremyraines16:08:19

I have it on use clojure.main in normal JVM process with the associated script/repl.clj and changes to project.clj

mikepence16:08:11

@wildermuthn: a more complex example might show how clojure makes hard things easier

dnolen16:08:52

@jeremyraines: then that error isn't possible

wildermuthn16:08:02

Thanks for the feedback! Paul Graham can definitely be abrasive, but though it might gather more attention being provocative.

jeremyraines16:08:15

ok. so I want to confirm but I'm hitting a wall from my newness to intellij. It seems I've "lost" the running repl window -- I have a green play button in the top, but when I push it now it says I already have a repl running on that port. (and my browser console says it's connected)

jeremyraines16:08:19

I found and killed the running repl process, and I'm still getting that error

dnolen16:08:31

@wildermuthn: being a little bit provocative is good. But the ClojureScript story is really about system building

dnolen16:08:53

the mainstream equates “front-end” with JavaScript, some separate consideration

dnolen16:08:08

whereas in the Clojure world we have all pieces for the various parts of the system we want to build

dnolen16:08:31

you often people talk about ClojureScript as if it’s really a separate thing from Clojure

dnolen16:08:44

but it isn’t the way JavaScript is something different from your back-end language

dnolen16:08:55

the surveys reflect this - everyone using ClojureScript is using Clojure already

meow16:08:08

@jeremyraines: You might have better luck in #C0744GXCJ - I have found the repl stuff in cursive to be really solid, fwiw.

jeremyraines16:08:18

thank you, i'll check in there

wildermuthn16:08:11

@dnolen: so putting more focus on Clojure being full-stack?

jeremyraines16:08:18

yeah, i feel close . . . in fact that repl that I had to kill seemed to be doing the right thing, but I can't see myself start it and see it succeed for some reason, so I'm not sure how i launched it 😕

dnolen16:08:53

@wildermuthn: I consider that the real story, for me it’s really liberating to have multithreaded server-side language and lose very little in terms of other semantics when switching to the front-end

wildermuthn16:08:04

I never know whether to use the words Clojure or Clojurescript when I’m talking about it. I often want to write Clojure(Script).

chancerussell18:08:52

@wildermuthn I like the article. Maybe including a mention of where the match macro is coming from would steer people into learning a little more about how that works

chancerussell18:08:21

(Assuming it's core.match)

chancerussell18:08:06

@wildermuthn: I'll read through it again this evening and send you some more feedback.

val_waeselynck19:08:31

@wildermuthn: I like the ideas in the article, but if I had read at the time I didn't know Clojure, I think I would have dismissed it as too dogmatic. I have gotten the habit of running away from sentences like "technology X is superior to technology Y - period." - because in most scenarios when I encountered it (including from my own thoughts) it was a symptom of narrow-mindedness. Maybe a little more diplomacy to ease people into this kind of thinking simple_smile

wildermuthn19:08:43

@val_waeselynck: The article’s condescending-ish tone isn’t persuasive?? 😉 I appreciate the good feedback. Thinking on how to modify it to rely less on Blub.

val_waeselynck20:08:02

@wildermuthn: I'm not sure a lot JavaScript programmers will be receptive to the switch vs condp thing - Several backend developers I know liked moving from say Ruby to NodeJs because it felt closer to the metal

roberto20:08:17

Wow! Yeah, the tone is quite snobbish. If I didn’t know clj, it would turn me away from it. It is also one of the reasons I don’t like ruby (the snobbish tone of the ruby blogs). JS is easy. That is why it is popular. Oh, and JS has pattern matching https://www.npmjs.com/package/pattern-match

roberto20:08:32

and I’ve seen some implemented with sweetjs also

dnolen20:08:45

@roberto: well JS is popular because there were few other options on the front-end for more than a decade

dnolen20:08:52

not because it was easy

dnolen20:08:11

I remember doing JS in 2005, it was terrible - as far from easy as one could possibly imagine

dnolen20:08:43

well “terrible” I mean I really enjoyed it - but it felt more like black magic than programming

roberto20:08:21

yeah, I started enjoying it about 3 years ago. And my perception changed too.

val_waeselynck20:08:59

@roberto: this library is mentioned in the article already simple_smile

teslanick20:08:55

When I started with CLJS, I saw it as the best parts of JS expanded; shared client/server language, dynamic, expressive, terse, fast. Plus first-class immutable data.

teslanick20:08:37

(that's not really true anymore)

val_waeselynck20:08:45

I personally really enjoyed moving from Java to JavaScript (it was in 2013 though). I really felt like I had gotten rid of a lot of useless problems. To think that I could repeat this process from JS is what got me into Clojure I think.

roberto20:08:31

I was attracted to CLJS because I took a course that introduced me to SML and Racket. I like both languages, and Cljs gave me the opportunity to use something as close to Racket in “real” apps.

roberto20:08:58

I still enjoy doing JS, and would also enjoy writing SMLjs if there were one.

scriptor20:08:35

could always write it yourself 😉

roberto20:08:48

I wish I could simple_smile

wildermuthn20:08:53

@roberto: Javascript might be the most practical programming language in the world, not because of the language, but because of its reach: browers, servers, phones, even embedded into hardware now.

dnolen20:08:13

there’s also an OCaml to JS thing and F# to JS thing as well

roberto20:08:14

thank you for the black hole

roberto20:08:28

yeah, I saw an F# to JS, but it required Visual Studio

dnolen20:08:09

GHCJS is a thing (though it seems a bit heavy to me) and PureScript and Elm are lighter weight alternatives

dnolen20:08:20

I’ve surveyed pretty much everything half-way serious

dnolen20:08:28

from what I can tell ClojureScript is way, way, way, way, way ahead

roberto20:08:59

yeah, I feel like a kid in a candy store …. with a stomach pain from so many goodies.

scriptor20:08:00

elm seems to have a lot of good support regarding debugging and such

dnolen20:08:33

@scriptor: not source mapping, just a better debugging model overall but ClojureScript has that too

dnolen20:08:40

programming w/ immutable values works

dnolen20:08:55

ClojureScript has source mapping everywhere

wildermuthn20:08:03

How much did Clojure’s experience with being hosted on the JVM help in ClojureScript’s development with being compiled to Javascript? It seems like that should have given CLJS’s development a firm foundation, as opposed to other languages that might have been built without having a host platform in mind.

dnolen20:08:07

it supports every popular JS engine

dnolen20:08:24

most compile to JS things are not serious about this the way ClojureScript is

dnolen20:08:37

not going with NPM is partly what made this possible

dnolen20:08:45

Node.js has all the portability of the JVM

ordnungswidrig20:08:41

I get errors like this, any hint, where to look? "Warning: Don't set .props.om_init_state of the React component. Instead, specify the correct value when initially creating the element or use React.cloneElement to make a new element with updated props."

nullptr20:08:47

ordnungswidrig: om? i believe you can safely ignore it -- if memory serves, it's only relevant for javascripters

ordnungswidrig20:08:20

@nullptr: is this something in react recently? The only thing I changed (AFAIR) is upgrading some dependencies

nullptr20:08:42

i believe so, but don't recall the specific versions

ordnungswidrig20:08:57

Can I mute them in the chrome console somehow?

pmooser20:08:47

@dnolen I'm still using some non-standard tooling, but are there any tips in general for trying to debug source-mapping issues?

dnolen20:08:18

@ordnungswidrig: can’t mute unfortunately, in the future we’ll be able to avoid the warnings can’t in 0.13.X

dnolen20:08:01

@wildermuthn: Rich Hickey did the first version of ClojureScript so I suspect Clojure’s strategy was very present in his mind.

dnolen20:08:52

@pmooser: not sure what you are asking

pmooser20:08:54

@dnolen Sorry - when source-maps don't seem to be working, ie I just see js line numbers, are there are any recommended steps to figure out what in the process is failing, e.g. a way to find an indication that it can't find the .map files or something along those lines?

dnolen21:08:35

@pmooser: usually it’s something simple the path is wrong

dnolen21:08:45

there really not much to debug, the path needs fixing

nberger21:08:29

Hey everyone, I just opened a PR (https://github.com/gfredericks/test.chuck/pull/14) in test.chuck, adding ClojureScript support. Comments are very welcome simple_smile

dnolen22:08:05

@nberger: cool! btw, Gary Fredericks the maintainer is more active on Clojure IRC if you want to get feedback from him directly outside of GitHub

nberger22:08:53

@dnolen: Thanks! I'll try to find him there

dnolen22:08:15

@nberger: handle is gfredericks there too

nberger22:08:40

@dnolen by the way, thanks for all the awesome stuff. Much of that PR is taken from your port of test.check to cljs simple_smile