#clojure log - Apr 17 2009

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

0:24 pjb3: I posted this little snippet of Haskell on Twitter earlier:

0:24 takeWhile (< 5) (foldr (:) [] [1..])

0:25 Something sort of equivalent in Clojure is:

0:25 (take-while #(< % 5) (reduce conj [] (iterate inc 1)))

0:25 But the problem is the Clojure one doesn't work

0:26 The reason is that reduce does not produce a lazy sequence

0:26 In Haskell, foldr is lazy, so it works

0:26 durka42: wait, is #(reduce conj %) a nop?

0:28 pjb3: Well, in this case it doesn't really do anything except realize the lazy sequence

0:28 ,(take-while #(< % 5) (iterate inc 1))

0:28 clojurebot: (1 2 3 4)

0:29 hiredman: I just fail to understand how reduce can be lazy

0:29 pjb3: ,(take-while #(< % 5) (map (fn [x] x) (iterate inc 1)))

0:29 clojurebot: (1 2 3 4)

0:30 pjb3: hiredman: It ends up being lazy in Haskell because function application and sequences are lazy

0:31 devinus: Does anybody use any specific Java -switches to increase the performance of Clojure?

0:31 pjb3: I think Clojure's reduce is actually like Haskell's foldl, which isn't lazy even in Haskell

0:31 * pjb3 goes to check that out

0:32 hiredman: pjb3: but, I mean, if the reduce is done at all, should it all get done, and it all is a infinite list, does not compute

0:32 devinus: -server

0:33 devinus: hiredman: does -server imply 64-bit, or should i use -d64 ?

0:35 hiredman: java ships with two jvms

0:35 -server enables hotspot, which is the ony with all the JIT goodies

0:44 pjb3: Here's an implementation of foldr in Clojure: http://gist.github.com/96861

0:46 So if you try to evaluate

0:46 hiredman: I just don't see how an operation that uses an accumulator can be lazy

0:47 pjb3: (foldr cons '() (range 1 3))

0:47 At some point in the evaluation it looks like this:

0:47 (cons 1 (cons 2 (foldr cons '() '(3))))

0:47 hiredman: hmmmm

0:47 pjb3: But eventually for it to finish, it has to continue the recursive calls

0:48 and boil it down to (1 2 3)

0:48 What happens in Haskell is that the expression evaluation is lazy

0:48 so if nothing ever asks it to evaluate the expressions

0:49 it can stop at:

0:49 (cons 1 (cons 2 (foldr cons '() '(3))))

0:49 If for example

0:49 it is called like

0:49 (take-while #(< % 2) (cons 1 (cons 2 (foldr cons '() '(3)))))

0:50 So anyway, that's how

0:50 takeWhile (< 5) (foldr (:) [] [1..])

0:50 hiredman: ok

0:50 pjb3: in Haskell works

0:50 hiredman: interesting

0:51 pjb3: It's pretty interesting, with all expression evaluation being lazy what you can do

3:16 AWizzArd: Moin moin

3:20 cgrand: Hi AWizzArd!

3:48 bOR_: does any vimclojuran recognize this error?

3:48 /hosts/linuxhome/falcon/boris2/programs/src/vimclojure-2.1.0/build.xml:104: The <jar> type doesn't support the nested "path" element.

3:48 kotarak: You ant is to old.

3:48 Your ant...

3:48 bOR_: ah. will install a new ant then.

3:49 thanks :)

3:49 kotarak: np

3:54 bOR_: Apache Ant version 1.6.5 compiled on January 6 2007

3:55 kotarak: bOR_: Apache Ant version 1.7.0 compiled on August 25 2008

3:55 bOR_: hmm. that is the ant version in the (latest) binary 1.7.1 ant package.

3:56 I'll install the source ant.

3:56 nod.

4:20 kotarak - downloading ant 1.7.1, both binary or source, gives me an ant that reports version 1.6.5

4:21 hmpf. I'll look on the net if I can find anything about that.

4:21 kotarak: bOR_: Then check which ant is actually invoked.

4:21 Maybe some PATH issue.

4:22 bOR_: seems logical, and I've made that error before.

4:22 boris:falcon:~/.local/bin:cp ant ant2

4:22 boris:falcon:~/.local/bin:ant2 -version

4:22 Apache Ant version 1.6.5 compiled on January 6 2007

4:22 I might just need a coffee and the problem will be solved :)

4:23 kotarak: Hmmm... ./ant probably gives the same. (Considering the very absurd case, that there is also an ant2 on your system. ;) )

4:24 Just try the version. Maybe it works although it reports a wrong version?

4:24 bOR_: good one.

4:24 nope, genuine error.

4:25 kotarak: hrmpf

4:25 bOR_: might ask our sysadmin to look into it.

4:25 it worked nicely on ubuntu, but here we are running a different flavor.

4:25 maybe he can just update the ant :). delegate the problem.

4:26 http://ant.apache.org/faq.html#RedHat_ES_3

4:26 that might be the answer.

4:26 kotarak: Hmm.. Check where your ANT_HOME env var points to.

4:26 bOR_: we're running centos, which I think is derived from redhat

4:27 sysadmin time. I don't have su here

4:30 * Raynes screams his bordem from the highest mountains.

6:22 cemerick: I guess I never internalized that PersistentQueue existed. Lovely little thing, it is.

6:27 rhickey: cemerick: I keep needing to get around to putting some wrappers in the library for it

6:28 cemerick: yeah, it's quite the gem, IMO. I spent about 10 minute figuring out how/whether I'd implement a clojure-y queue, when I had the stroke of genius to *search the internet*! :-)

6:31 rhickey: what would you think of a patch that would add "prefix-rest" destructuring? i.e. (let [[prefix > a b c] [1 2 3 4 5 6]] [prefix a b c]) => [[1 2 3] 4 5 6]

