Fork me on GitHub
#clojurescript
<
2015-08-27
>
bensu00:08:37

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

mattly01:08:38

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

dnolen03:08:29

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

kamn04:08:52

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

lfn304:08:13

@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

lfn304:08:54

and shove the resulting handler into figwheels :ring-handler

kamn04:08:06

@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.

onetom04:08:24

I have a

{:foreign-libs [{:file ""
                 :provides ["com.inspectlet"]
                 :requires ["my.inspectlet.init"]}]
 :externs ["inspectlet.ext.js"]}
It expects window.__insp already being an array w some stuff in it before it runs, which I implemented (essentially) as
(ns my.inspectlet.init
  (:require [goog.object :as o])
(o/set js/window "__insp"
  (clj->js ["wid", "12346236"]))
How can ensure this init code runs before the inspectlet.js foreing lib runs?

onetom04:08:01

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

onetom04:08:41

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

jackjames05:08:40

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

jackjames05:08:04

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

onetom05:08:48

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

onetom05:08:39

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

viesti05:08:39

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

onetom05:08:42

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

nidu06:08:23

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.

kamn06:08:45

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

nidu06:08:26

@kamn ouch, thanks. My mistake

cfleming07:08:12

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

ricardo07:08:46

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

ricardo07:08:50

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

Pablo Fernandez07:08:02

Ah, yes. Did you report it?

ricardo07:08:22

Writing it up now.

Pablo Fernandez07:08:38

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

ricardo07:08:38

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

ricardo07:08:03

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

bensu08:08:32

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.

maria08:08:14

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

dnolen10:08:42

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

juhoteperi10:08:51

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

juhoteperi10:08:05

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

dnolen10:08:03

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

dnolen10:08:08

@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.

dnolen10:08:43

@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.

dnolen11:08:29

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

dnolen11:08:25

@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.

dnolen11:08:57

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

dnolen11:08:10

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

onetom11:08:05

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

dnolen11:08:46

@onetom: dependency order is established via :requires

dnolen11:08:54

also should be covered in the link I sent earlier

onetom11:08:48

sorry, i will read that again 1st

Pablo Fernandez13:08:26

@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"

val_waeselynck14:08:45

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

val_waeselynck14:08:21

@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 simple_smile https://github.com/vvvvalvalval/reagent-phonecat/wiki/Questions-about-ClojureScript

dnolen14:08:23

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

dnolen14:08:38

but happy to answer questions

dnolen14:08:28

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

shaun-mahood14:08:06

@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?

dnolen14:08:38

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

dnolen14:08:53

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

dnolen14:08:32

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

dnolen14:08:15

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

shaun-mahood14:08:51

@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?

dnolen14:08:50

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

dnolen14:08:55

until this commit was the pits

dnolen14:08:22

more commits like this welcome

dnolen14:08:12

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

shaun-mahood14:08:15

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

shaun-mahood14:08:40

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.

dnolen15:08:54

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

dnolen15:08:07

happy to prioritize these things and push them through quickly

val_waeselynck15:08:02

@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)

dnolen15:08:30

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

dnolen15:08:43

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

dnolen15:08:34

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.

dnolen15:08:05

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

dnolen15:08:10

which is completely missing the point

dnolen15:08:16

stuff like that

val_waeselynck15:08:32

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

val_waeselynck15:08:36

instinctive reaction

val_waeselynck15:08:39

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

dnolen15:08:58

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

dnolen15:08:13

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

lvh15:08:17

@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.

dnolen15:08:26

but I was around when jQuery & Prototype were radical

dnolen15:08:34

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

lvh15:08:44

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

lvh15:08:02

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

dnolen15:08:52

@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.

dnolen15:08:16

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

dnolen15:08:37

@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.

dnolen15:08:53

React, functional approaches are still seen as very cutting edge

dnolen15:08:23

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

val_waeselynck15:08:56

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

val_waeselynck15:08:14

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

tel15:08:28

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

martinklepsch15:08:53

@tel: what do they look like?

tel15:08:04

they come in pairs

tel15:08:38

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”);

dnolen15:08:53

@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.

martinklepsch15:08:59

@tel: are you on the latest version?

tel15:08:10

thought I was

martinklepsch15:08:17

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

dnolen15:08:40

@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.

tel15:08:02

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

nullptr15:08:28

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

nullptr15:08:48

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

