#clojure log - Apr 06 2010

The Joy of Clojure
Main Clojure site
Google Group
IRC
List of all logged dates

0:18 ztellman: variadic functions in protocols seem to be broken

0:19 I assume there's no reason they shouldn't work?

0:27 trptcolin: is the simplest way to get the truthiness of an expression the following: (not (not expr))

0:27 or is there something clearer?

0:33 _ato: ,(boolean "I want ice cream")

0:33 clojurebot: true

0:33 _ato: trptcolin: ^

0:33 trptcolin: _ato: awesome! thanks

0:41 slyphon: anyone use the mocking lib?

1:36 doseq: ato: thanks, guess I'll definitely get express delivery.

4:07 LauJensen: Morning all

4:20 esj: Morning LauJensen and all !

5:28 licoresse: just looked at Sean Devlins Foil Disclojure, wonder if it was supposed to be a joke

5:29 LauJensen: hehe

5:31 licoresse: He's saying that he'll block all Java Interop and thereby all access to libraries, that everything is now relying on side-effects by returning nil from every symbol. Then he says that Clojure has too much syntax and to solve that, he'll convert it to a curly braces language...

5:32 licoresse: I like my processors warm

5:32 and, would Sean convert it to curly braces, or would Rich do it?

5:33 I get the joke now, thanks

5:33 LauJensen: hehe

5:33 np :)

5:33 licoresse: but it would be nice to have a clojure interop with obj-c

5:34 I have a hard time doing that stuff now

5:34 LauJensen: True - They need to hurry up with the Clojure-In-Clojure compiler

5:35 licoresse: Indeed

5:39 But I have a hard time understanding how exactly this relates to, for instance the obj-c RT, clojure in clojure would still rely on JVM

5:39 LauJensen: No, Clojure in Clojure would rely on a bootstrap, JVM, CLR, ASM, Dalvik, Javascript, whatever

5:40 _ato: >http://blog.n01se.net/?p=41

5:40 LauJensen: And once you have coded that bootstrap, the language compiles itself

5:40 licoresse: So it would be more or less like the Squeak VM? A Smalltalk program that generates C code

5:40 that compiles to a platform, et voila, you have a Vm

5:41 _ato: reading it now

5:43 Chousuke: Parts of Clojure would still be host-specific

5:43 but as cinc progresses, more code might possibly be shared between implementations on different hosts

5:43 licoresse: but a very tiny kernel, not?

5:44 Chousuke: currently the ClojureCLR project basically needs to reimplement everything

5:46 at the very least things written in Clojure would require fewer changes to port

5:46 LauJensen: licoresse: kernel is the same size, just written in Clojure instead of Java, but the bootstrap should be relatively small

5:47 Chousuke: ideally you'd just have to implement some kernel primitives and the rest is written using those primitives but then you might not be able to truly take advantage of the host in the implementation :/

5:47 bsteuber: LauJensen: "same size, but Java instead of clojure" sounds like a contradiction to me :)

5:47 licoresse: LauJensen: ok, I was thinking kernel as the movable part, the one thing that needs to be generated, but I follow

5:47 as in Kernel = Bootstrap

5:47 LauJensen: bsteuber: Well, you get my point I hope

5:48 bsteuber: sure :)

5:48 LauJensen: licoresse: Yes it we collectively rename boostrap to kernel, then indeed, its smaller :)

5:48 Chousuke: I wonder what parts would have to be reimplemented... probably at least protocols, deftype and some core functions... and codegen obviously :P

5:48 LauJensen: 'which parts'

5:48 licoresse: the braces would prob. have to be redfined as well

5:49 Chousuke: braces?

5:49 licoresse: Chousuke: yes, like curly braces everywhere

5:49 * licoresse trying to be funny

5:49 Chousuke: right :P

5:49 LauJensen: licoresse: I got it :)

5:51 licoresse: LauJensen: det er godt

6:05 design patterns in functional languages, anyone?

6:08 working with this rather huge swing app, and I got add-watch all over the place

6:11 I read some stackoverflow messages related to this, but it' seem FP people are alergic to anything that smells oop, which I find silly

6:13 bsteuber: well, most of OO patterns are simply not necessary with first order functions available

6:13 but sure, some might still survive :)

6:13 licoresse: patterns to me, means a formalized way of organizing things

6:13 Chousuke: the non-weird OOP patterns are not really OOP patterns at alll!

6:13 -l

6:13 egaga: besteuber: and possibly new ones emerge

6:14 bsteuber: true

6:14 Chousuke: The problem with Lisp is that if you find a pattern, you write a macro and the pattern disappears :/

6:14 underdev: beat me to it

6:14 licoresse: Chousuke: okay, that sounds fine, how to get to that stage

6:14 egaga: so how to rid of pattern of writing a macro when seeing first-order pattern ;P

6:15 Chousuke: you write code and your brain takes care of the rest.

6:15 licoresse: have someone categorized the most useful patterns

6:15 Chousuke: the human brain is exceptionally good at finding patterns

6:15 licoresse: oh please

6:15 Chousuke: sometimes too good, actually

6:16 underdev: facade for sure is still relevant

6:16 Chousuke: collections of patterns are useful for languages with no means to abstract them away because they demonstrate ways to structure code.

6:16 if you need to deal with patterns, might as well document the good ones

6:16 egaga: exceptionally good compared to other known existing things, sure, but i think humans are poor programmers

6:16 licoresse: egaga: I follow you :)

6:17 my brain is exceptionally bad at tracking 200k lines of code

6:17 Chousuke: I suppose Clojure has patterns too... They're just called idioms :/

6:17 licoresse: that's a start, idioms

6:19 underdev: the oo guys have been beating the composition > inheritance drum for a long time, and it's just darn easy to compose functions, and then it's still easier to build a macro to compose the functions for you

6:19 Chousuke: I think syntactic abstraction can condense a large pattern so that it becomes "idiomatic" within the context of the program you're writing. Kind of like in a local dialect.

6:19 I suppose this means that DSLs are idiomatic in lisps

6:20 underdev: and DSL is a design pattern (not GOF, but...)

6:21 Chousuke: What about patterns in the design of DSLs? :/

6:22 Like using vectors for bindings etc.

6:25 * licoresse reading http://norvig.com/design-patterns/ppframe.htm

6:27 licoresse: Anti-Object-Obsessed: “I do not believe in things. I believe only in their relationships” - George Braque

6:28 In my life, I learned one thing; the more freedom I get, the more structure I need

6:30 underdev: In my life, i've learned one thing: "Don't eat the yellow snow."

6:31 licoresse: lol

6:31 underdev: both important lessons, i think

6:31 licoresse: I have kids trying to learn the same thing, suggestions?

6:32 underdev: hey, it took a lot of trial and error to figure out that gem.

6:32 licoresse: is fp an appropriate approach to the yellow-snow-problem

6:33 bsteuber: A somehow related question is "what can take the place of UML for functional programming?"

6:33 licoresse: hmm

6:34 i guess, when you say UML, I am thinking both charts and a language

6:35 underdev: there are a lot of uml diagrams that are still useful, but not class diagrams or whatnot

6:35 and when i say useful, i'm speaking in the broadest sense of the term

6:35 applicable would be a better word :)

6:36 licoresse: in the kingdom of nouns :)

6:36 bsteuber: but maybe there are other kinds of diagrams that might be adequate for functional stuff

6:36 egaga: type signature

6:37 licoresse: how do you map pre and post conditions in uml?

6:38 9 years since I even cared about that stuff

6:39 I see that some people use class diagrams for modules, data members for tpes and methods for functions

6:39 clojurebot: datatype is see datatypes

6:40 licoresse: it's just a square box, does not convey anything IMO

6:41 * licoresse learning about the Alloy modelling language

7:05 tufflax: If I have made a seq of a vector, how can I revert the seq to a vector in constant time?

7:05 liwp: I don't think you can do it in constant time...

7:06 I think after it's a seq, you can only access it via the seq api which doesn't allow you to convert it to a vector in constant time

7:07 but (vec) will convert a seq to a vector for you, just not in constant time

7:07 tufflax: But the seq IS a vector...

7:07 tomoj: huh

7:07 tufflax: Isn't it?

7:07 tomoj: no vector is a seq

7:07 liwp: sure, but the seq interface only allows (vec) to call next on it

7:07 tufflax: I mean, underneath

7:07 tomoj: oh, perhaps

7:08 ,(class (seq []))

7:08 clojurebot: nil

7:08 tomoj: err

7:08 tufflax: ,(class (seq [1]))

7:08 clojurebot: clojure.lang.PersistentVector$ChunkedSeq

7:08 liwp: so vec will call next on the seq until there are no more elements, i.e. O(n)

7:08 I might be totally wrong of course ;-)

7:08 tufflax: hehe

7:08 tomoj: if you know that the seq was produced from a vector, then you should have access to the vector, no?

7:09 liwp: ,(source vec)

7:09 clojurebot: Source not found

7:09 LauJensen: ~source vec

7:09 tufflax: Maybe :P

7:09 tomoj: and if the seq was created far away, how do you know it's a vector?

7:09 part of the contract of your function is that you have to pass a particular kind of seq, or something?

7:10 tufflax: No, I'm just curious

7:10 tomoj: or maybe it could be O(1) on vectors and O(n) on other kinds of seqs

7:10 _ato: ,wall-hack-field

7:10 clojurebot: #<java_utils$wall_hack_field__654 clojure.contrib.java_utils$wall_hack_field__654@19230b2>

7:11 _ato: ,(wall-hack-field clojure.lang.PersistentVector$ChunkedSeq vec (seq [1 2 3]))

7:11 clojurebot: java.lang.ClassCastException: clojure.core$vec__4296 cannot be cast to clojure.lang.Named

7:11 _ato: hmm

7:11 ,(wall-hack-field clojure.lang.PersistentVector$ChunkedSeq 'vec (seq [1 2 3]))

7:11 clojurebot: java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)

7:12 _ato: dang

7:12 tomoj: ,(doc wall-hack-field)

7:12 clojurebot: "([class-name field-name obj]); Access to private or protected field."

7:12 liwp: looking at PersistentVector.java there doesn't seems to be any special casing for creating a new vector from a seq that is a vector underneath

7:13 _ato: it'd probably work in a regular repl (not in clojurebot's sandbox)

7:13 technically constant-time

7:13 although it uses reflection

7:13 so its probably slow :-P

7:13 (and a horribly ugly hack that will eat your babies)

7:15 tufflax: :p

7:30 zakwilson: Anybody awake host a Clojure app on Google App Engine?

7:35 liwp: I haven't used clojure with app engine, but I just saw this on my RSS reader: http://www.infoq.com/articles/deadline-clojure-appengine

7:36 and there are some other posts about it as well, I think

7:36 HTH

7:43 rhickey: whew, now 3500 members on ggroup

7:44 bsteuber: n1ce

7:49 chouser: I assume that the more knowledge of Clojure is decentrallized (through books, co-workers who know it, etc.) the larger the ratio of Clojure users to ggroup members will become.

7:50 cemerick: Yeah, probably somewhere between a 1x and 10x multiple, maybe. :-)

7:50 chouser: right

7:50 lpetit: sure