6:33 rhickey: cemerick: sounds really special purpose - I can't think of a single time I've desired that

6:35 cemerick: I bump into situations where it'd be handy every now and then...I generally just rearrange the order of the args to the fn.

6:35 rhickey: one issue I have with exposing persistent queue is that I also want to provide wrappers for other queues - java.util, JMS et al, so how to best name them?

6:35 cemerick: That obviously works, but often the arg order then doesn't entirely make sense given the fn's purpose.

6:38 rhickey: why do you want to provide wrapper for queues from java-land? There's a *lot* of list/vector impls in java-land, with no wrappers in clojure.

6:45 rhickey: cemerick: because stateful queues are an important part of workflow, Clojure doesn't provide them natively, people that don't know Java don't know they are there, there are opportunities to add value in abstracting away some differences and standardizing e.g. timeouts, they will form the basis of any distributed story for Clojure...

6:47 cemerick: rhickey: fair enough. Wrappers are a tough business though, leaky abstractions and all. I guess where there's muck, there's brass, and all that.

6:50 FWIW, I'd like to consider c.l.PQ to be the "primary" queue impl -- it likely suits a majority of use cases, and is far less environment-dependent than other queue impls (JMS, j.u.concurrent queues, etc).

6:51 (especially in terracotta :-D)

7:40 hrm, one cannot use set! to change *print-length* and such anymore?

7:47 rhickey: cemerick: I consider c.l.PQ to be an entirely different beast than stateful blocking queues and would rarely consider one useful where the other is

7:50 cemerick: rhickey: sure, so would I. I was only saying that a POQ (plain ol' queue) is generally required in more situations than anything else.

7:52 rhickey: cemerick: depends on what you are doing. I find queues as I/O more frequently used than queues as data structure

7:53 anyway, it's not either/or, but given the need for both, names are an issue

7:57 aperotte: hello everyone! I'm working on a data structure for clojure and wanted to know if anyone (rhickey in particular) had any input. It's an n-dimensional array in some ways similar to python's ndarray.

7:57 Raynes: "What is a good starter language for a 10 year old? I want to teach my 10 year old daughter to program." "Assembly."

7:57 cemerick: yeah...my comments were mostly made assuming there will be a 'queue' fn, with the only question being, what does it produce? I think making it so that it produces a LBQ or somesuch would be unfortunate. Clojure's impl of persistent data structures and their 'first class' status is arguably its best feature.

7:58 gregh: I learned assembly when I was 10, but it was a lot more fun on the apple ][ than it would be now

8:00 rhickey: cemerick: I don't disagree, but if queue returns a c.l.PQ, then what lingo should we use for I/O queues? - channel?

8:01 aperotte: are you trying to make a persistent data structure?

8:02 aperotte: rhickey: yes

8:03 cemerick: rhickey: well, if you're making wrappers that interoperate with peek, pop, etc, then I'd be happy enough to see them go into clojure.core.queues/linked-blocking-queue, etc. Then if you really want to be fancy about it, you could exclude clojure.core.queue and use the linked-blocking-queue :renamed to queue.

8:03 aperotte: rhickey: I wish there were a way to make java arrays immutable though

8:03 rhickey: aperotte: me too

8:05 cemerick: the semantics of stateful blocking queues and persistent queues are totally different, despite any apparent similarities

8:06 thus, I think only one should get the name queue

8:06 cemerick: indeed. I just didn't know how far you wanted to try to paper over the differences.

8:08 aperotte: rhickey: as it stands I'm implementing most of the interfaces of the other data structures (PersistentVector in particular).

8:08 cemerick: IMO, there are far too many possible (and actual) queue impls for various concurrency use-cases to do anything other than be very specific about each wrapper you want to have. Blessing just one of them doesn't seem right.

8:14 rhickey: cemerick: I'll be happy to prove you wrong about that. It's not a matter of blessing an impl (e.g. from a factory/ctor perspective), but rather one of defining some simple protocol that can be widely supported, thus making it easy to write impl-ignorant code. This in line with the Clojure model elsewhere. If someone wants to fully leverage something specific they can always do so explicitly

8:15 cemerick: rhickey: oh, so you're looking to fashion a corollary to seqs for queues?

8:15 rhickey: yes, io-queues are one area where I think it would be valid to unify the local and distributed models, as they are substantially similar

8:16 asynchrony, blocking, remote failure, timeouts etc

8:18 I've done some thinking about it, and would like to try at some point to at least see how much can be factored out of j.u.c.BlockingQueue and JMS queues

8:19 I consider such queues an essential architectural element in most systems

8:21 cemerick: In that case, I retract all of my previous statements :-)

8:21 rhickey: When I see people polling on refs I realize that they need more support here, and I'm afraid if I only give them c.l.PQ they'll do even more of that

8:21 cemerick: I think I was thrown off by the 'wrapper' term.

8:22 rhickey: well, see, I underestimated your ambition. I figured once 1.0 was out the door, you were just going to sit around, hang out on the channel, and argue with people on proggit ;-)

8:23 rhickey: :)

8:25 cemerick: understand that even though clojure has advanced so much, so quickly, old habits die hard w.r.t. expecting languages/frameworks to idle. Not many people keep reaching.

8:27 rhickey: I have so many things I want to do, I think now I just need 1.0 so I can do them without pissing anyone off with Clojure's "rapid change"

8:27 cemerick: do you still have a long-term todo floating around?

8:29 * Raynes can't wait for 1.0

8:29 Raynes: I'm going to put it in a flash drive and mount it on my wall.

