@bhauman: I see you've updated the read-me on how to get running with cursive. Got it running! Thanks!

@bhauman: I checked; there weren’t any errors

any common reasons why figwheel might not be picking up less compiled css artifacts for reload?

I think it’s an utterly standard setup

less4j dropping files into resources/public/css

just doesn’t seem to be picking up on their existence

and thus won’t reload them

@tel: do you have :css-dirs ["resources/public/css"] in config? like here https://github.com/bhauman/lein-figwheel#figwheel-server-side-configuration

@jaen that’s just not enough information me to understand the goal here (mentioning boot here just muddies the water too)

@dnolen: so, basically - boot creates temporary directories for each step in it's pipeline, which results in build being called with an absolute path for output-dir and since current module conversion code outputs intermediate files to output-dir and puts those files in :libs you end up with absolute paths in that option and lib-rel-path doesn't take kindly to absolute paths - throws this error - https://github.com/clojure/clojure/blob/cc69d19bd471c48d441071fff43e768ffa7eb8e5/src/clj/clojure/java/io.clj#L405. If I understand correctly the string/replacein lib-rel-path is meant to realtivise the path, yes? But it fails with paths that don't share ancestors with the dir you called Clojurescript from (as is the case with boot). Wouldn't then using java.net.URI#relativize as in the changed example be a better solution or are absolute paths not meant to be supported?

It probably won't end up being an issue with modules since we probably will end up not writing temporary files, but I think the issue stands on it's own if :libs was meant to support absolute paths as well.

@jaen I think :libs was written to support paths relative to project directory. Extending it to support absolute paths would be enhancement, but also a perfectly fine one.

Gotcha, I'll put that in a separate patch somewhen this week and get it a jira ticket if that's a welcome enhancement then.

@dnolen: do you think it's a good idea to open an issue for this: map-indexed should support multiple colls, like map?

@borkdude: the signature is the same as Clojure

it’s unusual for ClojureScript to take signature enhancements not present in Clojure

so if you’re serious about it, then probably best to open an enhancement in both projects, w/ patch etc.

@borkdude: I would definitely ask Alex Miller before expending any energy first though

@dnolen: yeah, I was going to do that, just asking for your opinion

my opinion is that map-indexed is a very sugary thing

if you’re going to do multiple collections (map f (range) …) seems satisfactory

@dnolen: hmm, true

and given transducers there’s no perf claim you can offer for map-indexed with multiple collections

@dnolen: didn't think of that one, but I don't think it's needed then

Hi there ^ Strange require behaviour on node: once req'd with a wrong name, it keeps looking for the wrong name. Thoughts?

