0:48 and no I don't teach IRL, in fact I haven't finished undergrad yet (I'm thinking of switching to a shorter degree and just graduating though, I'm getting sick of uni, so not always so patient :-P)

0:52_ato: Yeah, I have that problem as well. Purely theoretical stuff (like proofs of correctness and such) just bore me. That's part of the reason I'm considering changing degrees, I don't think I'm really suited to academic-style research, I like research by tinkering not research by formalism. ;-)

0:54 I definitely think the CS degree was worthwhile starting with though, it meant I could skip all the zaney software engineering courses and did teach me a lot of useful stuff I wouldn't have otherwise encountered (compiler theory, automata/turing machines, lambda calculus etc)

0:57clojurebot: "([n coll] [n step coll] [n step pad coll]); Returns a lazy sequence of lists of n items each, at offsets step apart. If step is not supplied, defaults to n, i.e. the partitions do not overlap. If a pad collection is supplied, use its elements as necessary to complete last partition upto n items. In case there are not enough padding elements, return a partition with less than n items."

1:03cgordon: I'm trying to use Leiningen, so I downloaded the latest "lein" script and ran "lein self-install". That put a jar file in ~/.m2/..., but when I run "lein new some-name", I get: Exception in thread "main" java.io.FileNotFoundException: Could not locate leiningen/new__init.class or leiningen/new.clj on classpath

1:04 If I do a "jar tvf ..." on the lein jar file, there is no leiningen/new.clj

1:07_ato: cgordon: you don't need to do anything special with slime. Create a file project.clj with your dependencies (there's an example in the lein README). Create a directory "src" for your code. Run "lein deps" to grab dependencies and chuck them into "lib". Fire up emacs and hit M-x swank-clojure-project and give your project's directory path

4:54AWizzArd: angerman: well, then it sounds that you are already on the right path. You can use (I think from Contribs seq-utils) the function indexed and then run filter over it. This would give you all those lines you want

6:23AWizzArd: Chousuke: funny, what you said is impossible I think. I mean your rule/law "nothing ever works flawlessly". If this rule were true then the nothing also points to itself. So the truth of your statement leads to its untruth :)

8:57rhickey: cemerick: it's a naming thing, certainly there's no reason for 2, deftype covers both use cases. But it looks like deftype might be able to generate what feels like a named class even in the dynamic case, including across redefs

8:57AWizzArd: Without type hints lispers sometimes are tempted to name a var after its type.

9:01AWizzArd: rhickey: what is the lateral class resolution to DynamicClassLoader good for? I mean, what are your grand plans? :)

9:01rhickey: anyway, seems like a clear path now to protocols/deftype/reify with no reference even to interfaces, reify of protocols

9:01 reify of interfaces and deftype implementing interfaces just about interop

9:04 AWizzArd: lateral class resolution means I can dynamically generate named classes, and find them in other dynamic classloaders, without trying to insert them in some shared root in the hierarchy (an impossible task given modular classloaders, context classloaders etc)

9:13rhickey: the only hitch will be a true (altering) redef of a type will require a reload of client code to work with new instances, but no JVM restart ever

9:14 I basically decided following the tree design was simply too restrictive, was never intended to cover these cases, and hell, why should these modularity systems have all the fun - they do this kind of thing all the time

9:30rhickey: so, protocol Baz looking for foo will be looking for foo_Baz

9:31 this aspect of JAva is broken, and I'd prefer not to have protocols be broken too. Right now the story is, same function name in different namespaces ok

9:32 and use of interfaces for speed under protocols is an implementation detail

9:32chouser: always using a prefix/suffix would dissallow the kind of "transparent" client use by Java code I'm using right now.

9:34rhickey: chouser: there are slightly different requirements at play here. There, the Java interface is driving, it won't be the primary interface to the protocol

9:34 I'm thinking about designs where some substantial facility has been built in clojure on protocols, how to write new Java to work with it

9:35chouser: I have Java clients doing things like RPC.newChannel("target").send(myMessage), where RPC is gen-class with static methods, and the Channel interface is from gen-interface. 'send' is implemented via proxy

9:35rhickey: JAva code can't presume all implementors of protocol implement some interface - that will never be true, since extends lets protocols reach classes with no derivation requirement

9:36 chouser: so for that you might still want definterface + deftype/reify

