#clojure log - Dec 30 2008

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

0:20 knabb: i figured it out

0:20 amazing you have to use xml for the buildsystem

0:42 hmm i m thinking

0:42 when implementing a stack in clojure

0:42 push could just cons to a list

0:42 but pop

0:43 should it then return the first element of that list and the rest of the list?

0:43 a stack seems naturally represented with state

0:43 so a macro to redef the passed variable

0:44 vogelrn: there's already peek that returns the head and pop that returns the rest

0:46 knabb: yes but pop should do both i mean

0:47 vogelrn: well the point is that it doesn't when you're thinking functionally

0:48 instead, you would likely use the head and recurse on the rest, or something of that nature

1:06 knabb: java really is the greatest eample of really poor problem solving

1:06 chrisn: Is there an error function (like failwith or fail in other languages)?

1:06 knabb: solve a problem by fixing it with an even more complex and idiotic problem

1:07 chrisn: nm, found them in contrib

1:07 vogelrn: knabb: What are you referring to out of curiosity?

1:11 knabb: ant

1:12 xml

1:12 iamslash: I'm a newbie of clojure... using emacs slime... can evaluate expressions... but

1:12 slime-edit-definition doesn't work.. on emacs...

1:12 what can i start from..?

1:12 knabb: what is the name of the symbol that looks like a weird E and is used a lot in math notation

1:13 vogelrn: you mean the sum one?

1:13 knabb: iamslash: if you use windows try clojure-box, otherways clojure-mode for emacs is easy to install.

1:13 iamslash: I'm using clojure-mode...

1:14 knabb: not lisp-mode?

1:20 iamslash: I installed... git://github.com/jochu/clojure-mode.git git://github.com/jochu/swank-clojure.git

1:21 clojure expressions work well... but when I run 'slime-edit-definition'

1:22 Emacs debunk "source definition not found' message...

1:22 vogelrn: to be honest I don't actually know what that is, I don't know much about emacs aside from the various tutorials I've read. What are you trying to do?

1:22 slime-edit-definition, that is

1:22 iamslash: yeah right...

1:26 http://groups.google.com/group/clojure/browse_thread/thread/e0ece17449ab24ec/5decf3d10d69616f?lnk=gst&q=%22Source+definition+not+found%22#5decf3d10d69616f

2:45 Lau_of_DK: Goood morning gentlemen

2:48 drewr: Good morning.

2:48 * drewr is unfortunately awake

2:49 Lau_of_DK: Rough night? :)

2:50 drewr: Fever, sore throat. Doesn't look good... :-)

2:51 Lau_of_DK: It sure doesnt, although I know many people having a hard time with that these days

2:53 drewr: Fortunately germs don't travel well over IRC.

2:53 Lau_of_DK: Scientists may disagree on that

10:19 jgracin: just updated SLIME and swank-clojure and now I'm getting an error during startup. (wrong-type-argument sequencep t)

10:19 I guess those are related to slime-repl changes. Has anyone managed to fix it?

10:20 Or perhaps, does anyone else have this problem?

10:21 aking: jgracin: for a working slime, I had to rollback my git slime to dec23

10:22 jgracin: aking: I see. Thanks, I'll do that.

10:33 Lau_of_DK: Good afternoon gentlemen

10:33 danlarkin: mornin'

10:33 Chousuke: evening

10:34 Lau_of_DK: You guys are either confused, or your nations have not yet been assimiliated by the Empire of Denmark

10:35 karmazilla: My suggestion to allow an alternative doc-string placement have not spured much discusion. I wonder if people are happy with the current allowed syntax

10:35 Lau_of_DK: karmazilla: What was your suggestion?

10:36 karmazilla: to allow the doc-string to come after the [params*]

10:36 Chousuke: karmazilla: wouldn't that create ambiquity?

10:37 danlarkin: but isn't that ambiguous?

10:37 Lau_of_DK: karmazilla: that would be ambiguous

10:37 :)

10:37 Chousuke: what if you wanted a function like (defn foo [] "string")

10:37 karmazilla: no, I defined it in a way that limited it to unambigues usages: http://groups.google.com/group/clojure/browse_thread/thread/fcde7a631a033b7b/faf1a89ab490f582

10:37 Lau_of_DK: But karmazilla, I agree that where it is now, is not very nice, Ive thought about an modification myself

10:38 karmazilla: Chousuke: that should work as it does today'

10:39 danlarkin: I like where the docstrings are now

10:39 Chousuke: I think the docstring is just fine between the symbol and the parameters

10:39 karmazilla: but (defn foo [] "spam" "string") is already allowed syntax, but the "spam" part isn't used for anything

10:40 Lau_of_DK: karmazilla: Is the only advantage of this change prettier code?

10:40 danlarkin: karmazilla: but (defn foo [] (println "side effect!!") "string") is allowed too, same thing as (defn foo [] "spam" "string")

10:40 karmazilla: Lau_of_DK: yes, just prettier code

10:41 Lau_of_DK: ok

10:41 karmazilla: danlucraft: not the same thing... side-effecting thingy != no-op string

10:41 Lau_of_DK: Isnt there already an option of doing something like (defn #^{:doc "This does nothing"} myfunc [x y] nil) ?

10:43 danlarkin: karmazilla: well what I mean is that "spam" in that example isn't a no-op string... it's a form in an implicit do

10:43 it gets evaluated

10:44 Chouser: I think karmazilla is correct that his proposed format wouldn't break anything.

10:45 karmazilla: I don't have the fantasy to imagine a cenario where it would break, anyway

10:45 Chouser: But personally I don't think it matters much -- one more optional way to format defn, slightly more complex implementation and docs, very minor (or no) benefit.

10:46 generally, I'm either writing one-off functions and provide no doc string at all and only one body per function. Or I'm trying to write good clean maintainable functions, and I provide doc strings and am much more likely to provide multiple arities.

10:48 karmazilla: not to be discouraging, but that's why I've not weighed in on the g.group.

10:49 danlarkin: I'd prefer the possibility for """this style string""" more than this change :)

10:50 rhickey: karmazilla: I'm not interested in supporting that syntax as it adds little and doesn't scale to multiple arities

10:51 obviously it was considered and rejected

10:51 karmazilla: Maybe it's just a habit that have this bother me more than most. When I write library code, I try to be rather thorough with my doc-strings, putting in code examples and other stuff, and then it just.... would feel better if I could put the arg list on top

10:51 rhickey: I have pages and pages of variants of fn in my initial design docs

10:51 karmazilla: ok

10:51 rhickey: design is about tradeoffs - multiple arities won here

10:53 Lau_of_DK: karmazilla: I think it was cool that you actually went the extra-mile and provided a patch though, I hope you keep the creativity flowing :)

