0:00 steiger: bye guys
0:13 technomancy: "the biggest issue with all dynamic solutions is they often don't work in production without specific bridges to the application host (netbeans, osgi, netkernel etc)." <= rich earlier today
0:13 jruby probably doesn't care about that kind of compatibility
0:14 neither do _I_ for that matter
0:15 I can understand why Clojure doesn't offer a dynamic classpath out of the box, but it would be great if it provided a way to do that if you really wanted it.
0:17 ,(.getContextClassLoader (Thread/currentThread))
0:17 clojurebot: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
0:18 technomancy: that's a #<DynamicClassLoader clojure.lang.DynamicClassLoader@84cc09>
0:18 maybe there's a way to use that to load a given class
0:23 nope; looks like even classes explicitly loaded with the DynamicClassLoader do not honor its dynamic classpath.
0:23 that's a shame
0:31 eyeris: My god I hate the classpath.
0:34 mikehinchey: add-classpath doesn't do what you need?
0:34 eyeris: I hate that my code has to be in the same classpath as my tools
0:35 e.g. vimclojure's nailgun server's classpath has to be able to access both my code and it's own
0:35 which means that my code and vimclojure both have to be compatible with specific versions of clojure and libs
0:36 But in general, I shouldn't have to have a different script to launch each tool
0:36 mikehinchey: how would it execute your code if it couldn't access them?
0:36 eyeris: that all just manipulate CLASSPATH a little differently
0:36 I am not trying to solve the problem
0:37 I am just bitching that it suck
0:37 s
0:37 technomancy: mikehinchey: add-classpath only alters the current instance of clojure.lang.DynamicClassLoader
0:38 in many instances that's not enough
0:38 not that I know why
0:40 riddochc: This is weird...
0:40 clojurebot: (str "\" "/") ")
0:40 clojurebot: Titim gan éirí ort.
0:41 riddochc: Woah. Even weirder.
0:41 mikehinchey: oh, maybe your onerous library is on the system classloader, so a child cl won't work
0:41 riddochc: For me, it gives: "\" clojure.core$_SLASH___4461@18c3679) "
0:41 This is out of an effort to get (str "\" "/") => "\/"
0:42 Which was brought about by trying to do something like (println (re-gsub #"/" "\\\/" "one/two/three"))
0:43 mikehinchey: ,(str "\\" "/")
0:43 clojurebot: "\\/"
0:43 technomancy: mikehinchey: I don't think it's _the_ system classloader, since JRuby is able to modify the classpath in a way that makes it work.
0:43 but it's some other classloader that isn't honoring my changes
0:59 riddochc: Now, *that's* what I wanted:
1:00 clojurebot: (println (re-gsub #"/" ,(str "\\\\" "/") "one/two/three"))
1:00 clojurebot: It's greek to me.
1:00 riddochc: ,(println (re-gsub #"/" ,(str "\\\\" "/") "one/two/three"))
1:00 clojurebot: java.lang.Exception: Unable to resolve symbol: re-gsub in this context
1:01 riddochc: Well, okay. It prints "one\/two\/three" - leaning toothpick syndrome, for sure.
1:02 tomoj: what's the point of (str "\\\\" "/") ?
1:08 riddochc: A situation of genuine double-escape need... Clojure's producing a string that will get interpreted by another program as code.
1:13 Made even more fun, of course, by the fact that things need to be escaped differently for this other program than they are for Clojure.
1:13 And yes, it deserves a few lines of comments.
1:33 hiredman: java.lang.ClassFormatError: Duplicate method name&signature in class file hiredman/reader/StringReader
1:33 what a drag
1:33 the java part compiles fine but compile-clojure pukes
2:14 Atif: ping
2:14 arbscht: pong
2:15 aatifh: arbscht, i have this float value 38.20000076 and just 38.20 how to do that?
2:18 ping
2:35 ping
3:10 yason: aatifh: assumedly you want to print the floating point number into a string?
3:10 aatifh: yason, yes
3:11 yason: aatifh: see the format function
3:11 aatifh: yason, hmm
3:11 yason: it's akin to printf() in C
3:17 aatifh: yason, so, thats it (format "%.2f" (Float/parseFloat "-12.1021"))
3:17 yason, I hope its a better way
6:43 mikem`: date
7:39 serp_: platt katt
8:55 AWizzArd: ~max people
8:55 clojurebot: max people is 185
8:56 licoresse: ~what's for dinner?
8:56 clojurebot: for is a loop...in Java
8:57 licoresse: ,*clojure-version*
8:57 clojurebot: {:interim true, :major 1, :minor 1, :incremental 0, :qualifier "alpha"}
8:58 snowwhite: What is the best to get the datetime object of a month before the current datetime?
8:58 *way
8:58 AWizzArd: What is a datetime object?
9:00 snowwhite: AWizzArd, Java datetime object
9:01 AWizzArd: i heared of java.util.Date
9:01 ,(.format (java.text.SimpleDateFormat. "yyyy-MM-dd_HH-mm-ss") (java.util.Date.))
9:01 clojurebot: "2009-10-20_06-08-37"
9:02 AWizzArd: maybe this is what you want
9:02 liwp: I think if you want to do maths with dates (i.e. the month before the current time) you'll have to use java.util.Calendar
9:03 if you have to do complex date/time stuff, look into yoda (?) which is an advanced date/time java lib
9:04 ahh, joda: http://
9:04 licoresse: (dec (.getMonth (java.util.Date.)))
9:04 liwp: licoresse: and now turn that into a date again ;)
9:05 licoresse: :D
9:05 chouser: It's just too horrible:
9:05 ,(.getTime (doto (java.util.Calendar/getInstance) (.add java.util.Calendar/MONTH -1)))
9:05 clojurebot: #<Date Sun Sep 20 06:12:33 PDT 2009>
9:06 chouser: snowwhite: that's the normal way to do it with builtin java classes, but from everything I hear I'd recommend you use joda time if a 3rdparty lib is at all an option.
9:12 liwp: looking at the joda api (I've never used it myself) it seems that (new Instant()).minus(Months.ONE) could work
9:13 there's probably some other, more idiomatic way of doing it, which would avoid the Instant instantiation...
9:16 snowwhite: chouser, Thank you so much.
9:16 mikem`: hello, beginner having some trouble: http://
9:19 I think it's the laziness biting me
9:21 tomoj: you defined process-spec-list to just be the identity, and (get-package-specs ..) worked, but (process-spec-list (get-package-specs ..)) didn't?
9:22 that's... odd
9:22 Chousuke: try (println (doall specs))
9:22 to see if it has something to do with laziness
9:24 mikem`: Chousuke: ah, you're right. I needed to doall the sequence
9:24 Chousuke: that's weird though
9:25 it should work even without doall :/
9:25 mikem`: hm, maybe I should get the hang of things first before using lazy functions
9:26 chouser: what is get-package-specs ?
9:27 mikem`: Chousuke: get-package-specs is: http://
9:28 Chousuke: mikem`: that doesn't return a vector though :)
9:28 I don't think that should explode though.
9:28 mikem`: ah, my docs are out of sync :)
9:28 tomoj: that shouldn't cause a Character->ISeq error, should it?
9:28 Chousuke: unless read-lines does something silly.
9:29 chouser: read-lines is a bit dangerous, but I don't see how it could cause that error
9:30 rhickey_: if you realize the lazy seq after the file is closed you will have problems. Look through the stack trace for the cause
9:31 Chousuke: read-lines is not a core function though.
9:31 mikem`: is it from contrib or did you write it yourself?
9:31 mikem`: read-lines? it's from contrib.duck-streams
9:32 Chousuke: 'k. I guess it should be fine.
9:32 chouser: read-lines will tend to leak the file handle rather than close too early.
9:32 mikem`: I can't reproduce it here -- can you paste the whole stack trace?
9:33 mikem`: chouser: i'm having troubles reproducing it too, now
9:34 are these lazy seqs cached somehow?
9:34 rhickey_: mikem`: have you rebuilt Clojure while running?
9:34 chouser: I wonder if some of your fns were not defined as you thought they were. 'source' shows the definition of a fn as it is in a file, not necessarily the way it's currently defined.
9:36 mikem`: rhickey_: nope. I was playing with the definition of process-spec-list, and it was probably wrong at the start. but the error didn't go away even when I changed its definition to the identity. that's why I'm asking whether the lazy-seq is cached somehow
9:36 chouser: ah, i see. I thought source would show me the function as it is currently defined in memory
9:36 rhickey_: mikem`: are you using Slime?
9:36 mikem`: rhickey_: no, vimclojure
9:37 chouser: lazy-seqs do cache their realized values, but if you're calling 'get-package-specs' each time then you're getting a new seq and nothing should be cached.
9:37 rhickey_: a stack trace would help
9:38 mikem`: in that case, it might be an issue with the function as defined in the source vs being executed
9:38 if i get this exception again, I'll get the stack trace :) thanks for the help
9:40 chouser: rhickey_: all the dispatch-fns in a multiprotocol should have the same range even if their domain is different?
9:40 I guess that's essentially what you say in the first sentence.
9:41 tomoj: I wonder why compile errors in slime show up in *inferior-lisp* instead of popping up debugger buffers
9:42 The-Kenny: tomoj: They trigger a debugger-buffer here.
9:43 tomoj: The-Kenny: orly? what versions of emacs, clojure-mode, and swank-clojure?
9:44 The-Kenny: tomoj: http://
9:44 tomoj: A very recent slime from cvs, clojure-mode etc. fresh from github.
9:44 tomoj: is that aquamacs?
9:44 The-Kenny: Yes
9:45 * eevar2 is happy with emacs.app 23.1 from macports
9:45 tomoj: hmm.. I'm using emacs 22. I'll try it on aquamacs to see if that's it or if there's something wrong with my clojure/slime setup
9:45 eevar2: and now the people in #emacs don't shun me any more ;)
9:45 rhickey_: chouser: no, just that the mapping of the set of methods must be to a single dispatch value
9:46 Chousuke: emacs.app 23.1 works fine
9:46 tomoj: I get a "Compilation failed: ..." in the minibuffer and the stacktrace in *inferior-lisp*
9:46 Chousuke: though it's a bit slow
9:46 rhickey_: chouser: but one mapping could be to [:a :b] and another to 42
9:48 Chousuke: I tried Yamamoto Mitsuharu's mac'ified port of emacs and it was a bit faster but I hit some bug that made me unable to type square or curly brackets, so I was kind of forced to return to plain old emacs.app :P
9:49 I wish they'd use git or something though. having to apply patches manually is a pain.
9:50 tomoj: does anyone using gnu emacs get compilation errors in a debugger buffer?
9:56 cgrand: rhickey_: have you any plan to suppoty primitive types (for args or return value) in protocols fns?
9:56 rhickey_: cgrand: not other than the ones to support them in general for fns
9:56 since protocol fns are merely fns
9:57 I guess the dispatch arg cannot be primitive in any case
9:57 tomoj: is there somewhere I can read about protocol fns?
9:58 rhickey_: http://
9:58 http://
9:58 tomoj: thanks
9:58 cgrand: ok, then what are you plans for primitives support in fns?
10:00 rhickey_: cgrand: Not fully worked out, but I'm thinking about supporting only longs and doubles, cutting back on the number of arity overloads in IFn (10?) and adding combinations for up to 4? args of mixed type
10:01 returns might have another interface, since can;t overload on return type, but also require more inference of return type, or more hints (call foo returning long)
10:01 sine longs cover all integer primitives and doubles cover floats
10:01 since
10:03 cgrand: ok, thanks
10:04 rhickey_: so compiler seeing (foo x) used as an arg taking long, or #^long (foo x) will convert foo to ILongFn and then invoke
10:05 Chousuke: is there any way to force clojure to recompile a namespace? I have problems bootstrapping my reader because clojure doesn't seem to recompile namespaces of which I have another (compiled) version already loaded...
10:05 cgrand: with protocols and datatypes, PersistentVector (for example) would be still be implemented with reify to support java Interfaces (and IFn?)?
10:05 chouser: this is probably beyond 1.1?
10:06 [rephrasing] primitive support in fns will probably be after 1.1?
10:07 rhickey_: chouser: definitely, probably after cinc so we can use macros for the vast boilerplate :)
10:08 cgrand: I'm still thinking about that. Obviously if there are still lots of interfaces that will need to be implemented then that will push one off of datatypes...
10:09 chouser: ah, yes. I used a couple macros in finger trees for reify boilerplate. Turned out well there I think.
10:09 rhickey_: supporting interface implementation in datatypes definitely complicates things, but I have looked at it
10:10 tmountain: just curious... how soon should we realistically expect to see cinc?
10:10 rhickey_: In the end I decided that reify still had the problems closures do, the data is opaque and inaccessible to all but the code created at the same time, thus inextensible
10:12 if I bring interface implementation support to datatypes it will be strictly curtailed to interfaces only, none of this abstract/super/protected junk
10:12 implementation inheritance is truly a mess
10:14 saml: is it easy to replace some java classes with clojure without letting the team know?
10:18 Chousuke: saml: if everything uses interfaces, maybe... otherwise, maybe not :P
10:19 saml: this code makes me want to go home
10:21 rhickey_: tmountain: not until after the mechanisms are in place to avoid Java - reify, protocols and datatypes are about that.
10:24 tmountain: rhickey_: just perusing the Datatypes wiki page... it's very cool to see even more performance enhancements coming down the pipe
10:28 AWizzArd: rhickey_: will you implement datatypes using newnew?
10:29 rhickey_: AWizzArd: no, they represent a different approach to the same issues, more finely sliced even than new new.
10:38 RomanRoe: Is it possible to store the vector used in a binding in a var for reuse? E.g. (def myb '[*a* 1]) & (binding myb ...) ?
10:42 rhickey_: RomanRoe: no
10:43 compile time is about forms, and runtime about their values
10:44 chouser: saml: yes, you can use gen-class and gen-interface to make a very clean Java API so that users of your classes don't need to know it's implemented in Java.
10:45 rhickey_: protocols+datatypes could replace reify, couldn't they? But that's not the plan because reify will still perform better?
10:46 rhickey_: chouser: what protocols + datatypes are missing is a bridge back to Java interfaces, esp. consumption from Java
10:46 perf-wise I expect protocols to be competitive if they don't get laden with more dynamicity :)
10:47 dataypes are raw Java classes
10:47 smae perf
10:47 same
10:47 RomanRoe: rhickey: thanks. would it work if I create a macro the wraps the binding macro?
10:48 rhickey: guess I simply have to try ;-)
10:48 chouser: rhickey_: so might reify be cut yet?
10:51 rhickey_: chouser: I see two things needed - some story for abstraction in Clojure proper (current best idea - datatypes + protocols). That might include interface implementation in datatypes, but I strongly desire not pulling in Java semantics. The other is uber-proxy, and reify is mostly there.
10:52 so uber-proxy could get all the host badness, super stuff, protected access etc, and better perf than current proxy. It certainly is what people expect of proxy
10:52 and there (proxy), closures make sense
10:52 then datatypes might get interface impl only, no superclasses, no closure
10:53 proxies remain anonymous, datatypes have useful explicit names
10:53 proxies have limitations of interfaces, datatypes don't
10:54 so good coverage of space
10:55 but I'm not focusing on the interop (proxy/gen-class) part since I want to do any enhancements to those in cinc - I'm tired of writing Java
10:55 chouser: ok, so current plans for reify have changed to not be used for native design, just interop. datatype+protocol is your current thrust for cinc.
10:56 rhickey_: chouser: yes, I'd really like for Clojure's extensibility/abstraction story to not suffer the expression problem
10:57 yet be high-enough perf to define the language itself in
10:58 so you need raw, accessible, data, Clojure is already fast at manipulating that
10:58 chouser: right, you just need a way to define it: datatypes
10:58 rhickey_: primitive args will be needed to allow high-perf code to cross function boundaries
10:59 but most altering fns create a new structure, so ordinary fns fine - after all we are going through ordinary fn > RT dispatch -> interface right now
11:02 cgrand: and with protocols that would be fn > protocol dispatch > fn. Right?
11:02 patricius_: Hi. I've been searching the net, but I can't find a clear explanation of the difference between the send and send-off functions. Can aynone explain?
11:02 I think the documentation is a little vague.
11:03 chouser: patricius_: send is for actions that are CPU-bound. send-off is for actions that might block such as on IO
11:03 patricius_: ah, thanks!
11:04 RomanRoe: patricius_: http://
11:04 patricius_: RomanRoe: thanks
11:05 Chousuke: this bootstrap stuff is giving me a headache
11:05 rhickey_: cgrand: yes, protocol dispatch built into first fn
11:06 chouser: patricius_, RomanRoe: note that there are implementation details in that article that are subject to change. This can aid understanding, just don't assume it will all remain true indefinitely.
11:08 RomanRoe: chouser: to put it in other words: when in doubt, check the source, right? ;-)
11:09 chouser: RomanRoe: well ... I was sort of going the opposite way. Check the source for *current* behavior, but rely on official docs (docstrings, clojure.org, rhickey in #clojure) for what constitutes the contract and is more likely to remain true going forward.
11:09 Chousuke: I get so far that Clojure tries to compile itself using my reader, but then explodes in the init of the ClojureReader class with the exception java.lang.UnsupportedOperationException: read (clojure.reader.ClojureReader/-read not defined?)
11:10 cgrand: rhickey_: ah ok, so fn > fn with the protocol built into the first fn for perfs.
11:10 Chousuke: and I have no idea what it's doing :(
11:10 chouser: for example, nowhere does Clojure promise that send will use a pool of threads of size CPUs+2. That happens to be true, but the formula could be tweaked at any time.
11:10 What will remain true is that send will be appropriate for non-blocking actions, and send-off for blocking ones.
11:12 RomanRoe: chouser: yep, makes sense
11:13 cgrand: rhickey_: another question (sorry to bother you), what about volatile and mutable fields? They are required for reference types, lazyseqs and transients.
11:15 patricius_: Does anyone know of an article about Clojure that I can do a 25 minutes presentation over? I'm attending a programming languages course and every student needs to present a couple of articles on programming languages and associated technologies.
11:17 chouser: patricius_: needs to be a published article, like in a real journal?
11:18 patricius_: Not necessarily.
11:19 chouser: We've had a tutorial on SmallTalk presented, which never apperead in a journal or something like that.
11:20 chouser: patricius_: there are quite a few blog posts out there that might be 25-minute size. were you hoping for a language introduction, or just some interesting feature or problem solved in Clojure?
11:22 patricius_: chouser: Well, I think an introduction to the language would be good. A detailed explanation of the concurrency features would be nice as part of that. We haven't seen a Lisp dialect in the course yet, and since I'm working with concurrent languages as part of my semester project, I think Clojure could be nice to present. In any case, my teacher will have the final decision in deciding whether the article (or website or whatever) is good enough.
11:26 chouser: perhaps the clojure tutorial here will do: http://
11:26 chouser: but it maybe too long
11:26 chouser: yeah, maybe.
11:29 patricius_: chouser: anyhow, thanks for your help
11:34 rhickey_: cgrand: no bother. I'm trying to see if a nested mutable thing (a la j.u.c.Atomic*) is good enough for the base mutability case
11:34 I'd really like to avoid plain "holes" in datatypes
11:35 with reify they would have been bottled up pretty well, with datatypes not at all
11:36 cgrand: ok so better push them in host-dependent code than pollute datatypes
11:37 rhickey_: cgrand: exactly
11:38 but there may be cases where the extra alloc is prohibitive
11:41 cgrand: rhickey_: thanks, things begin to fall into place
11:43 Licenser: hmm hmm hmmm
11:43 you are discussing thins that sound interesting :)
11:57 AWizzArd: Can (load my-path) accept compiled .class files, or only .clj files (or both)?
12:05 Chousuke: ooh
12:06 after adding a hideous hack to RT.java, the reader actually works
12:06 though, it throws an exception reading core.clj
12:07 AWizzArd: Chousuke: to get your own reader you had to change existing code yes?
12:07 I mean, not just writing a new .clj file, but editing the Clojure files themselves.
12:08 Chousuke: yes.
12:09 I have a hideous hack in RT.java involving using *warn-on-reflection* as a switch to force recompiling classes *but* not all classes ;(
12:10 it turns out that when I want to recompile clojure.core using my reader, it goes and recompiles my reader as well, and... boom.
12:10 AWizzArd: Is there something like CLs defvar in Clojure? That is: (defvar x 10), x ==> 10, (defvar x 20), x ==> still 10. (I know about the defvar in Contribs "def", but this isn't doing what I want).
12:10 Chousuke: defonce
12:11 AWizzArd: good
13:33 Chousuke: hm, interesting
13:34 I apparently managed to compile clojure using my reader now, but the result fails with "Invalid method Code length 89075 in class file clojure/core__init"
13:39 hiredman: :(
13:50 mattc58: hey are there any good canonical network programming libraries out there I could use as a model for something I'm doing? Not just a toy example but a real driver for something.
13:51 i'll be writing a Clojure library to another app that has a well defined protocol specification
13:51 btw, hello everyone
14:05 kmurph79: the current clojure doesn't seem to be compiling -- anyone else have this problem?
14:06 tmountain: mattc58: have you looked at clojure.contrib.server-socket ?
14:06 Chousuke: kmurph79: works for me
14:06 mattc58: tmountain: yes I have and I've used it a bit to get going. looking more for another network library that goes against an API that someone else has already created.
14:07 rhickey_: kmurph79: ok here
14:07 tmountain: mattc58: something like apache MINA?
14:08 kmurph79: thanks, maybe i have a bad ant or java
14:10 mattc58: tmountain: is there a clojure library for it? i'm unfamiliar with it but looking at the site now.
14:10 cemerick: mattc58: are you looking for something like python's twisted?
14:11 mattc58: cemerick: no, what I'm doing precisely is playing around with MongoDB and a couple other databases. no clojure drivers exist for it, so I might do that. so, it'd be a lot of network / socket programming against their API.
14:12 tmountain: mattc58: I believe you'd have to wrap the Java calls to use MINA, but I've heard it's a good bet for blackbox networking applications
14:12 cemerick: mongo doesn't have a REST or thrift api?
14:13 mattc58: there is a REST API in dev, but the normal way of using it is through native apids
14:13 apis
14:13 there's a java, for example that i could just wrap
14:13 rhickey_: mattc58: usually the easiest way to go is to wrap the Java API
14:13 he
14:13 heh
14:14 cemerick: more than easiest -- code reuse and all that is a good thing :-)
14:15 rhickey_: http://
14:16 mattc58: yeah i saw that actually
14:16 rhickey_: I spoke with Geir last fall and gave some input on making the Java driver collection-class savvy, and thus pretty transparent for langs like Clojure which use those interfaces
14:19 cemerick: rhickey_: any chance I could convince you to add a nbproject/private/ line to clojure's .gitignore? The constant merge failures on .gitignore are more frustrating than I'd like to admit.
14:20 adityo: ,(Float/parseFloat "59641879")
14:20 clojurebot: 5.964188E7
14:20 rhickey_: cemerick: sure just put up a patch
14:20 cemerick: rhickey_: great, thanks.
14:21 mattc58: as a general statement then, are we saying that if a good Java API exists that we should simply use that, and not create new Clojure software for the same purpose?
14:21 adityo: how do i get the entire representation i.e 59641879.00
14:22 mattc58: as I use Mongo more for a project I'll determine if that actually works well in practice (it should in this case)
14:23 cemerick: mattc58: There are differing philosophies there. IMO, if the java API is well-supported and does the job, you'll benefit a lot from whatever community exists there.
14:24 rhickey_: mattc58: there are shades of gray. I'd certainly use a Java lib before writing to a wire protocol. OTOH, a lib might benefit from some Clojure-specific wrapping. Most JAva libs will have had much more use than a fresh Clojure lib, and getting leverage out of that is a big benefit for Clojure.
14:24 cemerick: If the API in question isn't clojure-friendly in some way, then it's definitely a judgement call.
14:25 rhickey_: so, it's rarely worth reinventing the lib's heavy lifting, just a question of wrap or use directly
14:26 mattc58: yeah, this all makes sense to me. ok thanks, exactly what I was looking for.
14:27 cemerick: I *almost* feel bad dispensing such advice as I dump a metric ton of legacy java code for new clojure goodness, but I have a special situation. :-)
14:27 chouser: cemerick: there's a big difference between java code that others are voluntarily maintaining, and maintaining your own .java code.
14:28 rhickey_: hmm... (deftype Name [interfaces-only] [fields] [interfaces' + Object methods a la proxy]) is doable, with more efficiency than proxy, and all written in Clojure a la proxy
14:28 with dynamic update of method defs without reload
14:28 cemerick: chouser: very, very true.
14:29 * chouser says that as he eyes dumping a couple dozen C++ classes for new clojure goodness.
14:29 chouser: rhickey_: how more efficient than proxy?
14:30 rhickey_: the biggest overhead for proxy are construction-time instantiation of fn/closure per method, plus map lookup on call, both can be eliminated for deftype
14:31 since fns would be once for entire class, and coud be stored in static fields of class, so no map lookup on call
14:32 cemerick: rhickey_, the biggest tease on freenode ;-)
14:32 liebke: adityo: do you want to change the number representation for the purposes of printing? (format "%.2f" (Float/parseFloat "59641879"))
14:32 rhickey_: but still could be dynamic, since deftype will just generate (set! DefTypeClass/methodfnfield (fn [this]...))
14:33 adityo: liebke: exactly what i wanted..thanks :)
14:33 rhickey_: as long as you don't change fields or interfaces, no reload required
14:33 liebke: adityo: you're welcome :)
14:34 rhickey_: this way no one would be forced off deftype in order to comply with JAva interface, also path to supply equals/hashCode/toString for deftypes, often needed
14:36 chouser: does no construction-time closure mean no closures at all for deftype?
14:36 and yet method fns?
14:37 rhickey_: when you say proxy for a class with 5 methods, 6 objects are created right then, with deftype 5 fns will be created when you say deftype, and only the one object when an instance of that type is created
14:38 those fns could be closures, doesn't matter, but I don't imagine deftypes at other than the top level too often
14:38 but first-class fn per method, just shared for all instances
14:38 chouser: ah.. I see. by splitting def and ctor you can of course reduce ctor-time work.
14:39 rhickey_: right, deftype isn't about creating an instance at all, where proxy gave each instance its own set of fns
14:39 so put the fns in static fields
14:39 no lookup, still swappable
14:40 chouser: so interesting. by bundling the data in the object (like normal java objects after all) you remove the use case for instance closures
14:40 rhickey_: proxy will still be a better fit when you want closures, for handlers etc
14:40 also proxy had per-instance swappability, rarely used
14:41 chouser: and by making the methods swappable (for all instances simultaneously, right?) you remove the staticness of java classes (or even hypothetical named reify classes)
14:41 rhickey_: right
14:42 * rhickey_ prepares for massive hack of proxy...
14:43 chouser: but still no access to protected fields
14:43 oh, but this is for datatypes -- native clojure, not interop
14:43 rhickey_: the only remaining overhead will be boxing in/out of fns when needed, but if ever there was a candidate for escape analysis that's it
14:43 right - what protected fields? :)
14:44 since no lookup, can inline right into fn bodies
14:46 chouser: (.invoke @MyClass/methodFn this arg1 arg2)
14:46 ?
14:47 rhickey_: right, no @
14:47 chouser: oh ... not an atom?
14:48 lock?
14:48 rhickey_: no, volatile
14:48 last-one-in-wins replacement
14:50 never read-then-write
14:50 chouser: ok
14:52 rhickey_: this seems to fit together well now
14:54 lisppaste8: rhickey pasted "deftype with interface support" at http://
14:54 neotyk: ~logs
14:54 clojurebot: logs is http://
14:56 * cgrand never liked the implicit 'this in proxy
14:58 lisppaste8: rhickey annotated #88999 "deftype with interface no this" at http://
14:58 rhickey_: cgrand: this can be autohinted, without it you're left with this first pass ^^
14:59 liebke: I like that better, explicitly passing 'this
15:00 rhickey_: liebke: and writing both 'this' and that hint over and over?
15:00 In proxy I agree could be more of an issue due to potential nesting, less of an issue here at top level
15:01 liebke: I wouldn't like to write the hint over and over, but writing 'this' over and over is fine with me :)
15:02 rhickey_: liebke: well, people won't write the hint, then will complain Clojure is slow, also won't remember this, since they will be looking at docs without it
15:02 but ok, 2 for explicit this, any other views?
15:03 liebke: true, the fundamental problem with programming language design is people :)
15:03 danlei: I agree that it should be implicit
15:03 chouser: there's middle ground -- [(equals [this that] ...)] would still allow for auto-hinted this
15:04 rhickey_: chouser: yes, the macro could retrofit the hint
15:04 chouser: on the other hand, if the map in the second example were eval'd, that would make merging in some implementations pretty easy.
15:04 cemerick: yeah, some good old-fashioned tree-walking :-P
15:05 I'll generally lean towards explicit this, FWIW.
15:05 rhickey_: chouser: yes, that second example was following the newer approach of protocols aimed at easier reuse of impls
15:06 Licenser: You know what is one thing that clojure misses, a good Textmate integration :/
15:06 rhickey_: of course, with the map approach adding hints is not possible
15:06 chouser: right
15:06 danlei: for me the major point is that nesting at toplevel won't be much of an issue. what would be the benefit of explicit this?
15:07 Licenser: I know it sounds stupid but in the OS X world a lot stands or falls with this :(
15:07 danlei: besides being ... well ... explicit
15:07 cemerick: Licenser: you mean TM integration?
15:07 Licenser: cemerick: a good bundle that is easy to install / use. something that
15:07 'just works' Sorry sully return key
15:07 chouser: Licenser: http://
15:08 dunno anything about textmate, but google does. :-)
15:08 That's almost a year old -- is that a good sign, or bad?
15:08 Chousuke: hm
15:08 Licenser: chouser: a bad sign
15:08 arsatiki: GetBundles installs the wrong clojure bundle by default
15:08 Licenser: the bundle you can get with GetBundles is horribly broken
15:09 arsatiki: the more recent version from github works so much better
15:09 Chousuke: I wonder what's causing core__init.class to become 265kB in size :(
15:10 cemerick: I'm really surprised that anyone uses TM for clojure.
15:10 Licenser: The first time I instaled clojure, and set it up in TM I had to hand fix the bundle to even work somewhat propperly - a pain that I really don't want to go through again.
15:10 cemerick: 'course, there's vi folk here, so....
15:10 * cemerick ducks, runs
15:10 Chousuke: I don't know nearly enough about the JVM to debug this...
15:10 Licenser: cemerick: You get used to TM once you start, I didn't belived it myself
15:10 cemerick: Licenser: I use it for one-off editing, but never for sustained development.
15:10 Licenser: cemerick: I usually use VI for a lot but TM just integrates so nicely into OS X that it's something you don't want to give away again once you tried it
15:11 arsatiki: I've generally found myself more and more dissatisfied with TM lately
15:11 cemerick: Chousuke: what's the error?
15:11 rhickey_: it seems to me that forgetting 'this' is a common bug for users of gen-class
15:11 arsatiki: Probably has to do with the fact that TM crashes for me almost daily now.
15:11 Licenser: cemerick: what are you using for long term things?
15:11 Chousuke: cemerick: the class is too big, simply
15:11 cemerick: JVM has a 64k limit on class files
15:12 cemerick: and I go 201kB over that.
15:12 Licenser: I used Aptana (Eclipse) for a while but I had some very annoying things with it which made me keep my hands of it
15:12 Chousuke: the verbose decompilation dump is *3.5MB*
15:12 Licenser: Chousuke: heh I had this problem with JRuby once - was very frustrating
15:13 cemerick: Chousuke: hrm, my core__init.class is 220K...but I'm not getting any errors.
15:13 Licenser: Netbeans + enclojure.
15:13 Licenser: cemerick: I'll try that one then - gladly I'm not the person that refuses to try new things :P
15:13 bballantine: cemerick, Licenser - sorry to butt in -- I think the clojure eclipse plugin (counterclockwise, I think it's called) is young but good.
15:14 Chousuke: cemerick: ah, right, it was just "invalid method code length"
15:14 it looks like it's ~20k over the limit :/
15:14 Licenser: bballantine: I've no clue, I used eclipse with Ruby not clojure
15:14 cemerick: We use NetBeans RCP, so eclipse is irrelevant for us.
15:14 bballantine: Licenser, I've used Aptana as well (for ruby on rails) and hated it. I use eclipse for all java-related stuff and really like it.
15:15 cemerick: Good luck to 'em though.
15:15 Licenser: bballantine: it looked like a good choice since in the project half the team (or most of it) were poor windows users
15:15 bballantine: i now mostly use VI for small stuff and ruby, I use eclipse for java and big python.
15:15 Chousuke: I think I'll check how big the regular clojure class file is
15:16 The-Kenny: Nacht
15:16 Chousuke: hmm, right. 216kB for me
15:16 The-Kenny: sorry.. wrong window
15:16 Licenser: Nacht The-Kenny schlaf gut
15:16 The-Kenny: Licenser: heh, I'll stay. A friend of me will go to bed now ;)
15:17 bballantine: Licenser - also, eclipse works much better on Linux than OS X for whatever reason.
15:17 Licenser: Ah well even better :)
15:17 bballantine: yes that is something we found out too
15:17 Chousuke: any ideas on how to make it smaller?
15:17 Licenser: Chousuke: remove comments? *hides*
15:18 rhickey_: Chousuke: have you got some huge data literals in there?
15:19 lpetit: counterclockwise will have its next release make it beat up emacs, vimclojure, La Clojure and netbeans so hardly that they will not be able to reach its level without a lot of dev effort.
15:19 no, it's an easter egg, of course :-)
15:19 Licenser: so the SOTA for editing clojour is the enclojure plugin and netbeans?
15:20 lpetit: What's great about clojure IDEs is that there is room for everybody
15:20 You can just keep using your preferred IDE
15:20 Licenser: I'd preffare TM since I got used to it and like how it functions
15:20 saml: notepad + clojure.jar
15:21 Licenser: saml: when I try to run notpad.exe it tells me it isn't a executable
15:21 lpetit: If you don't have any constraints, and any preferred IDE, then I would suggest to try enclojure which seems to be currently both the more advanced in terms of functionality and in terms of "user friendliity"
15:21 lisppaste8: rhickey annotated #88999 "deftype with interface explicit this" at http://
15:21 saml: it's because you missed e for excellence
15:21 lpetit: But if eclipse is your IDE, counterclockwise is good enough for you, already, and will improve over time
15:22 Chousuke: rhickey_: well, it's core.clj, just compiled using my reader...
15:22 saml: i installed cljoure plugin for eclopse
15:22 Chousuke: rhickey_: it seems the init method is doing a Symbol.create and Symbol.intern for pretty much every symbol. :/
15:24 rhickey_: Chousuke: why would it be different than the Clojure reader?
15:25 Licenser: lets see now netbeans works
15:25 Chousuke: rhickey_: beats me. Maybe it's the horrible loading hacks and workarounds I put in RT.java to get it to actually compile in the first place...
15:26 liebke: rhickey: I think I like the map version better just because you pass it an actual fn, and not the 'proxy'-like method specification
15:27 rhickey_: liebke: I think the manual hinting that will require will be unbearable for many people
15:27 Chousuke: rhickey_: I had to convince it to compile a namespace that's already loaded :/
15:27 liebke: that is probably true
15:27 mwoelker: Hi there everyone, my email regarding side-effect free AOT compilation still hasn't gotten any responses and I was wondering if it's just considered a non-issue or if I did something wrong or if it has just been lost in the noise
15:29 rhickey_: mwoelker: sorry I haven't chimed in on that yet. Basically the problem is the use of reflection during compilation. That's something I want to move away from, but it will have to wait for clojure-in-clojure
15:30 lpetit: That's a joy to see so much interesting stuff in the pipe !
15:30 Chousuke: http://
15:30 jlilly: rhickey_: I'm not overly familiar with the implement x in x efforts. My impression was that they were mostly academic. What are your expectations for clojure-in-clojure?
15:30 mwoelker: rhickey_: but it should be possible to replace the reflection with some asm equivalent?
15:30 * hoeck1 votes for implicit "this" (in deftype)
15:31 rhickey_: jlilly: I want to stop having to write/maintain Java, especially when trying to enhance Clojure. Also ports will be greatly facilitated by having the bulk of the compiler and data structures written in Clojure
15:32 mwoelker: yes, something that looks at jars
15:32 jlilly: rhickey_: I suppose it doens't introduce performance concerns b/c its compiled.
15:32 rhickey_: jlilly: the exercise has also highlighted a missing piece of Clojure - it is built on abstractions but doesn't provide a mechanism for defining same other than Java's
15:33 so it is driving this protocols/datatypes design, which will be a great enhancement to Clojure
15:33 drewr: rhickey_: wouldn't I still have a hard time writing clojure in C because the interop is so Java-centric?
15:33 jlilly: my previous experience (mostly just hearing of it) was w/ the python & ruby communities. I guess they face a different set of problems w/r/t being dynamic.
15:33 drewr: or maybe implementing the language would be feasible, but using it would be quite a different experience
15:34 rhickey_: drewr: the design presumes some object system a la Java/CLR but JavaScript and Obj-C are also doable
15:34 making it easy to port to C is a non-objective
15:34 C being bereft of facilities
15:34 drewr: ok, so C was a bad example
15:35 wouldn't the interop on obj-c make it a very different language?
15:35 cemerick: drewr: chicken scheme could probably get you to a native executable
15:35 rhickey_: it really requires very little, and deftype/protocols make it clear how little
15:35 cemerick: native + cross platform, that is
15:35 drewr: as a trivial example, clojure would need to provide a wrapper around .toUpperCase, right?
15:36 not that it wouldn't be nice to have a clojure string lib
15:36 rhickey_: drewr: there would be things like that, and I imagine we'll go through to encapsulate some of that. But writing portable apps is also a non-objective
15:37 the whole point of moving to a different host is to leverage that host
15:37 wrapping all hosts defeats a purpose of Clojure
15:37 so some core facilities and libs will port, other than that each app should/will touch the platform directly
15:38 drewr: makes sense
15:38 rhickey_: but say a consultant wouldn't have to switch language to move to different client targets
15:39 hiredman: dmiller is looking at porting contrib to clojureclr
15:39 which will face a lot of .toUpperCase kind of stuff
15:40 http://
15:46 rhickey_: hiredman: comparable facilities are definitely there (especially on CLR) so it's just a matter of encapsulation
15:46 hiredman: sure
15:47 mwoelker: rhickey_: Another issue that was recently raised on the ML was joint compilation with Java or other JVM languages. Without going into to much detail, what's clojure story for that topic?
15:47 rhickey_: he end result will be core + a substantial portion of contrib will be portable
15:48 mwoelker: that's a hard problem - essentially you have to start compiling Java. I'm hoping maybe some frameworks will fall out of the IDEs which do that.
15:48 hiredman: headius there was talk of a "super compiler" at the jvm lang summit
15:48 said
15:48 rhickey_: right, there was talk of that, but it may be hard to generalize
15:49 especially to any combination of langs
15:50 hiredman: :/
15:51 mwoelker: what about the two pass stub compilation approach, just assume all symbols/classes/methods can be resolved in the first pass and generate appropriate class skeletons, and on the second pass (when all other class skeletons are there) do the actual semantic analysis?
15:52 hiredman: I know Chousuke was/is running to issues with bootstrapping his cinc reader into clojure
15:52 (I ran into some too when I was messing with it)
15:53 but metacicularity makes my head hurt
15:53 rhickey_: mwoelker: as I said, it means moving away from reflection as the means to determine class facilities, What the replacement is is an open question - ASM won't help you until you have class files, doing a prep-pass requires static analysis which is possible for Java but much less so for Clojure, where macros can hide anything
15:54 there are disciplined ways to ease the pain, rigorous use of interfaces, splitting gen-interfaces into their own files etc
15:55 mwoelker: rhickey_: as a newcomer to lisps, I guess I still haven't quite wrapped my head around how powerful macros really are...
15:55 rhickey_: but the general case is unsolveable as (gen-framework foo) could read a database and expand into anything
15:55 cemerick: wow, contrib is up to 3.2MB, compiled :-|
15:58 mwoelker: rhickey_: Well, the macro could still create the appropriate skeletons on the first pass, and the actual method bodies on a second pass. One would have to hope that the DB isn't messed with in the meantime...
15:59 hiredman: there is a lot in contrib
16:01 rhickey_: mwoelker: that's not the way a Lisp works.
16:02 cemerick: indeed. The diagram you linked to earlier is a little staggering. Has anyone put together a linker yet? (for lack of a better term)
16:02 stuartsierra: rhickey_: And I've written some gen-framework's :)
16:02 hiredman: cemerick: package manager?
16:02 mwoelker: rhickey_: I feared as much. So what else is there? Iterative compilation until a fixed point is reached?
16:03 cemerick: hiredman: no -- given a top-level, determine ns dependencies, and only package those into the jar, etc.
16:03 hiredman: oh
16:04 cemerick: mwoelker: are you knocking up against layered language dependencies?
16:04 rhickey_: mwoelker: it's a tradeoff of a Lisp that the dynamism hurts static analysis, but you can't superimpose a compilation model - there's one built in and it involves running arbitrary user code
16:06 it may be the case that you only need to statically analyze one half (the Java bit)
16:06 that would ensure Clojure compilation could proceed
16:06 technomancy: why does defn support metadata maps in two positions? (before the name vs after the body)
16:06 rhickey_: then patch and finish Java compilation
16:07 technomancy: before the name doesn't have anything to do with the syntax of defn, that's just adorning the name
16:07 mwoelker: rhickey_: Coming from a more "static" background, I am just afraid this lack of joint compilation might hinder wider acceptance and adoption
16:07 technomancy: oh, right that's a read-time thing.
16:08 rhickey_: mwoelker: quite a bit of useful things can be built without circularity
16:08 mwoelker: rhickey_: well it wouldn't even have to be circular, just lots of layers of clojure/java/... code
16:09 cemerick: mwoelker: it's pretty rare for joint compilation to be a hard requirement. The workarounds are generally very straightforward.
16:10 mwoelker: cemerick: so the solution would be to partition code into subprojects (written in only one language) and have the build tool figure out the right compilation order based on the dependency analysis?
16:11 cemerick: mwoelker: I can't imagine bothering to get so fancy. You've got some existing libs, presumably written in java. Make a new project that depends on those libs, written in clojure. Given the existing interop features of clojure, that handles 90% of the use cases.
16:12 Beyond that, you can use gen-class to wrap clojure libs so that they look just like Java from Java or other JVM langs. Package that up into a jar, and you've got Just Another Java Dependency.
16:12 mwoelker: That sounds like a good plan, I guess the case I was worried about was porting applications bit by bit (or even only just replace Java code with clojure in certain places), think polyglot programming, but I have to admit that may be quite an edge case
16:13 rhickey_: mwoelker: but that code, if properly written, will have interfaces defined on the Java side. It will be able to call Clojure code that implements those interfaces without a compilation dependency
16:13 cemerick: All of our projects are hyrid, about a 95/5 clojure/java mix. If the dependencies go in the right direction and you just set up the clojure compilation to happen after the java compilation, you're golden.
16:14 hybrid*
16:16 mwoelker: Okay, that should work. Thanks a lot for your insights and the discussion (and last not least patience). It is much appreciated.
16:16 chouser: We have java, C++, clojure, python, jruby, and protobuf code with interdependencies. It isn't pretty, but each component knows how to build itself and declares its dependencies to be built first. Hasn't been much of a problem.
16:17 this is all using cmake which I would not, by the way, recommend. At all.
16:17 mwoelker: chouser: wow that sounds like a boatload of fun
16:18 chouser: heh. yeah.
16:18 rhickey_: so, no consensus on these: ? http://
16:18 mwoelker: chouser: heh I was just about to ask what you were using, just in case I ever got into unenviable position to working with such a mixture...
16:18 chouser: I don't think we have any C++ that depends on anything JVM, or anything that depends on the python or jruby.
16:19 cemerick: chouser: Ouch. Like, ouch. :-/
16:19 chouser: but all the rest is pretty mixed up -- jruby that needs java that needs clojure that needs more java and c++
16:19 hiredman: really, I liked datatypes as just containers with no attached methods
16:19 rhickey_: hiredman: the methods are only if you need to implement interfaces - you can't define any other methods
16:19 cemerick: hiredman: I think the method impls are totally optional, right rhickey_ ?
16:20 rhickey_: cemerick: right
16:20 cemerick: I prefer #3, with the type hinting done automagically.
16:20 rhickey_: strictly for interfaces, equals/hashCode customization, which must be in class
16:20 mwoelker: rhickey_: FWIW I prefer the "autohinted this" version
16:21 chouser: I guess I have a slight preference for autohinted explicit this.
16:22 I can see an eval'd map being handy at times (to avoid otherwise potentially messy macros) but not sure if it's worth supporting both.
16:22 rhickey_: geez, you guys have been doing FP for too long :)
16:22 hiredman: sounds like a quorum
16:23 rhickey_: think about the poor folks coming from Java, never had to declare this before...
16:23 * hiredman is on the simon jones interview in coders at work
16:23 mwoelker: that would be me I guess
16:23 cemerick: doesn't ruby have explicit this?
16:23 obviously, python does, and people manage
16:23 chouser: python does
16:23 yeah
16:24 wtetzner: is there a way to give type hints in code that's generated by macros?
16:24 hiredman: well, if python does it, lets do the opposite
16:24 cemerick: I'm surprised there's no into!
16:24 (yet)
16:24 rhickey_: ut this is a bridge/interop thing where the interfaces are declared in Java as taking x, not this,x
16:24 but
16:25 cemerick: of course, that's just so much sugar :-)
16:25 rhickey_: into! ?
16:25 Chousuke: hoh
16:25 Kjellski: Hi there =)
16:25 Chousuke: now I got the size reduced
16:26 turns out duplicating every object with line metadata added was kind of... bloating the whole thing
16:26 however now I have another error :P
16:27 it's not finding the ClojureReader.read() method, and disassembly of the classfile shows a clojure.core$read__1264@32486cdd(java.io.PushbackReader, java.lang.Object);
16:27 and... what? :|
16:28 rhickey_: how about - if you don't supply this, and call it 'this', then the macro will supply it?
16:28 user preference
16:29 mwoelker: might make it harder to read other people's code...
16:29 cemerick: just think of the poor fellow who calls the first argument 'me', but binds 'this' to something else in the impl
16:29 rhickey_: sure, something like (defn into! [tc coll] (reduce conj! tc coll)))
16:30 rhickey_: cemerick: oh, for transients, but into uses a transient inside already
16:30 lpetit: I think I also slightly prefer "deftype with interface explicit this".
16:31 cgrand: rhickey_: how do you know that this is missing when methods are overloaded?
16:31 and I prefer explicit auto-hinted this (no surprise)
16:31 lpetit: "explicit auto-hinted first arg"
16:32 yes really, KISS
16:32 is it me saying that ? :-)
16:33 hiredman: Chousuke: how did you end up getting around the load being undefined thing
16:33 rhickey_: cgrand: overloaded by arity will have this in each sig
16:34 cemerick: rhickey_: oh, I see what's going on. I guess I'll just have to internalize that persistent! and transient are O(1)?
16:35 rhickey_: cemerick: yes, that's the beautiful thing
16:36 hiredman: lisppaste8: url
16:36 lisppaste8: To use the lisppaste bot, visit http://
16:38 hiredman pasted "incremental reader replacement" at http://
16:39 hiredman: so then once a clojure implementation of StringReader was read in and compiled, clojure.core/STRING-READER could be redef'ed to the clojure version
16:43 * danlei converts to autohinted explicit this, after thinking about it
16:44 chouser: I think I dislike the optional "this" more than I dislike the implicit "this"
16:44 danlei: yes, I don't like that either
16:45 a bit too much magic for my taste
16:45 chouser: I'm trying to remember how many confused comments I hear from people forgetting 'this' in gen-class fns vs. people asking how to get at 'this' in proxy.
16:46 There have been a few of each -- I don't think overwhelming either way.
16:46 lpetit: having explicit arguments everywhere would seem more FPy and consistent with the rest.
16:47 hiredman: gen-class's case is more frustrating because by the time you get to that point with gen-class you have been suffering for a long time
16:47 chouser: hiredman: heh. yeah.
16:47 lisppaste8: rhickey annotated #88999 "deftype explicit this, leaner, cleaner?" at http://
16:48 hiredman: looks like new new
16:49 rhickey_: with this, a simple struct-like thing can just be (deftype my.Struct a b c)
16:49 danlei: getting rid of one nesting level ready more clojury for me, at first impression
16:49 s/ready/reads
16:50 chouser: require all fields before any methods?
16:50 danlei: I like it
16:51 rhickey_: chouser: dunno, the way this works it's keying of symbol/seq/key, could be intermixed
16:51 It present extensibility issues, but the key is an escape hatch for more verbose things
16:51 hiredman: I know protocols vs. multimethods was hashed over a lot yesterday, what bout deftype vs. new new
16:52 technomancy: ,((fn [& args] args))
16:52 clojurebot: nil
16:52 technomancy: shouldn't that be an empty seq?
16:52 hiredman: ,(empty? nikl)
16:52 clojurebot: java.lang.Exception: Unable to resolve symbol: nikl in this context
16:52 hiredman: ,(empty? nil)
16:52 clojurebot: true
16:52 chouser: technomancy: & is next, not rest
16:52 technomancy: hiredman: smells like CL to me. =)
16:53 rhickey_: hiredman: imagine new new becomes a better proxy, access to supers, protected etc, and faster
16:53 technomancy: I guess I'm just not used to being able to use nil in seq-ish contexts
16:53 chouser: ,[(first nil) (rest nil) (next nil) (filter true? nil) (map inc nil)]
16:53 clojurebot: [nil () nil () ()]
16:54 rhickey_: I'd very much like to avoid the verbosity of gen-class with deftype
16:54 hiredman: so new new would have the verbosity of gen-class?
16:54 rhickey_: hiredman: not related
16:54 hiredman: hmmm
16:54 rhickey_: I was referring back to leaner/cleaner
16:54 chouser: rhickey_: I guess you expect :implements to be less common than an empty [] for interfaces?
16:55 rhickey_: chouser: I guess
16:55 chouser: hm, nm. Even if more common I think I like the explicitness
16:55 rhickey_: of coure then implementing a protocol should get a different name
16:55 course
16:56 chouser: considering when used in pure native clojure code, you won't need interfaces -- protocols go on top of deftype, not the other way around.
16:56 lpetit: rhickey: just to understand the limits of your example in lisppaste : what is provided as an example is the expansion of what would be done automatically by deftype if no equals / hashCode was provided (I mean, the example seems to do something very generic)
16:56 rhickey_: chouser: right
16:56 chouser: so yes, I think leaner explicit this is the best yet
16:57 liebke: rhickey_: I like the explicitness of :implements, but my code uses keywords everywhere, so I'm biased :)
16:57 chouser: It would be nice if field names were less obscured by their metadata, but I don't know what to do about that.
16:57 rhickey_: lpetit: I'm still thinking about auto-generated equals and hashCode, but yes, I'd like to avoid having people need to define the obvious right thing for an immutable datum
16:58 cemerick: rhickey_: it would be nice to be able to say (-> [] transient some-fn other-fn (into (get-data)) last-fn persistent!), etc.
16:58 make that into!, of course
16:59 rhickey_: cemerick: I'm not opposed
17:00 cemerick: OK, I'll tinker some more and see if it's really warranted. I'll file a ticket w/ patch based on that.
17:02 rhickey_: chouser: yes, we'd talked here about ethel^int in the past, post deprecating ^
17:03 actually that wouldn't have to wait, presuming no one depends upon ^ being non-constituent
17:04 danlei: rhickey_: if something is a field or method implementation would be decided by whether it's a symbol vs. seq in leaner deftype, right?
17:04 rhickey_: danlei: yes
17:05 trailing symbol meta?? name^{:tag String :alias :foaf:name}
17:05 ethel^int, foo^String
17:06 liebke: I like the trailing metadata, it's seems clearer to me
17:07 lpetit: rhickey: about predefined equals function, could equals (and to some extend participation to hashCode, though I'm not sure if feasible) semantics of fields be placed closer to the fields (in the metadata for the field) if field needs special treatment (e.g. not being considered ?? , being treated as equal by identity, or using a particular function / code snippet) ?
17:08 yes, first introducing the thing, then the metadata to the thing, sounds good
17:08 chouser: leaner explicit this combined with trailing symbol meta would look quite nice indeed.
17:09 all the member names would line up along the left, starting with a paren for methods.
17:09 rhickey_: lpetit: I don't know if the added complexity will be worth specifying that, if the default is good and you can define your own equals easily. Certainly per-field code is out, just ignore/identity/equality flags
17:11 lisppaste8: rhickey annotated #88999 "deftype explicit this, leaner, meta trailing" at http://
17:11 danlei: how about allowing symbols and lists as fields, like this (deftype foo [bar int] ...)?
17:11 s/list/vector
17:11 lpetit: rhickey_: thought about this because I guess except for rare cases, equals will really still be boilerplate, once you define ignore/identity/equality flags. And it's so easy to add a flag and forget to update the equality function.
17:11 to add an attribute, I meant
17:12 rhickey_: danlei: metadata on symbols has a lot of advantages for flowing through macros, and is used everywhere else
17:12 chouser: a bit OT, but evaluation order of things in {} and #{} are undefined, right?
17:13 rhickey_: chouser: probably unspecified
17:13 lpetit: it's interesting
17:15 lpetit: rhickey_: I have no idea if there's something to do concerning the hashCode computation story, though, except that this ignore/identity/equality flag could also serve the default hashCode algorithm !
17:18 hiredman: are def'ed types going to implement one of the meta interfaces by default?
17:18 er
17:18 datatypes
17:18 rhickey_: lpetit: if the default is per-field =, the biggest overrides will be :ignore, something to say :array=, and :identity for objects with broken equals
17:19 hiredman: yes, will get auto meta and with-meta support
17:21 lpetit: rhickey_: yes. And the hashCode default algorithm will be able to altogether ignore the field if :ignore, use object identity in some way if :identity. As for :array=, I dunno
17:21 rhickey_: lpetit: I think it could work, and could inform both equals and hashCode - good idea!
17:22 lpetit: rhickey_: and that would be appreciated even from start from the java guy coming to clojure, which surely will be bored to have to define equals/hashCode pairs (or not to and live with buggy code :) )
17:22 rhickey_: there's System/identityHashCode
17:23 arrays are tricky, since you might need to further specify for their contents...
17:24 lpetit: rhickey: yes, I see java.utils.Array has hashCode functions for arrays of primitive types, and a deepHashcode for arrays of Object types
17:25 rhickey_: ^{:equals :identity|:ignore|[]}, with [] possibly containing nested spec?
17:26 I guess you'd never have nested :ignore, and nested :identity might be rare as well
17:26 so many broken equals in the world though
17:27 lpetit: rhickey_: but for arrays the problem seems to still be symmetric for equals and hashCode in java.utils.Arrays : deepHashcode()/deepEquals(), hashCode()/equals()
17:27 rhickey_: could have nested arrays
17:27 lpetit: right, but we have overrides and will need them for array contents too
17:28 lpetit: rhickey_: "we have overrides" ? I'm not following you here
17:29 rhickey_: lpetit: if you would want to say :identity for a field you might also want to say it fr members of an array field
17:29 serp_: java supports method overloading where the arguments determine what method to call... does clojure?
17:29 rhickey_: deep* hardwire defaults
17:30 serp_: Clojure has multimethods for such overloading
17:30 serp_: I see
17:30 rhickey_: serp_: but not type overloading within fn
17:30 hiredman: ~multimethods
17:30 clojurebot: multimethods is what separates the boys from the men.
17:30 rhickey_: generally considered evil
17:30 hiredman: clojurebot: cute, but not useful
17:30 clojurebot: Titim gan éirí ort.
17:30 rhickey_: (type overloading)
17:31 certainly an interop mightmare
17:31 nightmare
17:31 serp_: I don't know what multimethods are =(
17:32 hiredman: http://
17:33 serp_: hiredman: thx
17:36 lpetit: rhickey_: ^{:equals :identity|:ignore|[]} with [] only relevant for arrays I guess (not a way to a la carte redefine equality semantics of arbitrary datatypes ;-) ? )
17:37 rhickey_: lpetit: right [] for arrays, useful in that it can contain another [] or :identity
17:39 lpetit: rhickey_: ok. sounds good. Not difficult to read, not too difficult to remember. The :equals name, maybe, implies too much that it solely concerns equality (and not hashCode), though it will affect the behaviour of the default hashCode method. But I don't have anything better to offer yet
17:40 rhickey_: defaulting to deepEquals for arrays would be a break with = for arrays, which right now is identity as is anyarray.equals
17:40 but I want deftype to be "right" for immutable by default, so maybe could do deepEquals for arrays
17:41 lpetit: rhickey_: java.utils.Arrays has both Arrays.equals() and Arrays.deepEquals(), even for Object[]
17:41 rhickey_: I agree about equals/hash, but they are supposed to agree
17:42 lpetit: rhickey_: yes, forget, :equals does the job well
17:43 rhickey_: lpetit: deep just handles nesting, which you would want
17:43 if the default was deepEquals for arrays, I think we could just do with :ignore and :identity
17:44 lpetit: rhickey_ : but wouldn't it be a problem for people wanting arrays for performance ? I can imagine by default in clojure people will not use arrays at all, except for performance => and then maybe what they want for hash is a quick System.identityHashCode call
17:44 rhickey_: lpetit: then they will flag the array field with :identity
17:45 lpetit: rhickey_ : oh yes you're right :)
17:47 rhickey_: there's still the Arrays.equals(Object[]) versus Arrays.deepEquals(Object[]). The former is said to be identical to Arrays.asList(Object[]).equals(). Is this worth the trouble having array equality have Arrays.equals(Object[]) by default and a :deep key for Arrays.deepEquals() ? (or the other way around ?)
17:48 rhickey_: lpetit: no, they differ only for nested AFAICT, and I can't see equals for nested
17:49 you wouldn't be able to reach into any Clojure composite like that either
17:49 lpetit: rhickey_: Arrays.deepEquals(Object[])
17:50 rhickey_: ok I've reached my incompetence level here, but I think we've almost closed the deal, haven't we ? :)
17:51 rhickey_: http://
17:52 only differs from Arrays.equals in the nested case, and then, without deep, would compare nested arrays by identity. I don't see the use case, and it wouldn't be possible to distinguish similarly nested Clojure data structures, they always do deep
17:54 lpetit: rhickey_: ok so deepEquals by default, and as far as I'm concerned, the deal is close :) (and that's an opportunity for me to go to bed :) )
17:55 Chousuke: *sigh*
17:55 rhickey_: lpetit: thanks for the input!
17:55 lpetit: Chousuke : grmlml :)
17:56 Chousuke: I'm this -><- close to succeeding in bootstrapping my reader but I hit yet another roadblock with the (load "core_foo") thingies in core.clj
17:56 I can't convince Clojure to recompile them even though they're already loaded :/
17:58 hiredman: :(
17:58 div: rhickey_: I assume that any :equals annotations would be overridden when an actual equals implementation is provided ?
17:58 Chousuke: and as a result the final .jar file won't have the .class files so it won't start because it tries to load the script files using the reader which requires core.clj which require the core_foo thingies...
17:58 hiredman: I have the urge to go home and traipse through src/clojure/lang for the rest of the day
18:00 Chousuke: I think I will need to rip open RT.java and add some kind of a "recompile" function to it.
18:00 rhickey_: div: yes, just ignored
18:00 div: ok, makes sense
18:00 hiredman: Chousuke: have you, uh, touch'ed the files you want to recompile?
18:01 http://
18:01 lpetit: div: so that IDE devs can add a layer of warnings not provided by the compiler :-p
18:02 div: lpetit: yes, a simple warning can go a long way :)
18:02 lpetit: I hope ccw was so advanced that I could start doing such added value stuff. Alas ...
18:03 Chousuke: hiredman: I can't do that, since then it won't load the class files before trying to recompile them :P
18:03 hiredman: hmmmmmm
18:04 Chousuke: hiredman: what I want it to do is, load clojure.core and clojure.lang.reader from .class files generated by the bootstrap process, then recompile everything using the new reader
18:05 but the thing is, it won't recompile clojure.core or clojure.lang.reader because they're already loaded :P
18:06 and if I override that check, it'll *always* recompile all the dependencies... and my head hurts
18:08 hiredman: nice
18:09 Chousuke: oh, and there's more.
18:10 I can't use gen-class to generate a hook for the java side to the reader because if I then during the second stage try to recompile the genclass'd namespace, it'll generate garbage because an existing class of the same name is already loaded (presumably to avoid collisions)
18:10 Licenser: hmm hmm, I
18:11 I've alist like (([1 2] [1 2]) ([1 2] [1 2])) how can I 'flatten' that?
18:11 hiredman: ,(doc flatten)
18:11 clojurebot: "clojure.contrib.seq-utils/flatten;[[x]]; Takes any nested combination of sequential things (lists, vectors, etc.) and returns their contents as a single, flat sequence. (flatten nil) returns nil."
18:12 Licenser: that is too easy darn
18:15 travisbrady: Does anyone have thoughts on what concerns would govern the decision to learn Clojure over Scala or vice versa?
18:16 Chousuke: syntax. :)
18:16 somnium: ~scala
18:17 hiredman: ~tell me about scala
18:17 clojurebot: {((x: Any, y: Any) => (f: Function2[Any, Any, Any]) => f(x, y))(1, 2)((x: Any, y: Any) => x)}
18:18 hiredman: ~scala {((x: Any, y: Any) => (f: Function2[Any, Any, Any]) => f(x, y))(1, 2)((x: Any, y: Any) => x)}
18:18 clojurebot: Any = 1
18:28 rhickey_: updated to reflect today's discussion: http://
18:28 need a new name for implement in protocols?
18:31 Licenser: I've another silly question, I've a function that expects a argument and n vectors (like (fun 1 [1 2] [3 4]...)) now I have those vectors in a list so '([1 2] [3 4]) but passing them that way isn't really liked by the function, how the heck do I pass the function the parameters o.O
18:31 I
18:32 I'm sure there is some super easy and cool way to do that which I don't know about
18:32 Chousuke: apply
18:32 liebke: Licenser: (apply fun '([1 2] [3 4]))
18:32 Licenser: you are my heros!
18:33 thank you a lot
18:33 travisbrady: hiredman: haha, ok, fair enough. I'm thinking more like "Clojure is really good at X" types of things
18:34 but thank you still, i agree Scala syntax can be really ugly
18:34 danlei: rhickey_: what does the "under any name?" wrt this mean? whether other designators may be chosen?
18:36 technomancy: travisbrady: you're unlikely to get an unbiased answer in here, but the fact that imperative code can be idiomatic in Scala but not in Clojure is the biggest thing from my perspective.
18:36 travisbrady: technomancy: ahh, that's helpful actually.
18:37 I've never used a lisp previously, so I'm leaning toward Clojure
18:37 technomancy: travisbrady: also keep in mind that you can read the entire implementation of Clojure in a day or two.
18:37 danlei: travisbrady: I don't know anything about scale, but are data = code and vice versa? if not, I'd consider it a drawback.
18:37 ambient: this is a bit weird: "no matching method found: aset" inside (defn daset [a vals] (doseq [[i j] (partition 2 vals)] (aset #^doubles a i j)))
18:42 danlei: travisbrady: to be more precise: in lisps, the code is made up from s-exprs, lists, and all built-in functionality of the language can be used to operate on that easily
18:43 travisbrady: wow, read all of Clojure's source in two days. cool. Scala is a shorter path in some senses for me since it let's you write really straight up imperative code
18:44 is there anything like sbt for clojure to simplify building and such?
18:44 danlei: you could also write imperative code very well with common-lisp
18:44 and with abcl even on the jvm
18:45 if you *want* to write imperative code, of course
18:46 Chousuke: technomancy: entire implementation excluding the icky java parts, right? :P
18:47 cgrand: ambient: you must fully hint aset
18:47 hiredman: of course
18:47 cgrand: ambient: (aset #^doubles a (int i) (double j))
18:47 hiredman: I don't think the java parts are that horrible
18:47 ambient: cgrand sorry, i just figured out i was giving the function wrong parameters
18:48 technomancy: Chousuke: if you leave out Java it's hours, not days. =)
18:48 Chousuke: hiredman: it's not horrible, for java code :P
18:51 hiredman: it's kind of intimidating, but once you start fitzing with it, it starts to look like clojure code with a lot of noise
18:52 Chousuke: LispReader is a good example
18:52 hiredman: yeah, all those AFns
18:53 Chousuke: it's got the same basic idea as my clojure reader... only, it's in java and mine is in clojure :P
18:53 licoresse: is someone working on proper error output from clojure compile messages?
18:53 (slime)
18:53 Chousuke: probably not.
18:53 licoresse: hm
18:53 technomancy: someone was talking about hooking it into the rubinius-style backtrace lib
18:54 Chousuke: I don't think anyone wants to work on the compiler too much at this point.
18:54 because it'll eventually get redone anyway
18:54 licoresse: any thoughts on how?
18:54 Chousuke: some simple things could be done though
18:55 for example, the no matching method errors should print the expected parameter types too :P
18:56 hiredman: the tapestry guy (hslip?) hade some kind of clojure stacktrace thing
18:56 http://
18:57 hlship
19:04 somnium: it looks like a slime stacktrace with css
19:05 * hiredman doesn't use slime
19:05 hiredman: I assumed you where complaining about the pages of java exceptions
19:07 somnium: ah, the second picture is nice, slime doesn't do that yet (obfuscate the java internals)
19:07 technomancy: it does dim them though
19:13 rhickey_: danlei: yes, arbitrary name for this
19:15 danlei: rhickey_: well, when using explicit this, why would one not allow arbitrary designators?
19:16 rhickey_: danlei: right, just wanted to be clear you have to add an arg for 'this', whatever you call it
19:16 danlei: rhickey_: ok, thanks (just wasn't clear to me)
19:17 rhickey_: danlei: well, it might not yet be clear :) those are just notes, not docs
19:17 danlei: rhickey_: yeah, I'm aware of that :)
19:18 it was just the formulation which confused me
19:30 mikehinchey: I submitted a patch to clojure.stacktrace to get it closer to clj syntax
19:32 peregrine81: Hey all I am doing eulers project again and I
19:32 technomancy: one of these days I'm going to go through the submitted patches, try them out, and +1 the ones that look good
19:32 peregrine81: m trying to find the Least Common demonator for 1-20. and it seemingly runs forever.. here is the gist
19:32 http://
19:32 technomancy: since it sounds more productive than complaining that my patches take too long to get applied. =)
19:33 danlei: :)
19:33 peregrine81: I had a really elegant solution with regular recursion but kept getting stack overflows
19:36 mikehinchey: technomancy: that might be good. I'd like to know where I could put some time in to clojure, because my submissions haven't moved in as I expected.
19:37 technomancy: mikehinchey: I'll vote for your patches if you vote for mine. =)
19:38 I think it's more about just QAing them so when rich does get to them the problematic ones are already sorted out.
19:44 The-Kenny: peregrine81: It's possible to increment the stack-size of the jvm if you start it.... but I'm not sure if that will help.
19:44 mikehinchey: technomancy: yes, I might create a branch with a bunch of patches to make sure they apply cleanly and tests pass
19:44 technomancy: even patches that were once good can succumb to bitrot.
19:44 peregrine81: The-Kenny: this solution runs without stack issues, but it just never finds an answer
19:46 tomoj: your current solution doesn't make any sense at all to me
19:46 mikehinchey: exactly
19:49 peregrine81: tomoj: why not?
19:49 oops sorry I will be back in 20
20:07 peregrin181: alright I am back
20:10 alright so to catch everyone up I have this code to calculate the least common denominator of 1-20 and it runs forever and I don't know why. Here is the code: http://
20:13 I know the LCD of 1-10 is 5250 so I don't need to find the LCD for numbers below 5250 nor the numbers 1-10
20:15 danlei: without any mathematical knowledge on my side, I'd write something like this:
20:15 (which might be spoilery)
20:15 (defn find-divisible [r]
20:15 (first (drop-while (fn [n] (not (every? #(zero? (rem n %)) r))) (iterate inc 1))))
20:16 tomoj: that's probably very slow
20:16 danlei: well possible, yes
20:16 but how fast must it be?
20:16 it solves the task fine
20:16 tomoj: oh, euler doesn't care
20:17 danlei: "Elapsed time: 128.06173 msecs"
20:17 not fastest, but fast enough for my neurons .)
20:17 tomoj: much faster than I thought
20:17 danlei: 1-10
20:18 should explode
20:19 tomoj: ah, yes, 1-20 is not so fast :)
20:19 danlei: yes, I'm waiting :D
20:19 tomoj: I think when I did that one I prime-factorized
20:20 i.e. factor each of 1-20 into a map of primes->multiplicities, and then merge with max, and then multiply the result up
20:27 peregrin181: tomoj: I'm sorry I don't understand
20:28 tomoj: I will need to study this closer
20:28 tomoj: wait, I think what I described was something else
20:28 peregrin181: tomoj: Why doesn't mine work?
20:28 tomoj: no, no it wasn't
20:28 I still have no idea what your code is trying to do, sorry :(
20:29 I mean I know what it's trying to do, but I have no idea how it's trying to do it
20:29 peregrin181: I start at 2520(cause I know 1-10 is 2520) and check numbers 11-20 to see if they have a remainder of 0
20:30 tomoj: ah, I see
20:30 yes, this takes a very long time because it's a big number, I think
20:30 danlei: combinatorical explosion, just like my snippet
20:30 tomoj: 1-10 is easy so you haven't saved much work
20:30 peregrin181: danlei: I mean I don't understand yours :)
20:31 danlei: peregrin181: what exactly don't you understand?
20:31 peregrin181: danlei: Any of it. I am very green in the world of Clojure/lisps
20:31 danlei: peregrin181: I'll explain, but it's slow, as tomoj said
20:32 peregrin181: danlei: other then anonymous function and functions
20:32 danlei: (defn find-divisible [r]
20:32 (first (drop-while (fn [n] (not (every? #(zero? (rem n %)) r))) (iterate inc 1))))
20:32 start from the every?
20:32 every? returns true if a given predicate holds for all elements of a seq
20:33 so the every? will return true, if all (rem n %) are true for the values in r, which is a range
20:33 (the range ist the argument to find-divisible)
20:33 peregrin181: so [1-20]
20:34 danlei: drop while drops everything while a predicate is true
20:34 you get the picture?
20:34 peregrin181: what is the iterate inc 1
20:34 danlei: yes, (range 1 21)
20:34 its all numbers starting from 1
20:34 also a range, but an open interval
20:35 peregrin181: so it returns to the top
20:35 danlei: so it drops all of those numbers (of the open interval)
20:35 and the first just picks the first available, which will be your result
20:36 drops all for which the (fn [n] ... is true
20:36 peregrin181: thank you. I am still not 100% clear but I think I get it
20:36 the #( means anonymous fn correct?
20:36 danlei: I'm not good at explaining :)
20:36 yes, its sugar for fn, binds % and stuff implicitly
20:37 and to show you how slow it really is:
20:37 "Elapsed time: 985956.807695 msecs"
20:37 :)
20:38 peregrin181: still faster than running forever
20:38 danlei: btw. theres also not-every?
20:39 yes it does the job, eventually ;)
20:39 peregrin181: danlei thanks
20:39 danlei: but it's a very naive approach
20:39 you're welcome
20:40 peregrin181: far less naive then mine
20:40 I'm trying to code in C#/Java in Clojure
20:41 danlei: well, I don't know any C# and almost no Java, so I have it a bit easier ;)
20:41 peregrin181: danlei: did you learn in lisp?
20:41 danlei: yes, I use it almost exclusively, which I can do, because I'm not a professional programmer. I just do stuff I like, and I tend to like lisps
20:42 peregrin181: danlei: cool
20:42 danlei: atm, I'm at university (despite of my age), and that will change soon, but well ...
20:42 peregrin181: why do you think my code takes so long?
20:42 danlei: the good thing is: my university is pretty lisp-friendly :)
20:43 and I don't study cs but computational linguitics, but that's another topic
20:43 peregrin181: I did nearly the same thing you did(with loops)
20:43 danlei: I really didn't understand how you approached it, I didn't spend much time reading your code, to be honest
20:44 a general tip is: always check if it simplifies and terminates
20:45 (i.e.: if your base-case is ever reached)
20:46 tomoj: ok, my prime-factorizing version can do 1-20 in 5ms :)
20:46 danlei: :p
20:46 tomoj: and my factoring algorithm is really dumb
20:46 danlei: I just waited for it, tomoj ;)
20:47 tomoj: how long did it take?
20:47 also, cool re compling, I'm taking an intro compling class now
20:47 I really want to rewrite nltk in clojure because python makes me sad
20:48 danlei: "Elapsed time: 985956.807695 msecs" :)
20:49 I'm just at the start right now, much "traditional" linguistics atm, the basics
20:49 desaussure &al
20:50 tomoj: here's my version (spoiler, of course): http://
20:50 danlei: *de saussure
20:53 tomoj: so the answer is in the hundreds of millions, I can see why the naive way takes so long
20:54 peregrin181: tomoj: my way
20:54 ?
20:56 tomoj: the way that counts upwards and checks for each number whether all the numbers in the list divide it
20:56 all the hard work of my way is prime-factorizing, and though my factorizer seems slow, you only have to factor 2-20, so
20:57 I wonder how long the naive way takes to get 1-30
20:58 or 1-300 :)
20:58 peregrin181: tomoj: mine prolly takes forever
20:59 danlei: would sure be a workout for my fan :)
20:59 tomoj: I can get 1-300 in just over a second
20:59 peregrin181: tomoj: Yea the way of finding the roots is far better
21:00 tomoj: it disturbs me that I don't know how to factor quickly
21:02 danlei: tomoj: do you speak common lisp?
21:03 peregrin181: tomoj: I'm not very good at math
21:03 lol
21:04 tomoj: danlei: a little, not much
21:04 danlei: I haven't done euler for a long time
21:04 but I have alittle factorizer here
21:04 sec
21:05 lisppaste8: danlei pasted "factorization" at http://
21:06 danlei: it's not stuff I usually do much, but it worked and was fast enough for my needs
21:06 peregrin181: is this cl?
21:06 miltonsilva: hi, does anyone know(has experience) how clojure scale to huge project? (specificly the ones that seem more OO)
21:06 danlei: yes
21:06 I started doing euler in CL, havent come around to do some of it in clojure
21:07 peregrin181: danlei: I wasn't a fan of CL
21:08 danlei: I like it pretty much :)
21:08 clojure, too. I like both of them
21:08 what didn't you like?
21:08 somnium: weblocks is cool
21:08 danlei: never used it, just hunchentoot
21:08 but I heard good things about it
21:08 somnium: I just don't want to try to learn another lisp until I feel like I'm really familiar with all of clojure's dark corners
21:08 peregrin181: danlei: CL seemed poorly documented, too many different implementations, little tool support(outside of emacs)
21:09 danlei: poor libs
21:09 danlei: peregrin181: oh. I'd /very/ strongly disagree about poorly documented
21:09 somnium: and all the 'serious' implementations cost a fortune
21:09 peregrin181: danlei: thats probably true
21:09 somnium: for a hobby programmer anyway, they're supposed to have better libs though
21:10 danlei: well the thing is, cffi is there and it's pretty easy to use
21:10 it's like clojure uses java as it's low-level and implementation language
21:10 tomoj: CLHS is poor documentation?
21:10 danlei: and the things I don't like about clojure are mostly stuff where java sticks out
21:10 so, well
21:10 arbscht: too many implementations? the number of java implementations is in the same order of magnitude
21:11 danlei: I don't know, all this has never been an issue for me
21:11 peregrin181: danlei: thats true. But at least I can use one of the java libs
21:11 danlei: yes, like you can use all C libs from lisp ;)
21:11 The-Kenn1: I really miss clos... method combination and such things.
21:11 somnium: arbscht: sun, openjdk, and ibm? there are more?
21:11 arbscht: somnium: a lot more
21:11 peregrin181: danlei: I really tried to like it :)
21:11 danlei: I know what you mean, but I didn't suffer very much
21:11 tomoj: danlei: that looks like basically what my clojure does
21:11 except I'm using multiplicity representation
21:11 danlei: I like clojure for being a modern lisp, which is moving, living and trying to be "better"
21:12 that's what makes it great (to me)
21:12 peregrin181: danlei: ding ding :)
21:12 arbscht: somnium: SE5, SE6, EE4, EE5 (GlassFish, JBoss, Geronimo, WebLogic ...), ME, FX, OpenJDK, GIJ/GCJ, ECJ, Harmony, Dalvik, JRockI
21:12 t
21:12 peregrin181: arbscht: But real people use JRE :P and Dalvik only runs on android
21:13 arbscht: peregrin181: I'm sure you could make such arguments for some CL implementations
21:13 danlei: tomoj: I had no problems with it's speed ... or was that just hypothetical?
21:13 peregrin181: there are also things that are very nice about cl, like the condition system for example
21:14 peregrin181: it's not black and white, I think both langs have much to offer
21:14 peregrin181: danlei: And I agree I wasn't trying to anger
21:14 tomoj: danlei: e.g. factorizing 53573153 takes 13 seconds for me
21:14 danlei: peregrin181: you don't :)
21:14 tomoj: a sec
21:14 tomoj: because it's got two big prime factors, and searching upwards for the next prime isn't very efficient, I think
21:15 danlei: tomoj: (FACTORIZE 53573153) took 16 milliseconds (0.016 seconds) to run
21:15 with 2 available CPU cores.
21:15 During that period, 16 milliseconds (0.016 seconds) were spent in user mode
21:15 0 milliseconds (0.000 seconds) were spent in system mode
21:15 1,384 bytes of memory allocated.
21:15 ah, sorry for the mess
21:15 tomoj: you know what, though? if you're dividing out all of the smaller factors, you don't even need to care whether the factor is prime
21:15 peregrin181: danlei: how did you get that data?
21:15 tomoj: checking primality is a waste of time
21:15 danlei: tomoj: so, the CL version is pretty fast actually
21:16 peregrin181: thats ccl's TIME
21:16 peregrin181: danlei ah
21:16 tomoj: I wonder why it's so much faster
21:16 peregrin181: tomoj: probably something to do with lazy evaluation
21:16 tomoj: Pure guess
21:16 danlei: I can't tell you :)
21:16 I'm no expert with this, just wrote it some time ago
21:17 tomoj: wow, skipping the primality check sped my code up 32x
21:17 1-20 in 1.5ms now
21:18 danlei: I guess I could even squeeze more performance out of the cl version if I declared types
21:19 tomoj: danlei: why are you checking for primality?
21:19 danlei: (time (factorize 1234321234213243)) -> 141ms
21:19 tomoj: get rid of the prime check, I bet you'll get the same answers and a lot faster
21:19 danlei: a moment
21:20 tomoj: because if you start dividing by 2 and work your way up, any number that's not prime won't divide the accumulator anyway, so no point in checking whether they're prime
21:20 danlei: doesn't really make a difference in runtime, but you're right
21:20 tomoj: wat? that doesn't make any sense
21:21 I got a 32x speedup...
21:21 danlei: well:
21:21 141ms, just like before
21:21 tomoj: oh, I was checking for primality by going from 2 to n-1
21:21 instead of sqrt(n)
21:21 that probably slowed me down a lot :(
21:22 danlei: yes, sounds so
21:23 tomoj: ok, now factorizing 1234321234213243 takes me 739ms, that sounds more reasonable as attributable to naive clojure overhea
21:23 danlei: yes, it does
21:24 I also tried to squeeze some performance out of it with type declarations, but it wasn't worth it
21:24 around 140ms
21:26 but I'm asking myself why I put the primep in there anyway ...
21:26 tomoj: I don't think type hinting would really help me any.. maybe I can avoid boxing though? I dunno how to speed clojure up
21:26 well, I put one in there at first too :)
21:26 danlei: :)
21:27 tomoj: it seems like a waste to check numbers which can't possibly divide the accumulator because you've already factored out all their factors
21:27 but I guess it's actually faster to do this than to make sure you're only checking primes
21:27 danlei: anyway, it's 3:30 over here, and I'll call it a night :)
22:05 Licenser: hrm, I
22:05 v
22:05 argh - sorry
22:05 I've a very odd behaviour with a funciton, it claims to have the wrong number of arguments - but it shouldn't
22:05 http://
22:05 Is that a bug or am I just plain stupid
22:06 likely it's the second but well I'm working on it for one houre and don't see what's wrong o.o
22:09 thanks, I am just plain stupid, I found the bug - had a argument too much in an anon function :/
22:18 brweber2: can anyone help me create an exception class that only has a constructor that takes a string parameter?
22:25 liebke: Licenser: remove the formater argument from the anonymous function you're passing to map: (map (fn [row] (table-row row formater)) data)
22:26 Licenser: liebke: thanks, found that a bit ago but I was running nuts - I really really have to get used to reading java exceptions again o.o
22:26 liebke: :)
22:27 Licenser: I was looking at the make-table function thinking I'd passed it the wrong number of arguments o.O
22:30 eyeris: I have code that makes a Swing JFrame. It runs properly when I use clojure.lang.Repl, but when I use vimclojure's Nailgun repl, the function that creates the JFrame returns nil.
22:31 Licenser: eyeris: does the nailgun reply have a display to draw on?
22:31 eyeris: Licenser: it should, because DISPLAY is set.
22:31 I guess maybe it is dropping the environment?
22:31 Licenser: I don
22:31 I don't know it would just be my first guess
22:42 eyeris: I just made NGServer dump it's environment when it starts and when it exits. DISPLAY is set at both times.
22:42 Good idea though :)
22:49 In vimclojure's repl, how do I evaluate what I type?
22:49 When I type in clojure code and hit enter, nothing is printed out
23:25 technomancy: why does test_clojure/logic.clj test to see that (symbol "") is true?