This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-12
Channels
- # bangalore-clj (4)
- # beginners (77)
- # boot (71)
- # cider (10)
- # clara (1)
- # cljs-dev (52)
- # cljsjs (28)
- # cljsrn (1)
- # clojure (390)
- # clojure-dev (5)
- # clojure-india (1)
- # clojure-italy (5)
- # clojure-nl (24)
- # clojure-poland (4)
- # clojure-russia (123)
- # clojure-spec (71)
- # clojure-taiwan (2)
- # clojure-uk (8)
- # clojurescript (236)
- # core-matrix (6)
- # cursive (19)
- # datomic (16)
- # defnpodcast (2)
- # editors (1)
- # emacs (36)
- # garden (2)
- # hoplon (5)
- # jobs (1)
- # jobs-discuss (10)
- # juxt (47)
- # luminus (4)
- # lumo (6)
- # off-topic (207)
- # om (1)
- # onyx (20)
- # pedestal (40)
- # perun (2)
- # re-frame (8)
- # reagent (48)
- # ring (2)
- # ring-swagger (2)
- # specter (13)
- # unrepl (89)
- # vim (6)
btw google-closure.js should allow lumo and planck to do advanced compilation in the future, if they want to go that route. So that could be a thing.
I haven't heard anybody announce any major progress in putting those pieces together though.
I don’t find an issue in Jira, as the addition of var-set
(and var-get
for symmetry) to CLJS discussed?
I'd like to have it, for uniformity. But I think I've heard it intimated before that something like (set! (.-a js/cljs.user) "val")
should be sufficient. And that the semantics between clj vars and cljs vars are different. But for cljc purposes, why not, right?
I missed your reply earlier: the problem is that (set! (.-a js/cljs.user) “val”)
requires the var name to be known at compile time.
I can work my way around it but var-set
would be great
@U3E46Q1DG vars do not exist at runtime in CLJS so no var-set
.
just use a volatile!
, you can deref
that and vreset!
looks like var-set
if you squint a little
athheller it’s “dynamic" vars that I want to pass around. So far I use a macro (dynvar *foo*)
which expands too (fn ([] *foo*) ([x] (set! *foo* x)))
As far as I can tell *out*
is not used despite being defined. But yeah basically a host of standard dynamic cars.
I'm reviewing this now: https://swannodette.github.io/2014/12/17/whats-in-a-var
Here is the work around for my dynamic vars conveyance needs https://github.com/cgrand/cljs-js-repl/blob/master/src/net/cgrand/cljs/js/repl/dynvars.cljs
absolutely not a fan of bindings in an async context. core.async doesn't know about your bound-fn
so it won't work.
It’s not a general purpose solution. You would have to bake it into core.async somehow. But for my goal it’s ok.
Upgradable means that from inside the repl you can take control over input and output.
Last thing, the one that justifies this binding stuff, I want to support several session at the same time (socket repl).
re: static repl... basically, cljs.reader/read-string, pr-str, some transforming of function calls into .call
and .apply
calls, and you might be able to create what looks like a repl, without the compiler. Just simple, runtime compilation of forms into .call
s. Could be useful for, for instance, providing a DSL interface to some application without needing a whole self-hosted instance.
I remember hearing a while ago that (.-someproperty js/some.object)
should be preferred over js/some.object.someproperty
by I see the latter in the wild more and more often. Is the former still preferred? and if so, why? Because of the method/property ambiguity?
Unfortunately I just discovered that just requiring cljs.pprint
(or cljs.stacktrace
) without using anything from it ruins dead code elimination in :advanced
mode. Additionally def-ing a static map with more than 8 keys causes a huge code bloat (goes from 5k to 300k bytes). Details here[1]. Any insights for solutions/work-arounds welcome.
[1] https://github.com/binaryage/cljs-devtools/issues/37#issuecomment-293575471
@qqq see https://anmonteiro.com/2017/02/compiling-clojurescript-projects-without-the-jvm/
@darwin I discovered a new neat feature in the Closure Compiler that allows stripping code before any actual optimizations happen
> (.setStripTypePrefixes compiler-options #{"cljs.core.prn"})
.. strips every (prn ...)
call when optimizing
but to extend on your problem: there are a lot of constructs the CLJS compiler generates that cannot be removed by Closure without help
@thheller thanks, that is definitely useful to know, but in this case I’m afraid it won’t help me, cljs-devtools is a library so I don’t really have control over compiler options, and I don’t want sniff for current settings and muck with user’s configuration in any way
one solution would be to fork both cljs.pprint and cljs.stacktrace and fix them for my use-case, but that seems dirty
but I thought you switched to using :preloads
for devtools which wouldn't include anything in user code in :advanced
?
cljs-devtools could in theory work in advanced mode (if needed) and should be DCE-ed if required but not used
it is a minor issue though, I got dragged into this because someone opened the issue on github
unfortunately this experience makes me trust less DCE claimed by cljs+closure compilers. It is true that hello-world example compiles to few bytes, but when you include something non-trivial or use any “too-dynamic" core method, you are likely pull in whole cljs.core and bump the size significantly…
the big part of cljs.core
are the collections which any reasonable sized app will use
yes but overall cljs.core
is safe. I worry more about any dependency I introduce, since most of them don't really account for DCE
FWIW it is also why I think :main
or :modules
are so important ... code that isn't reachable by :main
isn't included is the easiest path to ensure DCE
I agree, but speaking about core I think at least cljs.core.PersistentHashMap.fromArrays
might be worth looking into, reimplementing it with plain recur could eliminate that unexpected 8-keys threshold trigger.
devtools.defaults.known_features = new cljs.core.PersistentVector(null, 3, 5, cljs.core.PersistentVector.EMPTY_NODE, [cljs.core.cst$kw$formatters,cljs.core.cst$kw$hints,cljs.core.cst$kw$async], null);
seems to be just fine and does not bloat the output
before http://dev.clojure.org/jira/browse/CLJS-1879 {:foo "bar"}
would leave a stray cljs.core.str("bar")
call in your :advanced
output
I'm having some trouble with my non-advanced build throwing off errors Uncaught Error: Undefined nameToPath for cljsjs.react_dom
...but I've got react-dom in my classpath and I can see the right stuff in its deps.cljs.
% lein deps :tree | grep react
[cljsjs/react-dom-server "15.5.0-0"]
[cljsjs/react-dom "15.5.0-0"]
[cljsjs/react "15.5.0-0"]
@timgilbert cljsjs/react-dom provides cljsjs.react.dom
, not cljsjs.react-dom
Well, that's the confusing thing, I don't have any code referring to that namespace AFAICT
....ah, it might be in a library I'm pulling in
Thanks for the tip, will play around more. Mixing cljs with webpack/babel has proved to be an exceedingly bad experience so far
No idea, I'm just trying to get some ES2015 libraries to work in the browser
I don't necessarily blame clojurescript so much as the fact that the javascript tooling ecosystem is its own unique corner of hell
Seriously, it's like "java logging framework" levels of bad
oh I think react does some weird things that makes it not super easy to just drop into clojure
If you stick to ClojureScript packages, react works really well with everything, it's interop with native JS libraries that's painful
Yeah, working on integrating stuff with a large reagent codebase. The cljs bits work really well
also, I think the clojure compiler translates names like foo-bar
to foo_bar
for require paths
Yeah, well the problem is it's a transitive dependency out of a native JS library
Which itself is written in a thieves' cant of combined ES2015 import
statements and commonjs module.exports
bits
Definitely
The philosophy seems to be "whatever this mix of tooling will let through with enough tweaking"
Basically I'm librarifying this: https://github.com/toxicFork/react-three-renderer
So a few of my manifold problems are that this code has its own react dependencies, and there's no actual built .js file to just download and package
So I'm using webpack/babel to get it into a single ES5 .js file I can stick into a jar and require
@timgilbert what version of react does it use?
> Currently supported react version: 15.5.3 ( things break fast when you fly this close to the sun )
How true that is! But I'm just trying with 15.5.0, I assume the comment about flying close to the sun is just regular JS bragging
Have been doing that, yeah
@timgilbert you want to create a library for cljsjs
or for yourself?
Well, for myself although once I get it working I will gladly push it to cljsjs
you can just not tell CLJS about the .js
file you create, you do not need to import it
Another complicating factor is that we need to PRs merged that aren't in the official branch, so I'm working on a private branch at the moment
Well, I do want :advanced
, though I'm starting with :none
for now just to prove it out
It's more that the module ecosystem in JS is immature
@benbot I'd say the interop is fine. Some libraries are harder to use with Cljs tooling as they are supposed to be used with webpack or such.
I agree, yeah
But cljsjs should help and future features like Closure module processing will probably also help with this.
just keep the JS stuff in webpack and do not tell the CLJS world about them, just provide some externs
That's what I'm trying, yeah, but every build or tweak to my webpack config brings a new, unpleasant surprise
Heh, sorry, thanks for letting me vent for moment, channel
Yeah, I've got that part seemingly working at the moment, at least judging from lein deps :tree
Thanks, I'll take a look at it
@lockdown- not that I’m aware of, but how would you leverage them?
@lockdown- I've been looking at it, nothing implemented yet but it seems easy eanough
If/when I get it implemented, it will be integrated into Cljsjs tooling and probably be the recommended way to provide externs for Cljsjs packages
does pprint mess up compilation? with :simple
I get a runtime error $s$$.substring is not a function
that includes pprint in the stacktrace
which is weird because with :advanced
I get a completely different error Cannot read property 'style' of null
@devth I had once problem with ordering of requires concatenations in :simple
mode. My code worked fine under :none
and :advanced
but in :simple
some a function was used before it appeared in the concatenated source file. But this is just an anecdotal experience.
Try to use :pseudo-names
true in advanced mode and use devtools to pause on the first error, then inspect the call stack
IMO :advanced
is pretty well tested, in :simple
mode might be some rare bugs because not many people exercise this mode
the stacktrace originates in pprint
at:
(def ^{:private true} pprint-array (formatter-out "~<[~;~@{~w~^, ~:_~}~;]~:>"))
btwthis line apparently https://github.com/clojure/clojurescript/blob/746432fb0f6dcad1b16f5a9fa5746af364ce5fb8/src/main/cljs/cljs/pprint.cljs#L2838
@devth I think I saw your problem before
do you have :pseudo-names true
?
remove that
it’ll work
I think I opened a ticket at some point
to clarify, what I mean is: your pprint
error is related to pseudo-names true
but your style
error under advanced doesn’t seem related to it
Is there something like brave clojure for cljs? I feel like there’s a bunch of things that cljs can do that I just don’t know about
hi, I’m loading clojurescript from an html import and getting Failed to execute 'write' on 'Document': It isn't possible to write into a document from an asynchronously-loaded external script unless it is explicitly opened.
this is apparently caused by the document.write(...)
bits in the main.js generated from cljs (I’m using boot-cljs). the google tells me switching to direct DOM manipulation would work, i.e. getElementById, createElement(‘script’) etc. didn’t find much by searching on “load clojurescript asynchronously” etc. what’s the best way to do this?
@devth source mapping works OK under :advanced
which might at least help you pinpoint the source of the problem - good odds this is an externs issue though
i have source maps enabled and confirmed they work for most issues but not my Cannot read property 'style' of null
issue, which comes from grommet.js (only under advanced. none works fine).
@mobileink I'm not sure what is a HTML import, but probably the shim JS file generated by :main
doesn't support those. You could add script tags the the HTML file manually, but you will need different tags for none optimizations and optimized build.
You might be able to skip over the shim JS file by loading the code in dev like this: https://github.com/clojure/clojurescript/blob/master/samples/hello/hello-dev.html
that is how dev Cljs builds were used before :main
option
but this will be a bit hard, as Boot-cljs always enables :main
thanks. the old-fashioned way might be the way to go. still deciding whether boot-cljs is the way to go in this case.
Possibly not. Figwheel probably has better support "strange environments". But if you provide small example project with Boot-cljs and this problem I can take a look.
@devth ok I see grommet is a thing over React, sounds like some how you are passing null props
@juhoteperi sounds like i may have to just live with synch loading for now. thx.
@devth hopefully you’re not doing something like trying to pass some custom ClojureScript type to grommet
i'm wrapping every grommet component like:
(def anchor
#?(:cljs (js/React.createFactory (.-Anchor js/grommet))
:clj factory-shim))
I'm trying to mix css animation with Reagent. I'm having a particular problem where an element which is growing from 0% to 100% of its width is squishing the element next to it faster than it grows itself - it's pushing whitespace ahead of it, whitespace which disappears once it reaches its full width, for some reason.
Anyhow, I wondered if there's a channel for visual or animation design with ClojureScript?
hey @U4SKJCP3K , didn't get any replies re: visual or animation design with ClojureScript. Figured out how to fix my individual problem, though. Maybe we should start a channel? 🙂
I find this stuff to be quite tricky.
what does the symbol* convention usually mean? It usually seems to imply a prototype implementation of a function, right? Are there more specific semantics?
@john, One common idiom is when you have (defmacro foo [] ...)
it might wind up rewriting the calling code to use a function (defn foo* [] ...)
Another one is that dynamic variables often use is as a suffix and prefix, (def ^:dynamic *my-var* ...)
Sometime you'll also see the *foo*
convention used for just global variables that aren't dynamic, too
does anyone have any experience using react components with bootstrap here?
react wrapper / cljs (hopefully obvious)
I think I have too, my impression is that it's similar to how you might have a function a
which calls another function a'
in haskell, where the a'
function has a less convenient interface or other implementation details
writing what should be a fairly simple component
(defn panel [title]
(html [:div {:id "ticker-panel"
:class "container"}
[:button {:type "button"
:class "btn btn-info"
:data-toggle "collapse"
:data-target "#ticker"}
title]
[:div {:id "ticker"
:class "collapse"}
"test"]]))
works fine problem is that panel won't stay opencloses a second after it's called
it has something to do with whenever the dom re-renders in response to some other event the panel closes
eh I suppose that's to be expected
ClojureScript 1.9.518 released https://groups.google.com/d/msg/clojurescript/c_9LafTpS4g/xkZGIYPMBwAJ
I'm trying to def a fn into a namespace at runtime, with a name from a string received elsewhere, so that other functions can call the function by the symbol name. I've tried (aset js/my.newfns (str newname) #(some-fn %))
which appears to work at the repl, but it doesn't appear to be taking effect during normal execution (outside the repl)