1:04sandGorgon: hi guys... wanted to prototype a document store like functionality in clojure. basically a clojure server would be running on a remote machine, I request for a (guaranteed) unique filename and it returns a one-time URL that I can retrieve the files from. Later I'm gonna bolt on authentication and all that stuff

1:04 I'm confused on the first step - to build the clojure "server" would I have to use a web framework like compojure ?

1:06amalloy: sandGorgon: i'm not an expert here (so don't take my advice!), but you certainly don't have to. if you wanted, you could instantiate the java.net.ServerSocket yourself

1:07sandGorgon: amalloy, true - I was kinda hoping one layer of abstraction above it. my first thought was compojure, then I thought of ring, now I'm thinking of something using Aleph/Netty. But wanted to get idead

1:07sexpbot: <sandGorgon> amalloy, true - I was kinda hoping one layer of abstraction above it. my first thought was compojure, then I thought of ring, now I'm thinking of something using Aleph/Netty. But wanted to get ideas

1:09amalloy: somewhere around here i have a copy of my first clojure program, which was a simple chat server. compojure or ring or something is almost certainly better, but i don't have experience with any of them

1:09TheBusby: technomancy: I fought with the JVM's processing spawning for quite a bit before going JNI. The worst part is what works for one platform doesn't work for another, hence the JNI route...

1:10technomancy: TheBusby: yeah... honestly I only bothered because it looked like it would be really easy

1:11 I'm not sure it's worth the hassle at this point just to be able to do TDD outside swank

1:11sandGorgon: amalloy, actually the reason why it might be a bit different is that it might well be a multi-gigabyte file. So you dont want to drop down to socket level and have to deal with fillng up of posix buffers and all that.

1:23amalloy: technomancy: ^ indicates start of line, and / is a literal. they're separated by |, which is OR; those are wrapped in (?:) to get proper grouping - the ?: prevents it from stomping on your capturing groups

9:13chouser: yes, *ear-muffs* are for vars -- things that are meant to be rebound using (binding ...)

9:14 leading dash is for functions that are acting as methods for genclass. Note (defn- foo ...) is for a private foo which is different than (defn -foo ...) which is likely a public method of a class.

9:15 fliebel: yeah fn* is the real special operator, related to fn which is a macro

9:21chouser: fliebel: I think "ns clean" is too dismissive. A public API carries weight -- it should be clean yes but also documented, slow to change, conceptually aligned with how users are supposed to think about the problem space, free of implementation-specific details, etc.

9:21 private functions don't need to meet any of those criteria, so it's worth being clear about which is which.

10:24chouser: for work we already have an extensive build system using cmake (do not recommend), so I plugged clojure into that. The generated makefiles fetch dependencies and then we have a shell script that sets up the classpath and launches the appropriate Java class.

10:25chouser: for my own hacking around, I had started working up a system of jar directories, one per clojure major version plus a "common" one. So to start using a jar I'd just download it into the appropriate dir, launch the appropriate clojure repl version, and go.

10:49chouser: rfgpfeiffer: no, just use regular clojure functions for that

10:58technomancy: hmmm... might be time to drop test-is support in the next leiningen release. =)

10:58fliebel: Given the fact that Clojure-in-Clojure is possible, it is thus possible to define lazy seqs. Would it also be possible to define a lazy seq where the 0th element is actually in the middle of an infinite lazy seq extending in both ways? so like (iterate inc) with negative number included :)

11:26edw: I'm a longtime Emacs user and Scheme programmer and I'm trying to get Emacs set up to play nice with Clojure (1.2) and I the best guide I can find is a mailing list message from Constantine Vetoshev and I get an error when following along with that. Is there a definitive SLIME/Clojure guide out there somewhere?

12:43fliebel: chouser: I need to prepare dinner. I'll talk to you about reify later. Thanks for helping me. I'm now struggling with where to keep state and how to modify things withouy an endless recursion.

12:51andyfingerhut: chouser: I ask because I was thinking of how one could modify your finger trees without having a meter-obj in every deftype'd object in a whole tree.

