Fork me on GitHub
#clojurescript
<
2016-09-29
>
dimovich09:09:40

a bit offtopic, but if somebody gives you a photoshop file, and asks you to make a html file out of it, how do you do it?

dimovich09:09:08

do you manually take all the dimensions and export the layers, and handcraft the magic html?

dimovich10:09:02

btw, is there a way to see how much each lib is taking from the final main.js?

dimovich10:09:41

I mean, the size... My latest toy project generates a main.js that is 650kB, which is a bit much imho

dimovich10:09:53

that is with advanced optimizations

thheller10:09:19

@dimovich if its :advanced not really not but if you just looked at the generated js sources you should get a rough estimate

thheller10:09:24

I mean the individual generated files not the final main.js

dimovich10:09:31

yep, got it. the main.out folder

thheller10:09:43

simple du -h if you are on linux/mac. just ignore the goog stuff since that is like 90% comments

dimovich10:09:15

don't know how much possible, but if I could get the main.js to around 200KB, would be nice 🙂

thheller10:09:04

you should look at the gzip'd size much less threatening

thheller10:09:40

but yeah 650kb seems a bit excessive

thheller10:09:26

maybe you are using some libs with a many foreign-libs as well which can bloat things

dimovich10:09:38

hmm... could be... will try to switch off and on different libs and see how it affects... I have a suspicion react-bootstrap is eating my lunch

thheller10:09:36

hehe yeah that alone + react should be arround the 300kb mark

pvinis10:09:14

when i have chrome and im stopped on a breakpoint, how can i have a repl to check some stuff?

pvinis10:09:28

the console is only for running js. can i run cljs?

pvinis11:09:30

i will try that now

pvinis11:09:04

is there an easy way to set up wth re-natal?

lxsameer11:09:18

is it possible to force the clojurescript compiler to prepend external libs such as jquery to the resulted js file ?

bendlas16:09:19

Has development mode broken for anybody else with chrome 53? It seems, that the browser doesn't execute document.writeScript (from goog.require) synchronously, anymore. I get undefined errors for my main function, but running it manually 1 second later, works.

bendlas16:09:27

firefox works immediately

dnolen16:09:33

@bendlas unless it got released after 7pm last night, no I haven’t seen that

bendlas16:09:02

@dnolen ah, it seems the error is related to devtools or dirac

dnolen16:09:04

@bendlas oh but we don’t use writeScript just write in ClojureScript itself

bendlas16:09:14

@dnolen sorry, it's called document.write

bendlas16:09:40

removing the devtools and dirac preloads makes it work in chromium, too

bendlas16:09:54

I'll see about activating them after initial loading

dnolen16:09:00

ok, I use devtools I haven’t seen that issue yet

bendlas16:09:00

cursork: no, it's a bug in binaryage/dirac

bendlas17:09:53

darwin: sure, I'm just building a canary. Im pretty sure though, that the error is not due to version mismatch, as it interferes with page loading even without connecting to the debugger. Just adding the preload suffices to change the behavior of document.write

darwin17:09:33

btw. if you are on a *nix system, you should be able to use pre-built canary, here is how I do it on ubuntu via google-chrome-unstable package: https://github.com/binaryage/dirac/blob/4343aac6016476bf9736029ce6d8e82329868752/.travis.yml#L21

bendlas17:09:02

darwin: what do you mean? have you reviewed dirac.runtime/install! ?

bendlas17:09:36

I don't see why dirac should change the behavior of document.write on chrome 53, but not on 55

bendlas17:09:08

i said preload, because I can circumvent the issue by using the manual activation method from the main function

darwin17:09:24

I was reacting to your "building a canary”, building chrome from sources seems like a pretty damn difficult task

bendlas17:09:02

darwin: well, i have some experience with it, and I need to update the build script for NixOS anyway, so ..

darwin17:09:09

dirac should not change document.write (in any version)

bendlas17:09:24

darwin, that's what I thought

bendlas17:09:31

nevertheless, it does

darwin17:09:56

It does not, unless proven

darwin17:09:47

but anything can break when using mismatched chrome-devtools combination, I will wait for your investigation

