Fork me on GitHub

Is there a way to run filter against a PersistentHashMap and get out all the items which have values which are themselves PersistentHashMaps? How would I check for this? The item is basically a js object with several top level key value pairs which are just key : string and a few others which are key : object.


@dfcarpenter: sounds like you could use a combination of filter with some simple predicate functions like map? or associative?


If I am understanding the problem correctly


@chrisoakman: Thanks! I figured it out.


Anyone using chestnut? I’m not sure I understand the workflow. I can start a repl, (run) the webserver and figwheel and run (browser-repl), but then I only have access to the cljs repl and no access to the web repl (as it’s blocked). Is there any way to have both of them running? Or does everyone just rely on auto reloading and not evaluating specific sexps? Maybe I should be using multiple repls? But when I try to do it - one for the webserver and one for the cljs repl - the second one cannot pair with figwheel as it’s running in the original web repl process.


finally get google animation working with clojurescript, feels good 😄


Is there a way to override pretty-printing on custom Records? like the simple-dispatch on clj side?

Alex Miller (Clojure team)13:02:34

Yes. There's actually a jira to do this generically if you want to vote for it

Alex Miller (Clojure team)13:02:09

Oh sorry didn't realize I was in the clojurescript room, was thinking Clojure :)


but if I understood that, no way to use that with custom Records at the moment?


@ikitommi: I never looked at that part so I don’t know - you should file an issue if it can’t be made to work and if it does work in Clojure


if it doesn’t work in either, then preferred that we do the same thing.

Alex Miller (Clojure team)15:02:36 is the clojure ticket to make this change the default which is in the list to look at for 1.9 (but no guarantees)


we are experiencing long compilation times when using threading macro + (many) multimethods. example here I guess that I should report that to Jira? (cc: @dnolen )


@dnolen: Yeah, I’m happy about that one.


@mfikes: Might be interesting to you related to Planck - cross platform Unix shell commands using Node -


So I've been rolling my own asset fingerprinting for CLJS (since I couldn't find anything available) and I'm at the point where I need to hook into the CLJS build to execute the fingerprinting after the CLJS is built, but before the jar is. I'm using lein-cljsbuild and their hooks for the build itself and we deploy an uberjar. Has anyone done this sort of thing? I'm fumbling with adding my own hook (using robert.hooke) and it feels limiting because it's forcing me to internalize some environmental state.


I'm really surprised this isn't already a solved problem, actually... we got bit by a changed CLJS function arity with some browser-cached JS and I can't imagine we're the first.


@voxdolo: I’m finding leiningen quite difficult for these kinds of processes. I haven’t looked too deeply into boot, but I suspect it will be a better fit for asset pipeline stuff


@danielcompton: yeah, there's an existing boot task for doing fingerprinting too... the effort to move from lein to boot seems daunting though, given the infrastructure we've built around lein 😕


yep, same here


I think I can probably do what I want if I go the route of making it a full-fledged lein plugin (because then I create a settings map with the relevant external state), but wow... that feels like a long way to go.


It'd be really great if offered some extension points for doing this sort of thing.


not interested in adding stuff like that to ClojureScript


this solidly in "need to solve it elsewhere" territory


dnolen: it's obviously your call simple_smile I am curious how you deal with cache-busting though. It seems like a very real need when your ultimate consumer is a browser that has optimized highly around not re-fetching assets.


@voxdolo: integrating boot to do just the finger-printing + JARing seems perfectly reasonable to me


I don’t really understand why you would need to whole-hog Boot at all in this case


well, it's never quite as simple as just moving jarring to boot... that assumes a pretty shallow build process.


you're right though, it doesn't have to be a binary decision... it could be both


but using boot even just for creating our uberjar is a (greatly) non-zero amount of effort simple_smile


or just write a bash script plus a Maven pom for this step, which is probably what I would do


if some tool is getting in the way - stop using it for that thing - that’s how I go about it


Maven treads deep into unknown territory for me


there’s a learning curve, but in my experience there’s fewer potholes simply due to maturity


fair points all, though. I'll think on it for a while. Thanks for the input and it's good to know that does not expose any hooks around its build intentionally.


@voxdolo: somebody might have even gone down this path might want to check the boot channel about this


or at least can point you in the right direction (I’m not familiar with boot)