12:51chouser: andyfingerhut: yeah, I mentioned an alternative in a recent email

12:52 ...passing in the meter as an arg to methods that use it, and relying on some outter context to provide the correct one every time.

12:52 I didn't have outer contexts before, but my most recent commit adds a couple examples

12:54andyfingerhut: ok. It is just that so many of the methods need it. I'm not advocating for inner deftypes, but they look like they would kinda-sorta help in this kind of case. I'm sure there are other ways.

13:12proyal: howdy! question: i have two seq's, one of fn's, the other of values. in order, i want to map each item of my value seq with the corresponding (nth-wise) fn from my seq of fn's. is there a handy way to do that?

13:35dnolen: birdspider: hmm that should work yes... and yr classpath is set as well I assume? You do need to include each jar individually.

13:36birdspider: dnolen, well there is a bunch of stuff in lib, but i tried: java -cp lib/clojure-contrib-1.2.0-20100813.160219-142.jar:lib/clojure-1.2.0-master-20100813.160144-94.jar:lib/penumbra-0.6.0-20100502.112537-3.jar:src/ -Djava.library.path=native/linux/x86/liblwjgl.so clojure.main

13:45andyfingerhut: With 1.3.0, is someone already planning a web page or something similar that people can go to in order to assist in upgrading their code base from 1.2.0? As a minor example, I had some calls to re-gsub that worked on 1.2.0, but the name changed so it took some time to find in 1.3

16:16lpetit: First question: is there a way for me to initiate the Clojure environment, or very quickly after its initialization, with a parent classloader of my own. So that clojure always tries to find a classpath resource (bytecode on disk, clojure file on disk) via my classloader before "giving up" ?

16:17clojurebot: "([& vars]); Returns true if all of the vars provided as arguments have any bound value, root or thread-local. Implies that deref'ing the provided vars will succeed. Returns true if no vars are provided."

16:17ninjudd: lpetit: not sure i am qualified to answer, but i spent many hours a few months back trying to do something similar

16:22alpheus: I am not sure bound? is what I need. I am writing a function that relies on something that I expect will be set up by def/defvar or in a binding form and I wanted to assert that in the pre part of a condition-map for the function. Please feel free to tell me I'm going about that all wrong and point me toward the right documentation.

16:22lpetit: hiredman: no problem. I can write the classloader in java. But I can not "insert it" in the classloader hierarchy in the classical way. It's "constrained" by OSGi. Rather, I would like to create my own classloader, which will leverage the OSGi classloader as its parent one, and then inject mine (which will have some goodies such as being able to consult all classloaders of all bundles that...

16:22 ...depend on the clojure bundle) as the "reference" classloader for clojure

16:22 hiredman: at this particular moment, I don't even know if what I just described makes sense

16:23 ninjudd: before even reading your post, reacting to your explanation: my fear is that I do not have control over the context class loader in the long run. I'm thinking about entering by the backdoor room :)

16:24wwmorgan1: alpheus: I think that what you want to know is whether the namespace has the symbol you need. In this case you want ns-resolve

16:50lpetit: ninjudd, cemerick, hiredman: just read an article or two on the subject of OSGi and its affinities with context class path. It's just a no man's land in the spec. Every container has its own way to use it. Some expose every exported package by every bundle in this classloader, some do not guarantee that it is set, some by the use of proxies at bundle boundaries try hard to always set it...

16:50 ...correctly (but I guess that you need to always use OSGi services then, not directly call classes exported by another bundle ...

16:55lpetit: ninjudd: ooh yes. That's why I somehow give up on trying to cheat with OSGi, and now I'm trying to cheat with clojure :-). I can even consider hacking it a little bit in the corners. But right now I just need to understand how it works.

16:57ninjudd: so how do you plan to cheat with clojure? replace DynamicClassloader?

17:00lpetit: ninjudd: first step = find a summary of how the parts that use classloaders work, or someone with the ability to do this summary "live" for me. Then I'll see if this "DynamicClassloader" should be extended, composed, replaced, etc. (I don't even know exactly what I'm talking about, concerning Clojure and classloaders. And this kind of subject does not suffer to be imprecise)

