Fork me on GitHub
#clojurescript
<
2016-10-23
>
kiko05:10:44

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

kiko06:10:19

ah looks like it's from re-frame

mikethompson06:10:43

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

mikethompson06:10:29

Hopefully that link i supplied above has all necessary explanation

kiko06:10:35

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

mikethompson06:10:56

I appreciate you saying so, thanks.

Pablo Fernandez10:10:07

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?

asolovyov11:10:43

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?

koolkk12:10:43

hello does anyone knows why when i try to use

cljs.pprint/write
i get TypeError: Cannot read property 'write' of undefined

dnolen14:10:20

@koolkk did you require cljs.pprint first?

deas14:10:32

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

deas14:10:53

Any ideas what might be wrong?

deas15:10:41

Should the compiler be able to deal with that?

dnolen15:10:35

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

dnolen15:10:13

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

alasdair15:10:16

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.

dnolen15:10:38

@alasdair probably want to ask in the #om channel

alasdair15:10:04

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

metametadata15:10:21

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

asolovyov15:10:34

@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

deas16:10:11

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

dnolen16:10:31

@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

dnolen16:10:20

also you still have not given enough information

deas16:10:23

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

dnolen16:10:24

no stack trace, no real error

deas16:10:32

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

dnolen16:10:19

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

darwin16:10:46

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

dnolen16:10:55

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

darwin16:10:57

make sure you do full clean before compiling it again

deas16:10:24

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

deas16:10:42

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

dnolen16:10:59

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

dnolen16:10:03

and there’s nothing for us to do

dnolen16:10:22

or a Closure + ClojureScript issue

dnolen16:10:26

i.e. we can’t fix foreign stuff

dnolen16:10:39

but without more information we’re just wasting time

deas16:10:46

@dnolen What exactly do you want me to do?

deas16:10:37

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

darwin17:10:52

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

deas17:10:41

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

darwin17:10:58

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

deas17:10:24

@dawin Yes.

darwin17:10:41

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

deas17:10:43

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

deas17:10:59

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

deas17:10:41

@darwin No way around.

darwin17:10:42

I was speaking about :closure-output-charset

deas17:10:05

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

darwin17:10:48

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

darwin17:10:25

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

darwin17:10:46

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

darwin17:10:16

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

deas17:10:27

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

dnolen17:10:14

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

dnolen17:10:22

“we can’t do anything about foreign libs"

dnolen17:10:33

that stuff doesn’t pass through Closure necessarily

dnolen17:10:45

so output encoding options are irrelevant

dnolen17:10:09

still not quite enough information

dnolen17:10:27

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

dnolen17:10:43

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

darwin17:10:55

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

dnolen17:10:13

right but this was all grabbing at straws

dnolen17:10:19

since we never saw a stacktrace or real error

darwin17:10:22

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

darwin17:10:57

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

darwin17:10:52

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

darwin17:10:55

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)

deas17:10:18

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

darwin17:10:25

@deas, what the browser says?

deas17:10:40

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

darwin17:10:22

by the file you mean “vega.js”?

deas17:10:29

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

darwin17:10:08

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

deas17:10:46

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

darwin17:10:19

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?

darwin17:10:45

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

deas17:10:40

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

darwin17:10:22

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

darwin17:10:32

might be a bug

darwin17:10:52

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

darwin17:10:56

if it is really present

darwin17:10:13

might be a bug of closure compiler as well 🙂

deas17:10:40

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

dnolen17:10:59

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

dnolen17:10:29

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

darwin17:10:29

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

dnolen17:10:39

minimal meaning

dnolen17:10:00

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

deas17:10:45

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

darwin17:10:34

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

darwin18:10:17

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

darwin18:10:45

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

deas18:10:37

@darwin Again thanks a lot so far.

darwin19:10:02

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

darwin19:10:25

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

deas19:10:40

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

darwin19:10:39

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

darwin19:10:22

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

darwin19:10:39

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

deas19:10:36

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

darwin19:10:17

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

darwin19:10:17

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

darwin20:10:08

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

jrheard21:10:16

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

jondejung21:10:25

Any Boot Users online?

lockdown22:10:58

jondejung try the #boot channel