Fork me on GitHub
#clojurescript
<
2015-09-11
>
venantius06:09:32

Are there people using the Nashorn REPL / runtime in Cljs projects? What’s the intended use case?

martinklepsch06:09:15

@jab: there are #hoplon and #boot channels in here as well where you might find people to pair. To install a cljsjs package locally just run boot build-jar

pandeiro11:09:59

Is there somewhere documenting how the compiler treats goog.DEBUG?

pandeiro11:09:36

I had assumed that with :optimizations :advanced, it would be set to false

pandeiro11:09:22

ok seems I have to do it in {:closure-defines ...}? makes sense

pandeiro12:09:35

@mikethompson: is there a way with re-frame to attach an (add-watch ...) to the app's db atom?

martinklepsch13:09:34

@pandeiro: the atom is in re-frame.db/app-db or so so you should just be able to add a watch to that

martinklepsch13:09:20

@pandeiro: goog.DEBUG is true by default you have to manually set it to false even in :advanced

Jakub Holý (HolyJak)13:09:20

Hello folks, I have seen :node-dependencies [..] in some project.clj (a figwheel example), could you point me to the plugin/something that actually uses this entry? I believed it was lein-npm but that doesn't seem to be the case. Thanks!

dnolen13:09:55

@holyjak: pretty sure it is lein-npm, it’s just that the format changed

dnolen13:09:05

@venantius: some people don’t want to install yet another thing and Nashorn REPL reflects modern JS perf (Rhino doesn’t).

bhauman13:09:54

@holyjak: yep it's lien-npm- but a warning I haven't used the server side of that example in a really long time

dnolen13:09:08

@venantius: also all the different standard REPLs helped identify exactly what REPL logic could be shared and what logic needed to be protocolized

Jakub Holý (HolyJak)13:09:28

@bhauman: Thanks. So node-dependencies is the old lein-npm config while nowadays we should use :npm {:dependencies [..]}, right?

Jakub Holý (HolyJak)13:09:50

And run lein npm install prior to starting figwheel?

Jakub Holý (HolyJak)13:09:39

@bhauman: I have just got Figwheel with NodeJS working, would you be interested in a pull req. with the (short) instructions under https://github.com/bhauman/lein-figwheel/blob/master/README.md#supports-nodejs ?

jrychter14:09:46

So recently I have more and more problems which I don't even know where to file as a bug. Right now I'm staring at an error message that Datascript prints, but only when my app is compiled in :advanced mode, and only after switching ClojureScript from 1.7.28 to 1.7.48. In other words, everything works fine with 1.7.28, but going to 1.7.48 breaks things.

dnolen14:09:52

@jrychter: use one of the “pre-releases", we recently fixed an issue uncovered by DataScript

jrychter14:09:31

@dnolen: I'll try that. I wonder what else will break now simple_smile

jrychter14:09:59

@dnolen: checked and confirmed, 1.7.122 does not produce the problem (e.g. it works). Thanks!

dnolen14:09:12

we often cut releases for quick fixes (Windows for example), it always worth looking to see if there’s something more recent that includes the fix you need.

Pablo Fernandez15:09:31

Has anybody seen this error before: Namespace "com.cognitect.transit.util" already declared. in <eval> at line number 19664 at column number 6

Pablo Fernandez15:09:13

Indeed, it is defined at least twice in my generated JavaScript. Seems to run fine in Chrome (with no optimizations) but fails on Nashorn (with whitespace optimizations).

dnolen15:09:45

@pupeno sounds like something is wrong with your build if com.cognitect.transit.util is being supplied twice.

dnolen15:09:12

I double checked transit-js and util is not provided twice

nullptr16:09:11

Had a great time talking cljs last night at a local JS meetup -- very receptive audience https://twitter.com/jdalton/status/642224880092495872

dnolen16:09:10

@nullptr: awesome, sounded like it went great! did it get recorded??? simple_smile

