This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-17
Channels
- # beginners (52)
- # boot (116)
- # cider (21)
- # cljs-dev (44)
- # clojure (104)
- # clojure-dev (82)
- # clojure-greece (5)
- # clojure-japan (4)
- # clojure-nl (14)
- # clojure-russia (65)
- # clojure-serbia (3)
- # clojure-spec (38)
- # clojure-uk (9)
- # clojure-ukraine (1)
- # clojurescript (65)
- # clojurewest (1)
- # community-development (1)
- # core-logic (3)
- # cursive (5)
- # data-science (9)
- # datomic (13)
- # emacs (45)
- # euroclojure (1)
- # hoplon (2)
- # instaparse (23)
- # javascript (1)
- # jobs (2)
- # klipse (43)
- # leiningen (8)
- # lumo (25)
- # off-topic (7)
- # om (13)
- # om-next (3)
- # onyx (11)
- # pedestal (12)
- # planck (19)
- # proton (1)
- # re-frame (26)
- # reagent (26)
- # remote-jobs (13)
- # ring-swagger (23)
- # spacemacs (1)
- # untangled (3)
thx - is that a patch over current state or clean patch?
@hiredman tests were failing with patch due to typo. I fixed, but found something else that looks amiss - details in patch
I fiddled with the tag metadata in the patch too. I had been tagging exceptions with java.lang.Throwable, but it seems more correct to pull the tag from the analyzer analysis, but that tag is a class and not a symbol.
and the 0004 patch I just uploaded (sorry, I didn't notice your -4 patch until now) doesn't apply cleanly to master because I didn't pull master before I created it, so here comes 0005
Hey all. I’d like to start trying to contribute to clojure core. I have signed the agreement and I’m looking through the jira. I was looking at starting with the trivial bugs first as I’m rather unfamiliar with the codebase but all seem to have already been patched. Does this work on a first come basis? What would be the most productive use of my/your time when it comes to this?
@petr it's usually a process of: - find an open bug you're interested in fixing and that's within your capabilities - fix it - wait a bit
@bronsa is it safe to assume that any of the issues reported here have been approved as ready to work?
@petr all the issues marked as vetted
in JIRA that have no patch are tickets that have been approved as ready to work
more context and info here http://dev.clojure.org/display/community/JIRA+workflow
ah, right, actually, come to thing of it, would tag ever not contain a class coming from the analyzer?
in theory a compiler (pure function, data in, data out) is the sort of thing you should be able to share easily between clj and cljs
@alexmiller i have a couple of one-line commit to add on top of last patch, want me to make another ticket or attach them to the same?
diff is really minimal https://github.com/clojure/core.async/compare/master...Bronsa:master
bleh. I hate everything about applying multiple interleaving patches to multiple tickets.
I’m on the verge of unrolling all of them
and starting over with a single patch for each
the thread thing seems like an independent ticket
so I’d make that separate
yeah, I read the back chat
I think I am going to unroll these changes so we can get a single commit that represents the patch
for both 138 and 169
let me know if you want me to do anything (re: squashing, generating a single patch, etc)
I’m not expecting to get to the point of a release on this till early next week at this point as it needs to get run through internal testing on stuff I don’t even have access to
@hiredman yeah, I’d like a single squashed patch for 138
but let me back out the partial changes first to give you something to build against
yes, sorry
repo should be back to unapplied state for 169 and 138
@petr for a variety of reasons, there are not a lot of good newbie places to start in the Clojure jira. Most tickets tend to fall into one of: 1) good problem, easy to fix - those typically have already have a patch and are awaiting eval 2) good problem, clear idea to fix, but hard to implement 3) good problem, but no clear idea on path to a fix 4) problem/enhancement that has not been evaluated and may not be wanted/needed
most people get started working on something because it is a problem that is actually affecting them
i can now put in my CV driven alex miller insane by forcing him to revert my patches 3 times
:)
nope, still sane
haha >>>It's pulled, and it's fine, but there's clearly a balance between "octopus merges are fine" and "Christ, that's not an octopus, that's a Cthulhu merge".
@alexmiller that’s unfortunately what I’m finding. I have no problem working on more difficult problems, it’s just that I don’t know the clojure core to the point that I would feel all that comfortable in doing so. As per @bronsa ‘s recommendation I have found this list of issues: http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10373. It is a whole lot smaller than I had imagined but it does give me an idea of what I could work on without being too worried that the ticket would be rejected as a whole.
well, I would say that many of those tickets are in that bucket but have not actually been approved by Rich. I’ve stashed them there just so they get looked at
unfortunately I don’t have anything specific to point to at the moment
things are pretty far backed up waiting for Rich atm
Sorry, I didn’t mean to imply that I’d like you to spoon feed me tickets. I just don’t want to waste my time writing a patch for something that is not wanted and as a result wasting the time of other people
http://open-source.braveclojure.com/ has a list of projects looking for help
http://jafingerhut.github.io/clj-ticket-status/CLJ-top-tickets-by-weighted-vote.html is another view of the world, sorted by weighted votes
@alexmiller FYI apparently applying 138->169->185 causes conflicts but 169->138->185 applies fine
I’m probably not going to do this today as I am going to turn off the computer and go outside :)