This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-23
Channels
- # admin-announcements (1)
- # announcements (1)
- # beginners (222)
- # boot (210)
- # cider (26)
- # cljs-dev (50)
- # cljsrn (19)
- # clojure (243)
- # clojure-art (12)
- # clojure-finland (1)
- # clojure-poland (43)
- # clojure-russia (46)
- # clojure-sg (13)
- # clojurescript (60)
- # core-async (14)
- # css (11)
- # datomic (9)
- # devcards (9)
- # dirac (2)
- # editors (13)
- # emacs (5)
- # euroclojure (1)
- # events (3)
- # hoplon (76)
- # immutant (10)
- # job (1)
- # jobs (2)
- # keechma (1)
- # ldnclj (33)
- # lein-figwheel (1)
- # leiningen (20)
- # luminus (26)
- # mount (31)
- # om (105)
- # onyx (56)
- # parinfer (29)
- # perun (12)
- # proton (1)
- # re-frame (14)
- # reagent (5)
- # sydney (1)
- # yada (15)
@dnolen: There are a handful of self-host ticket patches which will collide owing to unit tests being added in the same spot. Just a heads-up. I’ll update patches as needed to make sure they apply cleanly whenever they no longer apply against master. (I can’t think of a good way to avoid the problem a priori.)
@mfikes: of those patches is there one that I should go ahead and apply i.e. doesn’t really require much review? like the Unicode one?
@dnolen: These are one-liner cut-n-try self-host tickets (one line to the prod code): http://dev.clojure.org/jira/browse/CLJS-1564 http://dev.clojure.org/jira/browse/CLJS-1584 and I think this one is also pretty cut-n-dry http://dev.clojure.org/jira/browse/CLJS-1521 I don’t think I’d characterize the other self-host tickets as cut-n-dry.
Cool. Yeah, that one you had strange reader errors. Maybe that one isn’t cut-n-dry then. 😕
@dnolen: Thanks. I think that broke the logjam, making it so that the other patches can be rebased and will have unique places for the code revisions
@bronsa: The Clojure implementation of tools.reader
delegates to some runtime support in classes in clojure.lang
when reading maps and sets in order to check for duplicate keys, but the ClojureScript implementation delegates to standard lib fns (set and hash-set). I think this results in no duplicate key checks for the ClojureScript implementation. Was thinking about logging a JIRA but wanted to run it by you first.
I was thinking in lines of http://stackoverflow.com/questions/8056645/returning-duplicates-in-a-sequence
Hi all! Just getting started with a very minor issue, but want to make sure I’m following the right conventions. When submitting a patch for a JIRA issue, should the included test always be added with the issue number, instead of included into existing tests?
This particular example deals with get-in
, http://dev.clojure.org/jira/browse/CLJS-1420, where get-in
already has some tests. Right now I have a patch with deftest test-cljs-1420
appended to the end of the test file, but wanted to confirm that this is the right way.
@wildermuthn: there’s no real hard convention here - that is approach is fine
Ok, thanks
I like #((rand) (rand))
(take your chances), or (let [a (atom 1)] #{(swap! a inc) (swap! a inc)})
. Fun!
@mfikes: cool I will probably cut a release on Friday since the :parallel-build
bug is a pretty bad one
@mfikes: you’re now just behind Rich Hickey in the largest number of changes committed to the ClojureScript code base 😉
it would be great if you guys want to add CLJS-1515 😄
@wildermuthn: patch applied
Thanks! My small Clojurescript team is going to be taking time each week to attack low-hanging fruit, so hopefully it won’t be the last minor issue we get working.
@wildermuthn: much appreciated