nullptr16:09:35

no — video guy didn’t show up — just slides

dnolen16:09:50

@nullptr slides look great

bhauman16:09:11

@holyjak: I'll take a pull request simple_smile

bhauman16:09:40

@holyjak: no need to edit the readme, but we really need a node.js wiki page

nullptr16:09:52

figwheel demo was a big hit

bhauman16:09:16

great! from the slides, it looks like a really good talk!

Pablo Fernandez17:09:39

@dnolen: what do you mean by checking transit-js is not provided twice? do you mean in my clojure code?

roberto17:09:11

Silly question. I’m probably missing something, but I can’t find any docs on deploying clojurescript in the wiki. Anyone have any pointers?

dnolen17:09:15

@roberto that topic doesn’t make any sense for the ClojureScript wiki

roberto17:09:23

where can I find some info? Trying to deploy my first cljs app, which works fine in dev, but facing some challenges deploying to prod. All of it due to my very little experience.

roberto17:09:53

I’ve googled around, but most of the blogs I’ve found make lots of assumptions about what I should know.

roberto17:09:12

I’m close, I can feel it simple_smile

dnolen17:09:34

@roberto: people can help you if you describe the problem you are having

dnolen17:09:49

lots of people in this channel have experience deploying ClojureScript apps

ericnormand17:09:03

@roberto: is it a difference between advanced optimization and no optimization?

venantius18:09:58

@dnolen: - Thanks for the explanation. I guess I’m more trying to understand the use case; it feels like bREPL is ideal for client-side application development and a Node.js REPL covers most server-side js needs; I haven’t heard a lot about people using Nashorn as a runtime but that might just be the communities that I’m active in.

dnolen18:09:02

@venantius: not that many people use the Nashorn REPL

dnolen18:09:10

but the same is true for the Rhino REPL these days

dnolen18:09:22

they are still useful for verification purposes

venantius18:09:26

@dnolen: Also, re our conversation earlier this week — I’ve been really carefully going through the Cljs Quick Start and I’m finding it hugely valuable. I know it’s very obviously labelled as the place people should begin with ClojureScript but I’d love to find a way to add more pointers from the rest of the community to that doc as a starting point for people new to the language.

dnolen18:09:51

@venantius: not sure what more I can do

dnolen18:09:58

I think I mention the Quick Start like every other day

venantius18:09:02

I’m sure you do!

venantius18:09:09

It’s not a challenge to you simple_smile

dnolen18:09:20

other people can go about pointing people to it

dnolen18:09:25

no other starting point makes any sense to me

venantius18:09:29

Mix of compliment and me wondering how we can raise the visibility of it

dnolen18:09:54

it’s very visible, it’s the most popular page on GitHub beyond the landing page

dnolen18:09:00

something like 12,000 reads a month

venantius18:09:15

My experience was really informed by “You should check out Figwheel” => try to understand cljsbuild settings => discover Chestnut => copy, modify => eventually spend a lot of time on the ClojureScript wiki looking at compiler options => finally realize I need to begin at the very beginning and slow-read the quick start

dnolen18:09:36

I’ve never recommended that

venantius18:09:37

So it’s entirely possible that’s a very anomalous path

venantius18:09:43

haha, again, I’m not claiming you have! 😛

dnolen18:09:47

and I don’t see very many people recommend that as a starting point

dnolen18:09:58

rather a useful “next” step

venantius18:09:40

Anyways, slowly putting pieces together.

pandeiro18:09:56

@dnolen You have a blogpost recommended chestnut

pandeiro18:09:16