7:51 chouser: I mena, I've never hung out in IRC channels or subscribed to mailing lists for any of the other languages I've learned. Never really even considered doing so.

7:52 cemerick: #clojure brought me back into irc in a big way. I had given up on it.

7:52 Not that it's to be trusted, but graphs like this are surprising to me. http://www.indeed.com/jobtrends?q=clojure%2Cjruby%2Cscala

7:55 chouser: hrm, it's going to be hard to keep http://clojure.org/libraries up to date. Correcting bad links will be easy compared to removing "dead" projects and keeping latest relevent ones listed.

7:55 neight leiningen nor clojure-maven-plugin is on there, for example.

7:56 neither

7:56 carkh: i think the new protocol/reify/deftyp stuff might bring more people in, because of the performance boost

7:56 cemerick: that page can probably be replaced with two links: one searching google, the other searching github. ;-)

7:57 LauJensen: (or Gitorious)

7:58 cemerick: LauJensen: is that reasonably installable yet? The last time I looked at it, getting a local install running was a bear of a job.

7:58 LauJensen: I haven't tried

7:59 We picked it because of a cleaner interface, as well as Github being slowed to a crawl, presumable by Rich's weekly 7000 lines of commits :)

7:59 cemerick: I'd like to have a decent git UI in-house, but I surely am not going to shell out what github wants for FI.

8:00 fogus: "So far we tracked Clojure separately, but it is so close to Lisp and Scheme that it is indeed better to join it with the other Lisp like languages." -> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

8:00 LauJensen: cemerick: Use Magit or Egg? Both excellent UIs in their own right

8:01 fogus: wow, I didnt even know :)

8:01 cemerick: LauJensen: never tried them. We use gitosis, which is good enough for now.

8:01 LauJensen: Yea its decent

8:02 cemerick: LauJensen: You should know by now that I don't use anything that involves emacs. :-)

8:02 gitx is my preferred local UI, tho

8:02 LauJensen: Oooh thats right, now I remember :)

8:10 rhickey: cemerick: what would the google search be?

8:12 LauJensen: rhickey: If you've seen the "Hacker Search" on my site, thats actual a google search which only gets results from my blog, cgrands, clojure.org and then finally Google. Its a nice way to restrict the search area

8:12 tomoj: huh, my city is listed in 2nd place on google trends for "clojure" :D

8:12 cemerick: rhickey: it'd be easy to rig up a little google search box that prepended 'clojure ' to the user-entered query. Prompt with "What would you like to do/build/etc with clojure?" (or whatever). Someone enters "web development", and is shown results for "clojure web development".

8:13 That won't get them to the perfect libraries in one shot, but will get them very, very close.

8:13 rhickey: cemerick: no searches like that yield anything remotely like the libraries list. Not to say it doesn't need some updating...

8:13 cemerick: heh, the intro blog post on "Clojure Web Development with Ring" is result #4 for my example :-)

8:14 rhickey: Sure, but who benefits from the libraries list, practically speaking? It's good for social proof of clojure itself, but I'm not sure people actually use it to find projects/libraries.

8:15 (I say that in the context of the libraries listing always being out of date, as such manicured lists always are.)

8:15 carkh: it's usefull for newcomers

8:15 chouser: cemerick: we'll be starting a trial of github:fi at work soon

8:15 rhickey: cemerick: to the extent it was curated and comprehensive, why would you use anything else?

8:16 cemerick: rhickey: curating it would probably be a number of hours of work per week as things stand, nevermind as the community grows....

8:16 egaga: how about a convention for library writers to create a page which contains in specified format what the project name is and description, links to important pages, and then one can crawl all the github

8:16 cemerick: chouser: no kidding! Deep pockets over there. ;-)

8:17 rhickey: chouser: github:fi ?

8:17 cemerick: egaga: well, there's already a page showing projects that use clojure on github AFAIK

8:17 chouser: cemerick: well, the trial is free... :-)

8:17 cemerick: rhickey: http://fi.github.com/

8:18 zakwilson: I used clojure.org/libraries about an hour ago to see what sort of parser libraries are available for Clojure.

8:18 * cemerick sits corrected

8:18 rhickey: other than the fork management and sparkle for same, why would one run local github?

8:19 chouser: rhickey: apparently putting our code on github's servers is off the table

8:19 rhickey: but you could run local git

8:20 w/o github

8:20 LauJensen: w/ gitosis

8:20 cemerick: gitosis is *not* fun to deal with

8:20 LauJensen: cemerick: I thought it was - fond memories

8:22 cemerick: Having a single choke point for all permissions, etc is not good. It was painful enough with just a couple of guys, I can imagine it being totally unmanageable with >10.

8:24 chouser: github has a bunch of other features: peer review tools, patch commenting, etc.

8:26 cemerick: yeah, the baked-in code review is attractive

8:27 bsteuber: how about a wiki page that links to libraries? this would scale with the community

8:27 Chousuke: I think clojure.org is a wiki, so... there already is one :P

8:28 cemerick: actually, wouldn't clojars be the ideal canonical directory if it were widely used?

8:29 LauJensen: It would require some kind of supervision

8:31 carkh: from the look of it, clojar has no clear text on what the library does

8:31 rhickey: cemerick: I've yet to see clojars act as a directory

8:33 so how does one find out how code review etc works on github? Do you just have to follow their blog?

8:34 Chousuke: most likely :P

8:34 rhickey: is documentation anathema to ruby-based sites?

8:34 Chousuke: it seems you can just open the page for a particular commit and leave a comment

8:38 bsteuber: I'd love to see libraries by user-added tags and number of references from project.clj/pox.xml files on github

8:38 chouser: rhickey: I just added a line note near the bottom of http://github.com/richhickey/clojure/commit/c733148ba0fb3ff7bbab133f5375422972e62d08

8:39 you can also see the box there to add a comment for the whole commit

8:41 rhickey: chouser: yeah, I saw little icons and plus signs and figured that out, but not the same as docs

8:41 chouser: true

8:41 cemerick: rhickey: yes, it would definitely need to expose a proper listing, and people would have to populate the description field in their poms / project.clj files.

8:42 rhickey: poms and project.clj files - do we need both?

8:42 cemerick: no, but some people use the former, others use the latter

8:43 chouser: poms will be .clj eventually

8:43 * chouser hopes

8:43 cemerick: ah, only poms are pushed to the repo, which makes sense

8:45 I don't think XML will be overtaken, even among clojure projects.

8:45 rhickey: chouser: yes, I'm wondering why people don't apply their efforts to polyglot and make the clojure support awesome, lein is just going to be burdened with replacing all of maven eventually anyway, and we will be left on our new island. Clojure is about getting off of the Lisp island.

8:45 not that pom files aren't hideous

8:45 cemerick: rhickey: clj polyglot is pretty damn great already, it turns out. I've been fiddling.

8:45 rhickey: cemerick: cool

8:46 bsteuber: cemerick: do you have a good tutorial?

8:46 chouser: rhickey: it is interesting to hear you weigh in on this -- I had assumed you were intentionally avoiding voicing an opinion. :-)

8:46 cemerick: bsteuber: I'll put up another screencast when I get through my current queue.

8:46 bsteuber: cool

8:46 chouser: maven pom.clj files look very nearly identical to lein project.clj files

8:47 cemerick: it was sort of inevitable, given that it uses maven for deps and that there's only so many ways to skin the cat :-)

8:47 rhickey: chouser: going through the labrepl effort, we found that maven/POM is a lingua franca - if people use it for their projects they will have the greatest reach. IDEs and other tooling aren't going to support lein anytime soon

8:48 bsteuber: couldn't we just use a 1-to-1 mapping from xml to clojure?

8:48 chouser: it's very good that lein projects play well with the maven universe -- producing poms, able to be a dep and have deps from maven

8:48 rhickey: given a pom, you can just open a project and go in any of the IDEs

8:48 chouser: bsteuber: I think polyglot maven is either that or very close.

8:48 rhickey: chouser: but what is the round trip? Does lein modify its part of the POM or replace the whole thing?

8:49 bsteuber: ic

8:49 cemerick: rhickey: of course, tooling support will likely never be at parity for polyglot

8:49 it's a one-off generation each time

8:49 rhickey: cemerick: same question, what's the round trip (if any)

8:50 bsteuber: I think lein replaces the whole pom

8:50 cemerick: all the polyglot impls are supposed to provide stable round-tripping. I don't think lein will generate a project.clj from a pom, but I could easily have that wrong.

8:51 rhickey: lein would have to make sure it preserved and didn't trash anything it didn't understand

8:51 at that point, it would have to become a clojure-syntax dialect for maven, which is what polyglot is, no?

8:52 cemerick: right, exactly

8:52 _ato: lein currently doesn't read poms at all and I doubt there's any intention of making do so

8:52 chouser: my point is simply that having chosen to use lein is not a dead-end decision. You're not forcing other projects to use lein just provide/consume the dep, and if you decide later to switch to maven it's not likely to be difficult.

8:52 bsteuber: cemerick: do I have to manually call "clj->xml" and "xml->clj" when updating any of the poms? or does it somehow automatically do this from timestamps?

8:53 chouser: I for one am planning to learn maven.

8:53 cemerick: rhickey: to be clear, each polyglot impl is supposed to support the *entire* model, so there shouldn't ever be a part of an XML pom that can't be converted to a pom.clj

8:53 * bsteuber already ordered the maven books

8:53 rhickey: cemerick: right, I presumed as much

8:53 cemerick: bsteuber: going back and forth between xml and clj really shouldn't be a common operation, or really one that you should have to worry about.

8:54 rhickey: I'm not saying maven is great, and quite frankly it frightens me, but wheel-reinventing and islands frighten me more

8:54 cemerick: rhickey: been there, done that? ;-)

8:55 bsteuber: rhickey: so when does clojure itself switch to mvn?

8:55 chouser: contrib already uses mvn

8:56 bsteuber: I know

8:56 underdev: chouser: have fun!

8:56 chouser: clojure currently has no deps, so little value there.

8:56 rhickey: chouser: so I commented on your line comment, and feel as if that discussion is completely in the wrong place, not connected to the issue, trapped in a single commit

8:56 chouser: underdev: :-/ yeah, I know.

8:57 rhickey: bsteuber: for what purpose? I don't even understand why contrib is maven. Someone posted a bug on that, in fact

8:58 * underdev took maven to a field with a couple of his friends after it kept failing to build with a "pc load letter" error

8:58 bsteuber: hm, I think I'm just a fan of "one tool to rule (build) them all" - but I see it's not urgent at all :)

8:58 cemerick: rhickey: The maven release process is pretty compelling.

8:58 rhickey: cemerick: but what about that has to do with building?

8:59 chouser: rhickey: yeah, it'll be interesting to work out when/if commit comments make sense.

8:59 cemerick: rhickey: builds have to produce artifacts, which need to get into repositories eventually, and ideally be reflected as being associated with particular commits, etc.

9:00 rhickey: cemerick: is any of that happening with contrib?

9:00 cemerick: IMO, "the build" is everything that happens from the time a programmer types the last paren to when the end-user gets the software on his systems.

9:00 chouser: ha!

9:00 rhickey: I found this interested re: associating with commits, and other issues: http://dustin.github.com/2010/04/01/why-not-maven.html

