2009-06-15
| 01:02 | Anniepoo | In a proxy what's the name of the constructor, since the class is anonymous? |
| 01:03 | hiredman | you cannot make a constructor |
| 01:04 | Anniepoo | hmm... I'm trying to overrride the constructor of JLabel to muck with it on setup |
| 01:05 | hiredman | you cannot |
| 01:05 | Anniepoo | ooochie... ok. |
| 01:05 | hiredman | you can muck withit first, then pass it to jlabel |
| 01:05 | Anniepoo | yes, that's what I meant |
| 01:08 | replaca | ~proxy |
| 01:08 | clojurebot | proxy is <Chouser> proxy teases with its ease of use, then suddenly betrays. |
| 01: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. |
| 01:08 | Anniepoo | hmm |
| 01:10 | hiredman | (defn special-jlabel [x] (JLabel. (str "XXX" x))) |
| 01:11 | hiredman | very simple |
| 01:17 | twopoint718 | I have a quick question about def. |
| 01:17 | twopoint718 | Are the vars that def creates public in that namespace? |
| 01:24 | hiredman | yes |
| 01:24 | hiredman | they are public in any namespace |
| 01:24 | hiredman | if you (def a 1) in the foo namespace |
| 01:25 | hiredman | if the foo namespace is loaded, in the user namespace foo/a will give you 1 |
| 01:26 | hiredman | you can assoc :private with true in the metadata to make a private def |
| 01:26 | hiredman | there is also defn- for private defns |
| 01:28 | twopoint718 | Okay so if I have a var in namespace foo, what do I use to refer to it from another namespace? |
| 01:29 | hiredman | depends |
| 01:29 | hiredman | how are you loading the foo namespace? |
| 01:30 | hiredman | short answer is the namespace qualified symbol |
| 01:30 | hiredman | foo/whatever |
| 01:31 | twopoint718 | I was using ":require" inside the ns form |
| 01:31 | hiredman | yeah |
| 01:31 | hiredman | so foo/whatever |
| 01:32 | hiredman | ,(resolve '+) |
| 01:32 | clojurebot | #'clojure.core/+ |
| 01:33 | twopoint718 | Okay, I think I know what I'm doing. I think I'd created a circular dependency |
| 01:34 | twopoint718 | ns A requires ns B, then B wants to refer back to something in A that hasn't been loaded yet, is that plausible? |
| 01:35 | hiredman | that is a circular dependency |
| 01:37 | twopoint718 | shoot |
| 01:43 | twopoint718 | I think I'll just pass two more parameters |
| 01:43 | twopoint718 | hiredman: thanks for the help, I think I've got it sorted out now. |
| 01:49 | Anniepoo | hiredman, thanks for helping out us noobies |
| 01:49 | hiredman | ~hiredman |
| 01:49 | clojurebot | hiredmans euler.clj is so embarassing |
| 01:58 | hiredman | ~sandboxing |
| 01:58 | clojurebot | Titim gan éirí ort. |
| 01:58 | hiredman | bah |
| 01:58 | hiredman | ~sandbox |
| 01:58 | clojurebot | sandbox is http://calumleslie.blogspot.com/2008/06/simple-jvm-sandboxing.html |
| 03:57 | sgtarr | clojure rules |
| 03:57 | sgtarr | but I have trouble finding a development environment which is not Emacs :/ |
| 03:57 | sgtarr | The Eclipse plugin lacks in features, the vimClojure crashes on me (author knows about this so it might be fixed soon) |
| 03:58 | eevar2 | did you try the netbeans plugin? |
| 03: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 |
| 04:01 | hoeck | sgtarr: but what I'like about the netbeans plugin is its easy setup and the way you mange your project and your dependencies |
| 04:09 | sgtarr | hoeck: netbeans tends to be rather sluggish and ugly in Linux |
| 04:09 | sgtarr | but.. seeing that I have few choices here, I'll give it another try |
| 04:09 | sgtarr | hi kotarak :) |
| 04:10 | kotarak | hi sgtarr |
| 04:10 | sgtarr | kotarak: do you mainly use vimclojure when developing clojure programs, or do you also use emacs/netbeans/eclipse/.. ? |
| 04:11 | kotarak | only VC |
| 04:22 | sgtarr | ok |
| 04:22 | clojurebot | book is http://www.pragprog.com/titles/shcloj/programming-clojure |
| 04:22 | sgtarr | ok |
| 04:22 | sgtarr | weird, why did clojurebot say where the book is? :) |
| 04:29 | sgtarr | it seems Clojure is taking off... more and more people getting interested |
| 04:29 | sgtarr | Just imagine if Lisp really got a "mainstream" comeback |
| 04:29 | sgtarr | And Lisp was never really Mainstream. |
| 04:30 | sgtarr | I'm reading "Programming Clojure" here at work instead of actually doing work. heh |
| 04:30 | Carkh | the secret weapon going mainstream ='( |
| 04:42 | sgtarr | Don't worry, it won't get *that* mainstream |
| 04:54 | sgtarr | Carkh: what do you use Clojure for specifically? |
| 04:54 | Carkh | server stuff |
| 04:54 | mxc | wasn't lisp mainstream in the 50s when it was that, fortran, or assembler? |
| 04:54 | Carkh | right now : a web application for telephony provider |
| 04:55 | mxc | clojure does seem interesting, as a current haskeller |
| 04:55 | sgtarr | haskell is just too strictly functional for me |
| 04:55 | sgtarr | clojure opens up flexibility |
| 04:55 | sgtarr | i'm a practical guy |
| 04:56 | mxc | i love my type safety |
| 04:56 | Carkh | haskell is nice, but it's hard to keep in the spirit of it all the way |
| 04:57 | Carkh | there is always a point where it gets too hard to keep fully type safe |
| 04:57 | mxc | would love to be able to use java libraries though |
| 04:57 | sgtarr | what I love about these languages is how elegantly you do concurrent programming |
| 04:57 | mxc | i just think that haskell's learning curve (basically a vertical line) is probably a bit steep |
| 04:57 | sgtarr | and that's one of the motivations for me learning Clojure now |
| 04:57 | sgtarr | mxc: hahaha, a vertical line :) |
| 04:58 | mxc | but once you get over it, its pretty amazing |
| 04:58 | mxc | i've used ocaml, f#, and haskell |
| 04: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 |
| 04:58 | sgtarr | and that has really put me off F# as well, since it's inspired by ML |
| 04:59 | sgtarr | Lisp however, is so elegant, it's the language of the Gods |
| 04:59 | eevar2 | question is whether i should pick up yet another language, or just focus on the toolset I already have ;) |
| 04:59 | mxc | f# is annoying since you have to use so many C# libraries that you lose all the type safey and FP assurances |
| 04:59 | mxc | sgtarr - ostesibly yes, but didn't they just hack most of it together with perl? |
| 05:00 | mxc | http://xkcd.com/224/ |
| 05: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 :) |
| 05:00 | mxc | hehe |
| 05:00 | mxc | have you ever tried patching existence? |
| 05:00 | sgtarr | nope |
| 05:01 | mxc | some theorize that there is version control, commits only last for plank time before the master reverts the commit |
| 05:01 | mxc | planck |
| 05:13 | sgtarr | mxc: haha :) |
| 05:53 | thomaslee | (let [run [1 2 3] runn (count run)] (do (dorun runn run) (do (dorun run)))) |
| 06:01 | jdz | first dorun looks wrong |
| 06:02 | jdz | not |
| 06:03 | thomaslee | it's straight from the interpreter. it runs, but don't expect it to do anything. :P |
| 06:04 | jdz | yes, i just have not used the two-argument version of dorun |
| 06:25 | thomaslee | what's the easiest way to get at the :doc string associated with a clojure function? |
| 06:25 | hoeck | (doc name) |
| 06:25 | clojurebot | "([x]); Returns the name String of a symbol or keyword." |
| 06:26 | thomaslee | I would've thought (meta <function>) would give me what I was looking for, but it seems to yield nil |
| 06:26 | thomaslee | It doesn't just print it out? |
| 06:26 | hoeck | functions have no metadata (yet) |
| 06:26 | hoeck | but vars have |
| 06:26 | hoeck | so (meta #'<function>) is your friend |
| 06:27 | hoeck | or (meta (var <function>)) |
| 06:28 | hoeck | or ^#'name :) |
| 06: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? |
| 06:31 | hoeck | yes, but the metadata is stored in the var object, not in the function |
| 06:32 | hoeck | and evaling <function> returns the content of the var, a function for example |
| 06:33 | thomaslee | hmm, okay. I think I understand. |
| 06:36 | thomaslee | so the names to which things are bound in clojure are objects unto themselves |
| 06:36 | thomaslee | which is why vars have the metadata but functions don't |
| 07:12 | eleftherios | I am getting very bad support from Pragmatic Programmers customer support for the Programming Clojure book |
| 07:13 | eleftherios | I was almost shocked to receive such a lousy response from these guys, I thought they were a friendly bunch |
| 07:13 | rys | I didn't get the best response either |
| 07:13 | eleftherios | they didn't even greet me |
| 07:13 | eleftherios | and they didn't have a name or signature on the email |
| 07:14 | eleftherios | the ebook has an issue, on the Sony PRS-505 at least (which is probably one of the most popular ebook readers) |
| 07:14 | eleftherios | the code is off the right edge so one can't read the code samples |
| 07:14 | eleftherios | what use is a programming book if you can't read the code? |
| 07:14 | eleftherios | and I sent a nice email letting them know about the issue |
| 07:15 | rys | Yeah, it's the same issue on the iPhone with the ePub for me |
| 07: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' |
| 07:15 | eleftherios | and 'read it in landscape' |
| 07:15 | eleftherios | and the guy obviously hasn't even tried because |
| 07:15 | eleftherios | in landscape mode you lose even more of the code |
| 07:15 | eleftherios | !! |
| 07:16 | rys | It doesn't work in landscape either, yeah |
| 07:16 | eleftherios | he is an idiot |
| 07:16 | eleftherios | and I replied in a very friendly way again |
| 07:16 | eleftherios | and said, 'look, how can you maintain the semantic integrity of the code when half of the code is not there?' |
| 07: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 |
| 07:16 | eleftherios | and that 'in landscape mode isn't available either' |
| 07:17 | eleftherios | and guess what? |
| 07:17 | eleftherios | he hasn't replied in 4-5 days |
| 07:17 | eleftherios | so basically, he gives a couple of wrong recommendations in a dry, almost rude email |
| 07:17 | eleftherios | and then they ignore further emails |
| 07:17 | eleftherios | so now I am upset and I want a refund because the eBook is not fit for purpose |
| 07:17 | eleftherios | and they have failed to be polite or helpful |
| 07:18 | eleftherios | and I am a long-time customer, they can see my account |
| 07:18 | eleftherios | unacceptable |
| 07:18 | eleftherios | 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 |
| 07: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? |
| 07:39 | doug_ | That actually gives '(5 4 3 2 1) but I'm not worried about the order. |
| 07:40 | doug_ | I meant (reduce #(into %1 %2) '() '((1 2) (3 4) (5)) of course... |
| 07:40 | jdz | doug_: what you are looking for is usually called "flatten" |
| 07:40 | doug_ | that's how I would have described it, but can't see a flatten function in the API |
| 07:40 | jdz | doug_: if you are sure all the members are lists you can do apply concat |
| 07:42 | doug_ | that works, thanks. Yes, all members are lists. |
| 07:42 | jdz | well, they could as well be other sequences |
| 07:42 | jdz | but they should be seqable |
| 07:42 | doug_ | slightly simpler |
| 07:43 | doug_ | seqs, yes. keep forgetting this isn't lisp :-) |
| 08: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) |
| 08: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 |
| 08:56 | rhickey | also others can't see them, just in the inbox |
| 08:58 | Chouser | the patch that the pull request points to is public |
| 08: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 |
| 08:58 | rhickey | so maybe tags? |
| 08:59 | rhickey | Chouser: yes, the code is public, but not the pull request, so creates a funnel into someone's inbox |
| 08: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? |
| 09:00 | Chouser | the "network" tab on the clojure project is going to get very busy |
| 09:01 | Chouser | looks like cgrand got two names on one branch -- are those tags? |
| 09:02 | Chouser | hm, apparently not -- just two brances in a row. |
| 09:03 | rhickey | on the same line because they haven't diverged? |
| 09:03 | Chouser | That would be my guess |
| 09:03 | rhickey | anyway, yeah, I can imagine this getting very busy and difficult to manage |
| 09:04 | Chousuke | assembla does nothing to help with pull requests? |
| 09: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. |
| 09:04 | rhickey | pull requests are a github thing |
| 09: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. |
| 09:05 | rhickey | patches aren't going to get the best merge logic |
| 09:05 | Chouser | true |
| 09:06 | Chousuke | the network graph is good for seeing what people are working on though. |
| 09:07 | rhickey | if people want git they want branch/merge, no? |
| 09:07 | Chouser | if you want git's merge logic, then we've got to have public branches |
| 09:09 | rhickey | yeah, I haven't gotten a great public branch creation recipe that doesn't seem to have a redundant step |
| 09:10 | Chouser | at least I can push a new branch without having to use the web site. |
| 09:11 | rhickey | this recipe: http://github.com/guides/push-a-branch-to-github doesn't leave your local branch tracking the server? |
| 09: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. |
| 09:14 | rhickey | I got "technomancy wants you to pull from technomancy/clojure at validate-symbols-issue-13" when he used a branch |
| 09:14 | Chouser | right, I meant for better visibility |
| 09:14 | rhickey | the problem is the branch could change |
| 09:15 | Chouser | not after you've merged it |
| 09: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 |
| 09:16 | rhickey | Chouser: true, but branch name doesn't label a point in time - are tags better for this? |
| 09:18 | Chousuke | hmm. |
| 09:19 | dudleyf | Most of the projects I've contributed patches to don't use pull requests |
| 09: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? |
| 09:19 | Chousuke | tags would help with that I suppose. |
| 09:20 | rhickey | or someone else couldn't reproduce - "grab fred's mod and try on your machine" |
| 09:21 | Chousuke | right. |
| 09:22 | rhickey | dudleyf: does that mean they use patches, or just don't use that part of github |
| 09:22 | Chousuke | hm. when applying git-format patches, does it preserve the author information? :/ |
| 09:22 | dudleyf | rhickey: The usual way is to create a patch with git format-patch |
| 09:23 | dudleyf | Chousuke: Yes |
| 09: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 |
| 09:23 | Chousuke | is there another command for applying it as a commit? |
| 09: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 |
| 09:24 | Chousuke | rhickey: git-format patches preserve that info. |
| 09:24 | Chousuke | at least to some extent. |
| 09:25 | Chousuke | still, pull requests would be more convenient :/ |
| 09:26 | Chousuke | maybe probe the github guys and ask them if they could improve tracking pull requests :) |
| 09:33 | AWizzArd | Was git now chosen as the next rcs for Clojure? |
| 09: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€. |
| 09:38 | Chousuke | apparently "git am" preserves author information etc. but it requires patches to be in mbox or Maildir format. |
| 09:38 | Chousuke | that is, it extracts patches from your mailbox. |
| 09:49 | rhickey | AWizzArd: we are working through the details now, but yes, git on github + assembla is the current plan |
| 09:49 | rhickey | does anyone have a project they can point to with good git workflow guidelines online? |
| 09:56 | drewr | One project I work with has been using ideas from http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html. |
| 09:57 | rhickey | drewr: I've been reading that - it doesn't have a policy for format-patch vs pull |
| 09:59 | drewr | The maintainer could accept either. |
| 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 | drewr | 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 | rhickey | 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 | drewr | 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 | drewr | 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:19 | Chouser | right? |
| 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://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html |
| 10:22 | mtd | 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 | Chouser | 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 | mtd | (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 | mtd | drewr: how so? |
| 10:27 | mtd | 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 | mtd | 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 | Chousuke | or hmm |
| 10:32 | Chousuke | oh cool |
| 10:32 | rhickey | git am/ |
| 10:32 | rhickey | ? |
| 10:32 | Chousuke | git am works even for single patches |
| 10:32 | Chousuke | never mind :) |
| 10:32 | Chousuke | 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://rails.lighthouseapp.com/projects/8994/sending-patches |
| 10:33 | Chouser | for what it's worth, I think clojure has patches from no more than 23 people |
| 10:34 | Chouser | and only 7 have more than 2 patches |
| 10:34 | rhickey | Chouser: hasn't the lack of git been holding everyone back? :) |
| 10:35 | rhickey | 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 | clojurebot | git is http://www.github.com |
| 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 | Chousuke | 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 | rhickey | we should use github pull/push stuff for feature work by those project collaborators |
| 10:50 | rhickey | i.e. contrib authors |
| 10:52 | rhickey | 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 | rhickey | 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:56 | pjb3 | https://rails.lighthouseapp.com/attachments/93396/habtm_join_table_with_pk_raises_exception.diff |
| 10:57 | pjb3 | 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 | Chousuke | 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 | rhickey | 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://www.modeemi.fi/~oranenj/require-doc-fix.patch |
| 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 | Chousuke | 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://groups.google.com/group/comp.lang.lisp/msg/c83b38f792219cc0 |
| 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: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 | rhickey | replaca: agreed, just need the TOS exemption. Also, it seems multiple accounts are a hassle: http://github.com/guides/multiple-github-accounts |
| 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://www.assembla.com/flows/show/bOk168wkur3P1LeJe5afGb |
| 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 | Chousuke | and you still get many small commits instead of a single big one |
| 11:53 | Chousuke | 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 | rhickey | Chouser: thanks for checking that |
| 11:55 | clojurebot | Who?? |
| 11:56 | Chousuke | the hashes seem to differ from the original commits though :/ |
| 11:56 | Chousuke | 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 | Chousuke | but it doesn't confuse rebase |
| 11:58 | Chouser | no, and the "index ..." is the same |
| 11:59 | rhickey | as Linus says here: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html |
| 12:00 | rhickey | Notice that this really is about other peoples _history_, not about |
| 12:00 | rhickey | other peoples _code_. If they sent stuff to you as an emailed patch, |
| 12:00 | rhickey | and you applied it with "git am -s", then it's their code, but it's |
| 12:00 | rhickey | _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 | hiredman | 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 | hiredman | pmap and some kind of reduce |
| 12:20 | hiredman | ,(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 | doug_ | 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 | duck1123 | 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 | hiredman | 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 | hiredman | 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://weblogs.java.net/blog/mlam/archive/2006/12/beware_of_the_n.html "The JNI overhead is in the order of something like 20x to 100x." |
| 12:43 | hiredman | of course jna is faster then jni, but still |
| 12:44 | hiredman | wiat |
| 12:44 | hiredman | reverse that |
| 12:44 | hiredman | anyway, calling native code is slow |
| 13:26 | jackdempsey | heh |
| 13:26 | jackdempsey | fwiw putting it up at github will definitely entice me to look into things more :-) |
| 13:26 | jackdempsey | imagine its the same for others.....also, having such a great library of videos/presentations is excellect rhickey |
| 13:27 | jackdempsey | 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://github.com/cgrand/clojure/commits/inline-math-ops and http://github.com/cgrand/clojure/commits/xml-preserve-whitespace |
| 15:08 | rhickey | so do we just copy: https://rails.lighthouseapp.com/projects/8994/sending-patches and modify for Clojure? |
| 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 | 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 | Chousuke | 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 | technomancy | 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 | rhickey | 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 | cemerick | 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 | dysinger | then you can evaluate and pull in with no hassle |
| 15:24 | dysinger | even with the github UI |
| 15:25 | dysinger | If I am contributing and I do this - then it's zero work for the upstream maintainer to pull my feature |
| 15:25 | dysinger | 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 | dysinger | 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 | dysinger | 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 | dysinger | doesn't have to be done that way though |
| 15:30 | dysinger | as long as the merge goes clean |
| 15:30 | dysinger | anyway regardless format-patch is not the best way to share patches is what I was trying to get across |
| 15:31 | dysinger | no authorship information is kept either with patches. |
| 15:31 | Chousuke | dysinger: actually, yes it is. |
| 15:32 | Chousuke | "git am" accepts git format-patch output and creates commits from them with full authorship info retained. |
| 15:32 | dysinger | Interesting |
| 15:32 | dysinger | 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 | dysinger | yeah and it just keeps going |
| 15:34 | dysinger | 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 | dysinger | or interactive rebase |
| 15:35 | dysinger | or ..... page down * 7 |
| 15:36 | Chousuke | or looking at the very first commits of a project from 25 years ago :P |
| 15:36 | Chousuke | 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 | Chouser | cgrand: Your two independant branches appear on the same line on the github "network" page, which is what confused me. |
| 15:38 | Chouser | (initially) |
| 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 | Chouser | just for fun. |
| 15:53 | Chouser | I'd guess it would split the branches onto two lines then. |
| 15:54 | Chouser | 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 | opqdonut | 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 | technomancy | 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 | hiredman | clojurebot: deft is http://gist.github.com/128259 |
| 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 | Chouser | one of the reasons there isn't an import *, I believe. |
| 17:31 | opqdonut | ah, nice |
| 17:31 | mrsolo | nice |
| 19:21 | mrsolo | i like the fact that file-seq is lazy...it rocks :-) |
| 19:27 | qrush | hey folks |
| 19:27 | qrush | any news on the github front? |
| 19:27 | qrush | still nothing 'official' |
| 19:27 | qrush | ? |
| 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:34 | qrush | gave clojure some lovin' http://github.com/blog/444-github-rebase-23 |
| 20:38 | Chouser | qrush: nice |
| 20:39 | durka42 | is svn deprecated now? |
| 20:41 | jackdempsey | hm |
| 20:41 | jackdempsey | "a website that can handle over 5000 requests per minute." |
| 20:41 | jackdempsey | that kinda surprised me |
| 20:41 | jackdempsey | i was expecting "per second" :-) |
| 20:42 | qrush | well the scala article says that value |
| 20:42 | qrush | I think in any case it's still impressive. |
| 20:42 | jackdempsey | (/ 5000 60.0) |
| 20:42 | jackdempsey | 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 | hiredman | ,(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 | jackdempsey | 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 | jackdempsey | why does the first replace (c d e) with z but the latter only replaces the c |
| 20:52 | jackdempsey | 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 | jackdempsey | ,(-> '(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 | jackdempsey | so if you call the replace at the right point thats how you can get z in there |
| 20:59 | hiredman | yes |
| 21:01 | hiredman | ,(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 | Chouser | poorly-managed as in low visiblity, can't reply via email, etc. |
| 21:14 | Chouser | and such a conversation should be public, searchable, etc. |
| 21:16 | jtal | can someone explain this usage of defn? http://kivasti.com/defpackage.html |
| 21:16 | jtal | where there is no argument vector |
| 21:16 | hiredman | yeah, there two |
| 21:17 | hiredman | 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 | hiredman | jtal: that is defn- |
| 21:17 | jtal | ah |
| 21:18 | hiredman | the form you showed is (defn -main … |
| 21:18 | hiredman | 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 | jtal | 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:24 | hiredman | ) |
| 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 | hiredman | :require does |
| 21:51 | hiredman | ,(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 | ataggart | though I do keep getting turned around about when to use '(...) vs [...] |
| 21:54 | hiredman | yeah |
| 21:54 | hiredman | 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 | jtal | 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. |
| 23:55 | mrsolo | http://blog.snowtide.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program |