(I know you know that, but google doesn't forget that stuff)

meow18:09:15

Speaking from experience, its easy to start with the Quick Start, run into something you don't understand, go off on a tangent to learn that thing, go off on other tangents, come back to Cljs and get to a point, go back to the Quick Start and realize you hadn't gotten all the way through it, get further this time but still go off on a tangential learning experience, repeat, repeat, repeat...

pandeiro18:09:27

'deploy to production' is obviously way too vague but there are kind of two definitions to 'start': begin learning cljs the language and begin building a cljs app that will ostensibly have users

pandeiro18:09:58

the templates approach was not ideal for function 1 but much better than the quick start for function 2

nullptr18:09:07

pkobrien: that also describes me trying to read a wikipedia article

pandeiro18:09:30

it's nice that the branches there were pruned to exclude non-wikipedia content

meow18:09:29

ClojureScript - It's tangents and rabbitholes all the way down

meow18:09:05

and at the end of each is @dnolen telling you to read the QS page again... 😉

meow18:09:03

Just pretend you're Bill Murray in Groundhog Day

roberto18:09:27

@ericnormand: the problem I’m now having is that the cljs code can’t access js objects in global scope, which for whatever reason, is possible in dev mode. I have to get back to work now. Will resume work on it later tonight. I have some more ideas.

ericnormand18:09:56

it sounds like you need to add some externs

roberto18:09:07

yeah, I was reading that

roberto18:09:18

but wouldn’t I need to do that in dev mode too?

roberto18:09:43

I guess that is what confused me, different behavior in prod vs dev.

jaen18:09:20

Hmm, I read the quickstart page the first time like two days ago when I started digging into module conversion stuff. It certainly is simpler than wrangling lein-cljsbuild & co to work, but I think boot is about as simple as quickstart is.

mcgivernsa18:09:53

I'd disagree - boot needs other stuff, quickstart literally just needs a JVM and a download

jaen18:09:55

(in other news, frak JS module resolution, I can't seem to get React to be resolve both as "react" and "react/lib/Whatver" at the same time)

jaen18:09:22

@mcgivernsa: I disagree, boot literally just needs a JVM and a download

nullptr18:09:57

s/simple/easy/

mcgivernsa18:09:58

ha, well, that's fair, but it also has much more overhead in the intro docs

jaen18:09:00

Then maybe we can disagree on the measure of "literally" we both take

jaen18:09:09

Might be, but compiling cljs boot is about the same amount of code build.clj is

mcgivernsa18:09:09

@meow I often find I need to read docs like that more than once to take in everything I read

jaen18:09:29

So I'd rather say if anything then it's docs not being simple enough

mcgivernsa18:09:07

I picked up the habit from a manual for a wood-burning stove, funnily enough: it said at the start of the manual that at least two read-throughs would be needed simple_smile

jaen18:09:31

That's a good habit I suppose

dnolen18:09:35

@pandeiro: that was back when chestnut did very little and had few options and the Quick Start didn’t exist

pandeiro18:09:38

@dnolen: i'm genuinely curious how far you think a project could get with the built-in compiler -- do you see that being a valid alternative to using lein/boot?

dnolen18:09:45

@meow: that’s not been the kind of feedback we’ve been getting about the Quick Start, most people just through the whole thing

dnolen18:09:13

@pandeiro: I don’t think you need anything else other than the built in compiler

dnolen18:09:34

anything more than that is purely convenience

pandeiro18:09:43

@dnolen: would you commit jars of deps?

dnolen19:09:12

@pandeiro: ??? the Quick Start ends talking about using some dependency tool

Pablo Fernandez19:09:13

Is it possible to specify individual files instead of directories to compile?

dnolen19:09:30

@pupeno: cljs.build.api/inputs

pandeiro19:09:26

@dnolen: yes i know, so until a project needs deps is the answer. sorry, didn't understand.

Pablo Fernandez19:09:40

Apparently not 😞 unless I’m missunderstanding what I’m reading.

dnolen19:09:40

@pandeiro: I was just talking about what do you need to work with ClojureScript, to me that’s orthogonal to whatever you are using to get deps

dnolen19:09:52

deps always bottom out at Maven doesn’t matter what you use

dnolen19:09:39

@pupeno: need to see an example of what you actually tried

roberto19:09:17

I normally work my way back: use the tool I feel most comfortable with to start playing with cljs/clj or whatever; and when I get comfortable, then start looking at the tooling and read more about how it works. Which is normally when I change to simpler tools.

pandeiro19:09:32

@dnolen: yeah the problem is those of us making webapps have a narrow definition of 'work with ClojureScript', but i do agree with you ... ClojureScript could be used for things that might not need deps, a web server, or anything else

roberto19:09:36

I find it hard to start the other way, because I can’t see the “bigger picture"

Pablo Fernandez19:09:03

@dnolen: I just found this: "We then invoke the standard function for building some ClojureScript source - cljs.build.api/build. This function only takes two arguments: the directory to compile and a map of options. In our case a simple :output-to will suffice for now."

dnolen19:09:29

@pupeno what are you referring to? the Quick Start?

Pablo Fernandez19:09:00

@dnolen: that’s what came up when googling, yes.

dnolen19:09:17

which reminds me someone should work on this http://dev.clojure.org/jira/browse/CLJS-1446

dnolen19:09:27

tons of low hanging fruit like this

Pablo Fernandez19:09:05

@dnolen: I’m working with cljsbuild, I’m not sure how that interfaces with cljs.build.api/inputs. Listing a specific file as source-paths didn’t work.

dnolen19:09:13

@pupeno: not sure what cljsbuild supports in this regard

meow19:09:15

@dnolen: I wasn't being critical of the QS wiki page - it's awesome and I really appreciate the work you put into it. I just happened to have come to ClojureScript with no experience with Clojure or LISP or any other functional language. So for me it was: decide to use ClojureScript, read the QS page, realize I need to learn Clojure, learn some of it, use and learn LightTable, try cljs again, need to learn React, mess around with OM, Re-frame, Freeactive, Rum, go back to the QS, realize I need to learn a packaging tool, learn Boot, change editors to Cursive, learn Devcards, etc, etc. Not complaining, just saying. Its been tangents and rabbit holes for me. But it's all good. simple_smile

dnolen19:09:44

@meow: I wasn’t saying that you were being critical

dnolen19:09:12

everybody has different strategies for learning, the response to the Quick Start has largely demonstrated that its approach works for most readers

meow19:09:43

Cool. And I like the approach that the QS takes. simple_smile

meow19:09:52

Just sympathizing with anyone who finds themselves having to return to it more than once.

ulsa20:09:30

Can it be summarized in a few simple rules, or is it just for me to RTFM on JS?

jaen20:09:55

I think the rule basically goes like "make a file that resembles the structure of whatever you want to have reachable from the outside of the file", though I didn't need to do externs so far and wouldn't know how would you do that in case of jQuery plugins and whatnot.

dnolen20:09:40

people generally think externs are more complicated and more work than they actually are

dnolen20:09:54

you only need to write externs for the stuff that you call

dnolen20:09:12

or properties that you use

dnolen20:09:28

BootstrapValidator.foo;

nullptr20:09:32

and type annotations are optional

dnolen20:09:47

BootstrapValidator.bar = function () {};

dnolen20:09:02

that’s all you need to do

ulsa20:09:05

I've seen jQuery.prototype.whatever = function(handler) {};, what's the deal there?

dnolen20:09:25

and again you don’t have to write them all, just the ones you need

dnolen20:09:50

@ulsa it just provides more information to the Google Closure compiler

dnolen20:09:11

you don’t have to do that, esp. if you’re using this stuff from ClojureScript and you’re not writing Objected Oriented JS

ulsa20:09:41

I'm trying to understand the rules behind this, like how to decrypt the exceptions I get

dnolen20:09:06

again don’t think there is anything more complicated then what I’ve just said

dnolen20:09:25

you don’t need to bother with understanding any rules

dnolen20:09:38

the only problem that can ever happen is renaming in your own code

dnolen20:09:49

so there’s nothing to interpret wrt. to the exception

dnolen20:09:55

it’s always the same, something got renamed

ulsa20:09:29

ok, I understand that; I guess I struggle with some fundamental JS understanding

ulsa20:09:35

example:

ulsa20:09:45

I get "a.rows.add(...).ui is not a function"...

dnolen20:09:58

all the errors are exactly the same

dnolen20:09:11

everytime you see advanced compilation error

dnolen20:09:19

99% the time, the error just means something got renamed

dnolen20:09:25

it doesn’t matter what the error message is

dnolen20:09:10

this one you pasted is not different

ulsa20:09:10

ok, but the mapping from exception to cljs to what extern to write is hard for me

ulsa20:09:27

(let [tbl (.DataTable
          (js/$ (str "#" table-id))
          (clj->js tbl-config))]
      (-> tbl
          .-rows
          (.add rows)
          .draw))))