17:02ninjudd: lpetit: i would start by trying to write your own classloader that users DynamicClassLoader as it's parent, which means that resources that are not found by your classloader will be loaded using dynamic classloader.

17:02sexpbot: <ninjudd> lpetit: i would start by trying to write your own classloader that uses DynamicClassLoader as it's parent, which means that resources that are not found by your classloader will be loaded using dynamic classloader.

17:03ninjudd: lpetit: then you can use setContextClassLoader to change clojure to use your classloader instead of DynamicClassLoader.

17:04 lpetit: what you are doing sounds very similar to what i was doing. NativeClassLoader and my import-native function are good examples

17:04lpetit: ninjudd: it's more that I don't know in which ways I can direct clojure to use my classloader. I remember vaguely having seen various places where a modif can be made (some *use-context-classloader*, some CLASS_LOADER static attributes of RT / Compiler, BASE_CLASSLOADER, etc). I'm lost between those "alternatives"

17:06 ninjudd: but *when* to call setContextClassLoader() ? I cannot do this once and for all, or I'll not play well with OSGi (that's what I understand). By doing so I may expose to few or to many things to all other following users of the thread. And I have no guarantee that it will not be changed by somebody else in the future.

17:06 Instead of telling clojure "use the context classloader", I would rather have a way to tell him: please also try to always use as a last resort this classloader I'm handing you

17:09lpetit: Oh and I also just thought about this one: the context classloader, by definition, is for one thread. I'm not sure at all in OSGi that I have any guarantee that it will always be this thread that will be used when accessing e.g. RT ?

17:13 lpetit: this part of clojure seems like a total mess to me. if you can convince someone (i.e. stuarthalloway) to clean it up, that would be a very good thing

17:15lpetit: ninjudd: a real world example of the problem. An AOT class is declared in a bundle A, via the plugin.xml. At some point the eclipse frameworks wants to load the class. I don't know when, I have no control, the class will automatically call clojure in another bundle to initialize its implementation namespace. I have no way to take control in this workflow by superimposing my "classloader-which-will

17:15 -call-back-to-the-calling-bundle-loader" so that clojure will even be able to find the implementation namespace's ".clj" resource

17:16 ninjudd: I'll try, as soon as I seem to know what I'm talking about :)

17:22AWizzArd: ninjudd: were you the guy who implemented a Set that keeps the order of insertion?

17:22lpetit: ninjudd: no we thought about 2 scenarios with cgrand: one where we totally bypass OSGi and indeed create and wire "on the fly" clojure environments. In this scenario we control which classloader is used to load clojure.lang.Compile. But this scenario does not play well with OSGi when you add AOT compiled classes to the dance. They just never will be able to get a the proper clojure classes,since t

17:24lpetit: ninjudd: but it's fair to say that users whose job is writing Eclipse plugins could benefit from this new approach (and the patched clojure) if they want the greater repl experience in their own development cycle

19:58ninjudd: i assume so, but at one point they changed the root binding from false to true to fix a bug. now it is kind of pointless. i believe the right fix would have been changing baseLoader as i have done

20:29 oh, you mean to wrap the call to setContextClassLoader with a binding of *use-context-classloader*?

20:30lpetit: ninjudd: in the changeset of Rich you pointed, there was a conjunction of several changes: on in main.clj to try hard to set the context classloader to a meaningful value, and one to change the value of *u-c-c* so that what has been done in main.clj has a chance to be used

20:57 but isn't this a problem that for its core initialization, clojure would have used as its root a "temporary" classloader. I should ensure that the "old" *classloader* of clojure is the root classloader of my own, right ?

21:00 ninjudd: if we don't want to break anything, we must keep it in place, though

22:25nroot7: In my program I represent each user as a agent maintaining its own state. This works fine w.r.t. to concurrency but what if I want to persist this state in a non-volatile way. Is this a common pattern in clojure world ? How is it implemented ?

22:30technomancy: nroot7: if 100% absolute consistency is not a requirement, you can have a watcher on your agent that serializes to disk