8:29 rhickey: cemerick: I do, but it's not a fixed roadmap. I made it non-public as I wanted to move it to issues, now I think issues shouldn't have wishlist items, so I may re-expose

8:29 * Holcxjo can -- better get it right and complete-ish instead of having to cope with backward compatibility problems later...

8:30 rhickey: Raynes: I don't see a lot of people clamoring for 1.0 in the gg thread, just requests for more stuff...

8:30 cemerick: yeah, the issue tracker is a little too concrete for such things

8:31 Raynes: rhickey: It's just a huge milestone for Clojure, I'm in no hurry to slow down the rapid change, I just love the numbers one and zero.

8:32 rhickey: Holcxjo: There's a tradeoff, in that it will limit the Clojure user base to those willing to contend with trunk for an extended period. Obviously there's more work to do, and probably a (very) few breaking changes still to come, but if people expect things not to change they can just stick with a version indefinitely

8:36 cemerick: rhickey: indeed, I've not seen anyone volunteer to "backport" fixes and such.

8:37 Holcxjo: rhickey: The problem is people sticking with an old version and developers then having to write sw that works with that old version -- not being able to use newer features...

8:37 rhickey: I'd very much like Stuart's book to correspond to a release of Clojure - we both worked pretty hard on our ends of that, and it would be huge for newcomers

8:37 cemerick: I continue to be skeptical of the 1.0 "process". Those who want it likely aren't going to help maintain it.

8:38 Holcxjo: You don't want to know how long I had to write sw to Python 1.4 standards... :-/

8:38 cemerick: 1.4? ouch.

8:39 rhickey: One difference with Clojure is that it is 99% library, with very fine granularity. It's not like syntax changes in other langs

8:39 Holcxjo: Once it's out there it'll live and live and live...

8:40 Raynes: rhickey: *cough*scala*cough*

8:41 cemerick: Holcxjo: some shops are still on java 1.1.7, and they like it that way. I'd love to see clojure 1.0 being used similarly by the same sorts of people 10 years from now. :-)

8:43 rhickey: if no one produces bugfix patches for 1.0 then there won't be a 1.0.1, it's that simple. Doesn't completely negate the value of 1.0, but means that people that want fixes only get them with enhancements/changes in trunk

8:44 * Raynes will follow the trunk because that's how I roll.

8:44 cemerick: rhickey: maybe those that are using clojure in some production capacity could pool their resources to support a guy (or half or quarter of one) that is responsible for the patching.

8:45 We're certainly not there yet, but I'd be willing to underwrite that kind of effort.

8:45 * rhickey still wonders how to underwrite Clojure itself

8:46 cemerick: well, presumably someone will make it big using clojure, then hire you (or something). That seems to be the general arc of such things.

9:02 cgrand: Hi! About c.l.PersistentQueue, should I be worried about it being used in c.l.Agent? I mean, it seems that it can keep references on actions after they are executed.

9:04 rhickey: cgrand: it can, but not doing so is not guaranteed. Is this causing an actual problem?

9:07 cgrand: I thought about it two months ago and wondered whether it could be correlated to my widefinde2 code being a memory hog... but I never tested this hypothesis

9:08 cemerick: speaking of agents, this is the third time I've seen this talked about (two other times in the channel): http://groups.google.com/group/clojure/browse_frm/thread/409054e3542adc1f?hl=en

9:12 kotarak: Has anyone hashdot running with Clojure on OS X?

9:13 rhickey: cemerick: no one replied if shutdown-agents was sufficient or not

9:13 kotarak: rhickey: he calls shutdown-agents in his exit function, no?