ulsa20:09:58

what's the extern for this wrt the above error?

ulsa20:09:29

is it jQuery.fn.DataTable.rows.add or what?

nullptr20:09:36

.draw is probably getting renamed

nullptr20:09:48

grep your externs file for draw, rinse / repeat

ulsa20:09:27

I know I sound clueless, but I just need a little nudge simple_smile

nullptr20:09:28

ui is not a fn, but there is no ui in your code

nullptr20:09:16

ui comes after .add(...), which is where draw is

nullptr20:09:23

so, draw is likely getting renamed to ui

ulsa20:09:40

I get that draw is being renamed, but from there to the actual extern is a huge jump for me atm

nullptr20:09:28

i don't know this api, but i'd guess it follows the same pattern as other things on datatable -- so just add it next to others

nullptr20:09:50

frankly, externs are pretty forgiving -- if you just have some draw symbol in there i think it will prevent it from renaming

dnolen20:09:42

this the externs files used by ClojureScript

dnolen20:09:26

first thing prevents Math.imul from renaming, next thing supports ES6 iterators, and the last thing supports 3rd party libs like Transit leveraging equality

ulsa20:09:43

given the snippet earlier, it seems to me to end up in the $ or jQuery "namespace", yet you wrote BootstrapValidator.foo;

dnolen20:09:10