10:53 duck1123_: It takes a while to get used to (coming from other lisps) but once you see the reason for why it is, it's not that bad.

10:55 karmazilla: I guess I have to keep my python out of my clojure, like I have to keep my haskell out of my python, and my java out of... no, wait.. nothing

10:56 Lau_of_DK: :)

10:56 I agree, keep Python away

10:57 duck1123_: keep the peanut butter and the chocolate together though

10:57 Lau_of_DK: Wise words

11:12 StartsWithK: does anyone know can clojure now be used with osgi? if not, maybe example of using ServiceLoader, it looks like ServiceLoader uses one class loadef for all bundles, so maybe that could work for clojure

11:13 i looked at cloujredev, eclipse plugins are osgi bundles, but it is in java nad clojure is not separate bundle, and there is no interaction from clojure code with object from other bundles

11:13 clojuredev*

11:14 duck1123_: forgive me if I'm wrong, but isn't OSGI kinda like a servlet container?

11:16 StartsWithK: something like that

11:17 duck1123_: I know clojure works with Tomcat, so there's hope at least

11:17 StartsWithK: problem last time i had is that every bundle gets his own class loader (or somethin even more complicated than that), so i couldn't..

11:17 .. create bundle without his private clojure.jar

11:18 and even with that, if proxy created with clojre would be sent to some other bunde it would fail, i think it remeber its old class loader

11:19 is this resolver maybe after AOT was added

11:20 duck1123_: you were trying to create classes for a different system with proxy?

11:21 StartsWithK: if object was created in bundle A, then passed as argument to method on object created in bunlde B, then it would fail

11:22 only 'solution' was that every bundle has everything it needs inside it, but then there was no point in using osgi

11:22 duck1123_: I would definitely try again post-AOT

11:23 StartsWithK: so RT changed the way how it handles class loader?

11:24 duck1123_: I know some things changed in that area... don't know if it solves your problem without looking deeper at it

11:26 StartsWithK: uf, don't want to go on that experimenting road with osgi like last time.. wasted too much time on it before

11:26 there is also *use-context-classloader*, and it was in clojure before

11:26 but its use is undocumented

11:27 it sugest that something could use another proxy, and not the one in RT

11:44 Lau_of_DK: Yo Pupeno

11:47 Pupeno: Hello Lau_of_DK.

11:48 Raynes: I find it amusing that even in the infancy of this language, there is more people in this channel than there is in #Scala.

11:48 :>

11:49 Lau_of_DK: Muhahaha :)

11:49 Chouser: Friendlier ones too.

11:49 Lau_of_DK: Aww Chous', was that directed at me? *blush*

11:49 Chouser: I imagine having the author here increases the relevence of the channel quite a it.

11:49 quite a bit.

11:49 cemerick: Raynes: definitely a good sign, but don't take irc users as an indication of anything like an indication of broader trends.

11:50 The masses like the curly braces, regardless of what is found within them...

11:50 Raynes: cemerick: I said nothing about popularity of either language, it's just funny.

11:50 Chouser: Lau_of_DK: take all the credit you'd like. But I was actually uncharitably directing it at others who appeared to intentionally make me feel like an moron while I was trying to make the jump to FP.

11:51 Lau_of_DK: cemerick: perhaps we should consider replacing all these parentheses with curly braces then

11:51 * cemerick chokes

11:51 Lau_of_DK: ehe

11:51 Chouser: heh

11:51 Raynes: {+ 2 2}

11:51 Lau_of_DK: {defn add [x y] {+ x y}}

11:51 Looks a bit like barbed wire, kinda cool

11:51 Chouser: I suppose we'd use () for literal maps then?

11:52 Lau_of_DK: Chouser: Really? That sounds awful

11:52 cemerick: it's sorta rubyish, really. { somefn arg arg }

11:52 Lau_of_DK: FP is a big enough steak on its own

11:52 cemerick: => reader syntax, baby!

11:52 Lau_of_DK: Perl!

11:53 vogelrn: I think #[] is open for literal maps, isn't it? :P

11:53 avoid using the parenthesis altogether

11:53 * Chouser can't take any more of this.

11:54 Chouser: vogelrn: truly evil, my friend.

11:54 ericlavigne: We can have <+ x y> and replace the <,> functions with lt,gt.

11:56 danm_: scala seems strange to me, like they don't need a macro system because any language feature you could ever hope for is either already in the language, or slated for the next release

11:57 ericlavigne: Or rather...

11:57 <

11:57 + x y

11:57 >


11:58 danm_: call by name parameters are an interesting way to avoid the need for macros as well

11:58 ericlavigne: Because not giving parentheses/braces their own line is a dead giveaway that you're using Lisp :-P

11:59 Lau_of_DK: If we could somehow implement this it would be great: http://99-bottles-of-beer.net/language-perl-737.html

12:01 * ericlavigne takes one look, then sits in the corner, shaking and wondering if he'll ever regain the will to program

12:01 Lau_of_DK: hehe, you should see the Malbolge solution then

12:01 HAHA: http://99-bottles-of-beer.net/language-lolcode-1544.html

12:04 And an extra fact, Clojure is actually on the top10 on that site

12:21 mibu: does anyone here know how to use the clojure.parallel lib?