9:01 cemerick: rhickey: Not sure. I think it was on Stuart's plan, tho he may not have gotten to the release automation part.

9:01 chouser: "from the time a programmer types the last paren" <- love it

9:01 rhickey: all I know is building contrib got harder for me, and much uglier

9:02 cemerick: part of that is that core isn't using maven, so there's some bridging that has to happen there now

9:02 rhickey: why does it always print "no sources to compile" and "no tests to run? every time it compiles and runs tests?

9:03 cemerick: Not sure, but that's probably it looking for Java sources to compile and test.

9:03 mattrepl: playing well with others seems important

9:03 cemerick: It's a simple thing to disable that if it matters.

9:03 LauJensen: rhickey: So you strongly favor ant for building Clojure projects?

9:04 rhickey: LauJensen: I didn't say that, just trying to tease out the costs/benefits

9:04 LauJensen: Ok great

9:04 rhickey: any was simple to install, few deps, worked well

9:04 ant

9:04 vu3rdd: rhickey: I along with another guy package clojure/clojure-contrib for debian

9:04 rhickey: maven was big and ugly and didn't seem to produce a different result

9:05 _ato: for contrib and core, depedendency management is basically overkill. For other projects that necessarily have more dependencies its useful

9:05 vu3rdd: contrib definitely is a bit of pain to build as debian does not allow "pulling the whole internet" to do the builds.

9:05 we need to use the maven local repo.

9:05 rhickey: anyway, what say maven fans to the critique I linked to above?

9:06 vu3rdd: debian folks have a wrapper for maven which uses only the local repo

9:06 underdev: maven fans? oh maven fans....

9:06 <crickets>

9:06 cemerick: 9.9

9:07 bbl

9:07 bsteuber: rhickey: I'm a mvn newb myself, but I guess the point is that stuff like IDE integration as you said outweigh most of its warts

9:07 vu3rdd: ant definitely is much simpler

9:08 bsteuber: also, we could just write better clojure-specific mvn plugins that do the jobs

9:08 I'd love a clojure-framework to support writing own maven plugins :)

9:08 should not be hard, I guess

9:08 underdev: chouser is on it!

9:09 you've been volunteered

9:09 chouser: ugh -- that critique worries me, because it's exactly the friction against unusual build requirements that's prompting me to learn maven.

9:09 so if maven is going to fail me in that regard ... :-(

9:11 _ato: I had much the same experience with maven, island or not at least a lein plugin is trivial to write. Ant + maven tasks is probably also a reasonable solution, use ant for your builds and maven only for dependency management

9:11 chouser: IDE integration isn't much of a plus for me. Actually, almost a minus as things that have IDE integration often seem to *need* it to mitigate other weaknesses.

9:11 I'm looking at you, Java.

9:11 * _ato also has zero interest in IDE integration for build tools

9:12 rhickey: chouser: but library authors should care that people who use IDEs might want to work with their lib in an IDE

9:12 _ato: standard directory structure is about all that it needs

9:13 rhickey: emacs+slime rulez is just going to limit the reach of Clojure

9:13 and good Clojure people have written good IDE support

9:13 chouser: well, I wasn't advocating slime either. :-)

9:13 rhickey: cli rulez

9:13 chouser: there we go

9:13 rhickey: :)

9:14 carkh: what's cli ?

9:14 jcromartie: if I wanted to use Clojure at work, I would absolutely need to show them an Eclipse/IDEA/NetBeans plugin

9:14 underdev: command line interface

9:14 carkh: underdev: thanks

9:14 jcromartie: and say "look! *click* *click* *click* It's just like Java"

9:14 LauJensen: cemerick makes a good case for Netbeans + Maven I think

9:15 chouser: no, I definitely want my libs to play well with others. clojure-jna for example needs to be updated to declare deps and be accessible as a dep in some good "standard" way.

9:15 ...which apparently means *some* amount of work to obey lein or maven rules.

9:15 LauJensen: well. He's fond of it. The "simplest possible xml config" weighing in at 38 lines with mysterious keywords scattered was unattractive

9:15 rhickey: if it was a big deal, or even required touching an IDE to make you lib IDE-friendly, that would be one thing, if it's just a matter of a (possibly generated) POM...

9:16 bsteuber: I think if we really care about the island thing, there's no escape from maven - so the best we can do is thinking of how to make it as usable as possible for clojure folk

9:16 chouser: so in the context of a little lib like clojure-jna, I'm doing nothing unusual, just need some deps -- don't even need to AOT compile -- just writing a pom or having lein generate one for me is attractive.

9:17 bsteuber: and actually, I do sometimes want to deliver a clojure app as mac os bundle or using webstart, where existing mvn plugins are a blessing

9:18 vu3rdd: it will be great if we have a simple config with key-value pairs of project name, version, dependencies with versions etc etc and a tool chich generates project.clj or pom.xml or whatever

9:18 chouser: but at work we have a relatively complex build system -- code in at least 4 general-purpose languages, files in at least 3 other DSLs each with their own code generator (each generating at least 2 languages)...

9:18 LauJensen: There's also Gradle...

9:19 chouser: what we've got now works, but requires lots of coaxing and hand-holding. I'm hoping maven will allow me to clean all that up, but "why-not-maven" worries me.

9:19 I guess I'll still give it a try...

9:20 stuartsierra: chouser: Maven will help somewhat by forcing you to clarify the relationships between projects/modules.

9:20 But it might also require rethinking your entire build.

9:20 underdev: bsteuber: i watched a screen cast where they used maven in netbeans to make a .dm... was excited. Then when it kept failing to build, or even find, the stuff for labrepl, i really didn't know where to begin. Maybe i have a hard time abstracting the java stuff from the maven stuff...

9:21 chouser: the relationships are clear, I think. starting from a clean checkout everything builds fine.

9:21 that is, all the internal deps are declared so that things build in the right order

9:21 underdev: "pc load letter" all day.

9:22 chouser: underdev: what does that even mean?

9:22 _ato: chouser: from my experience maven works fine on simpler apps, basically anything that can fit witin its cnoventions. I simlarly converted a lot of Java apps that used monsterous mixes of shell scripts and windows batch files at work over to maven. More complex stuff is doable if you're willing to invest a heck of a lot of time -- the documentation is generally terrible and the user interface (ie config files and command-line)

9:22 likewise.

9:22 chouser: _ato: :-(

9:23 _ato: I'd really like to like maven, really.

9:23 LauJensen: You're not selling it very well ato

9:23 _ato: I wish it were the answer to my problems

9:23 bsteuber: underdev: same problems for me, but I hope once I'm done with the mvn books it all will be a breeze

9:23 LauJensen: In this context, what do you guys think about Gradle, it seems pretty mature

9:23 * _ato is hoping the polyglot guys will go further than just giving it parens instead of XML and actually make it sanely extensible

9:24 underdev: and i found a really nifty pom to put stuff on google app engine. There may come a day where the pain of learning is outweighed by the benefits of using it. This day, at least for me, is not that day.

9:24 chouser: gradle *requires* me to use yet another language with it's own irregular syntax?

9:25 LauJensen: I dont know what you mean by irregular, Groovy as a language is straightforward and easy to pick up

9:25 underdev: otoh, maven smells like a tool that a tool like an ide would like.

9:25 _ato: but right now it's just not good enough, I mean sure its got zillions of plugins and IDE support and such, but if it takes me 3 times as long to figure out how to use them than to hack a up quick lein plugin or shell script then I'm happy on my island

9:26 underdev: ^^^^^

9:26 LauJensen: Yea the Lein island is happy island :)

9:27 bsteuber: so how do I deploy swt applications for different OS'es using lein?

9:27 underdev: i was just going on a three hour tour...

9:27 bsteuber: my impression was that lein stops being that simple once you want more than a simple clj project with jar deps

9:28 but maybe I just didn't learn enough

9:29 LauJensen: lein doesn't have the myriad of plugins that Maven does, but shouldn't there be a sensible division between building and deploying?

9:30 cemerick: LauJensen: so, there's a sensible division between automating stuff using existing tools, and rolling your own half-baked solutions? </snark> ;-)

9:32 LauJensen: cemerick: Oh thats right, you considered it a single task

9:32 Well I can follow that logic as well, but as Maven has proven, that complicates the matter a little bit

9:32 chouser: cemerick: are you back? do you have a response to that page rhickey linked to?

9:33 _ato: I don't deploy SWT apps to 3 platforms. What is there to it? To me it's build an uberjar and let people download it. If you want installers and such then that's up to you figure it out. Use maven if it fits, or extend lein, or use some other tool that's whole purpose in life is making installers

9:34 cemerick: chouser: coming back slowly :-)

9:34 bsteuber: ato: the point is, swt uses native libs, so you need different uberjars depending on your user's OS

9:35 underdev: there is yet another tack possible. Making lein do more maven monkey tricks. I forked it to nose around in it, to see what might be done.

9:35 chouser: I don't see the line where building stops and deploying starts. To build, I need to fetch deps, so I need to declare what they are. To deploy a lib I need to declare what I provide and what else you might need. Shouldn't that all be declared in a single format in a single file?

9:35 cemerick: underdev: That makes *no* sense IMO. Gradle is the endpoint of that approach, which I don't think serves anyone.

9:36 underdev: except one would need facility in clojure, not groovy

9:37 _ato: bsteuber: as far as I know, someone added native library support, I'm not sure how extensive it is. In any case it'd be trivial to write a custom lein task that pulls in the files you need for each platform and spits out 3 uberjars

9:39 underdev: i think it would be cool to have a dir, drop a pom in it, and lein does the rest

9:39 it would make sense to me, perhaps only to me...

9:39 bsteuber: ato: hm, okay - I got stuck when trying, but this was prabably lack of determination (and lein docs at that time), so I used a shell script instead

9:40 cemerick: underdev: you just described polyglot maven :-)

9:40 stuartsierra: rhickey: I'm just joining this conversation, reading your comments re Maven for Contrib.

9:40 My goal with switching contrib to Maven was to simplify the build.

9:40 underdev: that's not ready for primetime, rt?

9:40 cemerick: underdev: very, very close

9:40 screencast coming soon :-)

9:41 underdev: excellent

9:41 stuartsierra: rhickey: The build.xml for contrib was several hundred lines, difficult to modify, and buggy.

9:42 The pom.xml for contrib, even with extra configuration, is 137 lines, all declarative.

9:42 rhickey: stuartsierra: what did it do?

9:42 stuartsierra: the build.xml?

9:42 * rhickey used to build clojure by typing javac ...

9:43 rhickey: more generally, what's involved in building contrib?

9:43 stuartsierra: rhickey: Sure, but it's more complicated than that now. Bootstrapping core.clj, AOT-compiling, ...

9:44 rhickey: Building contrib has 3 steps: 1) compile gen-class'ing Clojure sources, 2) test, 3) build a JAR

9:44 npoektop: hi! if i use a macro from another file, and i change that file, i must recompile macro-using-file explicitely. Is there a way to automatically recompile all those files that use a macro when i change a macro?

9:45 stuartsierra: rhickey: The Ant build script AOT-compiled .clj sources in two stages, the gen-class ones first, in a specific order.

9:45 Chousuke: 137 lines still sounds like a lot but I suppose a fair chunk of it is either boilerplate or XML's natural verbosity.

