I don't have a twitter account, but be my guest!

@bhauman: ^

what’s the deal with cljs.core/format? it seems like it was removed at version 1885?

@mattly just doesn’t exist anymore, created DCE problems

Has anyone has tried to setup figwheel to work with non-CLJ api server by making the figwheel server a proxy server?

@kamn, no but I've done something similar in between some http services. You probably want to use rfn from compojure: https://github.com/weavejester/compojure/blob/1.4.0/src/compojure/core.clj#L190

and shove the resulting handler into figwheels :ring-handler

@lfn3: Thanks for the response! I quickly(and poorly) setup something similar but I was hoping there was some sort of concrete plugin to do it.

I have a

{:foreign-libs [{:file ""
                 :provides ["com.inspectlet"]
                 :requires ["my.inspectlet.init"]}]
 :externs ["inspectlet.ext.js"]}

(ns my.inspectlet.init
  (:require [goog.object :as o])
(o/set js/window "__insp"
  (clj->js ["wid", "12346236"]))

Is the my.inspectlet.init namespace is even a google closure module name?

If :optimizations :none it works, but :optimizations :advanced or :simple puts the inspectlet.js before my init code (hence fails)

@onetom: maybe just use :foreign-libs for the init js as well? something like: https://www.refheap.com/108833

(w/ that approach, inspectlet-init.js may require an externs file as well, not 100% sure on that)

yeah, that's what my colleague was recommending too, but in reality it's pulling that number from a file, using a clojure macro, so it's not that static

plus we have a few other libs - like HubSpot https://js.hsforms.net/forms/v2.js - to integrate too which has similar issues

seems that the problem that I was bit by yesterday was two folded: rookie mistake and not having proper :key https://github.com/Day8/re-frame/wiki/Creating-Reagent-Components#form-2--a-function-returning-a-function

also how does :foreign-libs relate to google closure :libs? where are the docs for such stuff? im looking at https://developers.google.com/closure/compiler/docs/api-tutorial3?hl=en but it doesn't seem to go into enough details

Hello, if anybody is familiar with re-frame, could you please take a look at my SO question here http://stackoverflow.com/questions/32236040/depend-on-both-input-arg-and-derived-collection-in-re-frame.

@nidu FYI there is a re-frame channel on slack

@kamn ouch, thanks. My mistake

@bensu: Very nice! Does that only work for Closure-compatible JS? Or doesn’t that matter since you don’t have optimisations on?

@pupeno: Not necessarily a bug... but definitely a design flaw.

@ricardo: context?

@pupeno: pushy and how it's handling external links

Ah, yes. Did you report it?

Writing it up now.

Cool. I also dislike that pushy only gives the url starting at the path, which would be problematic for multi-domain applications.

pupeno: Definitely. Here's the report in case you want to add something: https://github.com/kibu-australia/pushy/issues/7

I might submit a pull request that follows that regexp approach I mentioned, using an extra parameter that just matches everything by default.

Thanks @cfleming! I haven't tried with any other js module system. I might do it tonight and start using @maria additions to the compiler.

@bensu: let me know if you run into any problems with those js module compiler options 😉

@onetom: the wiki is the best the place to go for looking about compiler option information

in this case you want to look here https://github.com/clojure/clojurescript/wiki/Dependencies

I’ve been speaking with @onetom on the subject on different channel

My understanding is that foreign-dep files are always just prepended to optimized output

@yogthos re: string replace, known issue CLJS-1304, have patch that needs rebasing from @andrewhr

@cfleming: @val_waeselynck: ClojureScript gets browser support going back to IE6 from Google Closure for browser stuff and the JavaScript we generate is the JavaScript standard from 2001.

@lvh I haven’t said any such thing wrt. to not using cljsbuild - only expressed my own personal inclination to use little additional tooling over what ClojureScript provides itself. To this day ClojureScript actually tries to avoid introducing changes that would affect cljsbuild users due to its incredible popularity.

@pri: glad to hear the Garden tests are running faster than ever

@sdegutis: re: deprecating the mies node templates, don’t have time for extra projects anymore and most of the starting from nothing issues that I was personally interesting in got addressed with Quick Start.

@bhauman: re copying closure libs that follow namespace/classpath conventions should work in latest releases.

@juhoteperi: yes foreign deps never go through Google Closure minification, too many issues.

@dnolen: is there any way to influence the order of the foreign deps? or is it a bad idea for some reason?

@onetom: dependency order is established via :requires

also should be covered in the link I sent earlier

sorry, i will read that again 1st

@dnolen: welcome back

@borkdude: thanks!

@onetom: have you considered using closure defines http://www.martinklepsch.org/posts/parameterizing-clojurescript-builds.html

@domkm: I found CompiledScript in nashorn, but I’m still trying to figure out how to use it. I couldn’t find a single example saying “this doesn’t work"

@dnolen: thanks, will add this as suggested by @cfleming

@dnolen: if you're not too busy, could you have a look at the FAQ, at least the list of questions too see if anything's missing? You probably know better than anyone else what questions JavaScript developers have when considering ClojureScript, your input would be invaluable here https://github.com/vvvvalvalval/reagent-phonecat/wiki/Questions-about-ClojureScript

@val_waeselynck: sorry I don’t have time to look at all these things anymore

but happy to answer questions

it’s just nigh time for other people to understand all these ins and outs for themselves

@dnolen: I ran into some problems using 1.7.48, fixed by upgrading to 1.7.107 (on a windows machine). Latest stable on github is 1.7.48, is there anything I can do to help test one of the newer versions so it can be listed as the latest stable version?

@shaun-mahood: if you need the windows fix use the pre-releases

people need to get used to going to these for to minor bumps and quick fixes

there will be another big release down the line, but pushing for these appearing once every two months or so unless something truly pressing is required

there are other windows related things happening, and would rather to see this stuff go out all at once.

@dnolen: Ok cool. Have you got an easy way to test new releases on Windows or is there anything I can do to help as new releases are out?

@shaun-mahood: we need a ton of help on our Windows support - this is a big first step https://github.com/clojure/clojurescript/commit/d7740694be49ba38c778deae59a3e047ca881631

try this stuff and make sure these scripts work for you - should make contributions from Windows users dramatically simpler

until this commit was the pits

more commits like this welcome

equivalent scripts for maven local install & building the uberjar would be most welcome

@dnolen: Sounds good, I'll give it a try and see what else I can work towards in the future.

From the perspective of just using clojurescript, there haven't been any real hurdles for me getting setup on new machines or anything like that - with leiningen, figwheel and cursive it's about as easy to get started using it as any other new development environment, and significantly easier than most.

@shaun-mahood: for sure, but simplifying Windows contribution is an important goal

happy to prioritize these things and push them through quickly

@dnolen: ok, I understand. If I had only one question, it would be: What is the preconceived notion which deters the most JavaScript programmers from adopting ClojureScript? (expect for the fact that parentheses repel them)

@val_waeselynck: this is really nothing much I spend time thinking about

but I would summarize that programmers are tribal instead of caring about problem domains

I would consider myself an expert level JavaScript programmer who was no issues with using ClojureScript - but because I care about solving problems and I now prefer solving problems with a Clojure dialect. But I also have zero qualms about writing JavaScript if I have to.

@dnolen: thanks!

@val_waeselynck: sometimes you’ll hear people say “I want to use ClojureScript, but I want to use Gulp"

which is completely missing the point

stuff like that

yeah, people only think about what they lose of the things they're used to

instinctive reaction

Oh! I know! Now we have cljs-in-cljs, let's write a gulp plugin for ClojureScript

(just kidding)

@val_waeselynck: ClojureScript is built on technology hardly anyone uses for JavaScript - Google Closure Compiler and Google Closure Library

it’s take a very long time for the community to understand the value of this approach

@dnolen: Sorry man; I didn’t mean to put words in your mouth. That’s just the impression I got from a conversation we had where I was using cljsbuild.

^ this

but I was around when jQuery & Prototype were radical

and remember quite well how long these things took to get adopted

@dnolen: I don’t understand why; I know exactly one person who used it before this, and it basically had superpowers the entire time

(my favorite example being foreign module support for cljs :))