@ulsa: I wasn’t giving you the exact snippet

dnolen20:09:16

just the gist of the idea

nullptr20:09:02

if you don't want to take on externs fully, you can just extern a single JS method of your own and do your jQuery stuff there

nullptr20:09:13

if a large percentage of your cljs code is js interop that sounds like pain to me

nullptr20:09:49

no shame in easing your way in

ulsa20:09:45

ok, so trying to be concrete, in the rows.add thing above, what would the simplest extern be?

nullptr20:09:36

i don't know the library, but say .rows returns an object named RowsThing

nullptr20:09:47

RowsThing.prototype.add = function() {};

ulsa20:09:25

I think all calls return a DataTable, but ok

ulsa20:09:43

will that protect the draw from being renamed?

nullptr20:09:16

RowsThing.prototype.draw = function() {};

ulsa20:09:03

I think I see now

nullptr20:09:43

keep in mind this is 100% a closure compiler concept, it doesn't directly relate to cljs in any way -- so, any google closure compiler extern can be used/studied

ulsa20:09:42

so, DataTable has a rows property, which is a DataTable

ulsa20:09:59

which has an add method, which returns a DataTable

ulsa20:09:12

which has a draw method

ulsa20:09:20

am I on to something?

nullptr20:09:44

that makes it easy

nullptr20:09:44

DataTable.prototype.method = function() {};

boz20:09:53

Trying out planck. Love how zippy it starts! But getting this weirdness. When I type (+ 1 1) and enter, the repl looks like this...

cljs.user=> (+ 1 1)-7D-7C-7C
2
cljs.user=>
(I’m on Mac Yosemite using iTerm)

venantius20:09:08