f-air:xforms fdeserres$ lein clean
f-air:xforms fdeserres$ rlwrap lein node-repl
Reading analysis cache for jar:file:/Users/fdeserres/.m2/repository/org/clojure/clojurescript/1.7.48/clojurescript-1.7.48-aot.jar!/cljs/core.cljs
Compiling src/net/cgrand/xforms/awkward.cljs
...
ClojureScript Node.js REPL server listening on 50080
Watch compilation log available at: target/dev/watch.log
To quit, type: :cljs/quit
cljs.user=> (require '[net.cgrand.xforms.awkd :as a] :reload)
clojure.lang.ExceptionInfo: java.lang.String cannot be cast to java.io.File {:tag :cljs/analysis-error}
	at clojure.core$ex_info.invoke(core.clj:4593)
... 
cljs.user=> (require '[net.cgrand.xforms.awkward :as a] :reload)
java.lang.IllegalArgumentException: Namespace net.cgrand.xforms.awkd does not exist
	at cljs.closure$source_for_namespace.invoke(closure.clj:597)
...
cljs.user=>

@fdserr: pretty sure that isn’t specific to the Node REPL

or … actually it might be. Should be checked against other REPLs.

@dnolen Hi David, doing this...

@fdserr: just testing with the Rhino REPL or whatever is enough

Same with rhino indeed. Must be the build/repl/test scripts I use (from gardener). Back to Mies then... thankies @dnolen

@fdserr: heh no, this is just a REPL bug that I’ve been aware of for some time

@dnolen let me try on a fresh Mies...

@fdserr: pretty sure you’ve found a real bug http://dev.clojure.org/jira/browse/CLJS-1456

@fdserr: the issue is that require is a hack for REPL

Hmm has anyone else run into issues with unicode constants in ClojureScript tripping up the Closure compiler with advanced compilation?

(require ‘[foo.bar]) actually becomes (ns current-ns (:require … existing stuff ... [foo.bar]))

so I suspect we’re corrupting the ns somehow, I thought we had covered some cases but no doubt there are things we’ve missed

I have symbols representing musical notes using unicode sharps and flats (e.g. :C♯ and :D♭), getting ERROR: JSC_PARSE_ERROR. Parse error. Character '♯' (U+266F) is not a valid identifier start char but only with advanced compilation

cljs.core.cst$kw$D♯ = new cljs.core.Keyword(null,"D\u266F","D\u266F",-1836342684);
                  ^

@dnolen sorry to hear that =[ Indeed:

ljs.user=> (require '[cljs.core :as c] :reload)
java.lang.IllegalArgumentException: Namespace cljs.cor does not exist

It seems like maybe ClojureScript compiler needs to ensure the names in the constants table are compatible with Closure... what do you think?

Closure has a much more conservative opinion on valid identifier names than the JS spec or browsers...

and certainly more so than Clojure(Script)

@fdserr: could probably be fixed here https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/repl.cljc#L642-L659

imagine that i want to replace some protocol implementation on reified thing with specify!. but i want to call old implementation from new one

i want to wrap it with new anf specify! it on object

So I guess my question comes down to.... a) is that a bug? b) if so, is it known and c) do I have any option other than not using advanced optimization or refactoring this code base to use ascii keywords instead (which would be a PITA)

is it possible?

@dnolen will look into this, thx ^

@bo no simple answer for that question. But I would start by asking questions on the Google Closure Compiler mailing list first and reporting back what they say.

we can decide what to do based on their feedback.

@bo something to try before doing that, setting :language-in to :ecmascript5

@dnolen: I can see in the Closure code that it is definitely super conservative about identifier names. Basically /[$_a-z][a-z0-9]/i

That could maybe be improved on their end, but my gut tells me that this is a cljs compiler bug until they do, if its outputting code that it can't handle

or is that too simplistic?

@bo “bug"

heh

@dnolen: relevant tiny part of code in Closure FWIW https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/parsing/parser/Scanner.java#L739-L759

this is pretty far into the hazy territory of unclear issues

we’re not going to anything about this until the matter is clarified upstream

once we know what GCC’s stance is then we can decide what our options are

likely there’ll be an optional compiler flag to munge unicode symbols

so sorry this means no fix in the short term @bo

@dnolen: no worries... I wasn't hopeful there

looking into :language-in now

from that Closure code, I doubt it'll make a difference though

unless they use a different parser I haven't come across

yeah... no difference

@bo I don’t really understand your interpretation of the parser

@dnolen: hmm actually, Chrome blows up even with var D♯ = new cljs.core.Keyword(null,"D\u266F","D\u266F",-1836342684); in the console

SyntaxError

as far as I can tell they are trying to follow the spec

there’s a limited number of characters you can START with

but without compilation, the app works fine

however that’s not what you’ve encountered

yeah this is definitely not a start char

so it looks like a legitimate Closure BUG

@ul I think you can always close over the original thing in method overrides and use protocol methods to invoke old functionality on the original

i think the problem is that object will be mutated after specify!

and closure won't help in this case

I don't know enough about the cljs compiler but the fact that Chrome isn't accepting a var var D♯ = 42 is throwing me a bit now

the app otherwise works with out compilation. Is the code generated by the cljs compiler different depending on the closure optimization level @dnolen ?

i.e. is it not generating those vars in that case

@bo the cljs compiler doesn’t do much here, it largely passes strings through with exceptions for JS keywords

Maybe it's a Chrome console bug then?

@bo ah, ok I understand the issue now, sorry was thinking this was about vars

that you were writing, but that’s not the case

@dnolen: actually it's keywords

the issue is the keyword optimization under advanced compilation

@ul what about using specify (not specify!)

ah ok

so the code is different there

I was starting to wonder how this worked at all with optimizations off

it requires object to implement ICloneable

which is not available in my case

@ul ah, ok

@dnolen: ah comparing the .js generated with different opt levels and I see what you mean. Keywords are otherwise inlined as new cljs.core.Keyword(null,"C\u266F","C\u266F",-97295497) without :advanced

which puts the ♯ in the string

@dnolen: so does this still feel like a GC bug or a cljs bug with keyword optimization?

@ul another idea: specify calls reify, reify calls deftype, things on deftype can be overriden via extend-type or extend-protocol

@bo http://dev.clojure.org/jira/browse/CLJS-1457

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/compiler.cljc#L1393-L1405

this is the relevant section, patch welcome!

@dnolen: haha awesome thanks

@dnolen: does my ancient CLA from Clojure apply here or do I need a different one?

I doubt I'll be able to fix it, but I might take a stab

@bo Clojure CA is the only CA required

👍 thanks

@bo this is not a particularly challenging one, actually this is the only thing you need to change https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L370-L384

note we already do a bit of munging, so we just need to further munge any unicode chars

@dnolen: Thanks. I'll give it a crack. It's already 11pm here and I've never worked with the compiler before so we'll see.

my vote would be replace with “xNNNN” code.

yeah that seems doable to me

oh good, that's exactly what I was thinking except uNNNN

x seems better

either approach is fine

@bo no rush

@dnolen: mightn't it be useful to fix (munge) itself? It replaces a lot of other chars already. I'm perhaps over-estimating the significance of munge, but this feels surprising:

user> (munge "a.b/x->♯")
"a.b_SLASH_x__GT_♯"

I doubt ♯ is valid any of the places that the other munged chars aren't

@bo leave munge alone, too many repercussions

k

user=> (require 'cljs.analyzer)
nil
user=> (cljs.analyzer/gen-constant-id :C♯)
cst$kw$C_u266f_

🎉 @dnolen

sweet

I'm not being clever about unicode char sizes though

just doing a dumb %04x format

I’m OK with this not being the the perfect robust solution - this is the first time anyone’s even brought it up - which is a bit surprising.

indeed

added the patch to the ticket but adding a test now too

@ul still looking for a solution?

I just did a quick test with newly created deftype and reify, you could do a dirty lookup of original function on underlying js object

it will be something like: om$core$IRender$render$arity$<something>

this is dirty, maybe there exists some function which could give you this protocol fn name

@dnolen Untested easy fix to 'require et al: https://gist.github.com/justiniac/7d960e8925a426f3abac#file-repl-cljc

can you have a namespace divided over a .cljs + cljc file or must everything of that namespace be in one file?

@fdserr: yeah that won’t work, that’s just about restoring the prompt

gah 😕 where's the wrong name saved then? @dnolen

this isn’t about names, it’s not quite as simple as it seems on the surface

@darwin: thank you, just came for the same, but it's too hacky i think

@fdserr you need to snapshot the compiler environment and restore that

so @ on the cljs.env/compiler-env and then reset! if fails

@dnolen would it be needed at this very 'catch' or?

@fdserr: the try/catch approach is fine

@ul: I agree, another idea would be to reify your OpaqueComponent and in your implementation try to invoke render directly on prototype, not sure if this could possibly work, but it looks like reify sets original thing as prototype of a new anonymous js object and overrides some methods on this new object, if this worked you would get around looking up protocol fn member manually

@dnolen: will ponder that with a mug...

@fdserr: your idea is correct, but instead of capture and restoring symbol - you need to capture and restore the compiler environment

@dnolen thing is, I need to be able to build/test clj+cljs, not my cup of tea so far. would you consider a gist and take care of the fix when you see fit?

@fdserr: building and testing ClojureScript is very straightforward, no I won’t look at a gist or take care of the fix

the ticket is there, anyone can attach a patch at their leisure

woo my patch worked when switching my project to my local cljs build

yay

thanks for your help @dnolen!

@bo np

I haven't submitted a patch in sometime so if I'm formatted the patch wrong feel free to prod the ticket (i'm watching it) and I'll fix it right up

for now, I'm going to bed though!

maybe select-keys should throw when not called with a map? (both in clojure and clojurescript) now: (select-keys [:a :b] [:a]) ;;=> {}

@dnolen fair enough ^^

@ul yeah, I've tried setting :css-dirs to all kinds of things, absolute paths, relative paths with various slash conventions. I assume it's just somehow reading it out of resources, but for whatever reason figwheel doesn't find them

Hello, could anyone please point to some good tutorial for wrapping a js library (which is aimed to browserify/webpack i guess) with foreign-libs and externs? I'm trying to wrap react-dropzone but it seems i miss some points. Thanks in advance

@nidu this is specifically for packaging things as CLJSJS package but it might help nontheless: https://github.com/cljsjs/packages/wiki/Creating-Packages

@martinklepsch: thanks, guess i tried this one but maybe i just need one more attempt

@nidu: what’s not working for you?

@martinklepsch: first of all - i'm not sure what to put in externs. If i wrap js file with module.exports - should i just declare a function with some name? And how do i use it then - via require or just with js/foo?

@nidu: I see what you mean and unfortunately don’t have a good answer ready. This is certainly something to be discussed though. If you could open an issue that would be great.

@nidu: you'd have to preprocess it with webpack or something to remove the requires and expose a global variable of some name, no other way around that currently.

@martinklepsch: don't sure it's an issue, guys on cljsjs seem are doing fine it seems)

@jaen: is there a chance that this will be handled by the compiler in the future or is that something we should consider adding to cljsjs package-tooling?

@jaen: thanks! i knew there must be something like this!

@nidu: most packages expose a global variable and therefore don’t have this problem

@martinklepsch: this thing me and Maria are working on will probably handle this to some extent.

But I don't think this will ever be 100% automatic and some wrapper namespaces will probably still be required.

@jaen: perhaps this wrapping could be done as part of the cljsjs build step?

Some of the wrapping that's for sure - the plan is to specify something like here - https://github.com/jaen/custom-module-loaders/blob/master/build.clj#L3-L74 - that is libraries you want to use, their dependencies, names, main files and so on

And the compiler would then handle it hopefully

But specifying those libraries properly (from package.json for example) would make sense for a boot task or something.

That's one thing

@jaen: I haven’t had the time to pay close attention to all the awesome work being done with regards to better integrating the different JS module types. I assume there are some consequences for CLJSJS or things CLJSJS could help with and would very much appreciate the input of someone who’s familiar with these things.

And another is that I'm not 100% sure how we would want to refer to things; for example when you do var React = require('react'); you'd have access to`React.createElement`, but you could do var ReactElement = require ('react/lib/ReactElement') and do ReactElement.createElement and there will might be difference in how will they work (I think the former automatically wraps it with validation in development as well as perf code, while using it directly doesn't) and I would have to consider how we want that to map to Clojurescript namespaces exactly.

And yes, no problem with providing guidance on how to make use of that, it's just that we need to figure out how we want that to work exactly with Maria and dnolen (to support as many use cases as possible without it being overly complex), what I have in my repos is certainly not the final shape of it.

I have this line: (aset js/global "XMLHttpRequest" (.-XMLHttpRequest xmlhttprequest)), which apparently, when compiling with advanced optimizations, is being removed. I understand about ^:export, but how do I make sure Closure leaves global[“XMLHttpRequest”] alone?

Is it possible to get hot code reloading with Figwheel using .cljc files in the same way that it supports .cljs files?

@pupeno: instead of aset, use goog.object/set

maybe?

@pupeno: provide an extern, there are several pinned pages in this room to Closure docs

worth reviewing

@pupeno: if you’re trying to export something to be consumed by JavaScrip this is also covered in Closure docs

@dnolen: thanks.

Figured it out, fwiw. I'm a few versions behind: https://github.com/bhauman/lein-figwheel/issues/129

Hi all - If I have a cljsbuild in my project.clj and a cljsbuild in my uberjar profile and the hook then it seems the top-level cljsbuild config (e.g. the non-optimised one) is used and the one in the uberjar profile is ignored - is this expected?

Is there a way of saying ‘use the cljsbuild with id X when building an uberjar’?

@michaeldrogalis: it’s been a few days but I don’t seem to recall any problem with figwheel reloading cljc files

@colin.yates: Yep, my fault. I was on 0.2.5. Thanks.

@michaeldrogalis: np.

never mind my question about cljsbuild and uberjar - it helps if :uberjar is inside a :profiles and not top-level. #numpty

(I really shouldn’t have bothered getting out of bed today…)

Looking at the generated JS, I think the problem is order of execution, but I’m not sure.

is 443K a reasonable size for :advanced-compiled app.js? Not very complex, includes reagent. just want a sanity check.

@colin.yates: I see your problem turned out to be a different one, but did you figure out how to select a specific profile in :uberjar?

for me I simply needed to add a cljsbuild inside the uberjar profile:

I was afraid of that. 😉

(defproject pj-health "0.1.0-SNAPSHOT" :dependencies [[org.clojure/clojure "1.7.0"] [org.clojure/clojurescript "1.7.122"] [org.immutant/web "2.1.0"] [reagent "0.5.1"] [re-frame "0.4.1"] [hiccup "1.0.5"] [compojure "1.4.0"]] :source-paths ["src/clj"] :main pj-health.core :plugins [[lein-cljsbuild "1.1.0"] [lein-figwheel "0.4.0" :exclusions [cider/cider-nrepl]] [lein-ancient "0.6.7"] [lein-immutant "2.0.0"]] ;; Hook so uberjar (called by immutant war) compiles clojurescript :hooks [leiningen.cljsbuild] :clean-targets ^{:protect false} [:target-path :compile-path "resources/public/compiled"] :cljsbuild {:builds [{:id "dev" :source-paths ["src/cljs"] :figwheel {:on-jsload "pj-health.core/mount-root"} :compiler {:main pj-health.core :output-to "resources/public/compiled/js/app.js" :output-dir "resources/public/compiled/js/out" :asset-path "compiled/js/out" :source-map-timestamp true}}]} :profiles {:uberjar {:aot :all :cljsbuild {:source-paths ["src/cljs"] :compiler {:main pj-health.core :output-to "resources/public/compiled/js/app.js" :optimizations :advanced :pretty-print false}}}})

but it is all very sensitive - if you get the cljsbuild wrong in the uberjar profile then it will silently use the first one of the top level cljsbuilds

back in 20 - hope that helps

As it turns out, I'm doing something a bit more advanced. I'm using cljs.repl/source to obtain the source map for a function defined in a .cljc file. Now that Figwheel properly reloads the .cljc file on changes, the corresponding ClojureScript file that looks into the source map doesn't see the update until its own .cljs file has been updated. Can someone explain to me why that is? I'm not familiar with how source maps works.

@michaeldrogalis: I don’t really understand what you mean when you say “using cljs.repl/source to find the source map"

cljs.repl/source just returns the source

@curtosis 443K doesn’t sound crazy, the only thing worth measuring is the gzipped size

@dnolen: 116K gzipped, looks like.

@dnolen: Sorry, yeah that's what I meant. I'm using that function to get the source for a cljc function. Reloading the cljc compiled file makes the behavior change appropriately in Cljs, but using cljs.repl/source continues to return an older version of the function - that is, until that Cljs file itself is updated. Did that make more sense?

@curtosis looks about right to me. If you’re using cljsbuild make sure that you set :pretty-print false, if you skipped that that could save quite a few more K.

@michaeldrogalis: yes because cljs.repl/source is necessarily a macro not a fn.

@dnolen: Ahh, that's the critical information. Thanks, makes perfect sense.

@dnolen: no :pretty-printing here. thanks!

Some ideas for figwheel: while we were working with dojo (which is twin of goog), we've made boost for initial page load in development, by just building deps tree in memory on server and serving them in one request (not synchronous goog.require) - 10~100X faster

@colin.yates: AFAICT, there's no way to specify a specific :cljsbuild config id for :uberjar, since cljsbuild is called from :hooks and won't take args.

@curtosis: hiya, yeah, I was looking for some way but couldn’t find any either. Moving the entire fragment into the uberjar profile isn’t too troublesome - and might actually be nicer depending on whether you normalise by subject (cljsbuild) or context (uberjar’ing)

yeah... the only real use case I can think of would be if I needed to run the dev version in a jar/war environment, which I'm not currently doing (and seems suboptimal anyway).

now, what I do need to figure out is how to make it output to a different directory (easy) and get :uberjar to pull from that directory instead (unclear).

@bhauman: despite having figwheel running with devcards now and being able to run cards.html I am not sure the path issue is entirely resolved. I am still figuring things out but as I understand it the index.html in the template project is the "main app" file and the devcards can be written in the same namespace as the "main app" which would be the core.cjls. The .getElementById "main-app-area" seems to imply so. But when I have a look in the running cards.html app the main app area is actually called "com-rigsomelight-devcards-main". Is that expected?

I have this ClojureScript code (.createServer http app) where http is a NodeJS module, as in: (def http (nodejs/require "http”)). Closure compiled that to: Jz.Zg(p), so createServer got converted into Zg for calling it, but the nodejs module remains intact. What’s the appropriate way to deal with this? externing the http module?

@pupeno if you’re using Node.js there’s really no reason to bother with advanced optimizations

dnolen: I just wanted my library to not explode in people’s faces if they have enabled optimizations for some reason, but, oh well, I’ll just document it.

@bbss I think you may be confused by that fact that cards are meant to only be rendered in the cards.html and the application itself is intended to be rendered in the index.html

@bbss devcards creates the devcards application and adds the "com-rigsomelight-devcards-main" node to your page

@pupeno if your library depends on Node.js modules there’s not a good way to define that dependency in a reliable to users anyway

so it’s not clear to me why you care about advanced optimizations when that’s a much bigger issue

@bbss the main app area is just a pattern that I added so that folks can conditionally render their application in the index.html

@bbss sorry if it is confusing

@bhauman: okay I see, thank you. I am trying to find a way to include paren-soup inside cards and thought I could include the pre-built version in the index.html, as putting it in the cards.html itself doesn't work. Then wanted to grab the node with dom-node and manipulate from there. But seems not to work that way.

I guess I should dig into building/including the paren soup project myself.

@bbss dom-node creates a node and then hands it to you

@bbss: on change it calls the function again and hands you the node again

Okay, still seems the way to go if I'd want to include paren soup I think. But I'll figure it out while playing some more with it. Was just a bit confused by the difference in names as that was also the case yesterday, thought it was maybe related

@bbss: eveeryone want so to be able to edit code in the browser But I created devcards to provide the optimal experience of editing code in your editor and seeing the results in your browser

The combination of tests, markdown and compiling cljs is really exciting.

@bbss what you would want to do is to create a React Component with lifecycle hooks for initialization to contain paren soup

then you can pass that to defcard and viola

Okay, trying that!

or compose it into other thngs

@bbss: I just did that here: https://github.com/darwin/plastic/blob/df1d3c481f531c7d0038a5009776feeb42fd44ef/cljs/src/meld/meld/support.cljs#L271-L272

@darwin thanks!

rendering svg graphs via D3 wrapped as react component

reagent component

Checking it out

@bhauman is there any way to debug why figwheel might not be picking up css changes? I think it’s all configured properly

@tel: you can look at the figwheel server log, the messsages in the dev console, and you can add :debug true to the :figwheel client config

@tel: are the messages getting to the browser?

lemme check with debug

I’m getting pings in the browser console

but the server log isn’t noticing changes to the CSS

@darwin: I had seen plastic before, what are you going to use graphs for? I gave a short presentation on redux+d3 for making a brainstorming app using a force directed graph at a JS meetup last week. I actually planned to learn reagent/re-frame while expanding it.

@nicola: that is interesting, is the added complexity worth the trade off when the idea is to not reload the browser that often? And the incremental compilation of seperate files is what enables fast reloads in the first place.

@bbss: I posted some screenshots to #C09GR9UJC today, I want to use it to display tree data structures, I for example parse-tree output from tools.reader, etc.

@tel: my guess is that its probably a naming and path issue. There has to be a style element in the document that matches the name of your css file.

I want devcards to be example and visualization of tree state before I run batteries of tests on it

hm

@curtosis: I thought you could provide extra paths for the resources in uberjar….let me see if I can find where I read that

for example it will be ideal to show tree state and then run bunch of zip operations on it

<link href="/css/site.css" rel="stylesheet" type="text/css”> exists, and I’m compiling site.main.less -> site.css

@curtosis: alternatively you could do the hack I sometimes do and have a dev.js and prod.js with /dev.html loading dev.js and / loading prod.js if you see what I mean

could it be the absolute path?

yeah that is it.

hm

@tel: what do you guys use for transforming less to css to be then consumed by figwheel? I will need it soon

@tel: I mean that might be it

@darwin deraen/lein-less4j

mostly because it supports picking bootstrap up via cljsjs

@curtosis: no, I can’t find where I read about uberjar pulling in different resources - my hack works for me but it is a hack

@darwin That is what I would like be able to be proficient in too. Programming tools to help visualize the problem better than my mind ever could.

@tel: if the message is making it through this is the CSS reloading code https://github.com/bhauman/lein-figwheel/blob/master/support/src/figwheel/client/file_reloading.cljs#L417

checking to see if the relative path resolves it

@colin.yates: that makes sense. I might give that a try if/when it matters. right now I'm beating my head against the lein-resource wall. I cannot get a repeatable build out of it, no matter what I try.

though I’m going to need to trick the server into serving css assets at every url prefix if that’s the case, huh

@tel: I'm sure this is a bug we can fix

@tel: does the message get to the browser? That is the first question

hm, so even with the relative path

<link href="css/site.css" rel="stylesheet" type="text/css”>

it’s not showing up in figwheel_server.log

so I think it’s just not finding it at all

is there a way to see the files that are being watched?

:figwheel {:on-jsload “..."
                :css-dirs ["resources/public/css”]}

looks like this is the code

https://github.com/bhauman/lein-figwheel/blob/master/sidecar/src/figwheel_sidecar/core.clj#L384

@mfikes: I'm going to try to port to clojurescript on node the namespaces from tools.namespaces that are only JVM. Is there any convention on what to replace with?

@tel that is your problem. Your config should at the server level not the build level

oh, wow, that’s quite obvious when you point it out

@bensu: not that I'm aware of. Joel Martin has ported some of to node FWIW

sorry for the noise! 😕

Np it is very confusing to have two figwheel keys for conf

and there we are

thanks!

😜

@bensu: I've submitted a few things (some protocols and dynamic vars) as proposals for ClojureScript itself so that they can be used in the cljs.core namespace.

😅😅

@mfikes: can you point me to your work and Joel's?

@mfikes: @dnolen do we need a library?

@bensu it needs quite a bit of thought before pursuing anything specific, tickets are kind of a bad place to do this.

@mfikes I would outline some design thought pages on the ClojureScript wiki

good idea, if we start porting clojure JVM libraries to clojurescript on node/plank it'd be good to port the fundamental clojure namespaces to avoid wrapping node libraries each time.

more important than specific proposals is just enumerating the design https://github.com/clojure/clojurescript/wiki/Developers

I've submitted a handful of simple things like http://dev.clojure.org/jira/browse/CLJS-1426

@mfikes yeah tickets for this stuff is moving too far too fast

Ok. Yeah. Don't want to add noise

there’s a bunch of assumptions around http://clojure.java.io that should be questioned and weighed before doing anything.

Java I/O is oriented around streams and JavaScript doesn’t have anything like that at all.

ok, I'll start with a small rationale and a list. I'll be right back

https://github.com/clojure/clojurescript/wiki/Porting-JVM-dependent-namespaces-to-Node

@bensu right but that’s not really a rationale.

1) state what the problem is (portability of I/O) and the scope of problem (different value proposition for browsers)

2) state one possible solution (replicate Java I/O), enumerate all the downsides to this approach (there are many)

then other people can read over this and think about what should be done

i.e. should it happen in core? should it just be a contrib (probably), should it have the same namespace as (maybe) etc., etc.

@dnolen: coming right up!

Does anyone know what this error means? ERROR: JSC_INVALID_DEFINE_INIT_ERROR. illegal initialization of @define variable goog.DEBUG at /.boot/cache/tmp/app/1/huasbf/foo.out/debug.js line 84 : 13

(I have a view with an :on-click that is toggling goog.DEBUG)

ask @martinklepsch

@pandeiro: you can’t change defines/constants during runtime

oh but i can!

and do!

OK so goog.DEBUG is some special-cased deal?

@pandeiro: @martinklepsch just means if you do that you’ll won’t be able to advanced compile

if that matters to you, you effectively cannot change them at runtime as you are doing now

Yeah advanced compilation definitely matters to me

Maybe I shouldn't be using goog.DEBUG at all, but just some other global that I invent...

that sounds more appropriate if you want to modify things at runtime

Hmm. The code that toggles goog.DEBUG is in an event handler that will never get run but I guess that doesn't matter.

Funny thing is, the code still compiles and tests still run (in advanced mode)

Hi All!

@colin.yates: check out cljs-time's project.clj. They use with-profile to specify cljsbuild keys.

I want to make a page for a radio station with an Icecast stream...

is there any libraries you could recommend for this?

@dnolen: is this closer to what you had in mind? https://github.com/clojure/clojurescript/wiki/Porting-JVM-dependent-namespaces-to-Node

@bensu yes that’s heading the right direction - it’s beginning to show how non-obvious the actual end path might be

@dnolen: agreed. I'll start by putting together whatever I need to use all of tools.namespace from cljs and get a better feel for the problem

as usual, the problem is amplified by JavaScript target diversity. we should make a term for it

Anyone know if I could use om-bootstrap with input form validation with schema?

Does Clojurescript have something like Enlive/Enfocus/Hiccup but that exports to XML?

(My actual problem is translating data structures into approximate SOAP equivalents; I’d be a lot easier to test if my intermediary data structure was also a bunch of Clojure data structures, as opposed to browser DOM objects)

@lvh Sablono and React.renderToString

bhauman: Thanks!

@lvh React.renderToStaticMarkup actually :)