12:25 aking: When inside a proxy function, how can I do a "return this;"?

12:30 mibu: aking: I think just "this".

12:32 aking: mibu: thanks - seems to compile - I test in a sec. So, 'this' is a reserved word? I don't see it mentioned on the java interop page.

12:32 rhickey: aking: no, 'this is just bound by the proxy macro

12:32 mibu: aking: it's not reserved. it's just implicitly bound to this

12:33 rhickey: hmpf, no java.beans in Android

12:34 aking: ahh.. thanks - rereading the proxy doc mentions it - sorry for the noise.

12:34 inertia-: rhickey: clojure on the llvm, possible? certainly seems worth it

12:34 rhickey: inertia-: with what libraries?

12:35 inertia-: itself - perforamnce is what i am thinking of

12:35 rhickey: inertia-: better to target a fast CL

12:36 only perf benefit over JVM is tagged fixnums

12:36 without polluting Clojure with primitive types

12:36 inertia-: isn't there a greater potential for perf increases over time?

12:37 i'm not saying i'm a performance whore but i certainly think about it

12:37 rhickey: LLVM is not nearly the same infrastructure as JVM/CLR

12:37 inertia-: (mainly that java is always 1-4 times worse than C on alioth benchmarks)

12:37 rhickey: I'm completely not interested in reinventing wheels

12:37 inertia-: :)

12:38 i like clj very much, thanks rh

12:38 rhickey: inertia-: you're welcome!

12:42 zakwilson: I think it would be cool if somebody implemented languages similar to Clojure for other platforms, but Clojure is very clearly tied to the JVM. It took me a long time to come around, but I think that's a Good Thing.

12:43 rhickey: zakwilson: Clojure could easily target the CLR, and once did

12:43 could probably target any OO host with MT primitives

12:44 or drop MT, as ClojureScript does in targeting Javascript

12:45 ugh, jar utility cannot remove files ?

12:55 Chouser: (complement neg?) vs. #(not (neg? %)) vs. #(>= % 0) ...opinions?

12:58 mibu: chouser: not neg if you have a literal style, >= if you're the compact type.

12:59 chouser: for me, it's a matter of mood.

13:08 rhickey: Hello Android World! (from Clojure)

13:08 mchurch: What is the best/preferred way to spawn a thread in Clojure?

13:09 * danlarkin cheers!

13:10 karmazilla: mchurch: if not with an agant, then maybe (doto (Thread. #(println "pokemon")) .start) ?

13:15 mchurch: karmazilla: I haven't gotten to agents yet in my reading, but they sound cool.

13:15 karmazilla: I'm just looking for very basic thread functionality now (prototyping something) so that will probably be enough.

13:17 rhickey: danlarkin: looks like bean is the only function that uses an unsupported API (java.beans)

13:18 * aking woohoo for clojure Android

13:19 rhickey: I'll check in as soon as I figure out how to handle bean (had to comment it out to get Hello Android to run)

13:19 aking: cool - will try it as soon as it's in

13:19 rhickey: what did you do for the classloader? That patch I submitted - or a proper fix?

13:20 rhickey: aking: a proper fix :)

13:20 aking: heh :)

13:20 rhickey: the problem with the patch is it ignores the fact that the classloaders should have delegated

13:21 rather than just workaround, I dug into it and found how Android was responding to contextLoaders etc

13:21 so now the baseloader is properly rooted on Android and delegation works

13:22 aking: aye - thought that should have been the case, but I'm not familar enough with how clojure handles the classloaders - but hope it at least pointed at what was wrong

13:22 rhickey: also got the bridge method resolution fixed up, plus special handling for the source being present but the .class not

13:24 aking: once you make an announcement on the list, it'll be time to progit/digg it - it's been a few days since there's been a clojure story

13:27 rhickey: aking: I'd rather it worked smoothly before it got a lot of attention

13:27 but support is up (svn 1192) - you'll have to comment out bean in core_proxy.clj manually if targeting Android, for now

13:28 have fun!

13:32 aking: rhickey: great! I'll update and try it out after lunch

13:36 Nafai: rhickey: You got it working?

13:36 rhickey: FYI, what I got running was this: http://github.com/Nafai77/helloandroid/tree/master, with no changes to it other than adding <arg value="-JXmx1024M" /> to the dex target in build.xml since I was getting out of mem errors there

13:36 Nafai: Sweet!

13:37 * Nafai tries

13:37 rhickey: Nafai: you'll need to comment out bean in core_proxy.clj before building Clojure

13:37 * Nafai does that

13:38 Nafai: Just the bean method?

13:44 rhickey: The bean method?

13:46 rhickey: the entire bean function in core_proxy.clj

13:46 no bean on Android

13:46 Nafai: Ok

13:46 Right

13:48 replaca: rhickey (et al.): congrats on getting Android working!

13:49 * Nafai tries to get a screenshot from the emulator

13:52 * Nafai can't get it to work for some reason :(

13:53 Nafai: Still getting a no class def error

13:54 aking: Nafai: I'm updating now...

13:59 Nafai: works for me :)

13:59 * Nafai wonders what he is doing wrong

14:00 aking: woohoo - time for some Android clojure coding..

14:00 did you copy the updated clojure.jar file to hellowandroid/lib ?

14:00 Nafai: aking: Which Android sdk version are you using?

14:00 aking: Yeah, it's symlinked

14:01 aking: I'm running it under WinXP - android-sdk-windows-1.0_r2

14:01 Nafai: I'm on Linux, but same version

14:01 I'll have to play with it later, at work :)

14:02 aking: Nafai: if it's the same class def error, sounds like it's not picking up the updated jar file

14:02 Nafai: Yeah, it does sound that way

14:18 Lau_of_DK: Good evening Mr. Schulz

14:18 aking: Nafai: got a ddms screen capture of it running if you want to see it. Memory usage isn't to bad - a basic clojure android app seems to take about 2.6Mb

14:19 Nafai: aking: Yeah, I'd like to see it :)