@dnolen: re http://dev.clojure.org/jira/browse/CLJS-1446, what did you have in mind? Marginalia docs, or…?

venantius20:09:19

The actual ticket itself is a little sparse 😛

ulsa20:09:08

@nullptr: so, just to verify that I've got this... I start with something like this, and then iterate?

function BootstrapValidator() {}
BootstrapValidator.prototype.revalidateField = function() {};

function DataTable() {}
DataTable.prototype.add = function() {};
DataTable.prototype.draw = function() {};

nullptr20:09:26

looks like a good start :thumbsup:

dnolen20:09:54

@venantius: the ticket says “auto-doc"

venantius20:09:06

I was not aware that was an actual library! 😛

dnolen20:09:15

fixed auto-doc -> autodoc

dnolen20:09:59

has a reasonably simple example of how it works

venantius20:09:40

no promises but I’ll take a look at doing the autodoc this weekend

dnolen21:09:38

@venantius: in general we have zero expectations, people work on what they want when they want simple_smile

venantius21:09:33

the nature of oss

ulsa21:09:40

@nullptr: finally, if I have something like this:

(.tab
  (js/$ "#search-result a[data-toggle='tab']:first")
  "show")
then I need to add jQuery.prototype.tab = function(){}?

jaen21:09:45

@dnolen: to satisfy my own curiosity I started hacking on code that could handle loading whole libs using ES6ModuleLoader & co. And it seems there's no way to properly require react with it - I can either get require("react") to work or require("react/lib/SomeSubmodule") but not both at the same time (and both forms are used in the wild, so both have to work).

jaen21:09:56

I guess I'll have to ask around their mailing list on how to properly handle this; kinda pity they don't have IRC, I never got on well with MLs ; /

nullptr21:09:36

ulsa: looks right at a glance

ulsa21:09:23

thx @nullptr and @dnolen for your patience

dnolen21:09:52

@jaen do you have a gist of the resulting exception, or something that shows the problem? I suspect @maria can also help out here when she gets a chance.

jaen21:09:25

Sure, give me a second

nullptr21:09:04

jaen: #reactjs on freenode

jaen21:09:38

@nullptr: that's a problem with GClosure rather, that is in how it handles module translation

nullptr21:09:09

ah, yeah not so lucky there

jaen21:09:51

@dnolen: ok, so the simplest illustration of the problem goes as follows:

(def first-file (SourceFile/fromFile ( "node_modules/react/react.js")))
(def second-file (SourceFile/fromFile ( "node_modules/react/lib/EventConstants.js")))
(def third-file (SourceFile/fromFile ( "require-something2.js")))
(def first-input (CompilerInput. first-file))
(def second-input (CompilerInput. second-file))
(def third-input (CompilerInput. third-file))

(def loader (ES6ModuleLoader. (list "node_modules" "node_modules/react") (list first-input second-input third-input)))

(def locate-method
  (.getDeclaredMethod ES6ModuleLoader
                      "locateCommonJsModule"
                      (into-array java.lang.Class
                                  [java.lang.String com.google.javascript.jscomp.CompilerInput])))

(.setAccessible locate-method true)

(println (.invoke locate-method loader (into-array Object ["react/lib/EventConstants" third-input])))

jaen21:09:05

With this code as above "react/lib/EventConstants" resolves properly, but "react" does not. If I switch the first argument to ES6ModuleLoader. and "node_modules" goes first I can resolve "react" but not "react/libEventConstants".

jaen21:09:56

As far as I can tell that's the desired behaviour, because for each source file it iterates over module roots, picks first that matches, and relativizes the url to that and that means only one of the two can work as it is coded right now (because they have common subpath).

jaen21:09:52

The documentation is sparse so I might be misusing the loader, but this seemed the way to call it.

jaen21:09:48