9:45 underdev: lisp's mortal enemies

9:46 stuartsierra: rhickey: The order of compilation turned out to be important. After switching to Maven, several bugs were exposed regarding the order in which files got AOT-compiled, which we were able to fix.

9:46 Now the build doesn't depend on any particular order in which files get AOT-compiled.

9:46 Chousuke: underdev: poms are declarative, though, so it's not so bad.

9:46 underdev: rt

9:46 chouser: npoektop: I don't think there's any automated solution to that.

9:47 LauJensen: stuartsierra: sounds like quite an improvement

9:47 underdev: but being declarative, they're operation isn't transparent. but that's a whole 'nother kettle of fish

9:47 licoresse: Got a Kinder-egg toy today that i could'nt build :(

9:47 underdev: their*

9:47 cemerick: rhickey: regarding that link you posted a while back: if you're using maven to cut releases, you use the release plugin, which will auto-increment the version number (or you can specify it, *once*), and then it will do a clean checkout, twiddle the version number, do the build, run the tests, deploy the artifact(s), and then tag and push a new SCM commit using the version number you specified.

9:47 stuartsierra: LauJensen: It was messy for a while, because we had to find those bugs and fix them, but I think I can safely say that the contrib build is safer and more predictable now.

9:48 LauJensen: Great - I think I'll make an attempt at understanding it :)

9:48 rhickey: stuartsierra: I'm all for it being easier to maintain. Is there any way to keep it from saying no sources/no tests while building?

9:49 stuartsierra: rhickey: probably not, because that's part of the default build lifecycle

9:49 cemerick: stuartsierra: no, there is

9:49 stuartsierra: cemerick: how?

9:50 cemerick: stuartsierra: if we're talking about compiling java files, you can evict maven-compiler-plugin from the compile phase

9:51 stuartsierra: oh really?

9:51 rhickey: The biggest problem with Maven, I think, is that it's an all-or-nothing deal. It works best when it can control everything.

9:53 underdev: there was a blog post comparing it to tai chi or something, you do best when you yin it's yang, or something to that effect

9:55 stuartsierra: cemerick: Do you know how to disable maven-compiler-plugin in the POM?

9:55 underdev: YOU'RE YANGING!!

9:55 stuartsierra: underdev: I am indeed.

9:56 _ato: maybe you use this custom lifecycle stuff and remove it from the compile phase? http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/

9:57 cemerick: stuartsierra: fiddling now

9:59 underdev: whoa, mengu!

9:59 hahahahhahahaha

10:00 mengu: hi underdev :)

10:00 * underdev is taking personal credit for this

10:01 mengu: yeah from twitter :P

10:01 _ato: this is what I mean by its pretty easy for simple stuff but as soon as you need to do something custom you hit a brickwall of new terminology and what appears to be complexity for complexities sake. Sure it *can* do everything but the learning curve is a cliff face and you don't have any chalk -- climbing it hurts!

10:02 djpowell: how does maven make it easier to use someone else's library? just sticking the jar files in your lib folder doesn't seem that hard anyway. I don't see how maven makes anything more noob friendly. i feel I wouldn't be remotely qualified to use it unless i'd read a book explaining all of its concepts and processes, and persuaded everyone on the project to do the same; and i'd just rather spend that time doing something else, like

10:02 watching tv or something

10:02 underdev: nice

10:02 _ato: are the books on it any good? do they help?

10:03 chouser: djpowell: I want to use ring. ring has a half-dozen dependencies. So, should I go and download each of those deps manually?

10:03 djpowell: it doesn't seem to be that much of a chore

10:04 chouser: really!? when I have to do it again each time I upgrade ring?

10:05 carkh: ring should have the libraries in its source control, problem solved

10:05 djpowell: i don't know - perhaps if you work on lots of very short projects, that are very dependency heavy, then downloading dependencies starts to take up a significant portion of development time, but I don't usually hit that problem

10:05 naeu: in Ruby I can create a big array of numbers like so: a = (0..10000000).to_a

10:05 cemerick: carkh: I'll pretend you didn't say that. :-)

10:05 carkh: cemerick: hehe that's what i do on my own projects

10:05 naeu: however, if I try something similar in Clojure I run out of memory: (def a (vec (range 10000000)))

10:06 cemerick: oy

10:06 carkh: why is this a problem ?

10:06 chouser: carkh: sure, but then the ring dev has the same problem -- he's got to fetch all his deps manually. Also it means I can't just use his jar anymore, I've got to use his revision control tool and fetch his code.

10:06 hiredman: naeu: the default jvm heap is small

10:06 cemerick: for one, your source repo will grow very, very large over time

10:06 _ato: naeu: the JVM has a heap limit you can set on the command-line with eg. -Xmx512m for 512MB

10:06 naeu: does Clojure use more memory than Ruby in this kind of situation, or does the JVM place more constraints on memory availability?

10:06 cemerick: but beyond that, what chouser said :-)

10:07 naeu: what might the default jvm heap size be, and how might i determine it?

10:07 cemerick: stuartsierra: OK, I lied. You can unbind executions for plugins that don't bind themselves automagically, which is what maven-compiler-plugin does. :-/

10:07 carkh: cemerick: repo size isn't a problem these days, as for chouser, the maintainer has to pick and choose manually anyways

10:08 cemerick: carkh: when each version of the dependencies is 1, 2, 5, 10MB, that's still a problem

10:08 stuartsierra: cemerick: That's what I thought.

10:08 hiredman: ~google default jvm heap size

10:08 clojurebot: First, out of 18500 results is:

10:08 HotSpot Internals - Understanding Xss- java stack internals

10:08 http://forums.sun.com/thread.jspa?threadID=756468

10:08 chouser: there's a reason that every dev environment has tools to address this problem: apt, yum, etc. for C/C++ dev, CPAN for perl, gems for ruby, etc. And apparently maven for java.

10:09 carkh: could be overengineering

10:09 chouser: yep, could be. But it isn't. :-)

10:10 stuartsierra: Programmers love automating things.

10:10 underdev: i think we all want dep management, but we want it be more like fishing than diving into the icy arctic waters of alaska with a k-bar in our teeth

10:10 chouser: cemerick: so there's no way to prevent maven from trying to compile java files? or am I misunderstanding?

10:11 cemerick: chouser: you can set an exclude, so it won't ever compile anything, but no, it looks like the compilation is hardwired.

10:11 stuartsierra: I think it can be prevented, but at the cost of defining a new project lifecycle. Seems hardly worth the effort.

10:11 * chouser sniffs and tallies another red flag.

10:12 cemerick: chouser: Seriously? :-|

10:13 chouser: cemerick: it betrays a troubling design attitude.

10:13 djpowell: I don't think apt and cpan etc are build tools as well as binary libary download tools are they?

10:13 _ato: djpowell: they are

10:13 well in some sense

10:13 chouser: djpowell: taken together, they are.

10:13 cpan certainly does builds of native libs

10:13 _ato: depends what you define apt as being, but all the apt tools together are

10:13 metronome: naeu: ruby does use a whole lot of memory for that as well

10:13 _ato: and cpan definitely is

10:13 stuartsierra: chouser: It's not hard-wired into Maven, but it is hard wired into the "jar" lifecycle, which assumes you're building Java software.

10:14 chouser: stuartsierra: ah, that's a bit better.

10:14 cemerick: chouser: It's funny, people complain that maven "downloads the internet" because it doesn't ball up all its bits into a massive download, but people complain when it always does certain incredibly common things because it shouldn't be making assumptions. :-P

10:14 stuartsierra: chouser: So we could define a "clj-jar" lifecycle, which might be useful at some point.

10:14 naeu: metronome: I'm sure it does - it's just that I'm new to the JVM, and so it's interesting to know the constraints and how I might get a feel for them from within Clojure

10:15 chouser: _ato: right. apt sits on top of dpkg and friends which definitely includes a complex multi-language build environment. With 'make' down in its guts somewhere.

10:15 metronome: naeu: I know I was just saying :) but yeah there is a per-platform maximum heap size

10:16 naeu: metronome: is there some way of accessing these JVM settings from within Clojure?

10:16 djpowell: ,(.maxMemory (Runtime/getRuntime))

10:16 clojurebot: 66650112

10:16 underdev: yeah, i'll take apt-get with maven in the guts some where.

10:17 naeu: djpowell: thanks :-)

10:17 djpowell: you can also look at System/getProperties, and JMX for even more stuff

10:18 naeu: is there a way of listing the static/instance methods of a Java object from within Clojure?

10:18 chouser: naeu: clojure.contrib.repl-utils/show

10:18 naeu: at the moment I always refer to the documentation

10:19 chouser: oh great, thanks!

10:21 chouser: huh -- clojure could determine at method-resolution time (either compile time or at runtime reflection) when a method has varArgs, I think could automatically wrap in an array for you.

10:21 would that be desirable?

10:22 stuartsierra: chouser: how would it distinguish between varArgs and a single array argument?

10:23 bsteuber: ,(map #(.getName %) (.getMethods (.getClass (java.lang.Integer. 5))))

10:23 clojurebot: ("hashCode" "reverseBytes" "compareTo" "compareTo" "equals" "toString" "toString" "toString" "toHexString" "valueOf" "valueOf" "valueOf" "decode" "reverse" "byteValue" "shortValue" "intValue" "longValue" "floatValue" "doubleValue" "parseInt" "parseInt" "toOctalString" "toBinaryString" "getInteger" "getInteger" "getInteger" "highestOneBit" "lowestOneBit" "numberOfLeadingZeros" "numberOfTrailingZeros" "bitCount" "rotateLeft"

10:23 _ato: the compiler knows how many args you passed in

10:23 ah

10:23 but if there's only one it doesn't

10:23 chouser: ,(map #(.getName %) (filter #(.isVarArgs %) (.getMethods String)))

10:23 clojurebot: ("format" "format")

10:24 stuartsierra: ah

10:24 _ato: nice

10:24 djpowell: ah - i didn't know the jvm even knew about varargs

10:25 chouser: I suppose it would complicate already rather complicated method resolution logic.

10:25 npoektop: i've just showed slime to my co-worker, and he said he would never spend years learning emacs just to use this tool.

10:26 djpowell: show him nxml-mode!

10:26 doseq: Emacs is an archeological artefact.

10:27 ;)

10:28 hoeck: npoektop: what is the preferred editor/IDE of your co-worker?

10:28 cemerick: doseq: no ;-) necessary :-)

10:28 npoektop: i don't know that word: weakling or smth?

10:28 hoeck, eclipse

10:29 doseq: cemerick: I'm too old to be genuinely provocative.

10:29 djpowell: I don't use emacs for Java unless I need to go query-replace-regexp crazy, I use it about 50% of the time for clojure, and I use it for text and xml.

10:30 cemerick: doseq: yeah, I'm feeling aged myself in that vector

10:31 stuartsierra: emacs is like religion, you have to be indoctrinated early

10:31 cemerick: The church's best days are long, long past.

10:31 _ato: what converted me was on and off over a long time watching a competent emacs user colleague use it. The speed and ease with which they got things done was tempting enough to override the learning curve. It's not for everyone though, it seems to take a certain type of crazy. I was already halfway down that path anyway.