9:15 cemerick: Indeed, and I think he's saying in msg #4 that the behaviour I predicted does happen interactively, but not when the thing is init'ed by cron (which I don't have any theories about).

9:15 rhickey: kotarak: I didn't see enough info to further pursue it - e.g. are his agents still active?

9:15 cemerick: modulo the cron bit, the other two cases I helped with in the channel saw the same behaviour.

9:16 but then, like I said, I don't use agents, so I'm mostly speculating based on looking at the docs around the default threadpool impls.

9:18 powr-toc: Is there an easy way to determine dependencies between functions, for refactoring? I have about 2 dozen functions, many of which have been superceeded... Is the best thing to interactively evaluate and run them and see where they break?

9:18 clojurebot: functions are maps

9:18 powr-toc: I think I need to move to use the test suite in contrib...

9:28 aperotte: rhickey: I'm nearing the point where I can share what I have, but I wanted to make sure you don't have any more suggestions re: an ndarray/matrix datatype

9:30 kotarak: Is anyone using hashdot with Clojure on OS X?

9:31 rhickey: aperotte: probably easier for me to give feedback on what you've got

9:33 aperotte: rhickey: would you prefer to wait until I think it's more shareable, or would you rather see it now

9:34 rhickey: aperotte: up to you, I wasn't thinkisg about it until you mentioned your work, so I don't have any ideas at the moment

9:35 aperotte: rhickey: ok, I'll come back with a link to what I've done in a few days

9:35 rhickey: great

9:41 powr-toc: kotarak: no, not seen it before... looks usefull... is it?

9:42 kotarak: powr-toc: Don't know. I can't compile it with the standard VM and with soylatte it shouts errors at me when I try to run it.

9:42 powr-toc: That's why I asked..

9:48 powr-toc: kotarak: is it implemented in pure Java or something else?

9:48 kotarak: powr-toc: It has a C part as it seems.

9:48 Doing stuff with JNI.

9:51 -.-

9:52 powr-toc: I have it running. Compiled with soylatte, but running with stock VM.... But it works and seems a way to start scripts while doing some configuration...

9:55 powr-toc: neat

10:01 Chouser_: I don't see a whole lot of people contributing patches for Issues that they haven't run into themselves.

10:02 rhickey: Chouser: nope

10:02 Chouser_: I wonder if that suggests anything about how hard it may be to get backport patches from anyone once there's a 1.0 branch.

10:03 cconstantine: I think it does

10:04 Chouser_: personally, the thought or watching trunk patches going in, trying to spot which are non-breaking-change no-new-feature low-risk (etc.) bug fixes vs. not, and creating an backport issue for each just sounds like work.

10:04 like a Job

10:04 cconstantine: Sounds like more fun than the code I'm working with now... but yea

10:05 hiredman: wait

10:05 Chouser_: though I suppose if someone shows up in IRC saying "I'm using 1.0 and foo breaks", and foo has been fixed in trunk, I might be motivated to spin a backport patch right then.

10:05 rhickey: At this point I see it as a way I can keep innovating in trunk without hindrance. If people don't want to contend with change, they can look into the 1.0 branch, if they want fixes there, they can submit patches. I don't want to apologize for improving Clojure, or have Clojure be perceived negatively because it is "changing"

10:05 hiredman: I've got it

10:06 have all the svn commits listed on a webpage where people can tag them as "fix" or "breaking change"

10:06 crowd source it out

10:07 cconstantine: eep, that''d be terrifying if I had to rely on clojure to make a living

10:07 hiredman: :P

10:07 cconstantine: make it web 2.0?

10:07 Chousuke: :P

10:07 that'd require keeping commits small though.

10:07 cconstantine: I like the idea of just using the release number to encode what kind of differences there are between release

10:08 I think someone else recommended an x.y.z... z is bugfixes, y is new features, x is breaking changes

10:08 Chouser_: I think rhickey's perspective is good for now. Branch 1.0, then keep moving on trunk, while being open to accepting backport patches for 1.0

10:09 then what happens, happens. Clojure's done quite well so far not over-planning process or community details.

10:09 cconstantine: true

10:09 hiredman: ~map

10:09 clojurebot: map is *LAZY*

10:09 Chouser_: I think it's likely that some set of people will start using 1.0 (perhaps people not currently using Clojure)

10:09 they will find bugs

10:10 they may submit patches for those bugs, either by backporting existing trunk patches, or just plain fixing them.

10:10 why should anyone not using 1.0 work on keeping it fixed up?

10:11 cconstantine: Chouser_: because there are new features that are irresistible.

10:11 danlarkin: Chouser_: because it's the Right Thing To Do(TM(TM)

10:11 cconstantine: I see future new compelling features as the biggest threat to 1.0; if 1.x is better enough no bug fixes will move back to 1.0 forcing everyone to upgrade out of 1.0

10:12 danlarkin: cconstantine: I mostly agree

10:13 cconstantine: thats the reason I'm on trunk of svn

10:13 my usage of clojure is mostly educational/recreational though. I'm not doing anything *really* important with it yet

10:13 Chouser_: but if everyone moves to trunk or 1.x because of new features (which aren't even on the table for 1.0.x), then isn't that even more reason that nobody should waste their time backporting fixes to 1.0?

10:14 cconstantine: yes

10:14 I think you just restated the problem

10:14 Chouser_: oh

10:15 it doesn't sound like a problem to me

10:15 danlarkin: I look at it from this perspective: If I were to try to convince my boss to let us use clojure for work projects and I recommended to the team that we start off with 1.0, except there won't be any bugfixes unless we write them up with patches, they would question my sanity

10:15 Chouser_: hm, we should have a matching branch of contrib.

10:15 cconstantine: without backported fixes people who do find problems with 1.0 will be forced to upgrade; perhaps past a non-backwards-compatible change

10:15 danlarkin: exactly

10:16 Chouser_: danlarkin: who would you *want* to be responsible for writing those patches, that would satisfy your team?

10:16 cconstantine: The "Clojure development team"

10:16 rhickey: oh, them

10:16 * Chouser_ drafts cconstantine's group into the Clojure development team

10:17 cconstantine: The 'Them'

10:17 danlarkin: well other projects assign a release manager for each release (not saying that's the only way)

10:17 cconstantine: right

10:17 danlarkin: so in essence, someone would have to volunteer for clojure to follow the release-manager model

10:18 cconstantine: If there aren't any compelling new features for the language in the pipeline maybe it is time for a 1.0 *shrug* I don't know what is in development

10:18 danlarkin: having never participated in an open source project, my experience tells me yes

10:19 rhickey: cconstantine: abstractions over queues, streams, scopes, clojure-in-clojure, improved modularity, easier porting, a new "make" construct, more targets, improved numerics...

10:19 Chouser_: well, if anyone wants to hire to me backport trunk patches to 1.0, drop me a line.

10:20 cconstantine: rhickey: what kind of timeframe on that, and how reasonable would it be to have them be released in chunks?

10:21 danlarkin: heh well that's just it... if none of us have any interest in maintaining a 1.0, what is the point of releasing it?

10:21 rhickey: Chouser_: yes, Clojure development sponsors welcome

10:21 Chouser_: heh. I bet.

10:22 cconstantine: Clojure; sponsored by Dr. Pepper!

10:23 I think things like backports won't happen until there is a need for bugfixes without major upgrades

10:23 that won't happen until people make a living off it, which won't happen until there are known stable releases and few breaking changes

10:23 digash: I am trying to push Clojure in the enterprise and 1.0 will make it easier for me to make my case.

10:23 cconstantine: this sounds like a chicken-egg problem

10:23 digash: 2.0 and 3.0 will make it even more easier.

10:24 vegai: why not go to 4.0 straight away :)

10:24 danlarkin: but it's all so arbitrary :(

10:24 cconstantine: MS model? not really stable until 3.0?

10:24 digash: yes, you got it.

10:24 vegai: Clojure Vista

10:24 cconstantine: 'normal people' pay attention to the numbers way too much

10:24 Chouser_: maybe not a chicken-egg problem. a 1.0 branch can be created today

10:24 cconstantine: true, though this goes back to the problem of 1.0 not meaning much if there are no backported bug fixes

10:25 rhickey: Chouser_: exactly, and people for whom it is important will have to step up after that

10:25 Chousuke: is there symbol/keywords validation yet? :P

10:25 Chouser_: some selfless souls may backport some fixes. maybe that would be enough to create an impression of stability to get kind of users who need that

10:25 danlarkin: cconstantine: exactly

10:25 * cconstantine wonders who many backports are enough... 1? 2? many?

10:26 rhickey: or maybe I just need to thrash around in trunk to force people to care about the stable branch :)

10:26 Chouser_: there you go

10:26 cconstantine: is it reasonable to tell early adopters of 1.0 that they may need to do their own backporting for now?

10:26 Chousuke: heh

10:26 kotarak: Is there a way to specify an entry point for clojure.main?

10:27 Chouser_: a few more "Interim checkin - DO NOT USE!!" could get ball rolling

10:27 cconstantine: hehe

10:28 danlarkin: I wonder, is the plan eventually to have most users on a release? Like not many people run from Python trunk, or Ruby trunk

10:28 * rhickey wants to deprecate all-ns, but it is used in find-doc...

10:29 kotarak: rhickey: please don't! I use it for completion in vimclojure!

10:29 * danlarkin actually uses all-ns

10:29 chessguy_work: 'morning ya'all

10:29 Chouser_: could all-ns be thread-local?

10:30 cconstantine: danlarkin: I would hope the goal is to get everyone on a release

10:31 digash: does anybody uses inspector-tree? i have a patch to add a path to the selected node in the bottom of the screen. would it be usefull to anyone?

10:31 kotarak: No way to specify a function which should be called *after* loading the script file in clojure.main?

10:31 rhickey: Chouser_: it's orthogonal to threads - the problem is that modular Clojure will have some namespaces not visible from others and no global registry necessarily

10:32 digash: sounds nice - post 1.0

10:33 inspector could definitely use some love - the multimethods predate the hierarchy enhancements

10:33 Chouser_: oh, right, it's class visibility from *classes* not from *threads*. bleh

10:34 digash: /me need to learn about the new hierarchy enhancements.

10:39 * cconstantine needs to learn about the hierarchy system :/

11:21 djpowell: i think just-in-time backporting of fixes could work. Just wait until someone asks for a fix on the mailing list, and hope that someone will be nice enough to make a patch, then push it out quickly as a minor point release.

11:24 powr-toc: when working at the REPL in clojure-mode (Emacs) does anyone have any tips on the workflow around re-evaluating a function in its namespace? manually changing the ns in the repl, then evaluating the modified function and then switch back is a pain

11:26 Cark: powr-toc : do you mean without slime ?

11:26 djpowell: yeah - i've just tended to stick all the code in one namespace, and then switch to that namespace in the repl. can slime automatically switch namespaces?

11:28 Cark: i use clojure mode without slime, and here is what i do : i have a (comment section at the end of the file, with an in-ns form ...so i can eval it when i'm close to the end, or the top ns form when i'm close to the top ....i usually will be to the end of the file, using my test forms in the comment section

11:29 b ut yes, i think slime does this automagically

11:33 powr-toc: Cark: yeah

11:34 ok... was trying to avoid the complexities of slime until I've got more experience with clojure and know that I need the features

11:34 djpowell: i don't use slime either. i think because i have a fear of it breaking, and me wasting hours trying to get it working again, and also cause I seem to cope well enough with inferior-lisp mode. is it worth upgrading?

11:35 powr-toc: djpowell: same

11:35 though the ns thing I've just run into is annoying

11:35 kensanata: Does anybody know how I can get the clojure docs I see on clojure.org as a PDF or a similar format so that I can read it offline?

11:36 powr-toc: kensanata: I'd second that... but I'd just be happy with an offline version of the site... are the site docs generated at all?

11:37 kensanata: powr-toc: I feel bad starting wget and leeching the site if there is an alternative...

11:37 drewr: kensanata: There's one on the google group, but it's old IIRC.

11:38 powr-toc: kensanata: I wouldn't feel bad about it... It'd just be nice to have a better way :-)

11:38 djpowell: yeah, i'd quite like the docs to be part of the release bundle somehow

11:39 Cark: the api page is generated, also there must be tools that can take a web site and make it a pdf

11:48 arohner: djpowell: I'd recommend slime

11:49 actually wait

11:49 are you using (ns) declarations at the top of your files?

11:49 you should be, and then you can just (load 'filename) from the repl, and the code will end up in the correct ns

11:57 kensanata: I decided to just print http://jnb.ociweb.com/jnb/jnbMar2009.html to a PDF file... :/

12:30 pjstadig: anyone know of a "swing repl"?

12:31 i.e. something that pops open a swing window that contains a repl

12:33 Cark: you might be able to reuse clojure.main/repl to that effect

12:33 ,(doc repl)

12:33 clojurebot: java.lang.Exception: Unable to resolve var: repl in this context

12:34 Cark: ,(doc clojure.main/repl)

12:34 clojurebot: "([& options]); Generic, reusable, read-eval-print loop. By default, reads from *in*, writes to *out*, and prints exception summaries to *err*. If you use the default :read hook, *in* must either be an instance of LineNumberingPushbackReader or duplicate its behavior of both supporting .unread and collapsing CR, LF, and CRLF into a single \\newline. Options are sequential keyword-value pairs. Available options and their d

12:53 pjstadig: Cark: yeah i was just wondering if someone had done something similar already

12:53 wanted to be non-duplicative

12:59 kotarak: pjstadig: there was a graphical repl in the files section of the google group

12:59 But I'm not sure about its status

13:33 Chouser_: pjstadig: there's also "texture" -- it was meant to be a text editor, but so far is mainly just a repl

13:53 powr-toc: I forget how you print the last exception at the REPL... can anyone enlighten me? :-)

13:53 kotarak: *1

13:53 Chousuke: *e :P

13:53 kotarak: Oops. Sorry. I read "the last expression"

13:56 powr-toc: ahh thanks :-) (. *e printStackTrace)