14:19 Lau_of_DK: Me too

14:21 AWizzArd: clojurebot: max people

14:21 clojurebot: max people is 116

14:21 aking: Nafai: see it here: http://antimass.org/aking/clojure-android.png

14:22 Nafai: Yay!

14:24 AWizzArd: aking: is this running in a Java ME or does your phone support a full JRE?

14:24 aking: It's running under Google's Android vm

14:24 the emulator - but should work fine on an Android phone

14:25 mibu_: rhickey: do you plan in the future to implicitly integrate operations from clojure.parallel in the standard operations?

14:26 AWizzArd: aking: I ask because to my knowledge Clojure currently does not run inside a ME as those guys have too strict memory settings, something like that. So it seems that the Android vm uses some settings that make more sense for todays hardware.

14:27 cemerick: Chouser: did anything concrete come out of the pretty-printer discussion last month?

14:27 (I just want to use one, too :-) )

14:28 Chouser: mibu_: requires a third-party .jar, so it'd surprise me. But there's a pmap in core

14:28 aking: AWizzArd: I haven't tried under ME - but I don't see why it shouldn't work. rhickey has to remove bean support for android, which I believe ME is also missing, so it might start working.

14:28 Chouser: cemerick: nope, we've got two (unfinished?) implementations.

14:28 replaca: cemerick, Chouser: I was just thinking about digging in on a pretty printer last night

14:28 aking: AWizzArd: That clojure android app is running Nafai's code here: http://github.com/Nafai77/helloandroid/tree/master

14:29 mibu_: chouser: I understood the ForkJoin lib will be included in Java7

14:29 replaca: I'm pretty much done with common lisp format and that leads kind of naturally to the XP pretty printer

14:29 Chouser: mibu_: ah, I didn't know that.

14:29 replaca: are others doing active work?

14:29 Chouser: replaca: I was only working on pprint because I thought nobody else was. I've dropped it for now.

14:30 cemerick: replaca: not in this corner. All of my tinkering has fallen by the wayside :-(

14:30 Chouser: I must say, though, that the CL-style format feels like quite a burden.

14:30 replaca: I just started reader the MIT tech note on the XP pretty printer last night (the basis of the PP in CL)

14:30 Chouser: in what sense?

14:31 Chouser: replaca: it's like a whole language in itself -- not even an s-expression based one -- and so to use it or read code that uses it I need to learn the parsing rules, functions, the whole works.

14:32 cemerick: yeah, FORMAT is pretty rough for the user -- mini languages aren't fun

14:32 replaca: Chouser: indeed. it's oonly for those that like it. But it does giive you better control and simplifies your printing code. So it's a trade-off.

14:33 cemerick: stuff like this scares the bejeezus out of me, for instance: http://cybertiggyr.com/gene/fmt/

14:33 Chouser: When I first started on a pprint, I asked if XP as a good model and rhickey_ said it seemed overly complex. iirc.

14:33 replaca: The nice thing about XP is that it's already thought out -> therefore easier to implement

14:34 cemerick: Java already has a text formatter -- if that can be folded in transparently, then we'll all be better off.

14:34 replaca: (Cause you don't have to worry about unforeseen corner cases)

14:34 Chouser: perhaps we could come up with something that has the internal structure and feature set of FORMAT, but uses an s-expr API instead?

14:35 replaca: One thing that would be pretty easy is to sexpr the bracket constructs

14:35 It would make it more verbose, but easier to understand the flow

14:36 The nice thing about format is that you don't have to explicitly traverse your structures

14:36 This argument has been going on since the eighties, of course

14:36 Chouser: :-)

14:37 replaca: I've always liked format cause it get printing "out of the way"

14:37 Chouser: but clojure gives us new tools that CL doesn't have, so it may be worth at least skimming over the argument one more time.

14:37 replaca: And I mostly don't care that the formats are kind of write-only

14:37 cemerick: replaca: even when you need to fix a bug?

14:38 replaca: Well, the bug would only be in the format itself, so you can focus on that. But the point is valid.

14:39 I mostly did the format implementation just cause I wanted to (god knows why)

14:39 But there's lots of raw material there to support other mechanisms

14:39 and of course we have the java mechanism "built-in"

14:40 and certainly one reason to have format "lying around" is that it makes porting CL code easier

14:40 cause converting the prints seems like a silly way to spend time

14:41 all of which is basically orthogonal to pretty printing :-)

14:44 AWizzArd: cemerick: why are you scared by format? I mean, it's basically a DSL just as regexps are. Or maybe you try to avoid those too?

14:44 gnuvince: regexes *should* be avoided when possible :)

14:44 Chouser: heh. well, I certainly don't mind having a lib around that is 100% backward-compatible with CL for porting. Seems very nice for that use case.

14:45 AWizzArd: I was thinking about that -- if we could come up with an s-expr-based text matching language that was no more than 2 or 3 times as verbose as regex, I'd probably prefer that too.

14:45 replaca: gnuvince: yes, but we don't avoid them when they make our intent clearer.

14:46 Chouser: yes, but good luck with that. sexprs are pretty verbose relative to these tight string languages

14:46 cemerick: AWizzArd: format does way, way more than I've never needed such a facility to do. It's too clever for its own good, IMO. regexes solve an immediate and constant problem, and no better option has presented itself, so they remain.

14:46 Chouser: it might be worth looking at how perl6 approaches regex -- they redesigned to be much better at composition of patterns and such, at some cost in verbosity.

14:47 replaca: The advantage of both regex and formats (both CL and Java/printf-style) is that they work in the target domain: strings.

14:48 AWizzArd: Chouser: fair enough

14:48 cemerick: well, in todays world it's probably really not too common anymore to print out texts into a shell or something like that. Most programs come with a gui and for those there are other tools.

14:49 I don't see it as a real loss to not have format.

14:49 gnuvince: format can return a string which you can put in a message box, label, whatever.