10:32 stuartsierra: Someone remarked to me that all the original Emacs devs were pianists (like me), which is why they weren't bothered by seven-finger commands.

10:32 doseq: I would tolerate it if they used a modern approach to interface design and exposed features gradually.

10:33 Eclipse is the same. Developers need a bang on the head to say, hey, users haven't seen every step of the development curve like you have. They possess no mental model... you're approach is wrong.

10:33 tcrayford: I've been tempted to write a game like learning mode for emacs

10:34 The clojure dojo I go to spends ~90% of the time struggling with emacs :(

10:34 LauJensen: doseq: You have been flagged for criticizing Emacs once - The second offense results in immediate and permanent ban from the Internet

10:34 djpowell: I discovered that emacs lets you edit .patch files the other day, and automatically fixes up the hunk headers, and will also tidy up superfluous white-space differences. That is pretty cool.

10:34 _ato: Emacs not being built like a modern GUI app is half the point of it

10:34 doseq: LauJensen: noes! :D

10:34 stuartsierra: I learned Emacs from the tutorials, it's not that hard really. But you have to take the time.

10:35 doseq: Well, it doesn't even need to be a GUI... just an expositional text UI would do it.

10:35 Chousuke: emacs is not built like a modern GUI app because it is not one :P

10:35 djpowell: the tutorials eschew things like the arrow keys though, which is a bit too hardcore

10:35 Chousuke: it has its own UI paradigms

10:35 doseq: They just throw everything in there and hope you won't notice how confusing it is.

10:35 Chousuke: that's not true either.

10:36 _ato: try the tutorial

10:36 doseq: *shrug* I have my own views.

10:36 tcrayford: having to take the time to learn emacs has put quite a few people I know off even trying clojure :/

10:36 Chousuke: emacs development started back when you needed to read manuals to even boot a computer :P

10:36 LauJensen: tcrayford: If Emacs was too hard for them, Clojure would have killed them

10:36 cemerick: tcrayford: point them at any of the very nice IDE plugins!

10:36 LauJensen: that is categorically false

10:37 tcrayford: agreeing with cemerick there

10:37 clojure has been easier to learn than any other language I've tried

10:37 LauJensen: You can agree all afternoon, doesn't change the fact that if you cant figure out a text editor, functional programming is beyond you

10:37 cemerick: emacs is too hard for me, thanks very much. Or, I should say, I've got better things to do than fiddle with .emacs files all day.

10:37 LauJensen: cemerick: like fiddling with Maven? :)

10:38 doseq: Clojure has that nice quality of being easy to get started... (+ 1 2 3) is the gateway drug.

10:38 tufflax: LauJensen emacs is not hard in the same way, not that clojure is all that hard

10:38 underdev: boom goes the canon, no braggin, try to read my mind just imagine

10:38 _ato: heh, both Emacs and Clojure are pretty mind-blowingly different from the status quo

10:39 doseq: Mind you, I came from reading Little Schemer and it's WAY better than that.

10:39 cemerick: LauJensen: yeah; one influences my lonely editor, the other I can use to automate my entire software development process.

10:39 * underdev suddenly has the horrible thought that he is smart enough for emacs but not enough for clojure... and shudders.

10:39 * underdev will blame lau

10:39 doseq: F*ck car and cdr, and cdddr or whatever else they thought was super-awesome back in the 60s.

10:40 LauJensen: doseq: Watch your language please

10:40 doseq: LauJensen: is my self-censorship not sufficiently powerful?

10:40 tufflax: haha

10:40 LauJensen: No- Take a lesson from China

10:41 doseq: Well, car and cdr deserve it.

10:41 LauJensen: Anyway - I weigh preferences heavily, so that if one like cemerick prefers Netbeans I think its very great that the option is there, but I struggle to take it seriously when people "cant figure out Emacs"

10:41 cemerick: My liking NetBeans vs eclipse vs intellij has essentially nothing to do with the IDEs themselves.

10:42 doseq: I don't think it's that they couldn't figure it out, just that most of the population isn't masochistic enough to bother.

10:42 cemerick: I'm totally agnostic w.r.t. IDEs, build tools (despite what people think), and anything else that is auxiliary to what I'm actually trying to get done.

10:43 LauJensen: I'm completely with you on that cemerick

10:44 cemerick: LauJensen: Be more empathetic then. :-) Most people really, *really* don't care about their editor, so when presented with a huge opportunity cost for learning emacs, it's totally rational for 95% of all devs to walk away happily.

10:44 naeu: I like emacs - in general i like anything that's sufficiently challenging that the processes of mastering it teaches in abundance

10:44 doseq: I got a lot out of reading the UNIX creators' writing about cognitive engineering and their idea of how software tools should snap together thought-wise. Not saying UNIX ever really pulled that off totally, but it was/is a good idea.

10:45 * cemerick contemplates a strict non-engagement policy w.r.t. editors and build tools in #clojure

10:45 naeu: from that perspective I draw parallels between emacs and clojure

10:45 tomoj: is clojure missing a fold operator?

10:45 chouser: cemerick: good luck

10:45 hiredman: tomoj: seriously?

10:45 chouser: tomoj: 'reduce'?

10:45 tomoj: yes, but what about the other one

10:45 cemerick: chouser: I am zen. I am like the earth, trammeled yet immovable. ;-)

10:46 tomoj: it's chiral

10:46 esj: +1 for chiral.... nice word

10:46 cemerick: tomoj: reduce over an rseq?

10:47 tomoj: hmm

10:47 cemerick: I presume you're talking about foldRight, in scala terminology

10:47 tomoj: yes, one or the other

10:47 cemerick: or, er, foldLeft. I could never remember which is which.

10:47 tomoj: I can't figure out now which is which

10:47 cemerick: ha!

10:47 #scala FTW!

10:47 hiredman: clojurebot: foldl?

10:47 clojurebot: No entiendo

10:48 hiredman: clojurebot: fold?

10:48 clojurebot: fold2 is (defn fold2 [f1 acc1 f2 acc2 list] (if (nil? list) [acc1 acc2] (recur f1 (f1 (first list) acc1) f2 (f2 (first list) acc2) list)))

10:48 hiredman: clojurebot: very helpful

10:48 clojurebot: Pardon?

10:49 tcrayford: can't you just use reverse before a foldl?

10:49 seeing as you're walking the list anyway

10:50 tomoj: fold2 is broken

10:51 it should be this https://gist.github.com/1e0df667660e862d7a0c

10:51 webwanderer: hi, the repl says that it can't resolve 'rename'

10:52 are these library functions?

10:52 ,rename

10:52 clojurebot: java.lang.Exception: Unable to resolve symbol: rename in this context

10:52 tomoj: what would be better would be to have an easy way to define fold operators on sum types

10:52 hoeck: ,clojure.set/rename

10:52 clojurebot: #<set$rename__7548 clojure.set$rename__7548@1203412>

10:53 webwanderer: cool

10:55 LauJensen: cemerick: Sure they can walk away, and many do and thats fine. My point is simply, that in the context of learning a functional Lisp, please dont play the "I cant figure out Emacs" card. It seems like a distorted argument

10:57 cemerick: LauJensen: that's just shorthand for "It's not worth spending time on this."

10:57 doseq: I get the feeling this comes up a lot.

10:58 LauJensen: cemerick: How would you know, if you never learned? :)

10:58 chouser: LauJensen: conversely, I would ask again that you refrain from hobbling potential Clojure users with the impression they also must learn this other largely unrelated project, regardless of their size.

10:58 LauJensen: eh?

10:59 chouser: it's size

10:59 LauJensen: hobbling?

10:59 chouser: tripping them up

10:59 LauJensen: chouser: Like I said "walk away and thats fine" - I'm really the most happy when everybody is using what makes them most productive. For you its Vim, for cemerick its Netbeans, for me its Emacs - I have no preference on your behalf

10:59 underdev: stop breaking the knees of short people interested in clojure!

11:00 tomoj: does this mean we shouldn't talk about emacs?

11:00 cemerick: LauJensen: I've never learned objc, and I know it's not worth spending time on it. :-)

11:00 LauJensen: cemerick: Tell that to the many self-made millionaires using objc :)

11:00 cemerick: tomoj: I think it just means that, when talking to totally new potential clojure programmers, point at IDE plugins first.

11:01 underdev: #clojure #clojure-emacs #clojure-editor-war #clojure-build-systems #clojure-just-clojure-dammit

11:01 tomoj: ok, unless they happen to like emacs ? :)

11:01 cemerick: tomoj: or, in general, be context-sensitive/aware

11:01 right

11:01 doseq: cemerick: I wish wish wish I could convince myself that manual memory management was worth the effort. Surely iPhone garbage collection can't be that hard.

11:02 cemerick: doseq: ha! :-D

11:02 * cemerick descends into handball bliss

11:02 tomoj: does it not do garbage collection because it needs some time guarantee?

11:02 like GC causes unpredictable slowdown?

11:03 stuartsierra: tomoj: It's an older language, when GC was still suspect.

11:04 doseq: Well, they introduced it in Obj-C 2.0 for the Mac. Just not iPhone.

11:04 stuartsierra: huh, didn't know that

11:04 doseq: Yeah, it's an option now.

11:05 I spent about a month reading Apple's documentation and then my head exploded.

11:05 chouser: cemerick: rather than pointing toward IDE plugins, I'd suggest pointing toward whatever is closest to what they already like: IDE, emacs, vim, whatever.

11:05 doseq: Every single page requires about 5 other pages.

11:06 Are there any visual expression builders for Clojure already?

11:07 stuartsierra: doseq: paredit, sort of

11:07 I tried once: it's harder than it sounds

11:07 doseq: stuartsierra: building one you mean?

11:08 stuartsierra: yes

11:08 technomancy: stuartsierra: you pinged a few days ago?

11:08 (pang?)

11:08 stuartsierra: technomancy: Yeah, was talking to talios again about getting a release of swank-clojure into Maven central.

11:08 technomancy: oh, ok

11:09 I'm actually hoping to gather up what we've got into a 1.2.0 release

11:09 the break stuff is pretty major

11:09 doseq: I started one the other day using HTML form elements to represent nested expressions, I'm fiddling with it.

11:09 stuartsierra: technomancy: Cool, that would be an important first step.

11:09 doseq: that's what I tried

11:10 doseq: stuartsierra: cool, if you ever want to pick it back up you can collaborate with me if you want.

11:11 stuartsierra: doseq: sure, if I ever have time to go back to it... :)

11:11 doseq: stuartsierra: I'll let you know how I go.

11:11 npoektop: hey, guys, what time is now in Washington? I need Pacific time, but can't understand, it 8pm or 7pm

11:12 hiredman: neither

11:12 technomancy: stuartsierra: after that I'm wondering about handing off maintainership to hugod

11:12 npoektop: oops 8am or 7am

11:12 technomancy: he's much more qualified than I =)

11:12 npoektop: or 9ma

11:12 technomancy: npoektop: depends on whether you honor the monstrosity of daylight savings or not

11:13 stuartsierra: technomancy: ok, that's fine too. I'd like to get a repo set up for it somewhere, so whoever's maintaining it can sync to central.

11:13 technomancy: for those that do it's a little past 8am

11:13 npoektop: i'm not sure. they said 01:00pm to 02:00pm PT