tel15:08:16

1.7.107?

martinklepsch15:08:37

@tel: yes. fix was added after 1.7.58

tel15:08:45

gotcha gotcha

tel15:08:51

didn’t realize I was behind

martinklepsch15:08:04

one always is behind 😛

nullptr15:08:22

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

nullptr15:08:40

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

tel15:08:26

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

shaun-mahood15:08:10

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

dnolen15:08:47

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

nullptr15:08:09

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

val_waeselynck15:08:31

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

dnolen15:08:15

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

shaun-mahood15:08:10

@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.

dnolen15:08:00

@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.

dnolen15:08:28

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

dnolen15:08:47

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

dnolen15:08:13

there’s also a counterpoint to this

val_waeselynck15:08:24

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

dnolen15:08:25

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

dnolen15:08:37

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

dnolen15:08:48

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

roberto15:08:31

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

val_waeselynck15:08:24

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

val_waeselynck15:08:14

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

shaun-mahood15:08:16

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.

roberto15:08:26

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

tel15:08:05

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

noisesmith15:08:46

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

val_waeselynck15:08:58

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

tel15:08:01

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

tel15:08:04

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

val_waeselynck15:08:21

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

shaun-mahood15:08:27

@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.

tel15:08:40

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

noisesmith15:08:58

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

noisesmith15:08:17

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

val_waeselynck15:08:15

@noisesmith this never happens because js is single threaded

val_waeselynck15:08:48

you event is queued while the js thread is busy

noisesmith15:08:16

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

val_waeselynck15:08:16

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

tel15:08:58

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

tel15:08:17

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

tel15:08:32

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

martinklepsch16:08:29

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

martinklepsch16:08:48

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

tel16:08:05

nope, was looking up actively how to debug it simple_smile

tel16:08:27

will try that one now!

val_waeselynck16:08:45

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

noisesmith16:08:37

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

noisesmith16:08:15

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

val_waeselynck16:08:30

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

val_waeselynck16:08:03

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

tel16:08:12

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

tel16:08:25

$cljs$core$truth_$$?

curtosis16:08:37

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?

noisesmith16:08:10

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

dnolen16:08:45

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

noisesmith16:08:49

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

noisesmith16:08:58

dnolen: OK, thanks for the confirmation

tel16:08:08

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

bhauman16:08:12

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

bhauman16:08:07

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

tel16:08:43

gotcha gotcha

tel16:08:38

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

tel16:08:48

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

bhauman16:08:25

@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

bhauman16:08:10

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

curtosis16:08:18

so it would seem. simple_smile

bhauman16:08:41

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

curtosis16:08:25

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?

bhauman16:08:27

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

curtosis16:08:00

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

curtosis16:08:42

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

bhauman16:08:16

only if you provided your server handler as an argument

Pablo Fernandez16:08:53

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

curtosis16:08:32

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

curtosis16:08:35

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.

bhauman16:08:22

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

curtosis16:08:30

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

bhauman16:08:46

simple_smile I'm going to go eat

curtosis16:08:09

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

curtosis16:08:07

@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.

domkm17:08:31

@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.

Pablo Fernandez17:08:58

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

Pablo Fernandez17:08:11

Do you call render-app a renderer?

domkm18:08:38

@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.

Pablo Fernandez18:08:13

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

domkm18:08:21

@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.

Pablo Fernandez18:08:29

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

domkm18:08:50

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

domkm18:08:26

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

cldwalker19:08:29

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

dnolen19:08:12

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

dnolen19:08:06

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

cldwalker19:08:30

@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

dnolen19:08:50

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

cldwalker19:08:05

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

cldwalker19:08:57

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

dnolen20:08:37

@cldwalker: still not enough information to establish context

dnolen20:08:40

lein? no lein?

cldwalker20:08:42

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

dnolen20:08:02

@cldwalker: there’s no need to open issue

dnolen20:08:10

you are using lein

dnolen20:08:18

everything in lein is implicitly quoted

dnolen20:08:27

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

cldwalker20:08:25

@dnolen Gotcha. Wasn’t aware

cldwalker20:08:35

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

donmullen20:08:52

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

cldwalker20:08:35

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

donmullen21:08:18

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

dnolen21:08:39

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

dnolen21:08:45

it’ll be ready when it’s ready

dnolen21:08:00

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

donmullen21:08:20

you are a wise man, sir