@val_waeselynck: all I know is that JavaScript people read my blog and my impression is that they are impressed by how many client side programming issues we solve in a complete package.

having to cobble these things together manually with JavaScript is a huge downside.

@val_waeselynck: all this said, the vast majority of literature / documentation around client side best practice is written for JavaScript developers - and that’s a huge factor.

React, functional approaches are still seen as very cutting edge

@val_waeselynck: so perhaps the biggest detractor “my friends don’t use ClojureScript"

@dnolen: don't you think there is a selection bias on these JavaScript readers?

@dnolen: yeah this last one we can't do much about

@martinklepsch: I’m following your post on parameterizing clojurescript builds, but I’m getting severe warnings from closure at compile time during advanced compilation 😕

@tel: what do they look like?

they come in pairs

WARNING: /Users/tel/Dropbox/proj/reify/fisher/resources/public/js/out/reify/fisher/ui/services/login.js:15: WARNING - Misplaced type annotation. Type annotations are not allowed here. Are you missing parentheses?
/** @define {string} */;

Aug 27, 2015 11:21:42 AM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/tel/Dropbox/proj/reify/fisher/resources/public/js/out/reify/fisher/ui/services/login.js:17: ERROR - Missing @define annotation
goog.define(“XXXXXX”,"XXXXX”);

@val_waeselynck: perhaps, my impression is that most of the folks that like what I write seem to be fairly experienced JavaScript developers who are well aware of all the various issues ClojureScript tries to solve.

@tel: are you on the latest version?

thought I was

@tel: this problem was reported and fixed after initial release

1.7.58?

@val_waeselynck: but ClojureScript appears to also have a strong draw on developers who are “full stack” who don’t really believe so much in the front/back split.

the github says 1.7.48, but somewhere I saw 58… maybe that’s an advance branch without all the commits?

keep in mind that there are tens or hundreds of "compile to JS" languages, so the bar is really high for someone to even spend 5 minutes thinking about it -- especially since they're often exhausted with the rate of change in JS itself

in a 5 minute frame, clojurescript gets reduced to "weird syntax, no types"

@tel try 107

1.7.107?

ah

@tel: yes. fix was added after 1.7.58

gotcha gotcha

didn’t realize I was behind

one always is behind 😛

i tend to pique people's interest re: clojurescript when talking about the problems that are mostly solved by google closure -- DCE and x-module code motion are insanely better than what most people are using

big value in clojurescript just putting a pretty face on super valuable but widely ignored JS tech!

@nullptr: agreed

@martinklepsch: the faster you learn about it... 😉

@nullptr: One thing I've really liked about moving to clojurescript is that the rate of change is actually manageable

@nullptr: I also think the community getting behind things like Figwheel is also big - just a palpable community interest in doing things better

absolutely -- figwheel is a great hook to earn an extra 10 minutes of consideration, at which point the deeper value can be considered

@nullptr: @dnolen about that, is there a significant 'JVMphobia' among the JavaScript developers?

@val_waeselynck: sure, but not anymore than there is in the Ruby, Python, whatever community far as I can tell

@val_waeselynck: I had huge JVMphobia as a Windows .net and javascript developer. Still do, actually, to the point where I significantly prefer using cljs over clojure because I don't have to worry about anything java related at all.

@val_waeselynck: ah, but to voice something that outsiders often miss - ClojureScript doesn’t cater to JavaScript developers at all. It caters to developers period.

so “how can we make ClojureScript better for JavaScript developers” specifically is totally uninteresting and has never been a goal.

if we had done that … probably none of us would be here in this channel 4 years later

there’s also a counterpoint to this

@dnolen totally agree, I intend to emphasise that Clojure was designed to make programming (not js) better

Clojure doesn’t disdain the JVM, and ClojureScript doesn’t disdain JavaScript

all of these other advanced programming languages could have gotten to where we got a long time ago

except they stick their noses up at solid tech for “reasons"

yeah, there is so much “cross hate” going on in “programming communities"

well, every shiny new technology is in a way telling you you've been wasting your time, I can imagine that people who have become experts in some technology get defensive about that

even tho I don't personally think that's a good attitude to have

The clojure community is definitely the most friendly one I've seen as far as how it relates to other languages and existing tech. Pretty refreshing.

i think that is something to do with humans being generally afraid of things they don’t understand.

@martinklepsch: just to full circle: upgrading fixed it, thanks

do clojurescript atoms retry? eg. thanks to core.async or event handling functions

@shaun-mahood is this not true of all early-adopters common ties?

*communities

anyone run into (void 0) is not a function errors on advanced compilation?

it seemed like closure for some reason jammed it into the middle of a string… that ought to be dead code anyway 😕

@noisesmith that would surprise me, you don't need CAS on a single-threaded runtime

@val_waeselynck: I don't know. I've been watching and playing with new languages for a while, and it seems like the majority of them have had a lot more "us against them" mentality towards other existing languages. I think that clojure and clojurescript being hosted, and having good interop, makes it so that we don't have to make as much of a wholesale switch. Moving to something like Python or Ruby pretty much requires you to completely throw out your existing tech, but we can use clojure with the jvm, clr, and javascript, and in existing projects. Other communities may be super welcoming and friendly to the community members, but not other technology.

[r("ws://"),r(n((void 0)())?location.host:"localhost:3449"),r("/figwheel-ws")].join(“")

val_waeselynck: my though was what if an event gets handled while a swap! is in process

does swap! have the power to block event handling until it returns?

@noisesmith this never happens because js is single threaded

you event is queued while the js thread is busy

val_waeselynck: what about a swap! that contains some core.async ops inside it?

it's not swap blocking it it's the event loop of js

OK

martinklepsch: what is the status of 107? is it a stable release? are goog-define statements not around in earlier releases?

this (void 0)() bug is only happening in 107

I might rip out goog-define if it’s a show stopper : (

@tel: the semicolon fix is in js* not goog-define

@tel: tried debugging the void issue with :pseudo-names true etc?

nope, was looking up actively how to debug it

will try that one now!

@noisesmith: maybe this video can help you get your head around the js events loop: https://www.youtube.com/watch?v=QgwSUtYSUqA

val_waeselynck: core.async yields to other core.async tasks - couldn't core.async ops inside a swap! lead to a retry?

all I am asking is if there is any case where a clojurescript atom would retry, hypothetically

@noisesmith: no, using core.async in a swap changes nothing about the fact that your function will return immediately

@noisesmith: well I did not implement swap! but I don't see any reason it would

[$cljs$core$str$$("ws://"),$cljs$core$str$$($cljs$core$truth_$$((void 0)())?location.host:"localhost:3449"),$cljs$core$str$$("/figwheel-ws")].join(“")

$cljs$core$truth_$$?

I guess this isn't strictly a cljs question, but anyone seen a case where figwheel won't run due to a ClassNotFoundException, but running from the repl (which uses the "missing" class) works fine?

@noisesmith: here, no retry https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L3998

val_waeselynck: the source references retries, and defines compare-and-set! but I don't know how much of this is legacy from clj https://github.com/clojure/clojurescript/blob/8b7177a579d52a146d19902a19aa92708a567983/src/main/cljs/cljs/core.cljs#L4013

@noisesmith: atoms do not retry in ClojureScript, you only need that if you have multiple threads

val_waeselynck: looks like nothing actually uses compare-and-set! though, so you are likely right that I wouldn't see retries

dnolen: OK, thanks for the confirmation

maybe that’s just somewhere in figwheel itself—I guess that’s why people include certain source files only in prod or dev

@tel: I had figwheel compiling in advanced but it's really not intended to be included in advanced builds at all.

@tel: thats also why I have the figwheel client configuration in the cljsbuild config. So that its easy to exclude it from advanced builds.

gotcha gotcha

I was following the chestnut model where they were calling on sidecar explicitly

but I guess I have to go all in to make that work

@curtosis: Fighweel follows the cljsbuild method of creating a sub environment for compilation this could exclude certain lein configurations. https://github.com/emezeske/lein-cljsbuild/blob/master/plugin/src/leiningen/cljsbuild/subproject.clj#L97-L112

hmmmmm.

so your repl env is probably different from the cljs compilation env

so it would seem.

my guess is that you are leveraging the built in :ring-handler?

yes, I am. and just looking at the cljsbuild method, I suspect my :java-source-paths is the culprit, since the class in question is indeed a Java class, and I don't see that getting pulled over into cljsbuild. Because, really, why should it?

@curtosis: this is where I suggest that the server be independent from figwheel

correction: my :ring-handler is using one of my server classes, which yadda yadda yadda... but perhaps that's what you meant.

but hmm.. the figwheel :ring-handler shouldn't be my server, should it?

only if you provided your server handler as an argument

parameter

@domkm: I’m trying to figure out how you ensure no more than one thread uses the same scriptengine, do you remember?

I did.. I have :figwheel { :ring-handler my.code/app ...} which I think came from the luminus template originally.

I may have my mental wires crossed, but right now I'm not sure why figwheel would need the same :ring-handler as the server code.

if you are running the server seperately from figwheel then it doesn't.

also, I swear this was working before I left it alone for 3 weeks. 😛

I'm going to go eat

thanks for the help... I'll give that a go!

@bhauman: commmented out the :figwheel { :ring-handler } and it works like a champ. No clue how it was working before... apparently a http://www.catb.org/jargon/html/S/schroedinbug.html. thanks again.

@pupeno: Easy way is to just stick it in an atom and disj/`conj` renderers so only one thread has access. I'm sure there's a better way to do it like a real pool though.

@domkm: I’m not sure I follow. BTW, this is my route definition: https://gist.github.com/pupeno/0aca674623f4f3530d8a

Do you call render-app a renderer?

@pupeno: https://github.com/DomKM/omelette/blob/master/src/omelette/render.clj#L44-L57 This only allows one thread at a time to access each renderer.

domkm: wouldn’t that be a bottleneck with enough requests?

@pupeno: It creates more renderers as needed. There is certainly a way more performant way to share mutable resources on the JVM but I am not a JVM expert so I just did a quick Clojure shortcut.

So, you implemented your own pooling mechanism? Isn’t there some reusable library for that?

@pupeno: Yes, there almost certainly are. Use one of them.

@pupeno: Omelette was just a proof-of-concept. It's not production-quality.

Hi. Has anyone seen :closure-defines munging appears off in 1.7.107? Neither example in https://github.com/cljsinfo/cljs-api-docs/blob/catalog/refs/cljs.core_goog-define.md works because your-app.core has to be your_app.core

@cldwalker: need more information, you haven’t stated the issue clearly

are you saying it doesn’t get munged at all?

@dnolen In :simple mode, I’m not seeing vars overridden with values specified in :closure-defines. Following the examples don’t work for me. Only if I change the example to {“your_app.core.DEBUG_BANG_” true} does it work

@cldwalker: yeah that’s just a typo in the docstring

@dnolen ok and the same behavior for symbol as well e.g. {'your_app.core.DEBUG_BANG_ true} right?

@cldwalker: no

@dnolen Hmm. I’m seeing a stacktrace for :closure-defines {'three-word-ns.app/websocket-url "BAZ”}

@cldwalker: still not enough information to establish context

lein? no lein?

@dnolen https://gist.github.com/cldwalker/456fa489b77cc5d5204c . Happy to open a reproducible jira issue too if that helps

@cldwalker: there’s no need to open issue

you are using lein

everything in lein is implicitly quoted

we’re not going to change the docstring for lein users

@dnolen Gotcha. Wasn’t aware

@cldwalker: these details were missing from this https://github.com/clojure/clojurescript/wiki/Compiler-Options#closure-defines

now fixed

@dnolen Thanks for the help! Enjoying cljs with React Native

@cldwalker: sweet!

@cldwalker: are you using om w/ ReactNative - something else?

@donmullen: reagent for now but still weighing our options. om.next is enticing

@cldwalker: indeed - enjoyed David’s talk — @dnolen what’s the timeline for om.next public release?

@donmullen: in the grand Clojure tradition I don’t do timelines

it’ll be ready when it’s ready

lol!

planning on spending some time on this month though - that’s about all I can say

you are a wise man, sir