14:50 cemerick: I'm sure one's opinion is informed by the problems that one needs to solve. At least in my world, simple parameterization of a string is almost always sufficient.

14:50 ah, parameterization, and (str (interpose "," seq)), etc.

14:54 drewr: What am I missing here? (map Math/sqrt [1 2 3])

14:55 Lau_of_DK: (map #(Math/sqrt %) seq)

14:57 drewr: Lau_of_DK: Thanks. My brain was failing me there.

14:58 I knew I had to promote it to an IFn but I was doing identity for some reason.

14:59 Lau_of_DK: No probs, imho Clojure should eat Java directly :)

14:59 AWizzArd: But this is only because Math/sqrt is a Java method and not a Clojure function.

15:00 (map clojure-fun col) is equivalent to (map #(clojure-fun %) col)

15:00 or not?

15:01 Lau_of_DK: Yes sir

15:07 Chouser: as long as you're only providing a single col argument to 'map'

15:09 drewr: I wonder if it would be too magical to automatically promote things like Math/sqrt.

15:09 Maybe static methods only?

15:10 They act functionally.

15:16 Chouser: that's been brought up before. I think rhickey_ was open to the idea, though I'm not finding a reference right now.

15:16 jgracin_: I have what is probably a silly question, but I've got to ask it anyway. Is there any way to compile a clojure file which references some Java classes, but without having those Java classes in the classpath?

15:17 ericlavigne: Why only static methods? Ball.throw (non-static) could be a function whose first argument is a ball, while ball.throw would be a similar function with one less argument (already received the ball object as its first argument).

15:18 jgracin_: perhaps you could refer to an interface which those java classes implement?

15:19 chrisn: I like the way ericlavigne is going

15:19 That exact feature would have made a lot of my opengl code a bit cleaner

15:19 jgracin_: ericlavigne: I'm trying to see if I can mix Clojure and Java code which have interdependencies and therefore cannot be compiled sequentially.

15:20 Chouser: jgracin_: you definitely need access to any classes you extend or interfaces you implement.

15:20 jgracin_: e.g. how would I compile A.java b.clj C.java in which A.java depends on code defined in b.clj and C.java, and b.clj depends on C.java

15:21 Chouser: I see

15:22 Chouser: gen-class uses introspection to poke around in the superclasses and figure out what it needs to do

15:22 ericlavigne: jgracin_: you can avoid such cyclic dependencies by breaking your code into smaller pieces.

15:22 Chouser: what jgracin_ described isn't cyclic

15:22 chrisn: ericlavigne: perhaps what you describe is how partial should work w/r/t java interop?

15:23 Chouser: jgracin_: I think you might be able to get where you want to go with careful use of ant and tasks for compiling .clj files.

15:24 cemerick: hrm, clojure.xml/emit doesn't do any string escaping at all...

15:24 Chouser: jgracin_: you might also look into using gen-interface (which I think doesn't need any of the classes it references) early, then javac all your .java files, then use 'proxy' in your .clj at runtime.

15:25 cemerick: yeah, that came up on the g.group. It's fixed in clojure.contrib.lazy-xml

15:26 jgracin_: Chouser: Interesting idea, I'll try that. Thanks!

15:27 cemerick: Chouser: is lazy-xml being considered as a replacement for clojure.xml, or is an analogous fix going to slip in there eventually?

15:27 Chouser: Perhaps I should post an issue

15:27 * cemerick hasn't done much of anything with xml in clojure until 5 min ago

15:27 Chouser: cemerick: I'd like lazy-xml to replace clojure.xml, but I've got no indication any such thing is planned.

15:29 clojure.xml has a couple correctness issues. string escaping, removing whitespace on parse, adding whitespace on emit

15:29 cemerick: yeah, it seems very prototypey

15:30 ericlavigne: chisn: I am saying that we should think of the object to which a method belongs as being simply the first argument in a function. As a shortcut for Java methods, we should be able to say obj.method which implies partial application of obj to Obj.method.

15:30 Chouser: lazy-xml fixes a couple of those, though it still always trims whitespace.

15:31 cemerick: Chouser: my brief run-ins with xml wizards have left me with the impression that whitespace handling is a decidedly tricky/ambigious thing when it comes to serialization

15:31 chrisn: ericlavigne: I am checking out memfn...

15:32 doesn't work for statics

15:34 ericlavigne: Maybe memfn expects you to pass something like Math.class as the second argument.

15:35 I haven't used it.

15:35 cemerick: I can see how lazy xml parsing might not be an ideal standard approach, though. I certainly always want the whole doc, so the laziness is just overhead for me.

15:39 ericlavigne: chrisn: I speak of the way I would do it. However, I don't yet know enough about Clojure to know if a better way has already been implemented. I'm certainly quite impressed by the parts of Clojure that I have used.

15:39 chrisn: I am in the exact same boat.

15:40 Once I get my demo project finished and lightly polished, I intend to go through the core source code and then through the contrib source code.

15:40 I always ask questions that just require more knowledge of the apis that came with the system.

15:40 ericlavigne: The proxies seemed overly complicated, so when I needed to create Java classes I just wrote some Java instead.

15:41 chrisn: I just forced that bastards to work my way ;).

15:46 I wish you could create immutable classes from clojure. I am using defstruct all over the place and every once in a while I mistype a keyword. Which is a runtime error...

15:50 Chouser: chrisn: defstruct may produce a class with fields in the future.

15:51 cemerick: don't you do something clever along those lines?

15:51 chrisn: Chouser: Is it possible to get compile time errors for certain classes of problems? I know, dynamic language blah blah, but I am not always using it in a dynamic way.

15:52 cemerick: Chouser, chrisn: yeah, genbean. It's evolved quite a bit since my last post on it some months ago.

15:52 I'll probably post an update after clojure goes 1.0 and I've updated it to match.

15:52 Chouser: chrisn: you can throw and exception from a macro

15:52 s/and/an/

15:52 chrisn: yep, good point

15:53 I have buddy doing work on partially typing lanuages.

15:53 Adding in hindley milner to python, but only where you have types

15:53 works pretty darn well.

15:53 cemerick: of course, the really nice stuff still requires that you drop any static type checking when creating the objects in question (e.g. when providing a delay for a slot in an object, rather than a strict value)

15:53 Chouser: chrisn: interesting. I've thought for quite a while that i wanted a language with optional static typing.

15:55 chrisn: I personally think types rock. I love Haskell and F#. I just love getting shit done a lot more ;) . Plus Lisp code just looks better.

15:55 Chouser: Scala convinced me I do not want required static types. :-)

