1:02 Anniepoo: In a proxy what's the name of the constructor, since the class is anonymous?
1:03 hiredman: you cannot make a constructor
1:04 Anniepoo: hmm... I'm trying to overrride the constructor of JLabel to muck with it on setup
1:05 hiredman: you cannot
1:05 Anniepoo: ooochie... ok.
1:05 hiredman: you can muck withit first, then pass it to jlabel
1:05 Anniepoo: yes, that's what I meant
1:08 replaca: ~proxy
1:08 clojurebot: proxy is <Chouser> proxy teases with its ease of use, then suddenly betrays.
1:08 Anniepoo: say you want to make a special kind of label where the text has "XXX " automaticly prepended to the label. Otherwise it's an ordinary JLabel.
1:10 hiredman: (defn special-jlabel [x] (JLabel. (str "XXX" x)))
1:11 very simple
1:17 twopoint718: I have a quick question about def.
1:17 Are the vars that def creates public in that namespace?
1:24 hiredman: yes
1:24 they are public in any namespace
1:24 if you (def a 1) in the foo namespace
1:25 if the foo namespace is loaded, in the user namespace foo/a will give you 1
1:26 you can assoc :private with true in the metadata to make a private def
1:26 there is also defn- for private defns
1:28 twopoint718: Okay so if I have a var in namespace foo, what do I use to refer to it from another namespace?
1:29 hiredman: depends
1:29 how are you loading the foo namespace?
1:30 short answer is the namespace qualified symbol
1:31 twopoint718: I was using ":require" inside the ns form
1:31 hiredman: yeah
1:31 so foo/whatever
1:32 ,(resolve '+)
1:32 clojurebot: #'clojure.core/+
1:33 twopoint718: Okay, I think I know what I'm doing. I think I'd created a circular dependency
1:34 ns A requires ns B, then B wants to refer back to something in A that hasn't been loaded yet, is that plausible?
1:35 hiredman: that is a circular dependency
1:37 twopoint718: shoot
1:43 I think I'll just pass two more parameters
1:43 hiredman: thanks for the help, I think I've got it sorted out now.
1:49 Anniepoo: hiredman, thanks for helping out us noobies
1:49 hiredman: ~hiredman
1:49 clojurebot: hiredmans euler.clj is so embarassing
1:58 hiredman: ~sandboxing
1:58 clojurebot: Titim gan éirí ort.
1:58 hiredman: bah
1:58 clojurebot: sandbox is http://
3:57 sgtarr: clojure rules
3:57 but I have trouble finding a development environment which is not Emacs :/
3:57 The Eclipse plugin lacks in features, the vimClojure crashes on me (author knows about this so it might be fixed soon)
3:58 eevar2: did you try the netbeans plugin?
3:59 hoeck: sgtarr: I tried netbeans too, but I'm am emacs user, so I'm missing all the fancy keyboard-only jump-around-the-buffer commands
4:01 sgtarr: but what I'like about the netbeans plugin is its easy setup and the way you mange your project and your dependencies
4:09 sgtarr: hoeck: netbeans tends to be rather sluggish and ugly in Linux
4:09 but.. seeing that I have few choices here, I'll give it another try
4:09 hi kotarak :)
4:10 kotarak: hi sgtarr
4:10 sgtarr: kotarak: do you mainly use vimclojure when developing clojure programs, or do you also use emacs/netbeans/eclipse/.. ?
4:11 kotarak: only VC
4:22 sgtarr: ok
4:22 clojurebot: book is http://
4:22 sgtarr: ok
4:22 weird, why did clojurebot say where the book is? :)
4:23 * rys gets grumpy that his copy hasn't been delivered yet
4:29 sgtarr: it seems Clojure is taking off... more and more people getting interested
4:29 Just imagine if Lisp really got a "mainstream" comeback
4:29 And Lisp was never really Mainstream.
4:30 I'm reading "Programming Clojure" here at work instead of actually doing work. heh
4:30 Carkh: the secret weapon going mainstream ='(
4:42 sgtarr: Don't worry, it won't get *that* mainstream
4:54 Carkh: what do you use Clojure for specifically?
4:54 Carkh: server stuff
4:54 mxc: wasn't lisp mainstream in the 50s when it was that, fortran, or assembler?
4:54 Carkh: right now : a web application for telephony provider
4:55 mxc: clojure does seem interesting, as a current haskeller
4:55 sgtarr: haskell is just too strictly functional for me
4:55 clojure opens up flexibility
4:55 i'm a practical guy
4:56 mxc: i love my type safety
4:56 Carkh: haskell is nice, but it's hard to keep in the spirit of it all the way
4:57 there is always a point where it gets too hard to keep fully type safe
4:57 mxc: would love to be able to use java libraries though
4:57 sgtarr: what I love about these languages is how elegantly you do concurrent programming
4:57 mxc: i just think that haskell's learning curve (basically a vertical line) is probably a bit steep
4:57 sgtarr: and that's one of the motivations for me learning Clojure now
4:57 mxc: hahaha, a vertical line :)
4:58 mxc: but once you get over it, its pretty amazing
4:58 * eevar2 thinks haskell and/or ML looks interesting
4:58 mxc: i've used ocaml, f#, and haskell
4:58 sgtarr: we used ML (standard ml of new jersey) in university for a course, it's interesting but I do not want to use it again
4:58 and that has really put me off F# as well, since it's inspired by ML
4:59 Lisp however, is so elegant, it's the language of the Gods
4:59 eevar2: question is whether i should pick up yet another language, or just focus on the toolset I already have ;)
4:59 mxc: f# is annoying since you have to use so many C# libraries that you lose all the type safey and FP assurances
4:59 sgtarr - ostesibly yes, but didn't they just hack most of it together with perl?
5:00 sgtarr: mxc: fortunately they came up with a recipe that worked, because seeing that it's hacked together with perl it's impossible to maintain :)
5:00 mxc: hehe
5:00 have you ever tried patching existence?
5:00 sgtarr: nope
5:01 mxc: some theorize that there is version control, commits only last for plank time before the master reverts the commit
5:13 sgtarr: mxc: haha :)
5:53 thomaslee: (let [run [1 2 3] runn (count run)] (do (dorun runn run) (do (dorun run))))
6:01 jdz: first dorun looks wrong
6:03 thomaslee: it's straight from the interpreter. it runs, but don't expect it to do anything. :P
6:04 jdz: yes, i just have not used the two-argument version of dorun
6:25 thomaslee: what's the easiest way to get at the :doc string associated with a clojure function?
6:25 hoeck: (doc name)
6:25 clojurebot: "([x]); Returns the name String of a symbol or keyword."
6:26 thomaslee: I would've thought (meta <function>) would give me what I was looking for, but it seems to yield nil
6:26 It doesn't just print it out?
6:26 hoeck: functions have no metadata (yet)
6:26 but vars have
6:26 so (meta #'<function>) is your friend
6:27 or (meta (var <function>))
6:28 or ^#'name :)
6:30 thomaslee: hoeck: thanks, but I don't understand the difference -- why does (var <function>) work when <function> doesn't? Is defn not just performing a "(def blah (fn ...)" under the hood?
6:31 hoeck: yes, but the metadata is stored in the var object, not in the function
6:32 and evaling <function> returns the content of the var, a function for example
6:33 thomaslee: hmm, okay. I think I understand.
6:36 so the names to which things are bound in clojure are objects unto themselves
6:36 which is why vars have the metadata but functions don't
7:12 eleftherios: I am getting very bad support from Pragmatic Programmers customer support for the Programming Clojure book
7:13 I was almost shocked to receive such a lousy response from these guys, I thought they were a friendly bunch
7:13 rys: I didn't get the best response either
7:13 eleftherios: they didn't even greet me
7:13 and they didn't have a name or signature on the email
7:14 the ebook has an issue, on the Sony PRS-505 at least (which is probably one of the most popular ebook readers)
7:14 the code is off the right edge so one can't read the code samples
7:14 what use is a programming book if you can't read the code?
7:14 and I sent a nice email letting them know about the issue
7:15 rys: Yeah, it's the same issue on the iPhone with the ePub for me
7:15 eleftherios: and this guy replied in a few words and he said, 'we asked our readers and they want us to maintain the semantic integrity of the code'
7:15 and 'read it in landscape'
7:15 and the guy obviously hasn't even tried because
7:15 in landscape mode you lose even more of the code
7:16 rys: It doesn't work in landscape either, yeah
7:16 eleftherios: he is an idiot
7:16 and I replied in a very friendly way again
7:16 and said, 'look, how can you maintain the semantic integrity of the code when half of the code is not there?'
7:16 rys: Stock of the print version in the UK is weak, so I've been waiting since launch day for my copy, reading the crippled ePub version instead
7:16 eleftherios: and that 'in landscape mode isn't available either'
7:17 and guess what?
7:17 he hasn't replied in 4-5 days
7:17 so basically, he gives a couple of wrong recommendations in a dry, almost rude email
7:17 and then they ignore further emails
7:17 so now I am upset and I want a refund because the eBook is not fit for purpose
7:17 and they have failed to be polite or helpful
7:18 and I am a long-time customer, they can see my account
7:18 so if anyone is planning to get the eBook, hold your fire because as rys says too, you want be able to read the code
7:38 doug_: I want to convert '((1 2) (3 4) (5)) into '(1 2 3 4 5). I can do it with (reduce #(into %1 %2) '() '(1 2 3 4 5)) but is there a convenient function to do it for me?
7:39 That actually gives '(5 4 3 2 1) but I'm not worried about the order.
7:40 I meant (reduce #(into %1 %2) '() '((1 2) (3 4) (5)) of course...
7:40 jdz: doug_: what you are looking for is usually called "flatten"
7:40 doug_: that's how I would have described it, but can't see a flatten function in the API
7:40 jdz: doug_: if you are sure all the members are lists you can do apply concat
7:42 doug_: that works, thanks. Yes, all members are lists.
7:42 jdz: well, they could as well be other sequences
7:42 but they should be seqable
7:42 doug_: slightly simpler
7:43 seqs, yes. keep forgetting this isn't lisp :-)
8:15 guinea: This might be an emacs question, but whenever I try to start swank, I get, java.lang.Exception: clojure.contrib.javadoc/javadoc can now be found in clojure.contrib.repl-utils. (javadoc.clj:1)
8:56 rhickey: I don't like that pull requests don't get a proper place to live in github - AFAICS they just turn in to messages, so hard to track which have been applied etc
8:56 also others can't see them, just in the inbox
8:58 Chouser: the patch that the pull request points to is public
8:58 rhickey: technomancy's pull requests were all from named branches on his side - I liked that vs some cryptic number, OTOH a branch isn't a point
8:58 so maybe tags?
8:59 Chouser: yes, the code is public, but not the pull request, so creates a funnel into someone's inbox
8:59 Chouser: I made a named branch for that one patch, but I chose the changeset when I sent the pull request -- perhaps that obscured the branch name?
9:00 the "network" tab on the clojure project is going to get very busy
9:01 looks like cgrand got two names on one branch -- are those tags?
9:02 hm, apparently not -- just two brances in a row.
9:03 rhickey: on the same line because they haven't diverged?
9:03 Chouser: That would be my guess
9:03 rhickey: anyway, yeah, I can imagine this getting very busy and difficult to manage
9:04 Chousuke: assembla does nothing to help with pull requests?
9:04 Chouser: For these single-patch branches, it seems this is going to be more work for everybody than a patch attached to an issue.
9:04 rhickey: pull requests are a github thing
9:05 Chouser: I can see it making sense for something like clojurescript where I was maintaining a branch with multiple patches over the course of several weeks.
9:05 rhickey: patches aren't going to get the best merge logic
9:05 Chouser: true
9:06 Chousuke: the network graph is good for seeing what people are working on though.
9:07 rhickey: if people want git they want branch/merge, no?
9:07 Chouser: if you want git's merge logic, then we've got to have public branches
9:09 rhickey: yeah, I haven't gotten a great public branch creation recipe that doesn't seem to have a redundant step
9:10 Chouser: at least I can push a new branch without having to use the web site.
9:12 Chouser: Perhaps the pull request is where things go wrong. A github branch url (instead of a raw patch) could be attached to an issue.
9:14 rhickey: I got "technomancy wants you to pull from technomancy/clojure at validate-symbols-issue-13" when he used a branch
9:14 Chouser: right, I meant for better visibility
9:14 rhickey: the problem is the branch could change
9:15 Chouser: not after you've merged it
9:15 rhickey: Chouser: ah, yes, something has to go on the issue, and ideally the pull request should contain the issue, but overall the pull requests themselves seem not terribly trackable
9:16 Chouser: true, but branch name doesn't label a point in time - are tags better for this?
9:18 Chousuke: hmm.
9:19 dudleyf: Most of the projects I've contributed patches to don't use pull requests
9:19 Chousuke: You're worried that if someone commits to a branch after sending you a pull request, you could end up merging something unexpectedly?
9:19 tags would help with that I suppose.
9:20 rhickey: or someone else couldn't reproduce - "grab fred's mod and try on your machine"
9:21 Chousuke: right.
9:22 rhickey: dudleyf: does that mean they use patches, or just don't use that part of github
9:22 Chousuke: hm. when applying git-format patches, does it preserve the author information? :/
9:22 dudleyf: rhickey: The usual way is to create a patch with git format-patch
9:23 Chousuke: Yes
9:23 Chousuke: I know the patch contains the author info and all, but "git apply" at least only adds the changes to the working copy
9:23 is there another command for applying it as a commit?
9:24 rhickey: patches seem completely antithetical to the concept of git. I can see their use for quick - "try this out over whatever you've got", but the central concept of 'this code was developed using this basis' is destroyed by patches
9:24 Chousuke: rhickey: git-format patches preserve that info.
9:24 at least to some extent.
9:25 still, pull requests would be more convenient :/
9:26 maybe probe the github guys and ask them if they could improve tracking pull requests :)
9:33 AWizzArd: Was git now chosen as the next rcs for Clojure?
9:37 kotarak: I made the experience, that 90% of the patches are not in directly applicable form. So pull requests are pretty useless for open contribution. They only work with a team, which adheres to the same rules and whose patches are directly applicable. My 0.02€.
9:38 Chousuke: apparently "git am" preserves author information etc. but it requires patches to be in mbox or Maildir format.
9:38 that is, it extracts patches from your mailbox.
9:49 rhickey: AWizzArd: we are working through the details now, but yes, git on github + assembla is the current plan
9:49 does anyone have a project they can point to with good git workflow guidelines online?
9:56 drewr: One project I work with has been using ideas from http://
9:57 rhickey: drewr: I've been reading that - it doesn't have a policy for format-patch vs pull
9:59 drewr: The maintainer could accept either.
10:02 * rhickey is trying not to dread managing patches/pulls
10:03 * rhickey is failing
10:03 Chouser: was patches attached to issues dreadful?
10:03 drewr: Takes time with the tool to build up confidence that it's doing what you want.
10:05 rhickey: Chouser: no, I guess it depends on the nature of the patch, how it is produced etc, and what it is for. Patches for bugfixes might be fine, I guess I've been thinking more about feature development with more than one person
10:06 Chouser: it may also be that the "right" workflow for clojure is not the best for contrib
10:06 clojurebot: for is a loop...in Java
10:06 drewr: If it were me, I would "git checkout -b rhickey-issue-x COMMIT", where COMMIT is the revision he was working against, then "patch -p0 < foo.patch" or "git apply ..." or "git fetch/merge" depending on how he submitted it, tweak anything I didn't like, then "git merge --squash" everything back to master.
10:06 rhickey: In any case, there needs to be a very small set of well-defined recipes, i.e. for bugfixes - patches only accepted from format-patch on code rebased to latest master etc, whatever that recipe might be
10:07 stuartsierra: Incidentally, 3 people have sent me patches in the past couple weeks.
10:07 rhickey: drewr: you have more free time than I do :)
10:07 Chouser: stuartsierra: against contrib?
10:07 drewr: rhickey: Ha. I use git because I *don't* have free time. :-)
10:08 It's a steep learning curve but an invaluable tool.
10:08 stuartsierra: Chouser: yes
10:09 Chouser: stuartsierra: people must actually use your code. I never get patches. :-)
10:09 rhickey: drewr: it's not just a learning curve thing but a matter of streamlining, e.g. I frequently got patches/diffs in formats that various tools weren't happy with, big waste of time
10:09 stuartsierra: Well, my name is on a lot of the "shared" libs, like str-utils and seq-utils.
10:10 rhickey: a project should have guidelines certainly
10:10 drewr: rhickey: I forgot that you hate the cmdline. Yeah, git's going to be painful most likely...
10:11 rhickey: drewr: seriously, it's not about learning something new, it's about avoiding cacophony
10:11 so, let's get some best practices together here
10:12 drewr: You could create a dev list where people send their format-patch submissions and discuss.
10:13 That technique's been used for decades with much success.
10:15 rhickey: drewr: just discussing what the loss is, if any, for doing so with git vs. a pull strategy that retained more of the true history
10:17 drewr: For patches? It doesn't matter. Submissions should be atomic. You just want to see the result of their work.
10:17 Chouser: from my side it hardly matters. Either way I'll keep my local patch in a separate git branch. To submit I'll either "git show" or "git push", and then fill out the appropriate attachment description, pull request, or whatever (hopefully just a single step beyond git).
10:17 drewr: So there really isn't any history to care about.l
10:18 The nice thing about pulling is that they don't have to tell you what commit they started from.
10:19 Chouser: drewr: but if head has moved on since the patch was prepared, having a git branch will make a more sophistcated merge easy.
10:20 rhickey: if we do patches, the rule will be they must apply cleanly to master head or else must be rebased and resubmitted
10:21 eleftherios: assembla? Is this any good, first time I see it
10:21 rhickey: with pulls I imagine git can do a better job with a 'stale' request
10:21 drewr: Chouser: Not in my experience, but I could be wrong.
10:21 rhickey: ?
10:21 Chouser: it's possible for an old branch to not merge cleanly too, right?
10:21 mtd: rhickey: yes
10:22 drewr: Chouser: Yeah; if there are conflicts, there are conflicts.
10:22 mtd: rhickey: this recent post expands a bit on some rules you may want to consider http://
10:22 rhickey: it's a bit more "meta" than the "man git-workflows" that was mentioned before
10:23 rhickey: mtd: read that already, thanks
10:23 Chouser: right, so either way I assume rhickey will require "clean" merges, it's just a matter of how likely it is that a patch submitter will have to re-apply/re-submit. To avoid that kind of work, I'd prefer git branches to patches.
10:24 dunno about rhickey's end -- patches may be easier to apply than a git branch from a random remote repo?
10:24 rhickey: Chouser: patches will definitely sit around - else they constitute constant distractions. If when someone gets around to them they no longer work, asking for resubmits will be a pain
10:25 drewr: You would have this issue with any VCS. If I submit a patch today for lazy-cons, you all would tell me it's irrelevant. The submitter has to keep up.
10:25 Chousuke: a git branch for a random remote repo shouldn't be more difficult than git pull git://repo/url branch_name
10:25 mtd: Chouser: possibly easier to actually apply, but might be harder to manage overall. IIUC Linus usually pulls from known "lieutenant"s' repos.
10:25 (to cite a known example)
10:25 rhickey: one problem is with serial patches - 5 people based their work on the same base but not on each other's, so once one is applied the next breaks
10:26 mtd: rhickey: that's a good problem to have :)
10:26 Chouser: mtd: ok, but this would be similar -- rhickey will only pull from github repos of people who have submitted CAs.
10:26 rhickey: drewr: my understanding was that git history was substantially smarter than patches
10:26 drewr: Yeah, but not that smart.
10:26 mtd: rhickey: yes, that's correct modulo your serial patches issue
10:26 drewr: how so?
10:27 Chouser: nod
10:27 drewr: mtd: How so what? Sometimes git just can't figure out what you mean, regardless of the history.
10:28 rhickey: drewr: I guess it could be smarter if *not* the same basis
10:28 mtd: drewr: if you and I clone rhickey's branch x, work on it, and then tell rhickey "git pull my-repo for-rhickey" then it should figure it out even if we have a sensible common ancestor.
10:28 drewr: I guess I'm saying it can work, and you're saying it can break, and we're both right.
10:29 drewr: mtd: Yep. :-)
10:29 mtd: drewr: In order to make it work, I think it's mostly the contributor's task to keep a branch that'll pull clean
10:29 rhickey: patches are nice in that they can sit in the issues system or email list, examined directly, applied arbitrarily
10:29 mtd: rhickey: for small patches that should work I guess. Agree the transparency is nice
10:30 Chouser: it's easier to keep a local branch clean against head (via rebase) than anything else I've ever tried to do. ...which is why I would do that even if what was submitted was a patch.
10:30 mtd: Chouser++
10:30 rhickey: Chouser: agreed, that should still be the source of a patch, as is just good git practice
10:31 Chousuke: what is a shame though is that git doesn't seem to know how to make a commit from a git-format patch ;/
10:31 or hmm
10:32 oh cool
10:32 rhickey: git am/
10:32 Chousuke: git am works even for single patches
10:32 never mind :)
10:32 I didn't think the patch was already in mbox format
10:33 pjb3: rhickey: Here's the Rails workflow for patches with git: https://
10:33 Chouser: for what it's worth, I think clojure has patches from no more than 23 people
10:34 and only 7 have more than 2 patches
10:34 rhickey: Chouser: hasn't the lack of git been holding everyone back? :)
10:35 pjb3: nice, thanks
10:35 Chouser: naw, what's been holding everyone back is that you send in a patch and it just sits there for weeks because *somebody* think's they're just a distraction.
10:36 gnuvince: I can't talk for others, but my biggest hurdle to contributing to Clojure itself is my lack of solid Java knowledge (and also all important things related to algorithms, data structures, compiler technology, etc.)
10:36 Chouser: rhickey: j/k!
10:36 rhickey: Chouser: it's a fair point, balancing between being responsive and getting interrupted
10:37 Chousuke: at least with git you have the network graph which is pretty good for seeing what people are working on.
10:37 rhickey: I didn't say they were 'just' distractions, just that if they have to be dealt with as they come in, they will constantly interrupt
10:39 Chouser: Not very fair. I suppose you might lose some input for that reason, but it probably wasn't particularly deep input anyway. If someone has invested significant effort in creating a change of real value (and printed, signed, stamped, and mailed a CA), a little more effort and/or patience to get it into the project is unlikely to turn anyone off.
10:40 Chousuke: with SVN most development was kind of behind the scenes, so it was hard to tell what was being worked on.
10:40 Chouser: that's probably less true of contrib, where someone with much less deep knowledge of clojure can probably produce something interesting and useful without a ton of effort.
10:42 rhickey: Chouser: well, there was significant clamoring for git, and again repeated when I was in SF, at the Bay Area Clojure users group - it does make it easier to work on speculative changes while the core code is moving too. I hope we get more participation, else why change?
10:43 gnuvince: To shut the git squad up so we can discuss more important topics? ;)
10:46 rhickey: gnuvince: I've taken the feedback seriously. Certainly we could use more hands with bugfixes
10:48 Chousuke: I'm going to fix require's documentation :P
10:48 it still refers to the old /x/y/z/z.clj naming scheme
10:49 rhickey: so, the sense I'm getting from this discussion and the reading I'm doing in parallel is that patches are better for bugfix submissions. That history is essentially dictated by master and serial
10:50 we should use github pull/push stuff for feature work by those project collaborators
10:50 i.e. contrib authors
10:52 will 'git format-patch master --stdout > your-patch-file.diff' work for multi-commit changes?
10:53 drewr: git format-patch --stdout master..topic > ...
10:53 rhickey: drewr: I think that command presumed you were sitting in your topic branch
10:54 from pjb3's link earlier
10:54 drewr: Ah, OK.
10:55 rhickey: we don't need all this email stuff from format-patch, will it get in the way?
10:56 drewr: No, patch and git ignore it.
10:56 pjb3: rhickey: Yes, multiple commit patches work, here's an example
10:57 I've never actually done that, but I think those are separate commits, I could be wrong though
10:57 rhickey: pjb3: and git am will restore as multiple commits?
10:57 drewr: Yes to both.
10:57 rhickey: cool
10:57 Chouser: those are separate files, but I'm not seeing evidence in that link of multiple commits.
10:57 pjb3: rhickey: also the email stuff is how git give credit to the original person
10:58 drewr: I thought the point of format-patch is that it recreates git commits. Otherwise you'd just do git diff master.. > foo.patch.
10:59 Chousuke: drewr: right. it does. I just didn't know that you had to use "git am" with them :)
10:59 drewr: I thought git am was only for patches sent to your mailbox :P
10:59 drewr: k
11:00 rhickey: pjb3: yes, that's a great feature. Just doule checking the use of --stdout into a single file, the things I'd seen had you using format-patch to produce multiple files, then zipping them up, then unzipping into a dir and pointing git am at that - r.g. a lot more work
11:02 mtd: rhickey: for lots of patches the recommendation would probably be to just ask you to pull from a branch. Credit is then also given.
11:07 rhickey: mtd: I'm trying to get a single recipe together if possible, that will make it easiest for the maintainers, provide a single point for history etc
11:12 at least for bugfixes. for features, that will have a history of their own, pulls are definitely better. I don't want the only benefits of using git to be local checkins and rebase :)
11:12 Chousuke: rhickey: want to try applying this patch with git am and just see what happens? http://
11:13 rhickey: Chousuke: get in line (as soon as we determine where the line is) :)
11:14 Chousuke: that first from line there is a bit weird though
11:14 From b207aeb6253371b5fa7ba13765d683bf46300f76 Mon Sep 17 00:00:00 2001
11:19 rhickey: locks are not STM - can you tell in how many ways this fails to do what the Clojure ants demo does? http://
11:21 cemerick: gah, I need to be more careful about looking at google group URLs so I don't inadvertently land in c.l.l. :-/
11:21 * Chouser makes a good faith effort to read lisp...
11:22 cemerick: whoo-hoo, multiple-value-bind! :-P
11:23 Chouser: worse yet, setf
11:25 Chousuke: I can't test the CL ant demo. no LispWorks :/
11:26 leafw: "it should also be more efficient" -- if that was the motivation, he missed entirely what the ants demo was about: general purpose, lock-free programming.
11:26 Chouser: actually, that counts as a way, doesn't it? 'turn' in clojure uses dosync so I know it's safe (for some value of safe). The CL version just does a setf, so I have to confirm that everywhere it's called is sufficiently protected.
11:26 Chousuke: does it scale up to 700 processors? :p
11:27 replaca: rhickey: I saw your message on assembla. I think if you liked the naming idea, we could probably get github to waive the TOS in this case.
11:28 rhickey: replaca: it still needs to be clear that people are actually submitting to me, as it is with me they have a CA. Could be conveyed clearly though. Do you know github people?
11:30 replaca: rhickey: the project home lets you put a readme, so you could put the terms there. I think that would cover it. Or in the project description.
11:30 rhickey: the ants demo was designed to demonstrate 2 things that are very hard without STM - atomic work involving ad hoc subsets, and reporting on consistent views. It is not simply multithreaded ants running around
11:31 replaca: rhickey: I don't know them personally, but they seem pretty accessible. If you want, I could go chase it out.
11:31 cemerick: rhickey: well, I'm sure PC will acquiesce if you just explain it to him ;-)
11:32 rhickey: cemerick: yes, another day wasted
11:35 replaca: rhickey: yeah, it would have to be your preferred solution, of course
11:36 Chousuke: which message are you talking about, anyway? :)
11:37 rhickey: Chousuke: https://
11:40 Chousuke: rhickey: thanks
11:41 Chouser: that rails workflow looks pretty sane
11:47 rhickey: Chouser: yeah, as long as multiple commits are retained independently
11:51 Chouser: what's the benefit of multiple commits in a single patch?
11:52 Chousuke: perhaps easier to apply than multiple patches
11:53 and you still get many small commits instead of a single big one
11:53 which makes bisecting and reverting changes easier
11:53 opqdonut: indeed
11:54 rhickey: Chouser: if your work involved multiple steps, they are still visible, independently commented.
11:54 Chouser: I just tested it -- git format-patch produces a file that can contain multiple commits, and git am recreates them correctly.
11:55 rhickey: I guess the advantage of multiple files in a zip is that they could be independently applied
11:55 Chouser: thanks for checking that
11:55 clojurebot: Who??
11:56 Chousuke: the hashes seem to differ from the original commits though :/
11:56 I wonder if that's just me.
11:57 Chouser: hm, the commit id is different for me too
11:57 Chousuke: hmm
11:58 but it doesn't confuse rebase
11:58 Chouser: no, and the "index ..." is the same
11:59 rhickey: as Linus says here: http://
12:00 Notice that this really is about other peoples _history_, not about
12:00 other peoples _code_. If they sent stuff to you as an emailed patch,
12:00 and you applied it with "git am -s", then it's their code, but it's
12:00 _your_ history.
12:15 doug_: Getting to grips with agents. Am I right in thinking that agents themselves do not provide parallel processing? Do I need to resort to java.lang.Thread to spawn new threads?
12:16 dnolen_: agents do spawn threads
12:16 hiredman: agents are backed by a threadpool
12:16 send runs the agent action on a fixed size threadpool and send-off on a, uh, unfixed? size threadpool
12:17 leafw: doug_: since all clojure functions are Runnable and Callable, it's easy to hand them over to your own thread pool created via java.util.concurrent.Executors static methods.
12:17 doug_: So if I loop over a seq and send a function to a given agent for each item in the seq they will run in parallel (up to the limit of the threadpool)?
12:18 Chousuke: as long as it's not the same agent.
12:19 doug_: Chousuke: so I need to create one agent for each send and then collate the results myself?
12:19 hiredman: doug_: you might use pmap instead
12:19 pmap and some kind of reduce
12:20 ,(doc pmap)
12:20 clojurebot: "([f coll] [f coll & colls]); Like map, except f is applied in parallel. Semi-lazy in that the parallel computation stays ahead of the consumption, but doesn't realize the entire result unless required. Only useful for computationally intensive functions where the time of f dominates the coordination overhead."
12:20 doug_: hiredman, clojurebot: pmap looks interesting. I will investigate, thanks
12:23 wow. pmap knocked 40% off my elapsed time - best result from adding one character to my code ever, i'd say :-)
12:24 hiredman: :)
12:25 duck1123: doug_: keep in mind that last line in the doc. unless f does quite a bit, sometimes pmap is slower
12:28 doug_: duck1123: thanks. in this case f is scanning a lot of files from a directory, so getting good results. lets me parallelize the scanning of lots of dirs. Of course, too many and I'll hit i/o limitations, but the doc indicates that it's not running everything at the same time.
12:30 leafw: doug_: last I checked, pmap uses (+ 2 (.availableProcessors (Runtime/getRuntime)) threads.
12:31 duck1123: In my C++ class we were talking about some algorithm and I joked "just make it parallel". When someone responded that that was quite a bit of work, my response was "in Clojure it's one letter"
12:33 hiredman: ~def future
12:37 leafw: duck1123: via JNA, you should be able to get that C++ program to operate via batch mode using pmap in clojure, if the task can be broken down like that.
12:37 duck1123: if I need to refer to a global var that's in the same namespace as my macro, what combinatin of characters do I need to use?
12:38 leafw: I can't even remember what the algorithm was anymore, it's just one more example of how functional programming and Clojure has infected my thinking
12:38 cemerick: yeah, pmap is pretty fantastic.
12:38 hiredman: using jna to "optimize" is a bad idea
12:39 jna overhead will dominate
12:39 arohner: duck1123: ~ns/var I believe
12:40 leafw: hiredman: I find JNA nice to interface stuff like the fftw library.
12:41 hiredman: sure, it is nice for getting at native libs
12:42 but it is not something you can do a lot of and expect good performance
12:42 doug_: future looks interesting. I see pmap is implementing using future. would be useful if it allowed setting of the number of threads.
12:42 hiredman: http://
12:43 of course jna is faster then jni, but still
12:44 reverse that
12:44 anyway, calling native code is slow
13:26 jackdempsey: heh
13:26 fwiw putting it up at github will definitely entice me to look into things more :-)
13:26 imagine its the same for others.....also, having such a great library of videos/presentations is excellect rhickey
13:27 that and you crack me up....while intriguing me.....anyway, great stuff
13:39 duck1123: jackdempsey: clojure has been on github forever. (just not in an official capacity)
13:39 jackdempsey: ahh, cool
13:39 duck1123: there was an old git-svn version put out by kevinoneill
14:44 cgrand: Chouser: re: "two names on one branch" I don't understand, the branches are distinct: http://
15:08 rhickey: so do we just copy: https://
15:09 Chousuke: sounds good to me
15:10 technomancy: the main difference is that Rails keeps its tests in the same repo, so it makes it much easier for contributors.
15:11 cemerick: I totally missed the patch/merge conversation this morning. It seems like a bummer that pull requests can't be the standard workflow.
15:11 rhickey: cemerick: the discussion is still open - what are your thoughts?
15:13 * technomancy lost the tests for his symbol validation patch because of the two-repo problem. =(
15:13 rhickey: lost?
15:13 cemerick: well, I know absolutely nothing about managing a distributed, open source project, but it seems like git provides a great mechanism for ensuring that changes can be propagated and reliably merged from multiple parties (modulo straight-up conflicts). Further, github appears to make tracking who has what patches based off of what tree trivial.
15:14 technomancy: rhickey: I deleted my contrib repo and made a fresh copy a few weeks ago for some reason, and I didn't have my tests pushed out anywhere.
15:14 cemerick: Going to text patch files seems like a missed opportunity (not to mention icky in and of themselves -- reminds me of some bad old days gone by or something).
15:14 technomancy: of course I should keep closer track of things like that, but it would be much better if I didn't have to.
15:15 rhickey: cemerick: I'm still envisioning using pulls and proper github branches for features, patches for fixes
15:15 cemerick: ah-ha
15:15 stuartsierra: With git, is there any practical difference between features and bug fixes?
15:15 Chousuke: cemerick: fortunately git has a special patch format and is capable of tracking at least authorship :)
15:16 cemerick: why not use it for both?
15:17 Chousuke: apparently managing pull requests with github is a bit of a chore :/
15:17 they would not be as convenient to review either.
15:17 rhickey: the history for fixes will be determined by their incorporation, less to trust in a patch, patches can be applied ad hoc to any rev, less work than creating a server branch for a small change, branches aren't points in time
15:18 technomancy: Chousuke: sure, but sending a "please merge from this URL" rather than a literal patch still works fine
15:18 rhickey: pull requests go nowhere useful
15:19 technomancy: so basically use a patch if it makes sense as a single diff, but use a merge if the history is relevant/worth preserving?
15:19 that seems reasonable.
15:19 cemerick: I've never been on the receiving end of a pull request, so that's why I didn't grok the rationale.
15:19 Chousuke: I hope git will also encourage more fine-grained feature work.
15:19 cemerick: surely github is aware of whatever issues prevent pull requests from being generally useful?
15:19 Chousuke: SVN commits tend to be huge blobs of often unrelated changes :/
15:21 rhickey: technomancy: not really either or - the format-patch patches can retain multiple commits, the bigger differentiator will be - will this thing have a lifetime of its own, most features will have a short one at least
15:21 cemerick: when on the sending end of a pull request, do you create a named branch on the server? a tag?
15:21 technomancy: oh, I see.
15:23 cemerick: rhickey: I've either referred to a sha or created a tag for the maintainer to pull from, and mentioned it in the message.
15:24 But I can see that it would be tremendously useful for that kind of thing to be standardized.
15:24 dysinger: rhickey / technomancy - I use pull requests - the key is for the contributor to keep a branch for the feature and keep that branch rebased on the upstream master.
15:24 then you can evaluate and pull in with no hassle
15:24 even with the github UI
15:25 If I am contributing and I do this - then it's zero work for the upstream maintainer to pull my feature
15:25 and I as a contributor don't generate patch files that get stale over time
15:26 cemerick: hrm, also, if patches are being applied, those obviously won't decorate the network graph. Minor issue for minor patches, but the line can get blurry between "features" and "bug fixes".
15:26 Chousuke: the problem is that you shouldn't really publish branches that you're going to be rebasing all the time.
15:26 dysinger: it's only a problem if multiple people have that branch or not
15:27 cemerick: Chousuke: if they only reason you're publishing them is for consumption by the maintainer, than that's OK...
15:27 dysinger: yeah you wouldn't want to rebase public branches for ongoing public work
15:27 cemerick: s/they/the
15:27 Chousuke: so if you're going to work on a bigger feature, you shouldn't be rebasing it against master all the time.
15:28 dysinger: but it does make it the best most convenient no-work way for a maintainer to pull
15:28 Chousuke: at least if you have other people working with you
15:28 dysinger: true
15:28 I am just relating how we work with git on multi-projects
15:29 Chousuke: what you need to do is, when your feature branch is ready to be pulled, pre-merge it with master locally and push your merge on the public branch; then it can be easily pulled in by mainline.
15:29 dysinger: that works
15:29 but it's easier to see the differences in two branches if there was a rebase of the forked branch at the end - I am just saying it's easier on the upstream guy.
15:30 doesn't have to be done that way though
15:30 as long as the merge goes clean
15:30 anyway regardless format-patch is not the best way to share patches is what I was trying to get across
15:31 no authorship information is kept either with patches.
15:31 Chousuke: dysinger: actually, yes it is.
15:32 "git am" accepts git format-patch output and creates commits from them with full authorship info retained.
15:32 dysinger: Interesting
15:32 I have only used the files with git apply
15:32 cemerick: FWIW, I'm happy to do whatever rhickey prefers, but in general, it seems like not taking advantage of what github offers is less than ideal. Beyond that, I'm happier to let more experienced hands debate the specifics.
15:32 Chousuke: this is not stated explicitly in the manual, which is why I had no idea it does that :)
15:32 dysinger: cemerick ditto from me
15:33 Chousuke: but apparently, git format-patch produces mbox-format files, which git am accepts
15:33 dysinger: git had my head spinning when I first used it
15:33 cemerick: dysinger: heh, well, you're one of the more experienced hands, so keep at it :-)
15:34 stuartsierra: git is one of those "magic" commands that you never really understand, you just learn enough "incantations" to do what you need.
15:34 dysinger: now I couldn't live without git (svn,cvs,etcetcetc nothanks)
15:34 yeah and it just keeps going
15:34 2 years on and I am just now playing around with git bisect
15:35 Chousuke: stuartsierra: it's fun when you learn how to do something really cool with it though.
15:35 dysinger: It's amazing
15:35 Chousuke: like splitting too big commits into smaller parts
15:35 stuartsierra: yes, agreed
15:35 dysinger: y or re-writing history with an automated filter
15:35 or interactive rebase
15:35 or ..... page down * 7
15:36 Chousuke: or looking at the very first commits of a project from 25 years ago :P
15:36 The commit messages are often not very useful :/
15:37 Chouser: "initial commit"
15:37 Chousuke: or "entered into RCS"
15:37 Chouser: "replaced <obsolete subsystem> with <another obsolete subsystem>"
15:38 cgrand: Your two independant branches appear on the same line on the github "network" page, which is what confused me.
15:51 cgrand: Chouser: I wasn't clear: what I don't understand is not your confusion but why github display them on the same line
15:52 Chouser: ah. Yeah, I don't know either. I suppose you could add a subsequent revision on the first branch and see what happens.
15:52 just for fun.
15:53 I'd guess it would split the branches onto two lines then.
15:54 rhickey: fwiw, I think starting with a clojurized version of the ruby workflow is a great low-investment way to get started. Once it's rolling, if you find there's anything you don't like about it perhaps everyone will have had enough experience to craft something more custom.
17:24 mrsolo: type hint speeds up is substaintal is it a good habit to use it always when dealing witih java interop?
17:25 opqdonut: yeah
17:25 technomancy: mrsolo: no... only if you have identified a bottleneck
17:25 opqdonut: i somehow like the explicitness
17:25 of course it might worsen error messages
17:26 mrsolo: oh?
17:26 technomancy: I guess it could be helpful for documentation purposes.
17:26 mrsolo: it really doesn't take much to add it to argument list
17:26 technomancy: If you're feeling the need to say "this takes a Foo" then you might as well put it in the code rather than the docstrings.
17:26 mrsolo: may be a bit cluttered
17:26 technomancy: mrsolo: the question is if it will change
17:27 Chouser: If there were a clojure style guide, it would recommend avoiding type hints unless the performance boost is demostrated as useful in a particular case.
17:27 technomancy: if it has to be that class because of the underlying library, then go ahead
17:27 but if it would be possible/likely for you to swap it out with another type, then don't declare the type unless you need to
17:28 mrsolo: right
17:28 Chouser: type hints do not necessarily do type checking -- you should definitely not assume that you'll get a compile or runtime error just because an actual type doesn't match a hint.
17:29 mrsolo: of course
17:29 clojurebot: Ok.
17:30 Chouser: Clojure's also likely to get something like auto-hinting in the future, where each method call you use is checked at compile time (even if not using AOT) against all imported classes -- if only a few matches are found, those cases will get fast-path runtime code.
17:30 one of the reasons there isn't an import *, I believe.
17:31 opqdonut: ah, nice
17:31 mrsolo: nice
19:21 i like the fact that file-seq is lazy...it rocks :-)
19:27 qrush: hey folks
19:27 any news on the github front?
19:27 still nothing 'official'
19:27 technomancy: first merge commits have been applied! =)
19:27 qrush: oh snap
19:28 technomancy: qrush: contrib hasn't been moved over yet, but I think that's just waiting on getting the proper svn author import data
19:28 qrush: cool
20:38 Chouser: qrush: nice
20:39 durka42: is svn deprecated now?
20:41 jackdempsey: hm
20:41 "a website that can handle over 5000 requests per minute."
20:41 that kinda surprised me
20:41 i was expecting "per second" :-)
20:42 qrush: well the scala article says that value
20:42 I think in any case it's still impressive.
20:42 jackdempsey: (/ 5000 60.0)
20:42 hehe damn, need to learn how to use the bot :-)
20:42 durka42: ,(/ 5000 60.0)
20:42 jackdempsey: yea saw the article
20:42 clojurebot: 83.33333333333333
20:42 quidnunc: ,(/ 5000 60.0)
20:42 clojurebot: 83.33333333333333
20:42 jackdempsey: ah, comma
20:42 qrush: oh that's cool.
20:42 jackdempsey: ,(println "/me dum")
20:42 clojurebot: /me dum
20:42 hiredman: qrush: and hosted on github
20:43 jackdempsey: cool
20:43 hiredman: well, the code is
20:43 qrush: is that sandboxed?
20:43 hiredman: yeah
20:44 qrush: you clojure folks are nuts
20:45 jackdempsey: hehehe
20:45 hiredman: ,(import '(java.io BufferedReader))
20:45 clojurebot: java.io.BufferedReader
20:45 hiredman: ,(import '(java.io BufferedReader File FileReader))
20:45 clojurebot: java.io.FileReader
20:46 hiredman: ,(-> "/etc/password" File. FileReader. BufferedReader. line-seq)
20:46 clojurebot: java.security.AccessControlException: access denied (java.io.FilePermission /etc/password read)
20:46 jackdempsey: whats that -> method? hard to google for it :-)
20:47 hiredman: ,(doc ->)
20:47 clojurebot: "([x form] [x form & more]); Threads the expr through the forms. Inserts x as the second item in the first form, making a list of it if it is not a list already. If there are more forms, inserts the first form as the second item in second form, etc."
20:47 hiredman: ,(macroexpand '(-> "/etc/password" File. FileReader. BufferedReader. line-seq))
20:47 clojurebot: (line-seq (clojure.core/-> (clojure.core/-> (clojure.core/-> "/etc/password" File.) FileReader.) BufferedReader.))
20:47 jackdempsey: ahh
20:48 hiredman: it's pretty cool
20:48 ,(require '[clojure.zip :as zip])
20:48 clojurebot: nil
20:48 jackdempsey: feels almost like currying, though i hesitate to say it as i barely understand that topic :-)
20:49 so much to learn, so little time
20:50 hiredman: ,(-> '(a b (c d e) f g) zip/seq-zip zip/next zip/next zip/next (zip/replace z) zip/root)
20:50 clojurebot: java.lang.Exception: Unable to resolve symbol: z in this context
20:50 hiredman: ,(-> '(a b (c d e) f g) zip/seq-zip zip/next zip/next zip/next (zip/replace 'z) zip/root)
20:50 clojurebot: (a b z f g)
20:50 hiredman: ,(-> '(a b (c d e) f g) zip/seq-zip zip/next zip/next zip/next zip/next (zip/replace 'z) zip/root)
20:50 clojurebot: (a b (z d e) f g)
20:51 jackdempsey: heh, almost get that :-)
20:52 why does the first replace (c d e) with z but the latter only replaces the c
20:52 i see the zip/next number of calls is different
20:53 hiredman: ,(-> '(a b (c d e) f g) zip/seq-zip zip/next zip/node)
20:53 clojurebot: a
20:53 hiredman: ,(-> '(a b (c d e) f g) zip/seq-zip zip/next zip/next zip/node)
20:53 clojurebot: b
20:53 hiredman: ,(doc zip/next)
20:53 clojurebot: "([loc]); Moves to the next loc in the hierarchy, depth-first. When reaching the end, returns a distinguished loc detectable via end?. If already at the end, stays there."
20:54 jackdempsey: ,(-> '(a b (c d e) f g) zip/seq-zip zip/next zip/next zip/next zip/next zip/next zip/node)
20:54 clojurebot: d
20:55 jackdempsey: ,(-> '(a b (c d e) f g) zip/seq-zip zip/next zip/next zip/next zip/next zip/next zip/next zip/next zip/node)
20:55 clojurebot: f
20:55 jackdempsey: hmm
20:55 ,(-> '(a b (c d e) f g) zip/seq-zip zip/next zip/next zip/next zip/next zip/next zip/next zip/node)
20:55 clojurebot: e
20:55 jackdempsey: yea so that makes sense, the way the z replaced (c d e) it almost seems like it'd say c, d, e, (c d e) or something
20:57 hiredman: well zip/next returns (c d e), and the next zip/next returns c then d then e
20:58 jackdempsey: ahh
20:59 so if you call the replace at the right point thats how you can get z in there
20:59 hiredman: yes
21:01 ,(pl (↕map range $ 10 inc · inc · inc))
21:01 clojurebot: (3 4 5 6 7 8 9 10 11 12)
21:01 Chousuke: :P
21:13 Chouser: so github pull requests are just wrong (for us). They are a poorly-managed beginning to a private conversation about a what may become a commit to the main repo.
21:14 poorly-managed as in low visiblity, can't reply via email, etc.
21:14 and such a conversation should be public, searchable, etc.
21:16 where there is no argument vector
21:16 hiredman: yeah, there two
21:17 it is a multifn
21:17 jtal: "same as defn, yielding non-public def"
21:17 hiredman: (defn foo ([arg1] stuff) ([arg1 arg2] stuff2))
21:17 jtal: that is defn-
21:17 jtal: ah
21:18 hiredman: the form you showed is (defn -main …
21:18 not the same thing as defn-
21:18 jtal: does the "-" mean something?
21:19 hiredman: when you use gen-class it backs methods with functions identified with a prefix, "-" is the default prefix
21:21 jtal: it backs?
21:21 jackdempsey: Chouser: for small changes a patch probably makes sense...for a large change, a forked repo with specific branch and email to the list?
21:22 hiredman: jtal: gen-class generates a stubbed out java class
21:22 jtal: and uses all methods prefiex with "-" ?
21:23 hiredman: the methods in that class dispatches to clojure Fns
21:23 Chouser: jackdempsey: I think that's right. I also think that's essentially what the rails workflow is, which is I believe our current leading contender.
21:23 hiredman: jtal: I would read the gen-class and compiling docs on clojure.org
21:23 jtal: ok
21:23 just trying out enclojure
21:23 jackdempsey: yeah last i looked at their process it involved +1's on tickets as well
21:23 jtal: maybe they expect me to ignore this magic for the moment
21:24 hiredman: feel free to, none of that is really need except something like (ns com.yourcompany.defpackage
21:49 ataggart: can anyone point me to an example of using ns with :use, a prefix list also using :as
21:50 hiredman: I don't know that :use supports :as
21:51 :require does
21:51 ,(require '[clojure.zip :as zip])
21:51 clojurebot: nil
21:51 hiredman: ,zip/seq-zip
21:51 clojurebot: #<zip$seq_zip__6709 clojure.zip$seq_zip__6709@1d7141e>
21:52 ataggart: ya it just occurred to me that since :as creates an alias for the other namespace, and use allows one to not type the namespace, it's probably a moot point
21:53 though I do keep getting turned around about when to use '(...) vs [...]
21:54 hiredman: yeah
21:54 the answer is: use require and  all the time
21:56 Chouser: or :use and :only 
21:56 hiredman: …
23:36 jtal: any enclojure users? Trying to figure out how to get javax.swing stuff
23:36 it seems adding "Swing Application Framework" to libraries is not right
23:48 mrsolo: hmm what mit dumped scheme for cs undergrad program? ....
23:53 zakwilson: mrsolo: a year or two ago. They went to a program involving robotics and things that don't work neatly and cleanly in the real world. Python evidently had whatever was needed to talk to the robots.