Fork me on GitHub
#clojurescript
<
2015-10-19
>
markstang00:10:26

Has anyone been getting a stackoverflow error from "lein cljsbuild auto". I can usually get "lein cljsbuild once" to work, but auto seems to fail every time. Seems it doesn't like my "go-loop"

bhauman00:10:05

@jr0cket: that looks like a really old version of figwheel is running

fitzoh02:10:10

{:error
 #error {:message "Could not eval ", :data {:tag :cljs/analysis-error}, :cause #error {:message "Cannot read property 'findInternedVar' of null at line 1 ", :data {:file nil, :line 1, :column 1, :tag :cljs/analysis-error}, :cause #object[TypeError TypeError: Cannot read property 'findInternedVar' of null]}}}

fitzoh02:10:41

(running cljs_repl.core.eval("(+ 1 1)”))

fitzoh02:10:45

figured it out, was targeting browser instead of nodejs

dvcrn03:10:48

hey guys, a little question. I'm using a figwheel repl and cider (or cursive) to attach to that, all good. But as soon as I send a file over to the repl, figwheel compiles into a different folder (`./out/`) instead of the one I told it to (`./app/js/out/`). This only happens when I use the repl

dvcrn03:10:35

project.clj is available here https://github.com/dvcrn/dmedit/blob/master/project.clj. Did I set something up the wrong way?

lfn304:10:23

@dvcrn probably something related to your builds. Try adding :figwheel true to the build maps?

dvcrn04:10:23

let me try that!

lfn304:10:53

Just to clarify, it should read like

:builds {:main {:id “dmedit"
                                      …
                                     :figwheel true}}

lfn304:10:58

… minus the terrible formatting, obv.

dvcrn04:10:14

mhh, as soon as I use (cljs-repl) inside the nREPL, it spits out out/ again 😕

lfn304:10:43

output dir isn’t set on your node build.

lfn304:10:51

(you probably want the node and frontend build to output to different dirs as well, I can imagine them trying to overwrite each other with reckless abandon)

dvcrn04:10:19

ah so the stuff that is getting built is the node build? I assume launching the repl through (cljs-repl) is ignoring the other options because the main figwheel window is telling me Focusing on build ids: frontend

dvcrn04:10:14

ah hrm, seems like it https://github.com/bhauman/lein-figwheel#scripting-figwheel. the sidecar API wants something like :build-ids ["dev"]

settinghead04:10:22

are macro/function names with a leading dot officially supported? like (defmacro .’ []…)

settinghead04:10:48

i’m trying to compile reagent with cljs-bootstrap, but the compiler translates the name .’ to ._SINGLEQUOTE_, which is incorrect and gives javascript errors

ul04:10:44

@settinghead: I think supported names for macros are the same as for symbols here http://clojure.org/reader

ul04:10:50

especially "Symbols beginning or ending with '.' are reserved by Clojure"

settinghead04:10:58

think i’ll file an issue for the reagent authors

agile_geek06:10:35

@jr0cket: silly question but did you open a browser and connect to localhost:3449 ? That looks like figwheel waiting for a browser connection, once you open the browser figwheel connects to the browser based repl and shows repl prompt.

practicalli-johnny08:10:34

@agile_geek its not a silly question, but yes we did connect with the browser

agile_geek08:10:26

@jr0cket: cool. That’s me out of ideas then 😉

practicalli-johnny11:10:05

@bhauman: @agile_geek - yes, I was kind of assuming that the tutorial had one or more old dependencies in it. I'll probably stick with the Om & Om next tutorials for now as I explore the new (to me) world of React

bhauman12:10:31

@jr0cket that's more than likely why the repl isn't starting

kestrel712:10:51

Since upgrading to El Capitan my clojurescript app reports an error in the Safari error console: [Error] SyntaxError: DOM Exception 12: An invalid or illegal string was specified. cljs$core$async$impl$ioc_helpers$run_state_machine_wrapped Anyone see this? It works in Chrome still just fine...

bensu12:10:09

@kestrel7: what are you using to talk to the DOM? any specific library?

kestrel712:10:01

@bensu I have re-frame and reagent in use.

bensu12:10:27

hhhmm so React is talking to the DOM. Do you have any "set dangerous html" calls?

kestrel713:10:37

@bensu I do indeed: [:button.close {:data-dismiss "modal" :dangerouslySetInnerHTML {:html "&times;"}}]

bensu14:10:07

@kestrel7: well, your answer is probably there, specially if the code snippet you shared is inside a go macro. Check if that property &times works with the updated Safari.

anmonteiro15:10:07

hey guys, little question; is it possible to conditionally require a library to a namespace in Clojurescript? I've found this-> http://stackoverflow.com/a/29452022/3417023 for clojure but it doesn't seem to work in cljs

jaen15:10:36

I didn't try it, but I imagine you could split your application into modules - there's a simple example here http://swannodette.github.io/2015/02/23/hello-google-closure-modules/ - and then asynchronously load code the module as needed. But I didn't need this so far, so I don't know how it works in practice.

bensu15:10:11

@anmonteiro: I wouldn't recommend going there. In general require is not supported (there is a JIRA ticket for it)

bensu15:10:31

if your use case is to use a dev vs production starting point (as described in the SO question) there are other options

thheller16:10:31

@anmonteiro: conditional require at runtime is not possible, it needs to happen at compile time to make :advanced compilation possible.

thheller16:10:43

modules are a way to do that

kestrel717:10:19

@bensu I’ve tried removing the ‘dangerously set’ call but I still get the same problem. However I now understand from you that the problem is some invalid DOM manipulation. Thanks for the pointer. Any idea as to how to get the actual value of the illegal string?

bensu17:10:07

@kestrel7: not really. It looks like some of your React views is doing something that breaks Safari inside a go macro. So I would remove views until the error goes away. It sounds like a lot of work, but you have a very fast feedback loop when you use figwheel

settinghead17:10:03

anyone aware of any effort to apply a code reduction tool other than Closure Compiler? specifically something written in Node.js and/or Clojure/Lisp only?

bensu18:10:21

@settinghead: not that I'm aware of. I would probably advise against it: the ClojureScript compiler is very much geared to produce code for the Google Closure Compiler and work with it's libraries, idioms, and module system. Whatever build step you put after the ClojureScript compiler would need to take that into account.

thheller18:10:05

@settinghead: I'm not aware of any other such tool that can do dead code elimination as the Closure Compiler can. other "minifiers" don't even come close.

dnolen18:10:32

lots advantages to leveraging mature code bases simple_smile

martinklepsch18:10:23

Was wondering the other day: why are modules not compatible over different compile cycles? (e.g. common library & app specific modules)

martinklepsch18:10:04

afaik that’s because there will be different renamed/minimized variable names but that seems like something that could be worked around?

dnolen18:10:46

@martinklepsch: that doesn’t seems possible to me due to code motion

thheller18:10:49

@martinklepsch: you are not only dealing with renames, you are also dealing with cross module motions and functions being removed/kept alive

thheller18:10:18

"whole program optimizations" are not incremental

martinklepsch18:10:55

@dnolen: @thheller, right assuming that module contents are narrow/specific enough I forgot to add

settinghead18:10:58

@bensu @thheller @dnolen thanks. i've been trying to get ClojureScript to work in Meteor platform (which is node.js based). ideally i'd like to be able to initialize the entire code optimization process from node.js. now that Closure Compiler seems unavoidable, i think a compromise might be something like https://www.npmjs.com/package/closurecompiler

thheller18:10:22

I think I have been using closure modules longer than anyone else in cljs and never had a case where that would have been possible

thheller18:10:45

I tried very hard though .. I was convinced that it would be possible in the beginning

martinklepsch18:10:49

Seems to me that in a browser context it would be very handy to have two artifacts, one for rarely changing stuff one for often changing stuff, think I might have even discussed this with @dnolen before

thheller18:10:57

but that was mostly me not understanding modules correctly simple_smile

settinghead18:10:29

i looked at the codebase the other day, and seems that it's doable if i re-write this file (make it .cljc by adding node logic that uses the library above): https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj does this look like a sensible approach to you?

thheller18:10:49

@settinghead: that thing just wrap the JVM Closure Compiler

thheller18:10:01

you are basically just shooting yourself in the foot if you want to use that

thheller18:10:12

you still need a JVM

settinghead18:10:36

yes i understand that

thheller18:10:47

@martinklepsch: yes that seems handy, but it does not work.

dnolen18:10:52

@settinghead: we’re not adding any more Node.js support beyond what we already have

dnolen18:10:08

@settinghead: cljs.jar is a thing, it’s invokeable from the command line

dnolen18:10:15

this is what pasting services etc. now use

dnolen18:10:27

like JSBin

dnolen18:10:00

every release provides a jar containing everything to run ClojureScript (besides a JVM of course)

settinghead18:10:32

@dnolen: i came across it but i didn't realize it does code optimization too. i'll give it a try. thanks

dnolen18:10:10

@settinghead: if you’re new to ClojureScript read the Quick Start, it covers operation via cljs.jar

jaen18:10:20

@dnolen: if that's quick to answer, I've tried to see if my code keeps working under advanced optimisations, but it blows up due to nil value for source here - https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1678-L1680 I'm not sure what's the reason there is different resolution logic for no-opts vs. opts (there must be some, I guess), but with opts it means that cljs-source-for-namespace is used and due to it using io/resource it only sees thing on the classpath and adding the folder with sources to classpath should fix it, am I getting that right?

dnolen18:10:50

ClojureScript files always have to conform to the classpath

dnolen18:10:13

yes adding sources to the classpath should fix

jaen18:10:06

Heh, it was both that and the fact that I somehow had dashes and not underscores in the directory name. But it's interesting how it didn't manifest in a non-optimised compilation.

jaen18:10:10

Onto the next NPE then.

thheller20:10:30

@jaen: can you send me the react sources after they have been processed by the commonjs->closure stuff? I gave up quite fast after seeing what npm does .

thheller20:10:58

you said you had converted material-ui successfully?

jaen20:10:54

Not yet, since that requires me to write a custom module loader, which I once did in a spike, but didn't yet write that in the clean version.

thheller20:10:38

so you did it once? simple_smile

jaen20:10:47

I did the whole thing more than once

thheller20:10:51

not talking about any cljs stuff

jaen20:10:55

More like thrice

jaen20:10:06

It just was quick and dirty to understand what's up

jaen20:10:14

With all this

jaen20:10:45

As for converted React - sure, just let me recompile with no opts

thheller20:10:28

and would be interested in what (process-libs/process-js-libraries lib-opts) produces ... not more

jaen20:10:30

Yeah, that's the first spike I did, I think

jaen20:10:53

But that's insane

jaen20:10:05

And I don't recommend doing that : V

thheller20:10:23

yeah I kinda want to skip over that part

jaen20:10:24

But it basically just preprocessed them and shoved them into the output directory

jaen20:10:36

And just puts those in libs

jaen20:10:39

As far as I remember

thheller20:10:42

npm alone made me want to throw things 😛

thheller20:10:25

you are far more patient than I am simple_smile

jaen20:10:48

I dunno, I just do npm install and it kinda works, not sure what is so vexing in that?

jaen20:10:00

Unless you mean the fact that dependencies can be scoped?

thheller20:10:43

yeah node_modules/thing/node_modules/other/node_modules/even/node_modules/more/node_modules

thheller20:10:20

tried to make what you did in build.clj automatically

thheller20:10:27

which didn't work out so great 😛

thheller20:10:42

which is where I gave up

jaen20:10:46

I guess you might just read package.json, but not sure how (in)sane is that in practice

thheller20:10:35

I don't even want to try ... just gonna make me mad simple_smile

thheller20:10:56

but the stuff you have their works?

thheller20:10:21

guess I should just run it

jaen20:10:59

I think that repo is broken

jaen20:10:21

I must have force-pushed to the wrong branch in git

jaen20:10:26

When working on cljs compiler

jaen20:10:02

This one is a in-compiler spike though

jaen20:10:10

So not sure how much do you fancy that.

jaen20:10:00

Though if you use that you will be able to get your own preprocessed files

jaen20:10:36

Here's my output if you want though

dnolen20:10:03

@bhauman: I was thinking a that in browser Figwheel thing would be kinda cool, maybe very little to do?

dnolen20:10:15

er I mean DevCards

dnolen20:10:27

thinking CodeMirror editor, save, reload the code

dnolen20:10:53

kinda thinking the DevCards UI is a great way to get people to learn ClojureScript in the browser

bhauman20:10:31

yeah, some other folks have mentioned this. I think there is potential here.

bhauman20:10:07

you could start with in browser lessons and then work your way into the files

dnolen20:10:10

well was just thinking about doing my Om Next blog post entirely as DevCards interface simple_smile

dnolen20:10:39

but would need to know that DevCards could work w/o FigWheel driving it

bhauman20:10:01

yes it works fine you can advanced build it

dnolen20:10:11

well wouldn’t want advanced build

dnolen20:10:19

since cljs.js would be in there

juhoteperi20:10:30

Should be useful for demonstrating component options, like re-com demo does.

bhauman20:10:43

there is a fledgling api for rendering individual namespaces https://github.com/bhauman/devcards/blob/master/src/devcards/core.cljs#L991

bhauman20:10:20

I wrote a node script for my blog which prerenders the page/ns and spits it out with front matter

thheller21:10:55

advanced compilation is gonna be tricky though

thheller21:10:15

stupid process.env.NODE_ENV all over the place

jaen21:10:43

Yeah, I got advanced compilation working

jaen21:10:53

And the resulting file errored out

thheller21:10:04

:none runs fine though

thheller21:10:09

with a little hack 😉

jaen21:10:29

Hm, what hack?

thheller21:10:50

define process.env.NODE_ENV 😉

thheller21:10:06

hehe advanced compilation produces so many errors simple_smile

jaen21:10:09

I did put that in a script tag

thheller21:10:14

sort of expected though

thheller21:10:06

I can't believe it

thheller21:10:14

it actually works .. advanced compiled react

thheller21:10:30

WARNING: 0 error(s), 443 warning(s)

thheller21:10:53

too bad Closure doesn't recognize "production"!==process.b.a as something it can remove

thheller21:10:09

still pretty fun

thheller21:10:53

lein run -m build/production

thheller21:10:06

open public/index.html

thheller21:10:07

214kb pre-gzip, 61kb after

thheller21:10:35

not sure how much usual cljs + react.min.js is

jaen21:10:51

I've gotten WARNING: 0 error(s), 443 warning(s) as well

jaen21:10:05

but it didn't work for me I think

jaen21:10:25

Though maybe that's because you prepended the node env thing and I put it in the script tag

thheller21:10:05

yeah you did the hard part of creating those crazy converted .js files

jaen21:10:15

That's not me either ; d

jaen21:10:24

I just cannibalized Maria's code mostly

thheller21:10:25

yeah the closure compiler needs to know that

jaen21:10:29

And added some plumbing

jaen21:10:55

So with that it works no problem then?

thheller21:10:58

still amazed that stuff works at all

thheller21:10:18

well didn't try beyond a simple h1

jaen21:10:34

I have something a bit more, complex but not by much

jaen21:10:42

reagent counter

jaen21:10:46

I can see how it behaves

thheller21:10:56

is there a way to choose the name of the generated modules?

thheller21:10:23

module$react$lib$ReactDOM is crazy simple_smile

jaen21:10:31

yes it is

jaen21:10:34

and no, there isn't

jaen21:10:39

I had this in one spike

jaen21:10:46

And it caused problems

jaen21:10:09

Since GClosure modules create top-level objects and it clashed with React IIRC

jaen21:10:21

So I decided to first get it working with crazy names

jaen21:10:26

And worry about them later

thheller21:10:33

yeah it is good enough

thheller21:10:46

not sure if this would be wise to pursue

thheller21:10:02

so many non-closure things in there .. let alone 443 warnings

jaen21:10:15

dnolen suggested an alternative might be sugaring on the compiler side instead of generating better module names

jaen21:10:33

(at least WRT the module name)

dnolen21:10:56

@thheller: I’m curious about 2 things - DCE results

dnolen21:10:17

for one, the other is that feasibility is important

thheller21:10:33

uhm had the numbers above

dnolen21:10:35

I’m concerned that React is moving to a world where you must build via their NPM based tooling to get anything done

thheller21:10:45

214kb pre-gzip, 61kb after

thheller21:10:56

that is cljs+react

thheller21:10:10

could remove a lot more I'd think

dnolen21:10:30

that seems much smaller to me

dnolen21:10:38

React min is normally 40K by itself

thheller21:10:44

but closure doesn't recognise this if ("production !== process.env.NODE_ENV) stuff

thheller21:10:04

so it doesn't kill that

dnolen21:10:10

yeah I don’t really care about that

dnolen21:10:25

all that matters is that the code is correct and smaller

dnolen21:10:12

in anycase the more important part is a strategy for dealing with React that doesn’t involve NPM

dnolen21:10:54

I would not be surprised if 1 year from now React starts discouraging using the standalone scripts they provide

dnolen21:10:13

once React gets really popular (they’re almost there) they have more freedom to dictate how to consume it

thheller21:10:44

:advanced compiled

thheller22:10:14

not sure how feasible the whole thing is

thheller22:10:25

cause I don't know what it took to get the conversion going

thheller22:10:40

I imagine lots of manual labor

thheller22:10:48

compilation was easy

dnolen22:10:56

not really, it can be automated

jaen22:10:18

Mine's still compiling, I'm on a wooden PC ATM; let's see if React+Reagent work in advanced, at least for simple example

jaen22:10:39

@thheller: well, there was no manual labour involved with the files I've sent you

dnolen22:10:46

all this stuff is just re-using the bits Maria worked on over the summer

thheller22:10:56

well prepending process.env.NODE_ENV was manual, there are probably more things like that in there

jaen22:10:07

Not that I can tell

thheller22:10:30

I'm still amazed this works at all

dnolen22:10:31

@thheller: this is the kind of thing pluggable preprocessing is for

dnolen22:10:42

you will always need computational transforms anyway

jaen22:10:51

Oh-hoh, it's compiled. Let's see.

dnolen22:10:01

the only thing is to make it all pluggable configuration so users aren’t involved

jaen22:10:10

Hmm, I'm still getting Cannot read property 'c' of undefined over here, even with the preamble

thheller22:10:17

is that process.c.a? or something like that?

jaen22:10:28

Mhm, yeah, that's with process

jaen22:10:02

As for the manual labour you mentioned

jaen22:10:16

And with that code

jaen22:10:18

You can jsut do

thheller22:10:22

did you try with shadow-build?

jaen22:10:29

(cljs.build.api/build
  "test-project/src/cljs"
  {:main          "custom-module-loaders.core"
   :output-to     "test-project/out/custom-module-loaders.js"
   :output-dir    "test-project/out"
   :optimizations :advanced
   :verbose       true
   :asset-path "out"
   :preamble ["test-project/preamble.js"]
   :libs  [{:root "test-project/node_modules/react"
            :name "react"
            :files ["react.js" "addons.js" "lib/"]
            :main "react.js"
            :module-type :commonjs}]})

jaen22:10:33

And it magically works

jaen22:10:59

shadow-build would be a bit too complex for me now, I'd have to deal with lein and whatnot

jaen22:10:06

I'm just using raw cljs api

thheller22:10:09

no it doesn't need lein

thheller22:10:31

it is just clojure code

thheller22:10:43

(require 'build)

thheller22:10:54

(build/production)

thheller22:10:01

I only use lein for the classpath stuff

jaen22:10:11

Ah, I see

jaen22:10:36

Ok, let me cut the jar

jaen22:10:39

And I'll see then

thheller22:10:02

(build/dev) for :none with a repl

thheller22:10:54

I do not know boot but lein is definitely not required

thheller22:10:14

lein run -m build/production is just very convenient 😉

jaen22:10:38

Yeah, I can imagine

jaen22:10:15

My first spike had this - https://github.com/jaen/custom-module-loaders/blob/master/build.sh - which is not really a feasible thing to do xD

jaen22:10:05

Yeah, the simple reagent example explodes

thheller22:10:35

yeah reagent expects js/React and stuff I'd assume?

jaen22:10:45

I modified it not to

jaen22:10:55

And it works without advanced

jaen22:10:11

If you want to try it add [org.clojars.jaen/reagent "0.5.2-SNAPSHOT"] to your project.clj

jaen22:10:26

(ns react-test.app
  (:require [module$react$react :as React]
            [reagent.core :as reagent]))

(defn increment-button [counter text]
  [:button {:on-click (fn [e]
                          (swap! counter inc)
                          (.preventDefault e))}
   text])

(defn test-component []
 (let [counter (reagent/atom 0)]
   (fn []
     [:div {:style {:color "red"}}
       [:p "Test: " @counter]
       [increment-button counter "Click me!"]])))

(reagent/render [test-component] (.-body js/document))

jaen22:10:31

Is the sample code I use

dnolen22:10:19

getting futuristic

jaen22:10:43

Well, it works well in :none : V

dnolen22:10:44

getting this to work will be huge for React Native

dnolen22:10:56

+ Figwheel, yadda yadda

jaen22:10:01

Didn't try anything bigger than this yet

jaen22:10:29

Maybe I should try a bigger reagent project tomorrow and see if anything breaks

jaen22:10:41

But I imagine it probably exercises enough of reagent so it won't break with a bigger project, at least without optimisations

jaen22:10:46

Optimisations though...

thheller22:10:45

uhm your reagent pulls in way too many custom deps

thheller22:10:10

oh let me just exclude it

jaen22:10:28

Yeah, I think I made it depend on my fork of the compiler

jaen22:10:45

just exclude org.clojars.jaen/clojurescript and you should be good

jaen22:10:26

@dnolen: yeah, I think I remember mfikes saying something to that effect, though I imagine ReactNative will bring more problems with it, since it has native modules and whatnot

jaen22:10:30

Hah, speak of the devil ; d

dnolen22:10:45

@mfikes thanks for sleuthing that bootstrapping bug simple_smile

dnolen22:10:47

that was big a one (even though small in terms of code)

thheller22:10:06

@jaen I get Uncaught TypeError: Cannot read property 'monitorScrollValue' of null

thheller22:10:49

even in none, but I guess I need the converted .js

thheller22:10:56

since I still skip that 😉

jaen22:10:38

@thheller: I think cljs outputs only the files you depend on and those I sent you were outputted without reagent; give me a second

mfikes22:10:09

@dnolen: that bug is probably the most difficult one so far IMHO. It was just staring you in the face for a few months, laughing invisibly. :)

bhauman22:10:44

do you guys ever wish we all worked in the same office?

bhauman22:10:04

damn .... that would be fun

jaen22:10:11

@thheller: hm, no, the sources I've sent you were from a build with reagent; and I've just compiled it in your project without a problem (that is just adding my reagent fork and the sample code), so I'm not sure what can be wrong on your end.

richiardiandrea22:10:16

@bhauman: especially if it is kind of a earthship like yours 😄

bensu22:10:22

@bhauman: after hearing your speeches I realize I would never get anything done, laugh, and goof around 😄

jaen22:10:29

And here I thought an eartship is something like the Jawa sandcrawler : V

thheller22:10:42

TypeError: null is not an object (evaluating 'ReactBrowserEventEmitter$$module$react$lib$ReactBrowserEventEmitter.ReactEventListener.monitorScrollValue')

richiardiandrea22:10:46

@jaen: you cannot say Jawa in this channel lol

bhauman22:10:20

jawa jawa jawa jawa jawa jawa jawa ... I can keep going ... jawa jawa jawa ... ugh

dnolen22:10:38

@bhauman btw, Figwheel worked great for the Om Next workshop

jaen22:10:44

Ok, what did I just do? xD

bensu22:10:10

@dnolen: oh, right! how did that go in general?

bhauman22:10:24

@dnolen: awsome ... yeah it went well?

dnolen22:10:46

went pretty well, definitely need to figure out how to talk about Om Next to beginners simple_smile

dnolen22:10:56

but still people had a lot of fun as far as I could tell.

dnolen22:10:13

the more experienced UI people were excited about Om Next of course

dnolen22:10:33

everybody loved Datomic to no surprise

bhauman22:10:57

yeah pretty steep for beginners ... but something like CodeMirror could help.

dnolen22:10:13

@bhauman: yes this is why I was thinking about DevCards

dnolen22:10:28

@bhauman: but I also have some ideas floating around for a DevCards based work flow

dnolen22:10:42

i.e. if all the DevCards work, you know you have a working app simple_smile

jaen22:10:51

I feel kinda weird doing something like Om Next for my thesis, I feel like I'm incredibly late to the party now ; f

bensu22:10:52

@jaen late to the party? what do you mean?

jaen22:10:04

So I'm not sure what can be wrong

jaen22:10:37

@bensu: in that there's already a full featured library like that now

jaen22:10:42

So kinda late to the party

bensu22:10:19

there is a very promising library in alpha. If that's late, I fear for your sanity 😄

bensu22:10:52

and the ideas it has are so new that people can't digest them in a couple day course

thheller22:10:01

@jaen fixed it .. I removed [module$react$react :as React] since the namespace doesn't use it

thheller22:10:04

seems to break things

richiardiandrea22:10:27

my dream would be to have a complete dev UI, devcards at the bottom of the page and a repl on the left

richiardiandrea23:10:59

that is why I am working on the repl part, thanks to Mike's work

jaen23:10:10

@bensu: the fear is well founded, I'm afraid, I don't think anyone in their right mind would call me sane; but even if I'm afraid I'm too late I still have to do it so they don't throw me out of the university, so in half a year there just might be two libraries

jaen23:10:03

@thheller: yeah, that seems to break it; dependencies, oh well

thheller23:10:36

but I think that is what breaks the advanced compilation. what did you do to reagent?

thheller23:10:08

none works fine with the require but that require should be in reagent>

jaen23:10:50

Removed all the usages of js/Reagent and replaced that with appropriate module.

thheller23:10:25

ah requiring module$react$react basically pulls in everything

thheller23:10:48

some namespaces seems to get lost somehow otherwise

jaen23:10:13

Yeah, it seems so

thheller23:10:56

but I'm way too tired to think clearly ... gonna go to bed ... gn8

jaen23:10:33

React doesn't really seem to work as well when not using the React object, since for example render functions don't get wrapped with their perf middleware (which happens on building that object and so on)

jaen23:10:57

This probably could be solved somehow, but not sure how yet

jaen23:10:11

Yeah, it's quite late indeed, good night

flyboarder23:10:46

Has anyone else used Polymer with clojurescript?