dnolen: there is indeed a boot task for fingerprinting. I'm looking at just how heavily we depend on lein during our uberjar build and considering it. thanks again!


@voxdolo: are you shipping the cljs inside the uberjar? back when all the tooling was different, we just shipped a separate archive for static assets to be unzipped to a filesystem / served by nginx, and the output of the cljs build went into that assets directory


then fingerprinting could happen in sort of a generic way across all assets


[just an experience share, in case you're like me and ignored the possibility of pulling assets apart from the uberjar]


trptcolin: yeah, we're shipping the CLJS inside the uberjar. deploying to heroku hamstrings some of your decisions around that sort of thing.


so I'm really fighting multiple tools of my own choosing 😄


I laugh so I don't cry


I could build the fingerprinted file and push it straight to our CDN... thanks for the nudge trptcolin!


voxdolo: I use optimus for fingerprinting


works decently well, though the toolchain isn’t as well trodden as npm, less.js, etc


arohner: we used to as well, but we use sass for CSS, which is why we moved away from it some time back. This was before we had any CLJS in our project though. I suppose it could be useful just for fingerprinting CLJS though.


ah. I’m using less


google found: thought I have no clue how useful it is


that's what we started out using too. at this point I don't even remember what it was that drove us away from optimus, but that lib had something to do with it.


we're doing sass compiles with gulp now (which, unsurprisingly, has fingerprinting support of its own)


if you just need to fingerprint CLJS, I’d just use a simple .clj fn


I'll say this for the node folks, they've got some really fast build tools


I’ve been moving build stuff into, and then calling from lein w: {:aliases {"deploy-assets" ["run" "-m" "”]}}


so when you build, you're pushing them to some external CDN that gives you back a hosted URL for them?


I’m using AWS Cloudfront. On my machine, optimus calculates sha1 of app.js, writes app-<sha1>.js to disk


I wrote code to upload app-<sha1>.js to S3, to get served by CDN


at runtime, the server’s app.js file in the .jar has the same sha1, so it serves a link to <CDN DNS>/app-<sha1>.js


yeah, that makes a lot of sense


I'm knee-deep in a leiningen plugin at this point... so I'm going to follow this path to completion. I think there's a need for something doing this in a deployment-agnostic fashion, so maybe it'll be useful to others as well.


I can see a future in which we end up doing exactly what you're doing now though.


IMO, treat lein plugins like macros, only use them when you can’t do it any other way


if you just need to call a .clj fn from the command line, add an :alias that’s just lein run -m ns/name


the main thing plugins add is the ability to change your classpath


so, without moving deploying the fingerprinted file to a CDN, I don't think I can inject myself into the build process at the point where I need to any other way than with a lein plugin. I need to fingerprint after lein-cljsbuild, but before lein-uberjar.


Hmmm... I could just invoke uberjar from my own task. it seems a little like semantics at that point though. I'm already using lein-cljsbuild, so this sort of approach is already in play.


@voxdolo: this kind of thing is pretty straightforward in boot, don't know if that's an option


pandeiro: we've got a fair amount of infrastructure around lein in place that make it a pretty substantial move. Probably not something we would embark on to facilitate this specific use-case.


I've been watching over the wall with interest though simple_smile


@voxdolo: reading back, are you wanting to deploy your app to Heroku in two archives? a jar for the backend and something else for the CLJS? We're (heroku) still trying to figure out what will work best for our customers wrt cljs. So if you have suggestions i'd love to here them--so i can make it easier for you simple_smile


@codefinger: we're currently deploying our app as a single jar


yea, that's what we recommend now. but i keep hearing from people that don't want it in an uberjar--either because it's a SPA or some other reasons.


@voxdolo: not sure if this is helpful, but here is how I do cache busting for the CLJS cheatsheet:


that's using Grunt.js (which would obviously be another tool on your stack), but the idea is simple and could probably be implemented anywhere pretty painlessly


@chrisoakman: interesting. at what point in your build process does gulp get invoked?


I develop locally with no file caching, then when I'm ready to push a build out I type grunt build and then SFTP it over to a shared hosting account server


pretty low-tech, but quite reliable


I like re-naming the file because it makes it impossible for someone to get an "old" version, regardless of server settings, cache headers, etc