What does ":<-" stands for? I'm not sure if this is from standard of cljs or other libs.

ah looks like it's from re-frame

@kiko yes, it is syntactic sugar available in a reg-sub See: https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/subs.cljs

@mikethompson Thanks! I guess its a shorthand of (subs/subscribe [:foo]) ? https://github.com/Day8/re-frame/blob/master/src/re_frame/subs.cljc#L120-L127

Yes, it is a shorthand for supplying one or more input signals (you are building a signal graph)

Hopefully that link i supplied above has all necessary explanation

It shoiuld, i love re-frame always documented very well and fun . thanks mike 🙂

I appreciate you saying so, thanks.

+1

I added a library to my project, and when I try to use it, I get this error: Uncaught ReferenceError: free_form is not defined. I cleaned the whole project and re-built it. Any ideas why it might still be missing the dependency?

anybody using figwheel with node.js here? I've tried to get app like https://gist.github.com/bhauman/c63123a5c655d77c3e7f up and running, but it doesn't reload anything... Any other pointers how to do live reload with node.js?

hello does anyone knows why when i try to use

cljs.pprint/write

@koolkk did you require cljs.pprint first?

Hi

Ugh

I'm ending up with messed up encoding, ClojureScript version is latest ( 1.9.293). Also tried :closure-output-charset "US-ASCII".

Any ideas what might be wrong?

Should the compiler be able to deal with that?

@deas if you need to emit some literal string with escapes, you need to double escape

@deas or I’m misinterpreting your problem since you haven’t explained it in detail

Does db->tree expect collections to be either vectors or maps? (a scan of the code suggests it does). I.e. you cannot do a join on a set.

@alasdair probably want to ask in the #om channel

ah, sorry, didn't notice I was in the wrong place

thanks

@asolovyov I've used https://github.com/malyn/figwheel-node-template recently and reloading worked there. But I had to add an explicit call to main func in the core ns, otherwise it is not called again after file is reloaded.

@metametadata ok, thanks. I've put some println in the main ns and it's not called on reload now, so... a bit weird; I'll try using this template

@dnolen With the escaped strings in the source (cljsjs), I have no way to set output encoding. Always end up with UTF-8 encoded compiled file.

@deas hrm I can’t really offer any more help - you might want to ask on the mailing list to see if someone else is trying to accomplish what you want

also you still have not given enough information

@dnolen NP. Still, I guess it is generally not safe to assume the webserver will serve it with proper headers.

no stack trace, no real error

@dnolen Is there a test or something in the compiler sources I could start from tracing this down?

First present a stack trace - at least the lines that don't involve your own stuff

@deas: this might be relevant https://github.com/google/closure-compiler/issues/1704

:closure-output-charset "US-ASCII” fixed the issue for me

@deas without very basic information there’s nothing for me to point you towards

make sure you do full clean before compiling it again

@darwin @dnolen Been there. Setting the output encoding does not work for me - always end up with UTF-8. Personally, I get around this setting headers. But not everybody might be able to do this.

Try adding [cljsjs/vega "2.6.0-0"] .

@deas you’re still ignoring what I’m trying to suggest. Without more information this could very well be a Closure issue

and there’s nothing for us to do

or a Closure + ClojureScript issue

i.e. we can’t fix foreign stuff

but without more information we’re just wasting time

@dnolen What exactly do you want me to do?

@dnolen Sorry, I guess I got it. If we need double escaping, it is an issue with [cljsjs/vega "2.6.0-0"].

@deas “double escaping” problem does not apply to non-cljs files, I believe, double escaping means that you have to first escape the string for reader (java escaping rules) and then again for string emitted to javascript (javascript escaping rules)

@dnolen @darwin Looked at this a bit further. Not quite sure who is to blame. The files shipping with cljsjs/vega are perfectly fine encoded. The -min one is UTF-8 though.