11:13 technomancy: stuartsierra: can it sync from clojars?

11:14 * fogus cloning labrepl

11:15 stuartsierra: technomancy: Not as it exists now. A sync-able repo must be complete, self-contained, and contain only releases.

11:15 technomancy: gotcha

11:15 so they can't just skip SNAPSHOTS

11:15 stuartsierra: no, nor can you say "sync just project X from repo Y"

11:16 webwanderer: How do I set the repl to pprint by default?

11:16 stuartsierra: technomancy: But a repo is just a directory on a web server, so it would be possible to create a second repo on clojars, with some attention to management.

11:17 technomancy: sure; just not a lot of demand from within the community for such a thing

11:18 webwanderer: default pretty print.. anybody?

11:18 *default automatic

11:19 stuartsierra: technomancy: it's necessary if the clojure maven plugin wants to use swank-clojure as a dependency.

11:20 Or if we want to create Maven archetypes that set up the POM for a Clojure project with swank/contrib/etc. automatically.

11:20 technomancy: oh, not saying that's unimportant; just that users of clojars don't have a direct need for a releases-only repo

11:21 stuartsierra: Well, I'd become a user of clojars then...

11:21 indirectly...

11:22 But I think if anyone is going to publish a library they should make the extra effort to cut a release.

11:22 All these snapshots all over the place are a nuisance.

11:23 technomancy: definitely

11:23 * chouser loves sha1

11:23 stuartsierra: chouser: ugh

11:23 technomancy: but keeping them in the same repo has worked great for me so far

11:23 chouser: stuartsierra: :-)

11:24 stuartsierra: technomancy: oh, sure, that's fine by me. Until you want to sync them to the rest of the world.

11:24 technomancy: seems like it would be the job of the sync process to filter out the unwanted versions

11:24 I think that's pretty easy with couch replication

11:24 stuartsierra: Perhaps it should be, but it doesn't do that.

11:25 Maven sync is just rsync mirroring.

11:25 _ato: rsync --exclude '*-SNAPSHOT' :-P

11:25 stuartsierra: Don't blame me, I don't run it.

11:27 technomancy: I think it's a fine feature; it's just one of those many things that hasn't been implemented because nobody's needed it.

11:28 stuartsierra: We need it to build a bridge off the clojars island. :)

11:29 _ato: shouldn't be too hard to provide a "release-only" view the Clojars repo, if that's all that is required

11:29 isn't there some stuff about signing packages and such as well though?

11:30 stuartsierra: _ato: I don't think packages need be signed, but they must have license/author metadata, and they must have no dependencies not available in the Maven central repo.

11:30 In other words, packages in Maven central may only depend on other packages in central.

11:33 doseq: When the docs say host booleans are "boxed", does that mean they're objects instead of primitives?

11:34 lpetit: doseq: ye

11:34 s

11:34 technomancy: could just block snapshots from being downloaded when it sees the maven rsync user-agent. =)

11:34 _ato: hehe

11:35 doseq: lpetit: thx!

11:36 _ato: I wonder if anyone's already built a tool for validating whether something meets the maven central criteria

11:36 stuartsierra: technomancy: I don't think that would be sufficient: it's a manual application process.

11:36 _ato: :(

11:36 stuartsierra: And it still doesn't solve the self-contained dependencies problem.

11:38 _ato: The criteria are simple: 1) no snapshots, 2) accurate metadata, 3) no external repositories

11:38 _ato: "To improve the quality of the Central Maven repository, we require you to provide PGP signatures for all your artifacts (all files except checksums),"

11:38 http://maven.apache.org/guides/mini/guide-central-repository-upload.html

11:38 stuartsierra: ah, ok, but there's a plugin for that :)

11:39 talios knows more about this than I do

11:39 _ato: "This used to be the preferred process but we are no longer accepting rsync requests on a per project basis."

11:39 "Rsyncs will be provided for Forges that provide hosting services for OSS projects and other large project repositories that meet certain minimum criteria such as validation of PGP keys and pom contents as defined above. "

11:39 well I guess maybe Clojars counts as that

11:39 although it doesn't have PGP keys and validation

11:39 stuartsierra: Yes, and sonian hosts a free Maven repo for open-source projects.

11:41 _ato: hmmm there's 4 approved forges: Apache, Codehaus, Sonatype and Fusesource

11:42 technomancy: stuartsierra: are test dependencies outside maven central OK?

11:42 swank-clojure only has dev-dependencies

11:42 stuartsierra: technomancy: I don't think so

11:42 technomancy: ok, well the dev-deps don't make it to the pom currently anyway

11:42 stuartsierra: That should be fine then.

11:44 _ato: http://nexus.sonatype.org/oss-repository-hosting.html

11:44 "After the ticket is created, we will prepare repositories on http://oss.sonatype.org for you. We will update the ticket once it’s done. Normally it takes less than 2 working days."

11:44 stuartsierra: Yes, I meant sonatype, not sonian.

11:45 technomancy: having a dependency on clojure from swank-clojure is kind of redundant anyway

11:46 who's going to use swank-clojure without already having a dependency on clojure? =)

11:47 stuartsierra: right

11:47 And clojure releases 1.0 and 1.1 are in central already.

11:48 doseq: Is it legit to implement a multi-user app in clojure by giving all the users their own namespace?

11:48 stuartsierra: doseq: no

11:49 doseq: What would be the idiomatic approach to that?

11:49 stuartsierra: doseq: implement a security protocol :)

11:49 technomancy: doseq: it might be OK if the app were centered around running clojure code or something

11:49 where each user could have a sandbox

11:49 stuartsierra: namespaces are not isolated or protected from one another

11:50 technomancy: but in general that's not a great idea

11:50 _ato: heh, yeah just what I was thinking, if the app is a multi-user Clojure programming sandbox...

11:50 doseq: Yeah, it'd be a multi-user reader type situation where a web app intermediates the messages.

11:51 stuartsierra: Then if it's anything more than a toy you need isolation between users.

11:51 _ato: doseq: so a client/server model with accounts?

11:52 doseq: Oh I see, because if they knew there were other namespaces they could just run some commands to find out what they are... gotcha.

11:52 stuartsierra: yep

11:53 doseq: _ato: Yeah I'm just doing some thought experiments on ways to expose the reader via a multi-user web app.

11:54 hiredman: if reading is all you are doing you can just bind eval-reader or whatever to false

11:54 stuartsierra: (doc *read-eval*)

11:54 clojurebot: "; When set to logical false, the EvalReader (#=(...)) is disabled in the read/load in the thread-local binding. Example: (binding [*read-eval* false] (read-string \"#=(eval (def x 3))\")) Defaults to true"

11:54 hiredman: man, message queues are handy, everyone should have one

11:55 danlarkin: amen

11:55 hiredman: I can email someone this url, go take a nap, and when they click on the url a message goes in my queue which when delivered causes a siren.wav to play on my laptop and wake me up

11:56 doseq: hiredman: yeah it'd be a read-eval.

11:56 _ato: doseq: http://github.com/licenser/clj-sandbox/ may be relevant for you

11:57 you have to be pretty restrictive though

11:57 pjstadig: hiredman: what's the url?

11:57 stuartsierra: hiredman: There's gotta be potential for an app there.

11:57 pjstadig: :)

11:57 _ato: eg allowing java interop is basically a game-over

11:57 hiredman: stuartsierra: right

11:57 _ato: unless you whitelist it

11:57 hiredman: it totally is

11:57 danlarkin: yeah give us the url so we can wake you up :)

11:58 hiredman: can you imagine working on a project and the database guy is busy but will get your schema set up eventually

11:58 and you have a command you want to run once the schema is setup

11:58 technomancy: danlarkin: you still need to press two switches 8 feet apart and have three out of the five launch codes to do it.

11:58 hiredman: you give him a url to visit

11:58 danlarkin: damn!

11:59 hiredman: and 'block-on-remote-button 10 && do-stuff'

11:59 doseq: Thanks! clj-sandbox looks really interesting.

12:00 danlarkin: you've gotta believe we've tried to breed soldiers with an 8 foot armspan for just this reason

12:00 pjstadig: futuristic ninja robot soldiers?!?!

12:00 sweet!

12:00 hiredman: clojurebot: fururistic?

12:00 clojurebot: No entiendo

12:00 hiredman: clojurebot: futuristic?

12:00 clojurebot: Pardon?

12:01 rhickey: I just pushed some perf tweaks, should help in many areas

12:01 stuartsierra: rhickey: great!

12:01 * chouser pulls

12:02 rhickey: also, you'll now get reflection warnings on unhinted aget/aset/alength

12:02 pjstadig: clojurebot: mascot

12:02 clojurebot: the official mascot of clojure is a futuristic ninja robot

12:03 chouser: rhickey: count used to be inlined, but you backed it out May 29th. I'm trying to remember why.

12:04 rhickey: chouser: I think I was trying 2 things then, one was a specific overload for Counted

12:04 doseq: This link is so amazingly helpful: http://bc.tech.coop/blog/docs/clojure-docs.html

12:07 rhickey: chouser: this new thing, foo + fooFrom just helps HotSpot split off the fast path, as was done for seq

12:08 chouser: ok, that's interesting. I was about to ask what the value was, since the semantics appear to be unchanged.

12:09 or nearly. I didn't see how the null check first could be hurting anything.

12:46 doseq: Is there a way to disable Java interop?

12:48 defn: my guess is no

12:49 (class (str "abc")) => java.lang.String

12:49 ipostelnik: doseq, in what sense?

12:50 patrkris: is there a standard function to unzip a seq of n-dimensional vectors into a seq of n seqs?

12:50 doseq: ipostelnik: like, a Clojure-only mode where arbitrary Java access isn't allowed.

12:51 ipostelnik: doseq, most of clojure/core is still implemented in Java, though less so than 1.2

12:51 bsteuber: doseq: guess you have to block . and all .methods by hand

12:51 i.e. ehen reading input

12:51 when

12:51 doseq: I'm just thinking ahead to Clojure-in-Clojure, probably best not to develop any bad habits early.

12:59 defn: doseq: if you're worried about that sort of thing (and i personally wouldn't be), just dont use java interop forms

13:00 i dont think you need to protect yourself from it

13:01 doseq: Ok. It's also sort of an effort to delineate Clojure from Java, to figure out how possible it is to explain Clojure to people who know nothing about Java (and don't want to know). But thanks for that.

13:18 Crowb4r: part of clojure's poweer is it's access to JAVA

13:20 doseq: Agreed, but from a teaching point of view the fewer tangents and rabbit holes, the better.

13:25 metronome: clojure wouldn't make much sense without the interop though

13:26 doseq: But the goal is to evolve into a bootstrapped Clojure-in-Clojure scenario where the JVM isn't a requirement any more.

13:29 metronome: is it? that sounds cool but it will take a lot of work. I don't particularly like java but the JVM is incredible so it's a small sacrifice :)

13:30 dakrone: clojure-in-clojure allows for doing things like ClojureCLR with .NET interop much more easily

13:30 so if you didn't care for the JVM, you could use CLR

13:30 metronome: I'm still kinda new to the lisp world anyway, so I don't really know where clojure is going, was just my guess by having read the current codebase

13:32 liebke: doseq: even after cinc, Clojure will be a hosted language, with much of its functionality residing in the host platform, whether it's the JVM or the CLR.