9:36cemerick: rhickey: FWIW, in that use case, I'd say that a Java-friendly API should be written using genclass or a regular interface + deftype/reify.

9:38rhickey: cemerick: by regular interface above do you mean JAva-defined?

9:39cemerick: rhickey: yes. If you're writing Java code anyway, and you want to call some clojure lib, I think it's totally reasonable to say that the work and shape of that integration falls on the integrator, not the language.

9:40rhickey: the biggest problem of declaring 'no prefix' at the protocol side is that the clashes occur in client code doing ad-hoc extension

9:40cemerick: someone in that position will likely be doing something you're not going to anticipate anyway, so punting to interface+reify/genclass will be the rule more than the exception, I'd wager.

9:40rhickey: You can't be both a j.u.Map and a j.u.Collection, for example, due to this problem

9:41 one thing that is key is that if you have a protocol-driven design, and want to make it reach another, more Java friendly interface, you always can

9:42 but the protocol-specific interface gets a perf benefit that can't be gotten otherwise

9:44 I guess if I leave in :on, you could make protocols where a definterface drives that, but :on is really ugly, puts a discussion of interfaces up front, has name-mapping and other required knobs...

9:45 but it is a key question - are there many cases where a pre-existing interface should be the basis for a protocol?

9:46chouser: my code is already partitioned into core functions vs. clojure api (which includes macros) vs. java api (public interfaces, static factory methods, etc.) ...so I have no problem with internal clojure stuff that might look "ugly" to Java, as long as I can still wrap it up in stuff that looks pretty in Java without actually writing any Java. :-)

9:51Chousuke: rhickey: you haven't added a seq1 function (for "unchunking" a seq) yet, have you? I suppose it would be good to have in 1.1 if people need it :/

9:52rhickey: the other route is to do name-munging only, people can easily avoid munging by using compatible names. You would be precluded from implementing protocols with overlapping functions in the same deftype, but could still reach the other protocol with an extend-type