@deas from your example above, when you decode the string inside new RegExp('[\xAA\xB5\xBA\xC0-\xD6\xD8-\xF6…]’, is it a valid UTF-8?

@dawin Yes.

and in your final (generated) cljs build, does it have the same shape and form or it was somehow translated? (with “US-ASCII” on)

@dawin Not quite sure what exactly is going on under the covers. But the result is surely not what you want. 🙂

@darwin Well, ./cljsjs/production/vega.min.inc.js is UTF-8, ./cljsjs/development/vega.inc.js is escaped. Whatever :optimization > :none I use, I end up with UTF-8 in the compiled file.

@darwin No way around.

I was speaking about :closure-output-charset

@darwin Tried it. No effect. Output is UTF-8.

how do you check that "./cljsjs/production/vega.min.inc.js is UTF-8”? it may be perfectly valid UTF-8, but the string with escape sequences may be invalid

closure compiler in UTF-8 mode will blindly inline it without escape sequences and that causes the whole thing to be invalid UTF-8

so you have 2 issues, first :closure-output-charset is ignored for some reason

second, strings in vega might have invalid UTF-8 escape sequences in them

Extracted the jar. Try adding [cljsjs/vega "2.6.0-0"] and see for yourself. No way around UTF-8 output.

@deas @darwin note I already had a hunch about the problem above

“we can’t do anything about foreign libs"

that stuff doesn’t pass through Closure necessarily

so output encoding options are irrelevant

still not quite enough information

but my suspicion is that this is not a ClojureScript nor Closure Compiler problem

but using a library whose output encoding we can’t control in any simple way

well, I have one exactly identified case where closure compiler will do a wrong thing, there may be more of course, I just wanted to check if @deas issue is it

right but this was all grabbing at straws

since we never saw a stacktrace or real error

grrr 🙂

well if your regexp gets unexpectedly munged, you won’t see meaningful error, just your app stops working as expected

I’m looking through vega sources, don’t have a good way how to validate that javascript strings are properly unicode-escaped

and too lazy to setup a test project, maybe later, just hit another issue with leiningen and Cursive, so going to report that first 🙂

the only thing I can confirm at this point is that there are some strings with unicode escapes in them (at least in non-minified version)

@dnolen The error occurs in the browser. Problem "fixed" by setting UTF-8 encoding on the HTTP response. You really want to see it?

@deas, what the browser says?

@darwin Validate? Just drop put the file on server and load it via http.

by the file you mean “vega.js”?

@dawin You'll see the error unless the server explicitly sets reponse encoding to utf-8.

or you speak about my cljs build with vega.js included?

@dawin Yes. Just include it with the build and serve the compiled file via http.

well, but the build is definitely utf-8 encoded with unicode chars beyond ascii, so you should set response encoding to utf-8, why would you think you ASCII is ok?

as I tried to explain several times, closure compiler in utf-8 mode (default for cljs builds) will convert all javascript strings with unicode escapes in them to raw byte sequence

@dawin Well, I guess it is not save to assume webservers set UTF-8 response headers. Other than that, it is a bit confusing to ask for output encoding (:closure-output-charset) you don't get. 🙂

:closure-output-charset works for me, so you are probably hitting some edge case or doing something wrong

might be a bug

you could debug it to the point where clojurescript is passing options map to closure compiler

if it is really present

might be a bug of closure compiler as well 🙂

@darwin Got the compiled file served via http (w/o encoding set to UTF-8) ?

in anycase - there’s too many variables here for a resolution - so I’ll leave it be for now 🙂

my suggestion would be to create something minimal, repro, and submit an issue around that

@dnolen sure, thanks for your ideas, I’m just personally interested in the culprit

minimal meaning

a JS file with one line, a CLJS source file, and a build that requires nothing but ClojureScript itself

@darwin @dnole Thanks guys. Got a workaround but I also got really interested knowing about the culprit.

my theory right now is: vega.js is proper ASCII, all unicode containing strings are correctly expressed with unicode escape sequences (not broken). when included in cljs build, closure compiler turns them into raw byte sequences, so the output is real UTF-8 with some chars beyond ascii, so it must be marked as such so browsers understand it

vast majority of people produce cljs builds where files are just ASCII with no unicode in them, so they don’t run into this issue, or their servers detect unicode and serve proper headers

just a theory, I’m going to look into that vega.js case to confirm/reject it

@darwin Again thanks a lot so far.

just for record, this sample project proves that there is no issue when starting with a clean project from scratch and using python -m SimpleHTTPServer for serving the files, :closure-output-charset is effective and behaves as expected: https://github.com/darwin/closure-output-charset-test

btw. the BUG1704 is still present, as expected, because it wasn’t addressed upstream in closure compiler yet

Got it. It was <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>. Sorry for the noise. I should probably go to sleep. 🙂

@deas so missing charset=utf-8 in meta was causing that?

Yes!

I would think, this should be the default if you don’t specify it

and it applies to html content only (but I might be wrong)

The encoding from the meta headers seems to apply as a default for js as well.

hmm, interesting, I did a quick googling and it seems that UTF-8 is not default and meta really sets the default for script tags

so not setting charset=utf-8 on root level in connection with a “dumb" web server, you are asking for troubles with any code which might end up generating UTF-8 output beyond ASCII

https://dev.w3.org/html5/spec-preview/the-script-element.html#script-processing-encoding

and goog.require does not save us here: https://github.com/google/closure-library/blob/cd0e79408e4ec90e0da2eaee846a3400fae30445/closure/goog/base.js#L1115

which is the right behaviour, they should not force some arbitrary charset

http://stackoverflow.com/questions/12406066/does-html5-specify-a-default-character-encoding-for-html-documents-if-no-charact

mega props to @darwin for being a consistently chill friendly helpful person

🙂

Any Boot Users online?

jondejung try the #boot channel