bendlas17:09:10

I'll report back, but you said yourself that it shouldn't do that in any version. the matched-version requirement surely should only affect debugger connections, no?

darwin17:09:19

btw. you could try to call .toString on the bad document.write method, maybe it will reveal where it came from

darwin17:09:12

yes, if you just add dirac.runtime into preoloads and do not connect dirac devtools, then the matched-version requirement does not apply, dirac.runtime should be normal cljs dependency without any tricks

bendlas17:09:12

right, and I'm telling you, that just adding the preload changed the behavior, at least on chromium 53

bendlas17:09:32

but, my chromium 55 is about to finish

darwin17:09:04

if preload breaks it and manual installation via install! does not, then it could point to some :preloads feature bug

dnolen17:09:06

fwiw Chromium 53 is supposed to greatly restrict document.write usage

dnolen17:09:35

not really relevant for ClojureScript since we don’t do it after page load

dnolen17:09:45

but probably relevant for other tooling

bendlas17:09:10

darwin manual installation does also break, but it's not visible, because all the requires have been processed at that point

darwin17:09:30

I’m not aware of anything tricky in the runtime code, but I call clojure.browser.repl/bootstrap, which might do something significant: https://github.com/binaryage/dirac/blob/4343aac6016476bf9736029ce6d8e82329868752/src/runtime/dirac/runtime/repl.cljs#L179

dnolen17:09:41

also note we don’t use document.write for REPLs after page load since it doesn’t work consistently already - eval instead

darwin17:09:21

actually that is the only thing install! does

darwin17:09:08

I think I inherited it from weasel-based project I started from

dnolen17:09:46

you will probably need to replicate it then

dnolen17:09:55

the problem is goog.require after page load doesn’t work

dnolen17:09:36

like when reloading a namespace

dnolen17:09:18

also goog.require isn’t even suitable for hot-loading - thus all the tweaks

dnolen17:09:48

like (require foo.core :reload)

bendlas17:09:42

darwin: yep, doesn't work in chrome 55 either. with dirac tools connected or the default debugger

darwin17:09:36

@bendlas: ok, you were right, dirac alters document.write via clojure.browser.repl/bootstrap when you call dirac.runtime/install!

darwin17:09:03

any chance you could do all your document.write calls before calling dirac install!?

bendlas17:09:34

I've got no problem with that, it's the manual installation

bendlas17:09:41

but preloading is broken

darwin17:09:28

I will put that bootstrap call into async setTimeout 0, that should fix it

darwin18:09:45

you could do a quick test, create your own namespace, copy&paste dirac runtime preload code there and instead of install! call js/setTimeout with install!

bendlas18:09:45

oh, so it's not document.write that is actually altered, but the goog.require wrapper for it ... same outcome

darwin18:09:20

and put that cloned namespace as your preload

darwin18:09:56

I don’t understand what exactly went wrong with your code. All I understand at this point is that bootstrap method does monkey-patching to support possible future hot-reloading when compiled cljs code gets executed later

darwin18:09:05

but we do this monkey-patching too-early in dirac when used via preloads, because there may be some other code calling document.write and that would be a valid call, because document is not yet fully loaded

ag18:09:08

Hey guys, anyone using spec in CLJS? I have a question: so I found that you can require spec either way:

(require '[cljs.spec]) or '[clojure.spec]

ag18:09:22

but when it comes to clojure.check.generators

ag18:09:12

you can’t use [clojure.spec.generators] or [cljs.spec.generators]

ag18:09:27

but you can do this: [cljs.spec.impl.gen :as gen]

ag18:09:35

but is that right?

dnolen18:09:39

@darwin we don’t alter document.write in bootstrap

dnolen18:09:00

we only monkey-patch goog.base functionality

dnolen18:09:56

@ag you mixing up several thing here (though I understand why)

dnolen18:09:11

first, it’s not like we’re going to just randomly look for aliases

dnolen18:09:31

or allow you to do one or the other willy-nilly

dnolen18:09:59

the only thing that is supported is that if you write clojure.* and it doesn’t exist, we look for cljs.*

dnolen18:09:31

cljs.spec.impl.gen is an edge case - but it’s not that important so not handled - I have heard little evidence that anybody needs that ns generally

bendlas18:09:32

@darwin: setTimeout(dirac.runtime.install__BANG__, 0) seems to fix it

bendlas18:09:00

@darwin: the more correct method would be to listen for the load even, though

dnolen18:09:13

@ag so it’s not about “either way"

dnolen18:09:28

it’s just that clojure.spec is an alias for cljs.spec

ag18:09:53

> I have heard little evidence that anybody needs that ns generally really? how do we write test.check tests in cljs then?

dnolen18:09:48

@ag you need to be more clear

ag18:09:54

are you’re saying that generators shouldn’t be used in CLJS?

dnolen18:09:06

@ag no that is not what I’m saying

dnolen18:09:13

but I don’t know why you need that ns

dnolen18:09:25

give an example of something you actually need to do

darwin18:09:27

@bendlas: thanks for testing it, and good point with ‘load’, I will have to think about it more

darwin18:09:00

someone could call dirac install! later, when the document is already loaded

bendlas18:09:14

@darwin: what's going wrong with my code, is that after goog.require is monkey patched, <script>goog.require("foo.bar");</script><script>foo.bar.some()</script> doesn't work as expected any more, as described here: https://developers.google.com/closure/library/docs/gettingstarted#wha

ag18:09:07

@dnolen something like this:

[clojure.test.check.clojure-test :refer-macros [defspec]]
   [clojure.test.check.properties :as prop]
   [clojure.spec :as s]
   [cljs.spec.impl.gen :as gen]))


(s/def ::bool-kv (s/with-gen
                   (s/and not-empty map? #(< 5 (count %)))
                   #(gen/map (s/gen :types/keyword) (s/gen boolean?))))

(defspec css-classes-test 50 
  (prop/for-all [m (s/gen ::bool-kv)] ,,,,
I can of course place that spec into cljc and then use it here, but it’s only require for that test

bendlas18:09:20

@darwin: calling install! on load should work out fine

darwin18:09:07

@bendlas I agree, but I have to handle the case when load already fired - which won’t be hard I guess

dnolen18:09:13

@ag why do you need that ns for this? instead of just using test.check directly?

ag18:09:23

@dnolen hmmm good question. after all spec’s gen/map is not that different from test.check's

bendlas18:09:23

@darwin: true, but that should almost never be the case for the preload code.

darwin18:09:09

@bendlas: yes, it will never be the case when called via :preloads (in current implementation), but install! must be general, it must not presume that it will be called from preload code, I will hook the ‘load’ event if not already fired, else I will bootstrap directly

bendlas18:09:12

@darwin: the preload script can subscribe the invocation of install! to the load event, though. install! itself need not be changed, because if it's called directly, all requires will already have been processed.

darwin18:09:59

@bendlas: that is not good enough, someone could call install! when document is not yet loaded and run into the same issues as you did

darwin18:09:06

without preloads

bendlas18:09:38

true ... maybe go shopping for jQuery's .ready?

darwin18:09:07

@bendlas: I’m looking into closure library if there is some support for document ‘load’ event

darwin18:09:26

but we don’t need perfect cross-browser compatibility here, dirac works only with chrome

darwin18:09:56

ideally this defensive logic should be rolled into clojure.browser.repl/bootstrap itself

dnolen18:09:50

patch welcome, nobody has brought this one up before because all the code in ClojureScript is now oriented around never writing inline scripts like that

darwin18:09:34

@dnolen I see, if I'm able to find a clean, cross-browser solution, I will try to submit a patch

dnolen18:09:02

sounds good

joakimmohn21:09:57

i'm using cljs-ajax interceptors for managing identity and tokens, but I can't seem to be able to read the properties of the response map, its a js object. Has anyone used this library and interceptors? can't find much on this issue

kenny22:09:55

@joakimmohn Use aget or js->clj?

kenny22:09:56

Does anyone know if it is possible to set the headers for the GET request when opening a websocket with goog.net.WebSocket? It looks like it is not possible, which is quite surprising.