10:39cemerick: Looks like I need to rebind a multimethod with one that temporarily contains an additional set of methods. Is there a better way to do this, short of using defmethod before (binding...) and remove-method in a finally? (Thankfully, I'm not worried about race conditions in this case.)

10:54cemerick: eh, dispatch table caching is not a cost relative to the rest of the app

10:54 chouser: the specific situation is an indexing system where documents are {:name "val" :name2 "val"}, and different callers need to have control over how the values are indexed (tokenized or not and how, stored or not, etc). If document type A has a field :foo that should be tokenized, and document type B has a field :foo that shouldn't be tokenized, this has to be controlled in a context-sensitive way.

10:58 my vague understanding is that the prag, apress, and "in action" from manning are essentially meant to be head-to-head competition, while we're making ours try to come at things from a slightly different angle.

10:59cemerick: chouser: yeah, a 2-stage approach is better in general -- multimethod dispatching on document type returning a fn (or var that can be rebound as desired) that provides the actual configuration

11:17AlexStoddard: I have large data where I expect different instances to share a lot of structure (genetic variation in humans - representable as a vector or sequence). Clojure's structural sharing is mostly explained in terms of changes over time not changes between individuals. Any suggestions on how I might leverage structural sharing in Clojure to efficiently represent the data?

11:22Chousuke: AlexStoddard: can't you just model your data as a progression of individuals instead of as progression of time? :/

11:23 AlexStoddard: if you make a "modification" to a vector, it would represent a new individual, but the structure would be shared with the parent individual.

11:26AlexStoddard: Chousuke: That is what I am thinking, the abstraction makes sense. What I am unsure about is how to "attach" an individual to each given state of the vector.

11:27Chousuke: Each state *is* an individual. but you could have a ref to point to one of the individuals (changing over time) and call it pinnacle-of-evolution or something. Or you could have sets containing these individuals, or whatever

11:28chouser: AlexStoddard: the structural sharing is pretty invisible. Just hang onto one version of a thing, do some 'assoc', 'dissoc', etc. to get to your next object, then hang onto that as well.

11:30Chousuke: if genetic change can happen within one individual then you need to model them as time-dependent. eg. you need a ref to give an identity to the individual, or if that's too granular, a whole population (which "progresses" synchronously)

11:42rhickey: yes, there were a whole bunch of things slated for next release that got ignored, while others from backlog got worked on, so didn't seem to make much sense to me to keep trying to do that, but the approved backlog are things I think are more important

11:42chouser: mattrepl: if they exist at all it's ok to work on them, though they might need more design discussion or might not make it in anytime soon.

11:47cemerick: rhickey: one thing stuck out for me in those slides that are making the rounds this morning: "composability of independent decisions e.g. thread pool sizing". That's developing into a big issue for our UIs -- e.g. running a pmap in a UI app simply kills the entire system. Definitely good utilization, but being able to say "this pmap/send/future/etc should go into this low-priority/N-thread/etc threadpool/executor" woul

11:50rhickey: cemerick: definitely want to have more pool options, but still leaves basic questions unanswered - how do independent decisions interact>

11:50 there is implicit scope already in play in deftype - unqualified access to fields

11:57notallama: cemerick: i wrote a different version of future the other day that uses a daemon thread pool (http://paste.lisp.org/display/91277). that's something you can hack together yourself, if you want. for send, i think you have to change Agent.java (i didn't see another way to do it)

11:57cemerick: rhickey: absolutely. The brute-force approach leads to insanity. Further, I presume that the way j.u.concurrent does things is not suitable for .NET or cocoa or js or..., so I suppose clojure needs a higher-level set of levers than all of the fiddly bits that j.u.c provides.

11:58rhickey: cemerick: I think you miss my point - I consider this an unsolved problem

14:12technomancy: cemerick: according to John Rose it's a matter of manpower

14:12cemerick: that's what I thought, though I see the post that technomancy just linked to, and there was a java.net post about first-class continuations in JDK 7 over the weekend, so I thought maybe something was afoot

15:49 deftype has been about interfaces, but now can do protocols as well. Does it just use the interface? Does that mean it's not splitting its body into deftype/extend?

15:49rhickey: chouser: right, but the trick is to come up with the story from the other direction - imagine you don't know Java, and have been shown protocols and deftype. You can etend a type to a protocol externally or internally

15:50solussd: could somebody explain the difference between send and send-off?

15:51rhickey: externally with extend or extend-type, internally by putting ____ (called my.ns.Protocol) in square brackets and the definitions inline. The inline definitions have direct access to your fields, but are not closures over surrounding lexical scope (usually none)

15:51 additionally, you can do one-off implementations of a protocol with reify

16:37twbray: cemeric: I'm not really sure whether or not the amount of CPU burned is significant. But it's still surprising. Anyhow, a speedup factor of four based on straightforward use of Clojure primitives without too much voodoo is obviously good.

16:38cemerick: twbray: I guess my confusion is around what exactly a cpu cycle is, if not a corollary to a unit of time.

16:39twbray: cemerick: In practical terms, what it means is, how many of the machines cores are in use & not available for other work.

16:39 On this computer, for every unit of time, there are 16 units of integer computing potentially available.

16:39chouser: seems like it might matter a lot in a world of on-demand provisioned virtual machines billed by number of comuter-hours used.

16:39alexyk: twbray: a bit offtopic, but perhaps you can shed the light. I got a box with 8 quad-core CPUs, but top never shows loads more than 800% CPU. In such setups, is it because 100% CPU is counted per each quad-core? It's a Barcelona Intel x86_64 each. Can such a system run 32 threads at once?

17:04alexyk: ok, so I see two different ways to interop with Java here: (.parseDateTime dtFmt "2009-06-15 04:01:00") and (. dtFmt parseDateTime "2009-06-15 04:01:00"); but this doesn't work: (dtFmt. parseDateTime "2009-06-15 04:01:00")

23:24alexyk: I get an error in maven witrh clojure plugin, when it tries compiling a script which feeds fine into a repl: java.lang.Exception: Unable to resolve symbol: only in this context. Points to a line which is fine in repl, no actual symbol shown... is it normal?

23:24dnolen: technomancy: yeah, Python also encourages the overly eager use of sudo.

23:35clojurebot: "([f coll] [f c1 c2] [f c1 c2 c3] [f c1 c2 c3 & colls]); Returns a lazy sequence consisting of the result of applying f to the set of first items of each coll, followed by applying f to the set of second items in each coll, until any one of the colls is exhausted. Any remaining items in other colls are ignored. Function f should accept number-of-colls arguments."