So far the code handled all libraries I tried until I hit MaterialUI. MUI requires submodules in React which in turns makes it necessary to be able to handle both "react" and "react/lib/SomeModule", but I have no idea how to given this behaviour.

masonbrowne21:09:50

goog/base.js has the line “goog.global = this” right near the top with a comment above that says “in most cases this will be window". However, under advanced compilation with :language-in/out set to :ecmascript5-strict, that gets wrapped in an anonymous function with “use strict” just before it, and “this” is undefined, causing all sorts of madness. Dropping back to :language-in/out :ecmascript3 or back to :simple/:none/:whitespace optimizations fixes it. Anyone else run into this?

dnolen21:09:24

@masonbrowne: never bothered with those options

dnolen21:09:41

but also not sure why you would want to emit es5-strict anyway from ClojureScript

dnolen21:09:55

@jaen don’t understand what you mean by “picks first that matches"

jaen21:09:19

It just iterates through module roots and picks the first one that is a subpath of the file.

dnolen21:09:28

@jaen hrm that just seems broken?

jaen21:09:32

Possibly, or was just coded as simple as possible for it to work most of the time -and indeed it does when the paths are disjoint, but React insists on having most files in lib/ and that one file outside of it, producing two module roots that can't be sufficiently distinguished that way.

roberto21:09:43

I’m using mapbox in a cljs app. So I’m converting this js to cljs: L.mapbox.accessToken = “access token”. In cljs: (set! (-> js/L .-mapbox .-accessToken) “access token”) . This works in dev, but not when in production when I deploy. It complains that .accessToken is null, which is right. I thought that set! would create the new field in the js object. I’m also confused why it works locally but not in prod.

dnolen22:09:33

@jaen ok, I’m starting to see the issue

dnolen22:09:43

I suppose you could move things around to make it work no?

dnolen22:09:50

annoying but I don’t see something simpler?

jaen22:09:44

Renaming react.js to index.js in the root of React fixes that, but that's a stupid thing to have to be doing if the aim is to consume the libs as-is.

jaen22:09:03

I'll see what GClosure guys have to say about that

jaen22:09:06

(though MLs, ugh)

jaen22:09:44

And I can keep on figuring out the rest of code with that rename

jaen22:09:00

Was just curious if maybe you'll notice something I'm doing obviously wrong

dnolen22:09:31

@jaen I would say that Google Closure is probably just wrong in this case

dnolen22:09:52

the root module matching algorithm should be correct, not simple

jaen22:09:33

Another things I see is I don't see any way to suggest to GClosure what require string should resolve to what module (for example that react-draggable2 thing has a file names draggable.js and that's it, which means GClosure will expect people to require it like require('draggable') and not require('react-draggable2').

jaen22:09:45

@dnolen: ok, I guess I'll bring that up with the upstream then

dnolen22:09:55

fwiw the GCL authors are pretty nice and respectable IME

jaen22:09:00

I don't think I'm smart enough to figure out how to fix GClosure by myself

dnolen22:09:06

it’s a small focused community

dnolen22:09:35

@jaen: working on GCL is really quite straightforward. Not sure if you are an IntelliJ user but that makes navigating GCL very reasonable

dnolen22:09:47

er GCC I mean

jaen22:09:31

I used to hate IDEs, but then I started using Cursive because of reasons (the reasons being debugger integration, I do so many trivial-yet-vexing-to-find errrors I wouldn't be able to do Clojure effectively otherwise), so I guess I'm okay on that front

jaen22:09:06

I'll just have to figure how to use them mailing lists ;' )

jaen22:09:36

@nullptr: oh, that's interesting, thanks. Though it would have been the nicest if the had an IRC channel, alas...

ericstewart23:09:13

@boz: I’ve seen that planck behavior before too. Is your installed via homebrew by any chance? I don’t get it when I build planck myself though. It’s the ansi codes to show you matching braces.

boz23:09:14

@ericstewart: I did get planck via brew. Cloned and built and all is fine. … Thanks!