13:56 kotarak: powr-toc: you might be also interested in clojure.contrib.stacktrace

13:56 * kotarak wants to mention ,st and ,ct for VimClojure users.

13:58 * durka42 wants to take note

14:02 cp2: someone should write a nice bytecode library in clojure

14:02 so i dont have to work on my own projects

14:02 :)

14:07 kotarak: Could rhickey's defnk be added to clojure.contrib.def? http://paste.lisp.org/display/69347

14:14 Raynes: rhickey: You're right. They hardly even talked directly about the road to 1.0 at all. They mostly just complained about SVN and whined because Clojure isn't using Git.

14:14 :\

14:18 mattrepl: bah, the VCS is a part of the road ahead and _is_ pertinent to the discussion as the management of backporting fixes to release versions was mentioned

14:19 Raynes: But shouldn't someone have made another thread if concerned about that?

14:21 Either way. Rich will have to change to something else eventually, because Git-zealots are already rounding up pitchforks and torches ready to raid his home.

14:21 :p

14:22 mattrepl: hehe, I'd be hesitant to start a thread on it until Rich shows interest since he's shut down the idea in the past

14:23 cp2: im gitting angry, rhickey!

14:24 Raynes: Oh I see. He stated that Git wont happen any time soon.

14:24 * Raynes is reading down the thread.