15:56 chrisn: Heh. With F#, you can always cast something to an object. So you can easily defeat the type system.

15:56 I don't know about Scala.

15:57 Raynes: We were just having a conversation in #Scala about why F# is horrible.

15:58 chrisn: oh jesus

15:58 here we go

15:58 cemerick: indeed. It's like a black hole.

15:58 chrisn: why is F# horrible?

15:59 cemerick: maybe we can all just agree that all languages are horrible, and we'd all be better off running movable type presses.

15:59 or something :-P

15:59 chrisn: anyone tried newspeak? then you can plug in your own type system.

16:00 durka: hey kotarak, i'm having strange problems with gorilla

16:00 kotarak: Uh? *Strange* problems? That's no good.

16:01 durka: i start gorilla and do \sr in macvim

16:01 gorilla shows "Connection started"

16:01 macvim freezes

16:01 macvim and java quickly climb to the top of CPU usage

16:02 if i kill gorilla (ctrl-c), macvim unfreezes and shows the repl, which of course doesn't work because gorilla is dead

16:03 kotarak: huh?

16:03 That's strange.

16:04 Did you change something to get this behaviour?

16:04 (Other vim, ruby, clojure, contrib?)

16:04 Nafai: Doh

16:04 Figured out my issue. :)

16:04 I did 'git svn fetch' instead of 'git svn rebase' :)

16:04 durka: kotarak: i updated clojure and contrib to the latest svn

16:05 kotarak: Hmmm... Will check. I had no problems up to now.

16:15 durka: kotarak: i have to go, but mention my name and i'll see it

16:16 kotarak: ok. Just figuring out.

16:16 Some change in Clojure broke it.

16:40 RSchulz: kotarak: You should check out this topic from the group: http://groups.google.com/group/clojure/browse_thread/thread/93e35885b0c0706d?hl=en

16:40 It may be germane to what's happening to you in gorilla.

16:48 kotarak: RSchulz: thanks for the pointer

16:48 Will investigate.

17:12 mchurch: I have a noob question that is probably not clojure related. I'm trying to create a socket. This: (def sock (new java.net.Socket "" 5023)) : throws java.net.ConnectException : Connection refused. Why could that be?

17:13 Is it something wrong in my code, or is the problem at the system level?

17:14 karmazilla: apparently, nothing is listening on your localhost port 5023

17:16 RSchulz: mchurch: You're aware that that particular java.net.Socket constructor immediately attempts to connect to the spcified host and port, right?

17:16 mchurch: RSchulz: I think I've figured it out, because ServerSocket could be instantiated.

17:16 So I instantiated a ServerSocket on that port, then a Socket, and the socket connected.

17:17 So, I guess they're connected. I didn't realize that I needed a ServerSocket before a Socket.

17:17 RSchulz: You're attempting to connect to a listening socket in the same process?

17:17 Naturally, you'll need threads / Agents to make that work.

17:17 karmazilla: or non-blocking IO

17:17 mchurch: RSchulz: No, 2 different Repls

17:17 RSchulz: Yes, there has to be socket listening to accept the connection request.

17:18 mchurch: I'm just trying to get a handle on sockets before I do the next stage of my current projects

17:18 I didn't know what a socket was a couple weeks ago.

17:18 RSchulz: It's OK. Sockets didn't know about you, then, either.

17:18 Sockets, meet mchurch. Mchurch, sockets.

17:18 There. Now you've been properly introduced.

17:18 Anyway, what sort of protocol are you working towards?

17:19 You might want to work with slightly higher-level API such as the ones in Commons HTTP Client and HttpServlet.

17:21 mchurch: This is for an RPC engine.

17:23 karmazilla: also, for client code, you'd typically want to set timeouts before connecting, and thus not use a Socket constructor that connects automatically

17:23 mchurch: karmazilla: Ok. I'm just prototyping right now.

17:23 RSchulz: Is th wire protocol already defined? Is it an external requirement? Or are you inventing it? Or using HTTP?

17:24 Distributed programs are so non-tivial, it's almost always a good idea to build upon as much infrastructure / framework / etc. as you can.

17:25 Chouser: ...unless your homework assignment is to implement an RPC engine from the Socket level up.

17:25 RSchulz: Oh, to be in school again...

17:29 mchurch: RSchulz: The protocol's already written. We have an RPC engine already written in SBCL and I'm writing a Clojure version of it.

17:29 RSchulz: I see. Well, at least you don't have to think about that part. Is it text or binary?

17:29 mchurch: RSchulz: Binary

17:29 RSchulz: Odd.

17:30 Why?

17:31 mchurch: Oh. One unrelated question. Sorry, but this has been bugging me: regarding import, what's the Clojure analogue of import java.io.*?

17:31 In the event that I want to import a whole package rather than just a list of classes.

17:32 RSchulz: There's no "wild-card" import in Clojure.

17:32 mchurch: RSchulz: So you have to list all the classes?

17:32 RSchulz: Yes.

17:33 mchurch: RSchulz: Got it. Thanks.

17:33 RSchulz: I personally don't think wild-card imports are a good idea.

17:34 mchurch: RSchulz: What do you dislike about them?

17:34 RSchulz: You don't know what you're saying. In large systems that use many libraries, there can be clashes and you can get odd compilation errors.

17:34 I think you should say everything you mean, basically.

17:35 mchurch: RSchulz: Ah. Yeah, I can see that being a problem.

