6:49 lnostdal: hello .. err, weird question maybe .. but how mature is clojure now? .. i'm a common lisp'er, but a client insists that i am to "use java" (well, maybe using the jvm is close enough) .. i guess i need some sort of http server .. (jetty) .. and maybe it would be possible to hook clojure into this somewhere?
6:49 i know java as a language .. but don't know anything about the platform options
9:43 Chouser: lnostdal: there are a couple implementations of Java servlet stubs that can then hand off control to Clojure code.
9:43 That's probably the recommended route for Clojure on a web server.
9:44 lnostdal: ok
9:45 Chouser: One is "webjure", which is a sort of integrated framework, but may not be up to date with the latest version of Clojure.
9:56 cgrand: Why these two lines throws an exception?
9:56 (defmacro bar [s] `(~print ~s))
9:56 (defn foo [x] (bar x))
9:59 (I try to capture the value of a var at compile time)
10:01 rhickey_: you end up with an expansion whose head is a fn object
10:02 there are no evaluation semantics for that
10:04 cgrand: rich: thanks... I was fearing that answer. How can I work around ? By calling invoke on the fn object?
10:05 rhickey_: what's wrong with `(print ~s)?
10:11 cgrand: This was just an example to succintly shows my problem. This is not the real code. I've got a var named *escaping* which holds the current string-escaping function (the value of *escaping* changes during macro expansion, that's why I try to capture it)
10:11 rhickey_: ok
10:18 cgrand: actually this should work, seems to be a classname visibility thing - looking into it
10:20 cgrand: rhickey: thank you!
10:26 rhickey_: cgrand: fixed
10:26 cgrand: you're amazing!
11:27 MarkJP: �Man, being able to do things like this is awesome: (seq (.. cb (getClass) (getMethods)))
11:28 rhickey_: especially when you can do it like: (seq (.. cb getClass getMethods))
11:28 MarkJP: haven
11:28 haven't caught up on my google group reading yet :)
11:29 jteo: umm..what's ".."?
11:29 MarkJP: jteo: chaining method calls
11:30 in java it would be: MyClass.getClass().getMethods()
11:31 jteo: ah.
11:32 ah okie found the documentation/example
16:21 MarkJP_: interesting
16:22 (def foo "asdf")
16:22 (.. foo (getClass) (getDeclaredMethod "getBytes" nil) (getReturnType) (getName))
16:22 I get "[B"
16:22 same with character array types
16:24 don't think its a printing problem:
16:24 (str "START " (.. foo (getClass) (getDeclaredMethod "getBytes" nil) (getReturnType) (getName)) "END")
16:24 I get "START [BEND"
16:42 Chouser: Yeah, I've seen that for all kinds of Java arrays.
16:42 (into-array ["a"]) --> [Ljava.lang.String;@8fbecf
16:42 MarkJP: oh
16:43 Chouser: I wonder if it's some Java-internal naming to indicate an array?
16:43 hm, maybe I'd only ever seen [L, not [B
16:44 MarkJP: [C for char arrays
16:44 oh so its not Clojure doing that?
17:01 yep, its java
17:02 getSimpleName work much better
19:46 rhickey_: new numbers (svn rev 802) - please report any anomalies
21:06 BigDecimal literals - use M as suffix
21:51 Chouser: rhickey_: cool re: BigDecimal
22:03 rhickey_: should be useful
22:06 abrooks: rhickey_: How do you feel about a polymorphic "load" which takes a file (like "load-file") or a reader? (as a substitute for "load-file")
22:07 The next question following this would ask the same think of "line-seq" which has no file equivalent (but it would be handy to have one).
22:13 rhickey_: abrooks: there is load that takes a reader
22:14 abrooks: rhickey_: Right. I'm asking if you think it would be okay for load to take a reader or a file.
22:14 I would like to call "load" with either a reader or a file name.
22:15 Would you rather be explicit about which one you're calling (load/load-file) or would a polymorphic load be okay?
22:15 rhickey_: seems better to make a rdr function
22:15 else everything will have to be overloaded
22:16 but might be good candidate for multimethod...
22:16 abrooks: Okay. This suggests that line-seq should have a line-seq-file complement. Would you take a patch for that?
22:17 Or wait... you're considering polymorphic versions. :)
22:17 rhickey_: definitely not line-seq-file, (line-seq (rdr file))
22:17 making stream/reader construction easier would be generally useful
22:18 abrooks: This brings up another question: I haven't seen any examples of multimethods based on different types (only the keyword style tags) on the site. How would I do that? Are there examples?
22:19 i.e. if I wanted to construct an abrooks-load multimethod which takes either a string (filename) or reader, how would I express the matching?
22:19 rhickey_: no examples, just use getClass as the dispatch function, and classes as the dispatch values
22:20 abrooks: "(rdr file)" doesn't curently exist, right?
22:20 getClass: okay. Thanks.
22:20 rhickey_: no rdr yet, the trick is all of the different reader/stream combos
22:21 abrooks: I haven't found a good use for line-seq that isn't shorter than slurp'ing the file and re-seq'ing on top of it.
22:23 rhickey_: abrooks: use class rather than getClass
22:23 abrooks: Okay.
22:27 rhickey_: Thanks for your help, BTW.
22:27 rhickey_: sure
22:31 abrooks: rhickey_: Here's an odd thought (it's Chouser's really with some minor modifications). Print debugging (yes, yes, bad me) has always been a pain for me in lisps since you often can't drop a form in the middle of another without (A) wrapping it in a
22:31 Not done. Fat fingers.
22:32 rhickey_: Here's an odd thought (it's Chouser's really with some minor modifications). Print debugging (yes, yes, bad me) has always been a pain for me in lisps since you often can't drop a form in the middle of another without (A) wrapping it in a "do" and (B) making the nesting of the "do" parens happen at the right spot.
22:33 Chouser's idea was a reader macro or macros that could have a left or right associativity and wrap two adjacent forms in a "do". I'll nopaste an example in a sec.
22:41 With a macro like that, debug lines could be added essentially anywhere, only needing to change the <<</>>> to associate with the preceeding/following form.
22:41 rhickey_: following is easy, preceding not
22:42 abrooks: I think following is the common case. That would be cool enough. :)
22:43 rhickey_: I'm not promising anything yet, let me think about how generally useful this is
22:44 abrooks: rhickey_: Thanks for considering it.