13:40 dakrone: technomancy: did you get my pull request for leiningen?

13:41 technomancy: dakrone: yeah, I've been sick for a week or so =\

13:41 ztellman: does anyone know if protocols are supposed to support variadic arguments?

13:41 dakrone: technomancy: oh okay, I saw the flow of dev stop, wondered if you were traveling or whatnot

13:42 technomancy: that too

13:42 dakrone: technomancy: is there any easy way to add java arguments to the 'lein repl' task?

13:45 technomancy: also; hope you feel better soon :)

13:45 technomancy: JAVA_OPTS works for -Dfoo=bar type stuff I think.

13:45 thanks, I'm on the mend. =)

13:45 dakrone: okay

13:45 thanks

13:52 stuartsierra: With today's deftype patch, I get errors like "ClassCastException: <some deftype> cannot be cast to <another deftype>"

13:54 Where both deftypes have fields with the same names.

13:57 patrkris: is it best practice to always deref a ref to retrieve its value although it is callable as a function? That is, is it best practice to do (@a-ref :some-key), even though (a-ref :some-key) works?

13:57 stuartsierra: yes

13:58 Crowb4r: yes

13:58 stuartsierra: refs being callable is an implementation detail

13:59 patrkris: right, thanks

14:08 chouser: stuartsierra: what? that's not guaranteed?

14:08 stuartsierra: I can't find the source

14:08 And now it seems to have disappeared.

14:08 Nope, still there

14:09 chouser: callable vars doesn't fall out naturally from anything else -- that support seems to be hand-coded in Var.java

14:09 and I use that feature all over the place

14:10 stuartsierra: oh wait, I was talking about my deftype problem

14:10 chouser: oh, sorry.

14:10 oh, and you were talking about refs anyway, not vars

14:10 sheesh

14:11 sorry, I'll go back to not paying attention

14:13 stuartsierra: Something to do with using reify to implement ILookup

14:14 But I can't isolate it.

14:16 cemerick: chouser: re: IDE plugins, I totally agree, every recommendation should be context-dependent.

14:16 * cemerick continuing a 4-hour old conversation

14:16 chouser: cemerick: yay. :-)

14:21 stuartsierra: Found it!

14:23 rhickey: bug in latest deftype patch: http://paste.lisp.org/+235M

14:26 This happens in other situations too, this is just the simplest case I could find.

14:27 Something to do with binding of a reified ILookup at the call site, I think.

14:35 chouser: stantont: that's with latest master?

14:35 oops, that was supposed to be stuartsierra

14:35 this works fine for me on master at the moment

14:36 oh, scratch that. I'm seeing the exception.

14:44 brian__: noob question> why does does this work with def but not defn? (def counter (let [count (ref 0)] #(dosync (alter count inc))))

14:47 Chousuke: brian__: how are you defining it with defn?

14:47 brian__: sorry, i missed the []

14:47 it works, sorry

14:48 i gues my question ,then , is what is the difference?

14:50 Chousuke: nothing much

14:50 defn attaches some metadata and the fn actually has a real name instead of a generated one

14:50 brian__: why have two then?

14:50 ok

14:51 Chousuke: defn is syntactic sugar for defining functions

15:03 chouser: stuartsierra: I think I have a patch for your bug

15:03 stuartsierra: chouser: great!

15:07 chouser: ...but I've got a vague suspicion I'm doing it all wrong.

15:09 stuartsierra: oh

15:09 do you know what the cause is, at least?

15:10 chouser: actually, I think it is right. http://paste.lisp.org/display/97402#1

15:12 stuartsierra: I don't understand that code well enough to say.

15:12 chouser: If I understand correctly, the code in Compiler that generated ILookupThunk checked that it was being passed the right type.

15:13 and if not, returned its 'this' arg. The reify code that replaced it didn't do that, so I put it back in.

15:13 stuartsierra: ok, sounds reasonable

15:14 chouser: I assume that class comparison costs some performance, and maybe there's a faster way to do it, but this seems to give correct results and I think is in the right spirit.

15:14 stuartsierra: It's all at compilation time anyway, right?

15:14 chouser: no, that class equality check is on every lookup

15:15 stuartsierra: oh

15:15 that doesn't sound right

15:15 chouser: in the cache-hit case even, to see if it needs to fault out and find a correct LookupThunk

15:16 stuartsierra: but what do I know

15:16 chouser: I'm mostly concerned about the = there -- perhaps it should be .equals or 'identical?'

15:17 hm, I bet 'identical?' would be better.

15:18 stuartsierra: Do you know why reify was used for ILookup in the first place?

15:19 chouser: I would guess for simplicity -- replaced a couple dozen lines of ASM code with 2 lines of reify

15:19 ...which should have been 5 lines of reify. :-)

15:19 stuartsierra: ah

15:22 chouser: it's a bit unnerving how I reach back to experience with postscript and HP calculators to comprehend Compiler.java

15:23 stuartsierra: well, it's a stack language, after all

15:24 I've toyed with the idea of writing inline Java bytecode in Clojure.

15:39 chouser: ~seen rhickey

15:39 clojurebot: rhickey was last seen in #clojure, 211 minutes ago saying: chouser: this new thing, foo + fooFrom just helps HotSpot split off the fast path, as was done for seq

15:39 rhickey: chouser: I'm working on stuartsierra's bug

15:39 chouser: rhickey: you saw my patch?

15:39 rhickey: I did

15:40 chouser: ok

15:40 rhickey: thanks

15:40 * chouser gets back to work.

15:40 rhickey: did you try it?

15:40 chouser: my patch? yeah, seemed to work.

15:41 oh.

15:41 well, I only tried it on his test case. sorry.

15:42 patrkris: which thread pool does future use?

15:42 chouser: patrkris: the same as send-off

15:43 patrkris: chouser: thanks

15:43 stuartsierra: I thought send-off always created a new Thread

15:43 patrkris: stuartsierra: as I understand it, it uses an "expandable" thread pool

15:43 hiredman: it's a pool, so it may cache threads

15:43 stuartsierra: ah

15:43 chouser: clojure.lang.Agent/soloExecutor

15:44 which is a Executors.newCachedThreadPool

15:57 rhickey: stuartsierra: fix is up

15:57 stuartsierra: rhickey: awesome!

15:58 * chouser learns

15:59 rhickey: chouser: the problem with your patch is that the classname won't exist when AOTing. My patch grabs the class of this and has the reify close over it

15:59 chouser: yep, I see it.

15:59 rhickey: so, with your patch Clojure didn't build

16:00 chouser: I'm guessing I had some success when testing dynamically because old versions of the class sometimes existed

16:00 rhickey: the problem you ran into was one of the reasons I put this in the compiler in the first place, had forgotten about the issue

16:01 chouser: closing over the actual class value is a clever solution

16:01 clojurebot: -cp and CLASSPATH are mutually exclusive

16:01 rhickey: I didn't think of is the first time

16:01 of it

16:01 stuartsierra: rhickey: see, now if you were building Clojure with Maven, the snapshot JARs would already be in the repository and I wouldn't have to wait for Hudson ...

16:02 rhickey: stuartsierra: builds from my machine should be canonic?

16:02 stuartsierra: snapshots, yes

16:02 chouser: they used to be. :-)

16:02 rhickey: chouser: not really, only releases

16:02 * chouser carefully removes his dog from this fight.

16:03 rhickey: stuartsierra: I disagree, having the build server reproduce the build is a good quality step, I could have things not checked in

16:03 stuartsierra: true

16:04 chouser: do seqs cache their hash?

16:04 rhickey: it's there now

16:04 stuartsierra: ok

16:06 I found my copy of maven-ant-tasks.jar anyway :)

16:09 Thanks, now lazytest works again

16:09 Along with source directory watchers!

16:10 Still some bugs to work out, including the fact that generated test suites always get named "nil"

16:10 chouser: unit tests as a service?

16:10 stuartsierra: chouser: More like continuous integration. Change a file, tests get re-run.

16:10 chouser: interesting

16:11 stuartsierra: that came from Halloway's circumspec

16:12 later folks

16:32 wthidden: Is it possible to read a deftype object from a file?

16:33 chouser: no direct support for that currently, I think.

16:33 Chousuke: they have a literal syntax though.

16:33 technomancy: wthidden: if you define a pr-str method for it when you serialize it you could read it back in

16:33 chouser: well, you could read (Foo 1 2) or something

16:33 Chousuke: #:Foo{:k 1 :k2 2}

16:33 chouser: Chousuke: but that's not readable yet

16:33 Chousuke: no? :/

16:34 wthidden: Hmmm as I suspected.

16:34 Chousuke: how is it not readable if it

16:34 it's the literal

16:34 wthidden: the #: takes the reader for ride.

16:35 The reader looks as the ':' as a dispatch character and does not find it.

16:35 *at

16:36 chouser: right, the #:Foo{} output is not meant to be readable. At the very least it would have to be fully qualified

16:36 Chousuke: right.

16:37 wthidden: So i guess i switch back to struct for my task definitions.

16:37 chouser: structs aren't readable either, are they?

16:37 wthidden: yes they are, or at least for me :)

16:38 tcrayford: rhickey: have people told you about the emerging languages conf? http://emerginglangs.com/ The organisers are quite keen to have you on board.

16:38 wthidden: not sure what would happen if the struct definition was not loaded before hand however.

16:38 chouser: ,(class (struct (create-struct :a :b) 1 2))

16:38 clojurebot: clojure.lang.PersistentStructMap

16:39 chouser: ,(class (read-string (pr-str (struct (create-struct :a :b) 1 2))))

16:39 clojurebot: clojure.lang.PersistentArrayMap

16:39 chouser: wthidden: they're read as array-maps, not structs.

16:39 wthidden: ah.. but for my purposes good enough.

16:40 chouser: oh, well in that case you can have your datatypes print as regular maps too.

16:42 wthidden: ,(doc pr-str)

16:42 clojurebot: "([& xs]); pr to a string, returning it"

16:43 wthidden: chouser: thanks for the good tips.. need to check code in and get walking.

16:43 defn: hello all

16:47 patrkris: has there been any discussions on documentation formatting for docstrings? For example using something like markdown to document functions and what have you

16:48 chouser: patrkris: it has come up before.

16:50 patrkris: chouser: any initiatives?

16:50 chouser: patrkris: no, I don't think there's been any concensus on the direction to go

16:51 patrkris: ok - would be cool with something minimal that could help the reader

16:51 for example just having a convention of marking argument names or even the function name to make it stand out in the docstring

16:51 chouser: you're thinking of autodoc pages or something else?

16:52 patrkris: well the formatting could help make autodoc pages more readable

16:52 or at least the docstrings

16:54 I find sometimes, when writing or reading a doc string for a function, that the text becomes less readable and in some cases ambiguous when referring to function/macro/var names, because the docstring is just plain text

16:54 but maybe that's just me

16:54 chouser: well, it has come up before. :-)

16:54 patrkris: as you said, yes :)

16:55 technomancy: an elisp solution: http://www.emacswiki.org/emacs/CheckDoc

16:55 patrkris: will check it out

16:55 for now - see ya :)

17:14 rhickey: tcrayford: yes, I've accepted

