This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-09-15
Channels
- # admin-announcements (7)
- # alda (6)
- # beginners (34)
- # boot (23)
- # cljs-dev (3)
- # clojure (73)
- # clojure-italy (4)
- # clojure-japan (6)
- # clojure-nlp (1)
- # clojure-russia (104)
- # clojure-sg (2)
- # clojurescript (222)
- # clojurex (7)
- # cursive (41)
- # datascript (2)
- # datomic (56)
- # docs (1)
- # editors (6)
- # emacs (3)
- # events (8)
- # hoplon (139)
- # jobs (2)
- # ldnclj (24)
- # luminus (2)
- # off-topic (3)
- # om (12)
- # onyx (24)
- # re-frame (5)
- # remote-jobs (1)
- # yada (1)
In CLJS-324 dnolen said: "goog.string.format defies advanced optimization”. What does that mean specifically? Does it break under advanced optimization or is just not able to be optimized? http://dev.clojure.org/jira/browse/CLJS-324?focusedCommentId=31935&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-31935
@troyclevenger: Yup, that is the error. I did find that issue, so the error is resolved already. It was more a question about stopping the compilation on errors like that.
@estsauver: No I did not, it seemed I’m not the first having the issue, so I though a ticket had already been filed
Also I’m in doubt as to where the error actually is, whether it’s in omtools, the google closure compiler, or cljs
Has anyone experienced this error whilst trying to write macros for cljs? java.lang.IllegalArgumentException: No method in multimethod 'emit-constant' for dispatch value
Hmm. That destructuring problem reported yesterday by @troyclevenger looks slightly similar to the problem reported here https://github.com/r0man/sablono/issues/67 — but just slightly. In both cases it's about map destructuring. @troyclevenger, when you wrote "If I change it to a let statement it works", did you mean destructuring in a let form inside defcomponent?
http://stackoverflow.com/a/17495553/1481316 copy pasting this, into mier's browser repl, results in an error:
#error {:message "cljs.core.find_macros_ns.call(...) is null", :data {:tag :cljs/analysis-error}, :cause #object[TypeError TypeError: cljs.core.find_macros_ns.call(...) is null]}
Is there anybody using garden on any projects they'd be happy for me to look at? Trying to find some good examples of how to compose my css.
@danielcompton: it cannot be optimized away. Google Closure doesn’t even recommend it’s usage.
@dnolen: what’s the recommended alternative?
@danielcompton: I just wouldn’t bother. If you absolutely must you have cljs.pprint
.
@danielcompton: also if you don’t care about DCE issue, then use goog.string.format
So (gstring/format "site: %s user: %s time: %s" site username time)
should just be rewritten as
(str "site: " site " user: " username " time: " time)
?
@danielcompton: that’s not what I said above.
@dnolen: Yeah, I eventually figured it out. It was a combination of misunderstanding/not reading the docs, and thinking that I could define a macro in the same file, and all would be fine.
@dominicm: yeah ClojureScript has never supported inline macros, and that's unlikely to ever change due to code size issues (bootstrapped CLJS is 300K gzipped vs. 20K for a minimal CLJS app otherwise).
also there are portability issues we don’t want to create even in the bootstrapped case.
@dnolen: gotcha, so it just has costs to usage, and is generally avoided? Thanks for the feedback.
@dnolen: Yeah, it's understandable. I eventually stumbled across that. This is my first ever venture with Cljs, coming from playing with lots of Clj, so still getting my bearings on what's different.
@jrychter I meant changing the loop to a let. There seemed to be something between the loop bindings and the reify bindings that ws causing the problem.
not bad for a Lisp that compiles to JavaScript, ClojureScript broke 5000 Github stars https://github.com/clojure/clojurescript
should with-redefs
on a fn in a library I use work as expected in CLJS? (used during tests)
@martintrojer: it depends on what you mean by “work as expected"
well then, I guess that answers the question I’m trying to stub out cljs-http during test runs.
I guess I have to write wrappers myself?
well, I mean, cljs-http is all core.async-ed up. But I guess wrapper-fn’s and a dynamic var would solve my problem
@martintrojer: core.async doesn’t solve the no threads no bound-fn
issue
if you’re using cljs.test
you can use the async test support and enforced serial execution to ensure that your with-redefs
hold for the tests you care about
yeah, the single-threaded-ness is a bit of a mind bender here since all the backed up go blocks doesn’t run until after the tests.
(where the http access actually happens)
@martintrojer: I dog-fooded cljs.test
on core.async
so there are OK examples there
cool, I’ve got something working over here so I’m quite happy
OMG, the penny finally dropped on the cljs.test async stuff. That’s is just what I needed! Thanks @dnolen!
@martintrojer: heh that’s what I was saying
sorry, I’m slow
indeed
Im actually struggling with loading an svg and rendering it with reagent completely in clojurescript. Is this possible at all?
I want to recreate the svg as a reagant structure, so I could change it in the browser.
@dnolen phantomJS seems to crash when the (async done …) is the last value in a deftest (like the docs says).
Its fine in chrome
Making the (async done …) block not the last value in deftest makes phantom happy, but the any (is …) assertions is ignored
@martintrojer: don't know or want to know anything about phantomjs sorry.
hrm 😞
@martintrojer: have you tried slimerjs?
very cool Ludum Dare entry by @shaunlebron http://shaunlebron.github.io/gh4st/
@dnolen: , was fun building a game again!
❤️ cljs
@dominicm: @dnolen: I might be misinterpreting what you guys are saying, but (macroexpand ‘(cond :else :foo))
works fine in a cljs source file
you might be referring to limitations mfikes talked about here: http://blog.fikesfarm.com/posts/2015-09-05-runtime-macroexpand.html
@shaunlebron: right but it’s not the macroexpand
that people expect from Clojure, not a function
@dnolen: I’ll make note of that in the docs, thanks
@shaunlebron: it’s possible for bootstrapped ClojureScript to do real macroexpand but the details would need to be sorted out, @mfikes wrote about this a bit
I swear this came up in conversation a while back, but cant' find it ... I can't seem to get a repeatable build out of lein ring ubwerar
. Sometimes it's grabbing the prod cljs, sometimes it's getting the dev (which looks for a missing goog). Sound familiar to anyone?
@martintrojer: can you post the script that is running the tests? It is not trivial to get it right.
@bensu: https://gist.github.com/martintrojer/9a8e78126063705fabdb Please note that this setup is fine (running on circleci) for everything but the cljs.test.async macro which crashes it.
the cljs.test.async stuff works perfectly in Chrome (via figwheel)
@curtosis your description of the issue is a bit unclear, do you mean production js? You don’t generally deploy cljs to production.
@curtosis, @dnolen: i’m assuming you mean prod env folder cljs (similar to chestnut env setup)?
@afhammad, @dnolen : yes, I mean the prod env folder profile (e.g., :advanced
optimizations)
@curtosis: Alwasy do a clean before running the uberwar task should fix it
what seems to be happening is that the uberjar profile isn't being properly invoked.
@mitchelkuijpers: I've tried that.
@dominicm: @dnolen: following up on macroexpand
notes, pushed some docs here: https://github.com/cljsinfo/cljs-api-docs/blob/catalog/refs/cljs.core/macroexpand.md
which, apart from being extra (probably-duplicative) work, hints that something's not right in the uberwar task.
@martintrojer: I replied directly on the gist to reference the code, I hope it helps.
@shaunlebron: looks good
It looks ok (the WAR doesn't include the js/goog/ directory like the dev profile does)
though the ubjerjar task gives a nice "compiling app.js from (src-cljs/app.cljs env/prod.cljs)" message
(guessing on the message, it was a while back) but it doesn’t appear in the with-profile
version of ring uberwar
.
otoh, that may just be a difference in how the cljsbuild step is called by uberjar
vs ring uberwar
.
Hmm... I'm stumped with my module thing. A non-require lib using React like reagent works, yet react devtools don't seem to : | And it's a kinda broken trade to get modules working sacrificing debugability in the process : X
@curtosis: I'm sorry but I didn't understood you response Did it work or is there still a problem?
@jaen: what doesn't work? What I've found about react dev tools is that if your dependency tree brings in both dev tools and sans dev tools, google closure uses both and there is an externs clash ("ERROR: externs duplicated"). Is that the problem?
@bensu: hm, not sure how the dependency tree can bring in react dev tools, since they are a chrome extension not a jar; and besides right now I'm wgetting all dependencies by hand, so it can't be that - you can't really bring in unwanted dependencies if there's no dependecy resolution going on ; d
(I'm hesitant to push a new war to the server while I have people testing my previous successful build)
Hahahah. What the actuall hell. It turns out React devtools are now available for Firefox. So I install them, open my test project and lo and behold, the devtools work o_0
@jaen do you have the beta version of the devtools for Chrome? (there was breakage at some point which might be related)
I thought that maybe my module rewriting shenanigans are messing something up, but no it turned out to be simpler xD
@bensu: turns out I had to redeploy anyway, after the jvm crashed and forced a reboot. looks good! thanks again
@venantius: you mentioned middleware and the cljs-repl. Just wanted to let you know that you can add functionality through the ClojureScript repl :special-fns option which is much more direct. of course you have to invoke your own REPL.
There has been a steady uptick in the number of times my ClojureScript videos are being watched. I'd like to conclude that interest in CLJS is growing. Don't want to speak too early but its an interesting phenomena.
@mfikes: if I didn't have a startup/life-consuming-job I would offer as the andriod dev 😞 very excited about this.
@bensu: yeah. :) one nice thing is JavaScriptCore is very easy to build on Ubuntu. Makes me think Android is within reach.
@dnolen: if I understand correctly goog.provide('some.namespace')
creating a global object named some.namespace
is part of how GClosure modules function and it's neither possible nor desirable to disable that, yes?
Hah, then I need to figure how to deal with that - since if I have goog.provide('React')
that's gonna conflict with Reagent expecting js/React
to be well... React, not GClosure namespace object.
and yes should this new way work in the future, people will want to change how they load/interact with React
@dnolen: @jaen: I'm curious, doesn't the var React = goog.provide('React')
contain both goog
's properties and all of React's properties?
So, I named the react/react.js
module React
, react/lib/ReactElement.js
- React/ReactElement
and I end up with a skeleton of GClosure module namespaces (that is, properties are there, but are empty) and nothing that comes from React
And if I'm looking at goog.exportPath_
correctly then it seems it doesn't merge what's already there, just overwrites with {}
require
and provide
are just a fiction, for runtime dev they aren’t even really used, you must provide deps.js
for this reason
@dnolen: yeah, that is what @jaen said. I didn't know it wasn't used during dev. so it's only a hint to the compiler then?
@jaen: as I said, for runtime load you must provide deps.js
which has all the necessary goog.addDependency
calls
this is the reason :none
is so weird w/o :main
. Because you need a script tag that calls goog.require
before you do anything
this uses deps.js
to load everything in order synchronously in the browser via document.write
Right. Though this is all in Clojurescript's domain; I should not be mucking with that if I can just provide it with sensible module names.
@jaen: looking at the generated file out/lib/react/React.js
it seems like the big React object is being held under React$$module$react$lib$React
Hm, then that's interesting, because when I did what I described (that is named a module React
) it didn't exactly merge (reagent couldn't find createClass
for example). Unless I'm misunderstanding what I've done.
@bensu: yeah, GClosure renames all vars to that dollar-y casing because as far as I understand all vars in GClosure are effectively global.
As far as I udnerstand that's the desired behaviour of what GClosure guys implemented for CommonJS translation
@jaen well Reagent is introducing yet another variable, I would remove that, unless you already sure it works w/o it and you’re just trying to solve why Reagent breaks in this scenario
but also React may do something weird like write a global if it’s loaded into a browser
But then you have to require them with same names and I don't think people will fancy doing (:require module$react$addons)
so I changed it to translate module name into (:require react.addons)
instead (more or less)
@jaen so I wouldn’t mess with that part of it yet. I would stick w/ mangled names for now.
Honestly? I wanted to try doing it in the compiler but I couldn't exactly grok how to put it inside, hence how I did it.
It's one big ugly hack, but at least it has the positive effect of possibly motivating people who can actually code that ; d
(I ask since I'm reading https://github.com/jaen/custom-module-loaders where I can't find reagent)
Interesting. when you are ready, push it and leave a comment with the empty react problem. I'd love to try again tomorrow
hahaha we are on the same timezone then. you should be definitely hacking on that. I just have a meeting in the morning. bye!
@dnolen: yeah, I'm starting to wonder if being able to do React.ReactElement
is too much of a convenience in a wrong place. The interactions with goog.provide
get vexing. I suppose it would make sense to keep generating module names like module$react$lib$ReactElement
for starters and when that's done and in compiler, only then start figuring out how to make the requires nicer looking.
It could just be a desugaring pass then - if no React.ReactElement
namespace is found then it desugars into module$react$lib$ReactElement
(there would have to be some way to have it keep track of how dotted names correspond to dolar names) and tries again and if that does not succeed as well, then it's a require error.
But I'm afraid I wouldn't know my way around the compiler well enough to be able to write something like that.
@bensu: feel free to take a look at it tomorrow if you want - https://github.com/jaen/custom-module-loaders/tree/react-simple - but as per what I said to dnolen just now I start realising this is probably a dead end and retaining mangled module names and then adding some desugaring to the ns macro and/or compiler on top of that would be a more sensible way to go. Not sure if I'll be up to par to implement that though (probably not). But none the less this exploration was a good use of time it at least uncovered some issues such translation will inevitably face and how to not solve them ; d