14:24 rhickey: whatever the benefits of Git, it's not a contender until it is available on a credible host with attributes similar to Google Code, and has decent tool support a la SVN - it's simply not there yet AFAICT.

14:25 * danlarkin braces for the onslaught of "github!!1" replies

14:25 rhickey: oh please

14:25 cp2: heh

14:25 Raynes: rhickey: Yeah, I see Ozzy has demanded that you not use subversion.

14:25 * Raynes rolls his eyes

14:26 Raynes: Even Stuart is asking for Git. What is so great about Git?

14:26 rhickey: I think Git has great ideas, everyone mentions it to me after my talks as having a kindred spirit with Clojure's persistent data structures, it's not a technical issue but an environmental one

14:27 Raynes: Seriously, I'm wondering. I don't know much about it. All I know is that it hardly works on Windows.

14:27 * Raynes googles

14:27 * rsynnott really must learn to use it

14:27 rsynnott: so many things use it now

14:27 I'm more used to svn, though

14:28 cp2: Raynes: oh yea

14:28 git sucks on windows

14:28 msysgit is decent, but still lacking

14:28 tortoisegit is just completely lame (at the moment)

14:28 rhickey: cp2: that's enough reason against it right there, sucks on the 90% share OS

14:29 Chouser_: I think there are some people who have been burned by svn in certain demanding environments, and have found git to be a helpful. It think these are most likely to be militant.

14:29 cp2: for the moment

14:29 Raynes: Command-line tools would be nice, like the Scala compiler. Being able to compile something by saying "cljc teh.clj"

14:29 * Chousuke wonders how to use vimclojure

14:29 Raynes: But I believe there was a discussion here stating that that would be difficult.

14:29 cp2: Raynes: bash + alias perhaps

14:29 rsynnott: rhickey: Windows is probably a minority share on development machines, though

14:30 Chousuke: the README file lists nice features but fails to mention how to use them

14:30 Chouser_: I've never been burned by svn, and don't see how a single-user commit structure like clojure core has is ever going to stress it. I personally prefer git and use git-svn quite happily.

14:30 rsynnott: (especially if you ignore the in-house corporate app market)

14:30 Raynes: That's not the point. People /do/ still use Windows despite it's issues.

14:30 cp2: i heard using linux supports socialism

14:30 so i use windows

14:30 rhickey: rsynnott: Clojure does not ignore the in-house corporate market

14:30 rsynnott: I suspect that the inhouse corporate market ignores clojure :)

14:30 rhickey: true

14:31 kensanata: It doesn't hurt to be ready, though.

14:31 Raynes: I can get msysgit to clone, but not commit or anything of that sort.

14:31 rsynnott: the inhouse corporate market still seems uncomfortable with Java and C#; pre .NET VB is still a very big part of it

14:31 cp2: Raynes: weird, works for me

14:32 Raynes: cp2: I tested it by making a github project, after the master stuff, it complained about some linux-specific stuff, and apparently I'm the only one who has ever had the issue because I couldn't find anything about it.

14:32 I just decided it wasn't worth worrying about.

14:32 rsynnott: Chouser_: some early versions of svn built against certain versions of bdb had a very high-profile problem where they would occasionally irreversably corrupt themselves, often in suchh a way that it wasn't initially obvious

14:32 this has set some people against svn for life :)

14:32 cp2: odd :|

14:32 Raynes: At least I can clone without having to wade through linux crap. :D

14:32 rsynnott: "linux supports socialism" - what on earth?

14:33 powr-toc: What does %& do?

14:33 * Raynes hopes a "My os is better than your os!" duel doesn't start because of him.

14:33 durka42: powr-toc: it's a seq of the remaining parameters