17:35 RSchulz: You could conceivably even get sucessful compilation and run-time errors (during dynamic linking, most likely).

17:36 Clojur at least doesn't make you say the package part over and over for each class from that package.

17:36 mchurch: RSchulz: Yeah. That would be horrible.

17:37 RSchulz: Realistically, it's not likely, though I've had the compile-time manifestation quite commonly in my own code.

17:37 I just couldn't see a better name for one of my classes than "Set", and so you can see the problem.

19:06 durka: kotarak: tracing gorilla reveals that after \sr gorilla goes into an infinite loop of de.kotka.gorilla.repl-ln/read-hook called with nil

19:15 lisppaste8: durka pasted "gorilla trace" at http://paste.lisp.org/display/72852

20:57 MarkVolkmann: Is there an absolute value function in Clojure? I've looked but don't see one.

20:57 I know it would be easy to write my own, but don't want to do that if I don't have to.

20:59 pjb3: Math/abs

21:00 That's the java one, but I've heard people complain because it doesn't work with all numeric types in clojure

21:00 MarkVolkmann: Oh right! I forgot to just use Java.

21:01 ericlavigne: pjb3: Also, methods aren't functions. It's always nicer to use something from native Clojure.

21:02 pjb3: ericlavigne: Is there a clojure function/macro that will return a function that wraps a method?

21:03 ericlavigne: I think that's what memfn is for, but I haven't used it yet.

21:04 pjb3: user=> (map (memfn Math/abs) [-3 3])

21:04 java.lang.IllegalArgumentException: No matching method found: abs for class java.lang.Integer

21:04 ericlavigne: I think it's trying to find an Integer method called abs in the Math package :-(

21:05 Maybe something like Math.class needs to be provided as another argument to memfn.

21:06 dreish: memfn predates #() notation, and I believe it is generally considered obsolete now.

21:06 Chouser: ,(map #(Math/abs %) [-3 3])

21:07 dreish: But that's unrelated to the fact that 3 is an int, and Math/abs takes a double.

21:07 pjb3: (map #(Math/abs %) [-3 3])

21:07 Right

21:07 Chouser: Or: (map #(.abs %) [-3M 3M])

21:07 ericlavigne: I thought Math.abs was overloaded to take a variety of possible arguments.

21:07 * ericlavigne goes to check the javadocs.

21:08 durka: int, long, float, double

21:09 dreish: ,(Math/abs -3)

21:09 clojurebot is being shy, but that gives me 3 at my repl.

21:16 durka: so shy that it left the channel

21:26 pjb3: What's the easiest way to convert a map to a hash map?

21:27 Chouser: you can use a java.util.Map in a lot of places that you'd normally use a hash map.

21:27 pjb3: In this case, I have a function that will passed a map

21:28 and I will need to do some stuff with it, passing through it multiple times

21:28 each time I pass through it, it needs to be in the same order

21:28 I don't care what the order is, as long as it's the same each time

21:29 Chouser: java.util.HashMap doesn't guarantee that?

21:30 pjb3: The map passed to the function could be an ordinary map

21:30 I want users to be able to do

21:30 (myfunc {:x 1 :y 2})

21:31 Actually now that I think of it, I can probably just use (seq themap) in my function

21:32 Chouser: yes, I would think so.

21:32 pjb3: because I don't need to use it associately while processing it in my function

21:32 associatively

21:35 Chouser: (into {} themap) if you really want a PersistentHashMap

21:37 pjb3: Wouldn't it have to be (into (hash-map) themap)?

21:38 Chouser: that's fine too

21:39 pjb3: What's the difference between array map and hash map?

21:39 or right, the array map preserves insertion order

21:40 In clojure {} gives you an array map?

21:40 Has it always been like that?

21:41 I thought the default was hash map

21:41 Chouser: hm...

21:42 rhickey: pjb3: array map preserves initial order, multiple insertions will cuase it to transition to hash-map

21:43 cause

21:44 pjb3: multiple being some large number?

21:44 user=> (class (assoc (assoc (assoc {} :a 1) :b 2) :c 3))

21:44 clojure.lang.PersistentArrayMap

21:45 rhickey: user=> (def m {1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1})

21:45 #'user/m

21:45 user=> (class m)

21:45 clojure.lang.PersistentArrayMap

21:45 user=> (class (assoc m 9 1 10 1))

21:45 clojure.lang.PersistentHashMap

21:45 pjb3: I see

21:46 That makes sense, has it always been like that or was that a change recently?

21:46 rhickey: always been a transation, recently made sure small maps were array maps, including {}

21:46 transition

21:47 pjb3: For some reason I remember doing (array-map :x 1 :y 2) for small maps that I needed to have a specific order for

21:48 What happens if you have a large map that you need insertion order preserved for?

21:48 Chouser: you can still do (apply array-map coll)

21:51 pjb3: Ok, and then you just need to make sure to know that if you assoc onto that, you'll get back a hashmap

21:51 Chouser: right

22:31 rhickey: large array maps are a bad idea perf-wise

22:51 gnuvince: Grrr... I like Haskell and all, but sometimes they can make things so hard to understand...

22:52 Nafai: rhickey: Thanks for all of the hard work getting Clojure working on Android, you rock.

22:52 rhickey: I verified it also works on an actual device :)

22:53 I've updated the README that is on github that includes the svn revision number and also to comment out the bean function

22:56 gnuvince: Nafai: you mean, Clojure can be used to create application on Google's Android?

22:56 Nafai: gnuvince: Yup!

22:56 gnuvince: That.s so cool :)

22:57 * gnuvince should really rush through this Haskell book and start being more serious about Java

22:57 Nafai: http://github.com/Nafai77/helloandroid/tree/master

22:58 aking: Nafai: you might also want to add a comment about increasing the heap size when compiling with dx

22:59 Nafai: or just update the build.xml :)

22:59 Nafai: aking: I didn't have to do so

22:59 * gnuvince is so lost in this parsing chapter

22:59 aking: Rich did - and so did I - runs out of mem on XP