17:16 tcrayford: I don't know why I'm not on the list yet

17:16 tcrayford: awesome then. Wish I could go

17:20 defn: http://gist.github.com/358134 <-how would you implement a read fn on top of this code? similar to the write, but perhaps use an atom as a queue?

17:32 Raynes: heh -- I must say your project description of sexpbot made me chuckle -- "a horrible design IRC bot written in clojure"

17:32 horribly designed*

17:33 Raynes: what's up with this wall-hack-method stuff? I've seen this in clojurebot and your bot now...

17:49 Raynes: defn: Well, I'm fairly certain that it is horribly designed.

17:49 defn: The wall-hack-method allows me to call a protected method. What exactly it does is none of my concern.

17:50 defn: It's a "first large project" sort of thing. So, I was never hopeful about the design stuff. :P

17:53 defn: Raynes: :)

17:54 I'd just like to implement a small subset of your bot's functionality -- I'm wading around trying to find out what I can use to accomplish what I need to do.

17:55 I'm looking to implement a basic reader which will parse lines for a channel, run a couple commands on the incoming line, and that's it.

18:00 Raynes: anyway, it's not so bad -- i like your multimethods :)

18:01 erikcw1: I've deceloped a little test app using lein/swank. I'm now trying to figure out how to package it. I created a jar with "lein uberjar" - but when I run java -jar my.jar I get Exception in thread "main" java.lang.NoClassDefFoundError: google-scraper/core - what am I missing?

18:01 Raynes: defn: :D

18:03 technomancy: erikcw1: you sure you're not running an old non-uber-jar you have left around?

18:04 erikcw1: technomancy: yup -- I did rm *.jar

18:04 defn: Raynes: oh and thanks for the walton plugin -- hopefully ill have some more progress on indentation and such

18:05 Raynes: defn: Yeah. I need to actually integrate it into the bot as well. So that people can be PMed with a few examples on request.

18:05 Just haven't gotten around to it yet.

18:06 technomancy: erikcw1: creating the uberjar also creates the regular one; be sure you're using *-standalone.jar

18:06 defn: Raynes: no worries -- i notice the cycle is sort of "omg features!" and then 2 weeks ago by with nothing

18:06 Raynes: the nature of the beast I guess

18:06 erikcw1: technomancy: yup -- using the *-standalone.jar

18:06 defn: 2 weeks go*

18:07 Raynes: Hehe.

18:07 technomancy: erikcw1: if the code is public you could report a bug on the leiningen mailing list

18:59 defn: must...add..syntax..highlighting..to...walton...

19:06 technomancy: any chance we could get the patch on ticket #246 applied?

19:54 rhickey: technomancy: pushed

19:54 technomancy: rhickey: great; thanks!

19:55 rhickey: np

19:55 you've been very patient

20:41 defn: it's moments like this that make me proud to be in this community

20:42 lancepantz: what happened?

20:43 defn: just seeing technomany toss out "any chance we could?...", and to have the creator of the language say "all done, you've been very patient" -- it's just nice to see the give and take

20:44 chessguy: i think i'm gonna cry....

20:44 defn: lol chessguy

20:45 a guy who plays chess crying...

20:45 anyway i didn't mean to make a huge deal out of it, i just find that sort of communication and consideration to be very important

20:46 </rant>

20:46 chessguy: i.....i love you, defn!

20:46 *giggle*

20:50 kwertii: anyone know whether Las3r (Clojure -> Flash/SWF compiler) is still alive? Cool idea, but no commits since last May.. :/

20:52 dysinger: I'm still looking for clojure help... team of 7 currently - looking for one more.

20:52 aedon: aloha

20:53 :)

20:53 chessguy: dysinger, what kind of project?

20:53 dysinger: document archiving, search, discovery & BI backend - multi-node cluster - all clojure

20:54 all cloud

20:54 trillions of docs

20:54 blah blah blah

20:54 chessguy: a startup?

20:54 dysinger: 3 years ago

20:54 kwertii: dysinger: are you looking for contractors or full time?

20:54 dysinger: both

20:56 kwertii: dysinger: I wrote an OpenCalais/RDF database based semantic parser/search engine for blog feeds. is that something like what you're up to?

20:58 chessguy: > ({})

20:59 clojurebot, ({})

21:05 _ato: ,({})

21:05 * dnolen deftype and protocol performance is blowing his mind

21:09 chessguy: anybody using eclipse + counterclockwise? what's a faster way to stop the repl, and reload it with the changes to the source?

21:16 dnolen: chessguy: have you tried (load "your-lib") at the REPL ?

21:26 chessguy: man, i am totally not getting the 'interactive' part of this interactive language

21:27 scottj: chessguy: if you've only changed one expression, there's a keystroke to eval that. if you've just changed one file, there's a keystroke to reload that file. They're probably in the menu

21:28 lancepantz: you don't have to use it

21:29 chessguy: ok, i have one file, the only line says: (def me {:first-name "andrew"})

21:29 i "run as clojure repl" and eval "(me)"

21:29 lancepantz: i didn't see the need for it at first, then when i started doing more complex stuff i got it

21:29 chessguy: and it tells me it can't resolve "me"

21:30 (and no, i'm not typing the quotes around (me)

21:32 scottj: chessguy: right clicking in your file pane and select clojure > load clojure file in repl

21:33 chessguy: hm, that works bette

21:33 r

21:33 lancepantz: or you can (load-file x)

21:33 chessguy: but i still get: Wrong number of args passed to: PersistentArrayMap (repl-1:2)

21:34 scottj: me is a map and you're trying to call it as a function

21:34 you want to eval "me". "(me)" tells clojure me is a function

21:35 chessguy: aha

21:35 duh

21:35 scottj: of course maps can be used as functions, but you have to give them an arg. so you could call (me :first-name)

21:36 there's probably a way for eclipse to start a repl for a project and have it load your files, but I don't know (I use emacs)

21:42 chessguy: hm. i'm still screwing something up. now every time i go to load the file into the REPL it's erroring out because the definitions already exist

21:44 hiredman: chessguy: you are trying to def in the wrong namespace

21:44 chessguy: i'm not declaring a namespace

21:45 hiredman: if you def X in the namespace b and use b in namespace a

21:45 then try to go and def X in a you get that error

21:49 chessguy: aha, problem was i was using something that was already defined in the core

21:57 ok, i think i'm finally able to get around. just in time to go to bed...

22:12 dakrone: defn: ping

22:16 TheBusby: So what's the convention for dealing with multi-word project names and leiningen? I'm running into problems doing "lein new my-project"

22:20 dakrone: TheBusby: what do you mean? lein new my-project works fine for me

22:21 defn: dakrone: pong

22:21 TheBusby: when I go in the project.clj and add "main my-project.core", and then modify src/my_project/core.clj to have gen-class and a (defn -main...) the standalone uberjar fails with ClassNotFoundException

22:21 dakrone: defn: just wanted to let you know the link on your blog post seems to be going to the wrong place

22:22 defn: dakrone: thanks for the heads up

22:22 fixing now

22:22 dakrone: defn: no problem, looks like a neat tool

22:22 TheBusby: wondering if ":main my-project.core", should read ":main my_project.core" instead...

22:22 dakrone: might want to run it through a (distinct ...) before displaying it though

22:23 defn: dakrone: fixed

22:23 dakrone: I noticed a lot of repeats

22:25 defn: dakrone: yeah that's on the list

22:25 gonna turn the results into a sorted-set

22:25 that oughta clean things up a bit

22:26 TheBusby: dakrone: seems like my-project works fine until you try and execute the uberjar, and then I think the different between "my-project" and "my_project" leaves java unable to execute -main

22:27 defn: TheBusby: i think your project.clj should be the '-', and your directory/files should use the underscore

22:27 TheBusby: defn: that's the way it does it by default, and it doesn't work

22:29 dakrone: TheBusby: trying it...

22:30 TheBusby: evidently "lein new my_project" works fine, but then you have (ns my_project.core (:gen-class)) which doesn't seem very clojury

22:31 dakrone: TheBusby: got it

22:31 :main my_project.core

22:32 in src/my_project/core.clj I have (ns my-project.core (:genclass))

22:32 and then the (defn -main ...)

22:32 and it works now

22:34 TheBusby: checking now

22:34 when I do that I get an error during "lein compile" where it says "my_project.core" not found after loading '/my_project/core'

22:35 when I do "lein version" I get "Leiningen 1.1.0 on Java 1.6.0_17 Java HotSpot(TM) 64-Bit Server VM"

22:35 dakrone: what does your directory structure look like?

22:35 and can you paste all of your project.clj and the (ns ...) part from your clj file?

22:35 TheBusby: ~/my-project/project.clj and ~/my-project/src/my_project/core.clj

22:36 (defproject my-project "1.0.0-SNAPSHOT"

22:36 :description "FIXME: write"

22:36 :dependencies [[org.clojure/clojure "1.1.0"]

22:36 [org.clojure/clojure-contrib "1.1.0"]]

22:36 whoops, sorry

22:36 http://pastie.org/906835

22:37 http://pastie.org/906838 for core.clj

22:39 * dakrone boggles

22:39 dakrone: this is really really weird

22:39 TheBusby: what version of lein are you using?

22:40 dakrone: I can build the uberjar *sometimes*

22:40 1.1.0

22:40 TheBusby: sometimes?

22:40 dakrone: make a change to project.clj -> won't build, undo it -> won't build, make same change -> builds

22:41 TheBusby: doing "lein clean" between attempts?

22:41 dakrone: no, most likely the culprit

22:43 very strange

22:44 TheBusby: still getting inconsistent results?

22:44 dakrone: sort of

22:44 not having any luck

22:45 alright.

22:45 :main my_project.core

22:46 (ns my_project.core (:gen-class))

22:46 rm -rf classes lib *.jar

22:46 that worked for me

22:46 if you want I can post all the files

22:47 TheBusby: I get "lein new my_project" to work earlier

22:47 er, I got

22:47 but then you end up with the non-clojury ns name. Guess I should just file a bug?

22:47 dakrone: yea, it seems like using - means use _ everywhere except for the project name

22:49 or, you could keep - in the project name and remove it from the source directory structure

22:49 TheBusby: does that work okay for non-*nix environments?

22:50 dakrone: which one? using _ or not having any -'s?

22:50 your project could be named "my-project" and have src/myproject/core.clj

22:50 TheBusby: that works?

22:50 dakrone: you have the change the :main name

22:51 the :main would be :main myproject.core and in core.clj the ns would be (ns myproject.core (:gen-class))

22:54 TheBusby: anyway, I'm out for a bit, good luck!

22:55 TheBusby: dakrone: thanks for your help!

23:32 technomancy: TheBusby: confirmed there's a bug with the uberjar manifest

23:32 it sure would help if Clojure exposed its own functions for converting between filenames and namespaces. =(

23:33 TheBusby: technomancy: I posted an "issue" to your github repo earlier with a repro plan

23:34 in the meantime though I just modified leiningen/jar.clj to do " (str "Main-Class: " (apply str (replace {\- \_} (str main)))) "

23:35 I doubt that's correct solution, but it's just what I'm using now...

23:35 I'm assuming the "my-project" to "my_project" conversion was necessary

23:45 technomancy: yeah, that's close enough

Logging service provided by n01se.net