14:34 rsynnott: (linux isn't even my OS, but I hardly think that political principles are an issue with it :) )

14:35 cp2: rsynnott: hehe, im not serious of course

14:35 powr-toc: cool

14:35 rsynnott: has anyone ever said that seriously, though?

14:35 the very idea seems weird

14:36 cp2: i hope not

14:43 rsynnott: but yes, really, what is wrong with svn? :)

14:46 cp2: i dont really see anything _wrong_ with it

14:46 its just not ideal for gigantic projects

14:46 for example, the linux kernel

14:47 but clojure isnt a gigantic project, so svn works fine i would say

15:14 kotarak: Chousuke: there is some documentation in the doc subdirectory

15:15 Chousuke: Short tour: start the ng-server, open a clojure file, type r-s and hit <C-x><C-o> in insert mode

15:15 Chousuke: in normal mode type \sr and enjoy the repl

15:15 Chousuke: Other things are explained in said documentation file

15:19 Chousuke: And for the SLIME question on the list: Write some macro call, eg. (defn foo [] :xxx) place the cursor inside the parens and hit \me or \m1. The preview window might closed with \p.

15:25 jwinter_: just got bit by the fact that println flushes output, but print doesn't

15:26 is there a reason why clojure.lang.Script wouldn't flush output when it finishes?

15:27 hiredman: jwinter_: have you tried clojure.main instead?

15:27 jwinter_: no, would that make more sense for shell scripts?

15:28 hiredman: jwinter_: take a look at java clojure.main --help

15:28 jwinter_: nice, thanks hiredman

15:29 hiredman: well, see if it flushes on exit first :P

15:29 jwinter_: yep, it does

15:59 Chousuke: kotarak: thanks

19:45 gvol: is anyone successfully using slime with clojure (both from version control?)

19:45 I keep getting an exception: Caused by: java.lang.Exception: clojure.contrib.javadoc/javadoc can now be found in clojure.contrib.repl-utils. (javadoc.clj:0)

19:45 technomancy: gvol: yeah, though I haven't updated in a while

19:46 gvol: How recently?

19:46 technomancy: are you using git? I could just give you the exact revisions I'm using.

19:46 gvol: I'm using bc's build-clj script

19:47 so some git, some cvs and some svn

19:47 technomancy: gvol: that script is unnecessarily complicated since it configures slime to also support Common Lisp

19:47 (unless you *want* CL for some reason)

19:48 gvol: no

19:48 clojurebot: is_rhickey_is_a_minor_god? is yes

19:48 technomancy: gvol: try the installation directions here: http://technomancy.us/122

19:48 gvol: cool, I'll check that out

19:48 Thanks

19:48 * technomancy wishes bc's script didn't have quite so much google juice.

19:49 technomancy: it's definitely not the best thing for users getting started. =\

19:49 gvol: :-)

20:04 beautiful, slime starts etc.

20:04 now it complains about lazy-cons

20:06 cp2: are you using latest svn of clojure (or relatively new)

20:06 gvol: java.lang.Exception: Unable to resolve symbol: lazy-cons in this context (probs.clj:56)

20:06 I assume that I have to add something to some path

20:06 cp2: yeah, lazy-cons is gone

20:06 use cons and lazy-seq

20:06 gvol: oh

20:06 cons works like lazy-cons?

20:07 cp2: no, but cons + lazy-seq does

20:07 gvol: ok

20:07 cp2: http://clojure.org/lazy

20:07 read more

20:07 gvol: thx

20:21 danlarkin: Oh how I wish defmethod accepted a docstring

20:27 cp2: wow, i just took a look at the code for filter

20:27 pretty elegant

20:27 imo, anyway

20:48 rhickey_: tom hickey is your brother im assuming?

21:01 danlarkin: cp2: yes

21:01 cp2: i like his designs, looks good

21:11 has anyone here used nbgit for netbeans?

21:50 danlarkin: it would be nice if contrib had an http library

21:55 hiredman: there are so many java http libs

22:00 Drakeson: I know it's embarassing, but I have no choice: why I cannot put (set! *print-lenght* 100) in my user.clj?

22:00 (it says: Can't change/establish root binding of: *print-length*)

22:02 danlarkin: because at the time user.clj is evaluated *print-length* has not yet been created

22:03 Drakeson: where should I put repl related setting, then?

22:04 is there a repl-hook ?

22:08 how can I disable caching for a lazy seq like: (def N (iterate inc 0))?

22:17 dreish: I have (def *print-length* 30) in my user.clj

22:18 cp2: cool :)

22:18 danlarkin: oh? hm maybe I'm wrong

22:18 happens a lot!

22:18 dreish: Drakeson: As for disabling caching, I think the short answer is you can't, and the longer answer is you can.

22:19 danlarkin: I think that's consistent with your answer. But I'm puzzled by how it works for me.

22:19 What doesn't work for me right now is repl-utils/source. Very sad about that.