22:59 Nafai: aking: What change did you have to make? I can make it and upload it

22:59 Yeah, I'm on a 64-bit vm on Linux :)

23:00 aking: From rhickey earlier: FYI, what I got running was this: http://github.com/Nafai77/helloandroid/tree/master, with no changes to it other than adding <arg value="-JXmx1024M" /> to the dex target in build.xml since I was getting out of mem errors there

23:02 Nafai: Ok, cool

23:02 I'll push that change

23:02 I might start porting over some of the sample applications to Clojure

23:03 aking: Nafai: I'm running emacs/slime under XP with a remote repl to my 64bit linux box for most of my clojure work - but used XP only for ANdroid testing. Eventually I'll get Android setup under linux

23:03 Nafai: Cool

23:06 Unfortunately, ddms doesn't run on 32-bit Linux at the moment, since it links against 32-bit swt librarie

23:06 Change pushedd

23:07 aking: Nafai: you mean "ddms doesn't run on 64-bit linux"?

23:08 Nafai: Yeah, :)

23:15 gnuvince: Hmmm

23:16 From Real World Haskell "Fewer parentheses leads to reduced mental juggling while reading a function."

23:16 I'd disagree with that: fewer parentheses means you need to remember the proper operator priorities

23:19 mattrepl: and mentally decoding $

23:21 Chouser: looking back at my Scala code, I'd have to agree.

23:23 Reducing parens does give an overall look of simplicity -- it does not appear to be tangled or deeply nested.

23:23 but both are illusions. It may be tangled and deeply nested, you just can't tell. In fact it is quite difficult to tell what the heck is going on at all.

23:25 falconai: any one have a quick example of how to use the "read" function? (read "(doc read)") obviously doesn't return any data structure

23:25 rhickey: I find Haskell particularly painful to read due to precedence etc - I'd much rather have sexprs

23:25 Chouser: (read (java.io.PushbackReader. (java.io.StringReader. "(doc read)")))

23:26 rhickey: falconai: (read-string "(doc read)")

23:26 * Chouser sighs

23:30 falconai: so it looks like a sequence is returned by read-string...but it has to be a tree where as sequences are usually linear ... how do i traverse this tree?

23:31 Chouser: falconai: no, it's returning whatever literal object the text represents

23:32 list, map, vector, etc.

23:33 falconai: i see...what i am trying to do is the following:

23:34 scheme's frtime (a CELLs like data flow framework) let's one do something like this: (even? 2) which returns true (like clojure) (even? seconds) switches true/false every second

23:35 scheme does this by extending its evaluator...i guess in clojure it would mean that between reader's output and the compiler, i would have to get access to the forms, manipulate them and send them on to the compiler...

23:36 does it make sense?

23:37 Chouser: I suppose.

23:38 there's code in clojure.contrib.walk for walking arbitrary clojure s-expr trees and making replacements.

23:38 you could run the reader yourself, I suppose, and then process the results and finally eval.

23:39 ...or you could write macros, which are given the already-read s-expr trees to work with

23:39 falconai: does walk operate on character based s-expr or forms returned by reader?

23:40 Chouser: ...or you could take advantage of built-in clojure features to get what you want without messing the the structure of the programs

23:40 'walk' operates on the data-structures returned by 'read' which are the same as what are passed to macros

23:40 falconai: there has been some discussion of "cell" implementations and "reactive programming" on the google group, including a couple of implementations.

23:42 falconai: right, i saw that (I think my original message might have started the main discussion)...but as far as I can tell, frtime is a more robust system...several years of use, several papers and a dissertation behind it

23:42 Chouser: ok

23:44 starting with 'read' seems like a hard way to go.

23:45 falconai: so a reactive expression such as (even? seconds) needs to be converted to a non-imperative expression involcing agents and watchers...but the end user should only see the reactive version (and not code related to agent watchers)...

23:45 what is a good way to do that? (keeping in mind that reactive expressions can turn programs "inside-out")

23:46 Chouser: would a macro be unacceptible? (react (even? seconds))

23:46 falconai: ...i have never programmed in clojure, scheme, CL, etc....so I am starting as ignorant as can be

23:47 I think (react (even? seconds)) may end up being the pragmatic solution...but what about when these reactive values are nested: (react (even? (+ (* temperature 100) seconds))) where temp and sec are reactive...will i be able to use

23:48 macros to 'walk' the expression tree and get at the reactive values?

23:48 Chouser: yes

23:49 falconai: good, encouraging...is there a way to make the REPL go through my macro for each new expression? (or is that the same as messing with the reader?)

23:49 Chouser: a macro named react in the above example would be given the entire tree of s-expressions, and would be expected to return a new tree of s-expressions to be evaluated in their place.

23:49 falconai: ideally, i'd still like to avoid telling clojure explicitly about reactive values...i'd like them to be transparent (which may not be possible in a clean way)

23:51 Chouser: well, you could write your own repl (not terribly hard) and process all expressions after 'read' and before 'eval'. But wouldn't it then be impossible to provide any non-reactive expressions?

23:51 falconai: Chouser: is textjure some sort of graphic REPL? for some reason i get that impression...and i'm very interested in something like it (lifting clojure's environment to something similar to spreadsheets)

23:52 Chouser: I plan for textjure to include a repl and a text editor using Swing widgets instead of a plain text terminal.

23:54 falconai: sounds good, do you have an ETA on it? :)

23:55 Chouser: well, the repl largely works already, but without a good text editor I don't think it provides much benefit.

23:56 I want vi-like keybindings, and passable syntax highlighting and indentation support.

23:57 right now I'm spending most of my "clojure time" fixing up the web page docs, but I hope to get back to textjure in another week or two.

23:58 falconai: speaking of which, http://clojure.org/repl_and_main is empty

23:59 Chouser: yeah, rhickey_ added a few blank pages. I'm not sure exactly why. :-)

23:59 gnuvince: probably to have people fill them up ;)

Logging service provided by n01se.net