This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-07-18
Channels
- # admin-announcements (4)
- # announcements (1)
- # boot (9)
- # cider (19)
- # clojure (59)
- # clojure-android (59)
- # clojure-berlin (2)
- # clojure-dev (13)
- # clojure-japan (11)
- # clojure-russia (112)
- # clojure-spain (2)
- # clojure-uk (2)
- # clojurescript (183)
- # core-typed (9)
- # cursive (4)
- # datomic (9)
- # indycljs (2)
- # jobs (3)
- # ldnclj (3)
- # off-topic (4)
- # re-frame (4)
- # reagent (13)
@meow: Interesting. I never looked into letfn
for :def-emits-var
. Gonna see if it has implications there.
@dnolen: OK. That deserves this quote: http://www.saveaquote.com/quotes/information-technology-it/quote-243812
Guys I need some feed-back on the cljs android REPL that I am working on. Should I drop the android apk on slack ?
@lazy-lambda: I don’t have an android phone but if you do I’m sure someone will try it!
Dumb question: Why “lein clean ; lein figwheel”. Why is the lein clean needed / what is it doing?
@erichmond: it’s not hard to get corrupted builds between sessions, lein clean is just a safeguard
Between auto-reload on the server and figwheel on the front-end, and REPL driven development, it’s already a dream fulfilled. No complaints here!
If you don’t have an Android device handy, you can try @lazy-lambda ’s Replicator in http://Appetize.io: https://appetize.io/app/ea677qtmeyy9ec50khdp85j78c
@erichmond: There's also boot. Never a need to do 'clean', since it has the concept of immutable file sets.
@erichmond: you can get a little taste of it here, http://blog.michielborkent.nl/blog/2015/06/06/from-leiningen-to-boot/
@erichmond: I'm still working with lein by default (old habits...), but good to know that this exists
like a dog worrying a bone, I've been working on letting go of OO, embracing functional programming and immutable values via calculating frames-per-second. I finally have a version that doesn't use atoms. It was a good exercise for me. Here is the final result (so far - these things are hard to let go of):
(defn listen-fps-interval!
"Executes callback at regular intervals returning the frames-per-second."
([callback]
(listen-fps-interval! callback 500)) ; Measure every half-second
([callback interval]
(request-animation-frame! (listen-fps-interval! callback interval nil 1)))
([callback interval start-time frame-count]
(letfn [(step
[timestamp]
(let [start-time (or start-time (- timestamp 17))
elapsed (- timestamp start-time)]
(if (< elapsed interval)
(request-animation-frame!
(listen-fps-interval! callback interval start-time (inc frame-count)))
(let [fps (->> (/ frame-count elapsed) (* 1000) (.floor js/Math))]
(if (callback fps)
(request-animation-frame!
(listen-fps-interval! callback interval timestamp 1)))))))]
step)))
What's a good way to set a dom ready handler in cljs (I'm using reagent)?
@pesterhazy: there is a #C0620C0C8 channel. I'm not using reagent atm, but most of these things have an on-load
or main
function that gets invoked. Plus you want to make your code reloadable.
@meow: I guess I can simply make XHR requests in my (init) function?
Are there any frameworks that embrace a relay/falcor model besides Om Next, currently?
@erichmond: https://github.com/tonsky/datascript , not really a framework, but a building block that can certainly replicate that, and perhaps even be better (imo)
@greywolve: Om Next was designed to integrate with DataScript trivially 😉 It’s like 10 lines or something last I checked.
@dnolen: regarding http://dev.clojure.org/jira/browse/CLJS-1277, any objection to creating separate issue for implementing require, in-ns, etc?
i’m looking into this now. implementing require
might be beyond my current understanding of the compiler
step 2 is demonstrating we can compile a file with require
in it with no other ns forms.
ok, just trying to wrap my mind around the compiler in general. i blame the >20k LOC issue 😉
@maria’s work on the compiler is a good approach, incremental patches and just focus on the aspects of the compiler that are relevant to the task at hand.
the compiler is mostly functional so you rarely have to worry about significant repercussions for any small change.
@bostonou: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/repl.cljc#L644-L646
(require ‘goog.string)
-> (with-meta (ns cljs.user (:require [goog.string])) {:merge true})
this allows us to completely reuse the ns
logic in the compiler and tell the compiler that this should merge existing information not replace anything.
I am looking to use https://github.com/streamproc/MediaStreamRecorder , where should I start when it comes to integrating this into my cljs boot build process?
Thanks you @dnolen, would https://github.com/clojure/clojurescript/wiki/Dependencies#using-externs still be the most up to date information about getting external code integrated?
@samedhi: yes for a library like that you will definitely need to provide your own externs
@samedhi: I don’t think you’ll see a better story for foreign libraries until much later this year
@samedhi: to build on what @dnolen said, take a look at http://cljsjs.github.io/
and here is info and a boot tool to help with what you'll need to do: https://github.com/cljsjs/boot-cljsjs
@erichmond: probably sometime in September at the soonest
A while back I was rambling about an alternative virtual-dom approach in this here chatroom. I don’t remember exactly who was involved in the discussion, but for those who were listening in, here’s an implementation of that approach: https://github.com/brandonbloom/cljs-vdom
@bbloom: seems like dealing with the reparenting issue is pretty novel amount VDOM implementations
The “syntax” that’s provided for my testing purposes doesn’t address it b/c it uses hierarchical paths as IDs, but if you use the “core” API directly, you can easily give things any ID you want.
When I take a crack at a component model, I’ll encode IDs in terms of a “context” plus a “key”, where the default context will just be the ID of the current parent. The net effect being that you can opt-in to reparenting by overriding the default context, at the cost of having to ensure your keys are unique within a the greater scope of that given context.
@dnolen: If I recall correctly, you said Rich also didn’t like the lack of independent addressability. With the global IDs, this is no problem either.
@bbloom: btw, seems like with bootstrapping sharing programming language experiments will be a lot simpler
bootstrapped ClojureScript is still less JS than the front page of the New York Times 😛
@bbloom: do you have any specific ideas wrt to event handling? or is that something that should be added as a layer on top?
I'm looking to jump back into cljs (I used it a little over a year ago for some experiments). Do you guys have a suggested article/tutorial/etc to get started with cljs using all the new great tooling I hear about?
I'm looking to build thick client style apps so I don't need integrated backend functionality.
well I guess thick client doesn't make that much sense, basically building the entire app clientside and in nw.js
@orther: lots of people really like figwheel, you can start programming a ClojureScript app in about 30 seconds
I've read about figwheel, I've wondered if the magic behind it will cause me any problems.
after you understand the basic tooling underneath from the Quickstart I reccommend the figwheel template
I recall reading a blog post on cljs and the author mentioned that by removing the need for clojure/jvm it allows a bigger group of community (the js devs) to jump right in with less of a barrier
One common theme I sense is “I think I want to get into ClojureScript, but yuck, you are asking me to install the JVM on my box."
@orther: No problem. You won’t be the last to broach the question. It happens once per day or so at least.
@dottedmag: I don’t see why not, would be cool
A few people I have talked to that watch clojure/clojurescript and are interested in cljs but not using it now have said things like, "Yeah I heard they are porting the compiler to be self hosting so I don't have to use java. I'm waiting for that."
@orther: that said some people may very well end up using ClojureScript only via Planck or whatever, and that’s great.
and ClojureScript will actively help make such cool efforts possible and simple, but it’s not a “direct" focus area
A different way of looking at it: What if ClojureScript required Node.js (instead of the JVM)? That would be a new thing for people to cope with. My advice: Deal with it! Don’t let something as simple as that cut you off from the great things you can do with this language.
@dnolen: A part of me sees where the questions regarding ditching the JVM comes from. It could be a goal. But, in fact, it is not a goal. Just needs to be in a place.
The painful thing is.. CLJS is very attractive as an alternative to JS, from the perspective of a recovering JS dev such as myself. Historically, the JVM was a necessary evil for using CLJS. With self-hosting, it looked for a moment like it might become an unnecessary evil. But instead, I think we JS devs just need to learn that the JVM actually isn't evil at all. It might be incidental complexity, but it's not a very deep tar pit at all — it's just hard to know how deep it is until you step in it.
@ivanreese: I never learned Python, never really developed an opinion about it. But, I used Mercurial, and loved it. I wonder… does ClojureScript actually require users to know a lot about the JVM? Maybe it is not as hidden as is the case with Mercurial / Python.
ivanreese: Closure Compiler is in Java, and ClojureScript it is not very useful without it.
@dottedmag: to be a bit more precise, the primary use case is not very useful without it
I created a new Wiki, with a stab at the JVM FAQ entry, spit out off the top of my head. Perhaps we can clean it up over time: https://github.com/clojure/clojurescript/wiki/Bootstrapped-ClojureScript-FAQ
I think I’ll add an entry for the natural follow-on question that someone might have “Then why was bootstrapped ClojureScript crated?
@maria @dnolen @mfikes Kudos on all the progress with bootstrapped cljs/Replete/planck. Really fun to watch you all work!
@chancerussell Thanks! (It is fun building little applications on top of bootstrapped ClojureScript!)
I’m looking forward to the day where it’s as easy/fast to write my little system scripts in ClojureScript as it is in Ruby, etc. Not that it’s particularly hard now, but the idea of compiling and running one-off scripts in one go is really appealing.
@chancerussell: Planck is definitely a big step in the right direction
I’m having trouble wording this one “JVM” point (trying to say it right without sounding negative): "A significant majority of ClojureScript developers are also Clojure developers. (In other words, ClojureScript largely exists to support the Clojure development community; not the JavaScript development community.)” (Anyone feel free to edit my botched attempt to express this.)
@mfikes: or about the primary users. Yeah I don’t think that point is really so relevant.
@dnolen: I’ve tried to put the clojure version checking code into a separate ns, and require it and call its function before other ns form. and it doesn’t work in AOT compilation. i wanted to avoid dropping the same code all over the place. is there anything i should try (that i obviously don’t know of) to make AOT work?
@annapawlicka: yeah this was something I was afraid of.
yup, it’s throwing NPE in AOT
@annapawlicka: hmm, it’s for this reason that I’ve really avoided wanted to include this type of thing in ClojureScript
@annapawlicka: so much easier to solve at boot or cljsbuild
that was my thought. those type of checks should be done by the build tools
@annapawlicka: sorry for encouraging you to pursue this, but at least it’s a bit clearer why it’s not the right place to check
@dnolen: that was fun, i’ve never actually looked closely at cljs source code. Now I do
I’m gonna try and create PRs for boot and cljsbuild - more knowledge about tools for me
@dnolen: i will comment on the jira issue about the AOT problem and will close it
@annapawlicka: thanks!
@annapawlicka: boot-cljs is probably the best place to add this kind of check. If you have any questions feel free to ping me
@martinklepsch: thanks! I have a free morning tomorrow so might start looking into that then. and cljsbuild too
@annapawlicka: is this maybe already all that’s needed? https://github.com/adzerk-oss/boot-cljs/blob/master/src/adzerk/boot_cljs.clj#L23-L28
yup, looks very much like what i wrote recently
boot-cljs follows ClojureScript versioning so the most recent version always checks for this. Maybe this is going to become a bit more loose in the future though.
i think it should only warn when the version of clojure prevents cljs from compiling
you mean of two incompatible versions are used? Agree.
That’s why I mentioned that boot-cljs follows CLJS version numbers
Anyways, I should really sleep. Feel free to hit me up if you have any questions.
it looks like assert-clojure-version!
checks for 1.7 only, and from experience i know that `1.7.0-alpha2’ won’t work with the latest cljs. so it should check for qualifiers as well.
Good point.