22:25 Drakeson: dreish: does not work for me: Name conflict, can't def *print-length* because namespace: user refers to:#'clojure.core/*print-length*

22:25 dreish: What version?

22:26 Drakeson: the most recent

22:26 dreish: Weird.

22:26 Wish I could help. Sorry.

22:26 Drakeson: (Apr 14 is the last change)

22:26 what version is yours?

22:26 dreish: That's about the last time I updated, too.

22:27 I'm pretty sure the way that works hasn't changed in months.

22:27 Drakeson: you just put (def *print-length* 100) in user.clj and that's it?

22:27 dreish: Oh! No, I didn't. Sorry.

22:28 (ns clojure.core) (def *print-length* 30) (def *print-level* 10) (ns user)

22:28 That can't be the right way to do it, but it works. :)

22:29 (It has been a long week.)

22:29 Drakeson: yay! (iterate inc 0) cannot break my session anymore :D

22:30 thanks

22:30 dreish: np

22:30 The other way to protect yourself against iterate is to misspell it.

22:30 Drakeson: heh :)

22:30 dreish: ,(interate inc 0)

22:30 clojurebot: java.lang.Exception: Unable to resolve symbol: interate in this context

22:36 cp2: i guess when-let doesnt allow multiple bindings

22:37 danlarkin: cp2: correct

22:38 cp2: question about type hinting

22:38 if i am doing (defn ... [#^Class clazz value] ...)

22:38 is there a way to hint that the type of value should be whatever clazz is

22:38 as in, #^clazz value

22:39 actually i should have tried that before i asked

22:39 but im assuming it doesnt work

22:39 chessguy: hey what would you guys use in clojure for a bi-directional map? that is, a map whose values are also keys to their keys?

22:40 cp2: hm, apparently that syntax is valid, doesnt do what i want though

22:41 user=> (defn testaroo [#^Class clazz #^clazz value] [clazz value])

22:41 #'user/testaroo

22:41 user=> (testaroo String 123456)

22:41 [java.lang.String 123456]

22:42 shouldnt allow that

22:43 danlarkin: String is a class

22:44 cp2: yes

22:44 danlarkin: orrrr rather String is a Class

22:44 cp2: hm, i think i see where you are going

22:47 alright, not necessary for my code

22:47 would have just been nice to enforce that with type hinting

22:51 danlarkin: well you can enforce that the argument is a Class

22:52 but you can't, say, require it implement an interface or something

22:52 that isn't what type hints do

22:52 cp2: yeah, i see that now

22:53 no worries

22:53 chessguy: so...any thoughts on a bi-directional map?

23:11 mihand: I have not seen one in clojure and I think runtime suport is needed . i'd expect (assoc {:a 2} :r 2) to fail for that kind of map

23:11 but i'm a newbie

23:13 i'd use regular maps with custom add remove

23:16 is there a way to implement an Associative in clojure?

23:17 like you can implement sequences with lazy-seq and cons?

23:18 durka42: like proxy?

23:28 mihand: ignore the question . it was nonsense

23:32 technomancy: danlarkin: I've been thinking about an http library for contrib

23:32 danlarkin: technomancy: I just started one :)

23:32 technomancy: danlarkin: ooh; let's see it?

23:32 danlarkin: hah, it has GET so far

23:32 technomancy: that's a good place to start!

23:33 what's the JDK got as far as HTTP? is it just too low-level?

23:33 generationkill: ,(first ())

23:33 clojurebot: nil

23:33 generationkill: ,(first (list nil))

23:33 clojurebot: nil

23:33 cp2: URL / URLConnection

23:33 danlarkin: URL, HttpURLConnection... it's so stateful and disgusting

23:33 generationkill: am i the only one bothered by this?

23:34 technomancy: I heard a rumor that Google started using Python because the Java HTTP lib didn't let you set the HTTP user-agent header

23:34 (back in the day, of course)

23:34 generationkill: likewise:

23:34 ,({:a nil} :a)

23:34 clojurebot: nil

23:34 generationkill: ,({} :a)

23:34 clojurebot: nil

23:34 technomancy: aha: http://groups.google.com/group/comp.lang.java/msg/88fa10845061c8ba?pli=1

23:35 danlarkin: WOW

23:35 that's hilarious

23:36 generationkill:

23:36 Lawrence == Larry ?

23:36 I didn't know

23:38 danlarkin: GET down, moving on to POST, /me cheers

23:39 technomancy: danlarkin: be sure to post to the ML once you've got something ready to share; I'd love to help out

23:39 danlarkin: technomancy: will-do, I'll gist it or something

23:43 generationkill: Is Clojure ready to be 1.0?

23:45 cp2: heh, funny

23:45 i was about to write a function 'enumeration-seq' to put the elements in an Enumeration in a sequence

23:46 but then enclojure highlighted it, so i checked the api

23:46 already written!

23:49 generationkill: ,(find-doc enumeration-seq)

23:49 clojurebot: java.lang.ClassCastException: clojure.core$enumeration_seq__4930 cannot be cast to java.lang.String

23:51 durka42: (doc enumeration-seq)

23:51 clojurebot: Returns a seq on a java.lang.Enumeration; arglists ([e])

23:51 cp2: oh what

23:51 generationkill: why?

23:51 cp2: java.lang.Enumeration...

23:52 pretty sure thats a type

23:52 Enumeration is java.util

23:52 durka42: ,Enumeration

23:52 clojurebot: java.lang.Exception: Unable to resolve symbol: Enumeration in this context

23:52 durka42: ,java.lang.Enumeration

23:52 clojurebot: java.lang.ClassNotFoundException: java.lang.Enumeration

23:52 durka42: ,java.util.Enumeration

23:52 clojurebot: java.util.Enumeration

23:52 durka42: fact

23:53 slashus2: The doc is wrong?

23:53 cp2: (clojure.lang.EnumerationSeq/create e))

23:53 yes, it is wrong

23:53 public static EnumerationSeq create(Enumeration iter)

23:53 er

23:53 clojurebot: bender is my idol

23:53 cp2: import java.util.Enumeration;

23:58 generationkill: (apply * (range 1 1001))

23:58 ,(apply * (range 1 1001))

23:58 clojurebot: 40238726007709377354370243392300398571937486421071463254379991042993851239862902059204420848696940480047998861019719605863166687299480855890132382966994459099742450408707375991882362772718873251977950595099527612087497546249704360141827809464649629105639388743788648733711918104582578364784997701247663288983595573543251318532395846307555740911426241747434934755342864657661166779739666882029120737914385371958824980812686783

23:59 generationkill: Am I the only one bothered by the ambiguity of the nils?

Logging service provided by n01se.net