#clojure log - Feb 09 2012

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

0:55 TheBusby: hmm, anyone have any idea why clojure.xml/parse would take 2.5 *minutes* to parse a medium sized wipipedia page?

0:59 fun exercise: (clojure.xml/parse "http://en.wikipedia.org/wiki/The_Book_of_Eli")

0:59 adiabatic: Is that valid XML?

1:00 TheBusby: xhtml

1:00 adiabatic: No. http://validator.w3.org/check?uri=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThe_Book_of_Eli&charset=%28detect+automatically%29&doctype=Inline&group=0

1:01 TheBusby: ahh okay,

1:01 so since some huge number of websites use invalid HTML/XML at some level, what would be a good way to parse HTML in Clojure?

1:01 amalloy: TheBusby, adiabatic: it's not invalid in any way that clojure.xml cares about

1:02 it's perfectly valid xml, it just doesn't conform to the xhtml spec

1:02 (in that apparently <ul></ul> is illegal - it can't be empty

1:02 )

1:03 TheBusby: hmm, is anyone else experiencing the same issue?

1:04 adiabatic: how do I import clojure.xml? :D

1:04 noidi: TheBusby, try https://github.com/nathell/clj-tagsoup

1:04 but tagsoup ignores all the stuff that makes the HTML unparseable

1:05 scottj: TheBusby: the data parsing libs in clojure aren't always the best since they don't use any external dependencies even when there are great libs out there

1:05 noidi: if you care about those bits, take a look at http://jericho.htmlparser.net/docs/index.html

1:05 TheBusby: noidi: Thanks, I'll give that a try now.

1:07 noidi: does tagsoup work with data.zip.xml by chance?

1:07 technomancy: scottj: hey, did I tell you I got new stickers?

1:08 noidi: TheBusby, I haven't tried that, but the docs suggest that it is: "the output format is compatible with clojure.xml"

1:08 ah, it calls xml/parse automatically

1:09 scottj: technomancy: yeah I saw that and will get you a SASE sometime; are they the same size as old ones?

1:10 i.e. about the right size for an ipod shuffle :)

1:10 technomancy: scottj: no; a fair bit bigger

1:10 scottj: cool

1:10 technomancy: 2x2 inches

1:10 noidi: TheBusby, so yes, it should return exactly what zip/xml-zip expects

1:11 bguthrie: By any chance does anyone happen to know what shell-out was deprecated in favor of?

1:12 TheBusby: noidi: Giving it a shot now

1:12 bguthrie: It used to be a part of contrib, but I don't see any references to it or functionality like it in the exploded github.com/clojure projects - unless I'm missing something?

1:14 technomancy: bguthrie: clojure.java.shell

1:15 bguthrie: @technomancy Awesome, thanks so much for that.

1:15 technomancy: np

1:20 TheBusby: noidi: that seemed to do the trick nicely! < 300ms

1:23 noidi: cool!

1:48 * technomancy wouldn't be too sure about ample reason

1:48 muhoo: sudden realization when reading about how clojure handles immutability: it reminds me a lot of git

1:49 Scriptor: how so?

1:49 muhoo: structural sharing, in particular. git comits

1:49 they're hashes of all the previous commits leading up to that one.

1:49 technomancy: http://eclipsesource.com/blogs/2009/12/13/persistent-trees-in-git-clojure-and-couchdb-data-structure-convergence/

1:49 muhoo: heh

1:50 technomancy: quite true

1:50 also nix packages

1:50 ~nix

1:50 clojurebot: excusez-moi

1:51 technomancy: ~nix is a purely functional package manager exhibiting many similar characteristics to Clojure's persistent data structures or git commit trees: http://nixos.org/nix/

1:51 muhoo: also, and this one is a bit farther afield... string theory and EPR

1:52 technomancy: oh?

1:52 muhoo: the multiple-worlds interpretation of quantum physics. things never change, new realities are created every moment.

1:52 clojurebot: In Ordnung

1:52 technomancy: ah

1:53 Scriptor: does string theory say that as well?

1:53 muhoo: from my feeble understanding of it

1:53 technomancy: is that in whitehead?

1:53 or russell maybe?

1:53 muhoo: no, einstein, IIRC

1:53 technomancy: huh

1:54 muhoo: http://en.wikipedia.org/wiki/Many-worlds_interpretation

1:55 sorry, everett-wheeler-graham

1:55 Scriptor: that's more of a copy-on-write implementation though :)

1:55 muhoo: ye

1:55 there's no garbage collection

1:56 then again, maybe there is

1:56 technomancy: dun dun dun!

1:56 muhoo: i can't wait until theoretical physicists start using clojure for their computation work.

1:57 Scriptor: heh, my friend's doing/did research in a quantum physics lab

1:57 still chugging along with fortran there

1:58 I think R is gaining some adoption, so incanter might have a niche

1:59 technomancy: so really the tardis is the cause of the universe's most egregious memory leak

1:59 never thought of it that way

2:00 and that, my friends, is why you should never create a time paradox

2:00 muhoo: paradoxes are, IIRC, impossible in a many-worlds interpretation

2:01 because the past is immutable

2:01 Scriptor: multiple leaks, really

2:01 technomancy: well I was thinking because the universe uses reference counting GC, and cycles make that break down

2:01 muhoo: as soon as you go into a different universe, it's a new branch. copy-on-write

2:01 Scriptor: wait, the universe or the multiverse?

2:02 anything with 0 references is just in a superposition

2:02 * muhoo feels like re-reading robert anton wilson's "schoedinger's cat" again

2:16 clj_newb: is there a way in clojure to do dead code static analysis?

2:17 i.e. it'll find me all functions that no one calls, all agents/atoms/vars taht no one uses, etc ...

2:18 technomancy: clj_newb: radagast does that for defns

2:36 clj_newb: interesting, a wizard of middle earth

2:36 for a moment, given the difficulty in pronouncing the name, I thought it came from ancient mythology

2:37 technomancy: you never know with tolkien

2:37 you never know with philologists in general, actually

2:37 clj_newb: I thought that that the RedWall series was good; then I read the Hobbit.

2:38 technomancy: well there's good and there's great

2:39 TimMc, arohner: https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md <- in particular under "Upgrading Existing Plugins"

2:39 or anyone with a lein plugin who's interested in trying out lein2 really

2:40 clj_newb: writing goes somethign like this: me, good, great, tolkein. [on an exponential scale]

2:40 technomancy: heh

2:52 wow, the contrib projects have each developers' timezone in the pom

2:52 that's ... interesting.

2:54 clj_newb: on osx, is full screen a matter of OSX or a matter of Java?

2:54 (I'm writing a gui app in clojure; and trying to figure out how to deal with full screening)

2:54 technomancy: https://github.com/clojure/data.xml/blob/master/pom.xml#L18 helpful for IRC stalking I guess?

2:54 all I know is OS X full-screening causes no end of trouble in Emacs

2:54 clj_newb: say my clojure/java app hangs (beacuse some exception is thrown and the gui loop is screwed up); now, is there a way for me to in osx force the app to go go a window; so I can get back to the console?

2:55 well, OSes, by definition, do not play nice together

2:55 ba da bum

2:55 technomancy: heh

2:55 clj_newb: i'm actually really curious about osx lion's single window focus thingy

2:55 perhas this is more appropriate for #macosx

3:47 Blkt: good morning everyone

5:05 jaley: I have a function calling .indexOf on a lazy sequence in the middle of a big loop, with a reflection warning. What's the right way to fix it? If it's a type hint, which type?

5:06 clgv: jaley: well, first: are you really sure you want to call.indexOf on a lazy-seq?

5:07 jaley: clgv: not certain, if you've a better suggestion that'd be preferred :) I want the first indexOf a matching string. The list is sorted by a probability score

5:07 clgv: oh and the list only ever has 10 elements

5:08 raek: jaley: you could construct a map from strings to indices from that seq

5:09 and then use that map to lookup the index of a string

5:09 jaley: raek: something like (into {} (map-indexed ...))?

5:09 raek: sure

5:09 clgv: jaley: I think a sulotion depends on the context since there several possibilities

5:09 raek: or (zipmap strings (range))

5:09 clgv: *solution

5:10 jaley: raek: ok, but .indexOf was worst case O(n), where n is 10, this seems like more cpu time for little gain?

5:10 clgv: jaley: can you paste an example with intended context?

5:10 raek: sure

5:11 I think the interface where .indexOf is defined is java.util.Collection

5:11 check the javadocs

5:11 lucian: shouldn't the reflection be avoided by forcing the lazy-seq into a vector?

5:12 jaley: i guess i would prefer to have a vector at this point for access by index, that makes the most sense

5:12 cemerick: lpetit: FYI, try #ccw

5:13 jaley: presumably I still need a type hint to avoid reflection if I then use .indexOf on that vector though?

5:13 raek: jaley: yes

5:15 osa1: I've done everything written in https://github.com/samaaron/serial-port but I'm getting ClassNotFoundException gnu.io.CommPortIdentifier java.net.URLClassLoader$1.run (URLClassLoader.java:202) when I run (use 'serial-port), can anyone help me?

5:15 jaley: so (let [^PersistentVector v (vec x)] ...) -- not sure if that will actually perform better though? presumable this copies the sequence to a vector first

5:15 but i think that's as good as i'll get

5:16 clgv: jaley: if you dont have other advantages from that, just annotate the interface that adds .indexOf to LazySeq

5:18 jaley: clgv, raek: done. thanks for the help!

5:20 clgv: jaley: but if you need that functionality more often you could write a more fitting more efficient solution. in the "worst case" by using loop-recur

5:22 jaley: clgv: sure. it's not really a bottle neck right now, I just had a load of reflection warnings in the part of my code that calls one of our java libs and was tidying it up. thanks again!

5:23 clgv: jaley: what I meant is now you have effort n+k and you could have effort k

5:23 jaley: clgv: oh I went with the ^LazySeq hint, not the vector

5:23 clgv: or maybe you have 2k and could have k. I dont know your matching function

5:24 raek: osa1: did you run "lein deps"?

5:24 osa1: raek: yes

5:25 raek: do you have a RxTx jar in your lib/ directrory?

5:25 osa1: raek: yes

5:26 raek: and you didn't launch clojure in some strange way?

5:26 osa1: raek: I'm run it with `lein repl`

5:26 I run*

5:28 raek: weird, there's a RXTXcomm.jar file inside the rxtx22-1.0.5.jar file...

5:28 I wonder which convention this is

5:29 osa1: raek: are you getting the same error?

5:29 raek: osa1: maybe the library uses some cake-specific features

5:29 osa1: the RXTXcomm.jar does not show up in the lib/ directory, right?

5:29 also, are you using the latest leiningen version?

5:29 osa1: raek: no, I only have rxtx22-1.0.5.jar

5:30 Leiningen 1.6.2 on Java 1.6.0_29 Java HotSpot(TM) 64-Bit Server VM

5:31 I'm upgrading lein

5:32 raek: I upgraded lein and then run lein deps again, and I'm getting same error

5:32 raek: I know that the native-deps plugin was merged into leiningen some time ago, but I haven't used it myself

5:33 osa1: yeah I also have a folder created with name "native", and it have some files I think related with rxtx

5:33 raek: osa1: could you try to put the dependency in :native-dependencies insted of :dependencies

5:34 also, I found this: http://groups.google.com/group/leiningen/browse_thread/thread/11e225cdea343176

5:35 osa1: you could also try to run "lein native-deps"

5:35 Sebboh: I'm *very* new to Clojure, so pardon me if I'm asking a silly question, or an often-asked question. :) I've read a little about clojure's perceived dependency on the jvm, and on the Java class library. Well, have you folks looked at Squawk? http://labs.oracle.com/projects/squawk/squawk-rjvm.html It's a jvm that is made out of very little C, a jvm implemented mostly in Java. Could you replace the java parts of that with Clojure parts?

5:35 raek: I'm just guessing here since I haven't used any lib that needed native deps myself

5:36 osa1: raek: looks like lein doesn't have a task named "native-deps".

5:36 raek: Sebboh: I guess so... Clojure is just a jar file :-)

5:36 osa1: did you try to put it in :native-dependencies and then run "lein deps"?

5:36 osa1: raek: yes and nothing changed

5:37 raek: osa1: you could try aksing in the #leiningen channel

5:37 or wait some hours and ask here again (when the US folks has woken up)

5:37 osa1: raek: ok, thanks

5:39 raek: Sebboh: sorry, I misread your question. the clojure compiler and the core data types are implemented in Java. you should be able to run clojure on any jvm.

5:40 and yes, there has been attempts to write as much of clojure as possible in itself. take a look at the ClojureScript project.

5:40 Sebboh: raek, well, Squawk (from Oracle/Sun, it's in "Labs" status..) is a J2ME jvm. So, it's probably very limited. But it's design might be... inspiring. :)

5:40 raek: it is possible that eventually the JVM version of clojure will use the approach of ClojureScipt (often called Clojure-in-Clojure, or CinC)

5:41 Sebboh: I will read up on ClojureScript and CinC.

5:41 :) Thanks!

5:48 raek: osa1: maybe you could try to delete the contents of lib/, have the dep in :native-dependencies and do "lein deps" again?

6:48 Raynes: raek, osa1: 1) Leiningen's native deps support was broken until the most recent release, 1.7.0. 2) When you run 'lein deps', Leiningen looks in each of the jars that you depend on for a folder called 'native'. If it is there, it pulls it out of the jar and puts it in a directory called 'native'. If you have :native-path set in your project.clj, it'll extract them to :native-path/native/*. After they are extracted, Leiningen will set java.library.path to

6:48 correct native deps for your particular operating system and architecture.

6:48 I'll see about documenting this soon.

6:49 Anyways, there is no :native-dependencies and no native-deps task.

6:49 I think those things were specific to a plugin for native deps that predates built-in support in Leiningen.

6:52 osa1: Raynes: so, do you have any ideas about my problem? I don't have :native-path in my project.clj, should I add one?

6:52 Raynes: I didn't actually read that far back. Give me a sec.

6:55 osa1: Huh. That's strange. I'm not sure I've ever had the pleasure of dealing with jars with jars inside of them. I'd create an issue on that project about Leiningen support. samaaron insists on using cake even though we've dropped development on it in favor of working on Leiningen, but I'm sure he'd help you out.

6:57 osa1: Raynes: ok, thanks

7:25 denlab: hi, 4clojure.com is down

7:26 Raynes: That's unfortunate.

7:26 denlab: and we are in the middle of a clojure evangelisation prez

7:26 Raynes: Damn it. Why am I always the only one awake with access to the server.

7:26 denlab: not a good press for clojure

7:26 Raynes: Give a minute and I'll restart it.

7:26 denlab: ;-)

7:26 would be great

7:27 Fossi: at least it shows the great community support ;)

7:27 osa1: ok, if anyone else is intrested, about my serial-port problem: https://github.com/samaaron/serial-port/issues/2#issuecomment-3886469

7:27 Raynes: I'm also trying to manage a nosebleed at the same time.

7:27 osa1: it means I have to use cake for now

7:28 dEPyWork: I came up with a "slogan" Clojure could use! :)

7:28 denlab: don't drop blood on the server

7:28 dEPyWork: It goes like this:" I've seen the future. It has pros, cons and conj."

7:28 what do you guys think? :P

7:28 Raynes: denlab: I appreciate your concern for my blood loss into the server.

7:29 Luckily the server is about about 500-600 miles away fro me.

7:29 cemerick: Raynes: what is that, permgen bonking on you?

7:30 Raynes: cemerick: Usually it just runs out of memory. In this particular case, it seems to have been swallowing up CPU for some reason. Mostly we suffer from not having a monitoring process that restarts the server for us when it goes down. I'm going to work on something when I get a chance.

7:30 denlab: It is back up.

7:31 cemerick: heroku won't bounce the app when it becomes unresponsive?

7:31 Raynes: denlab: You can assure your people that the problem is not Clojure and its ability to handle traffic but the nature of the website and how it allows people to evaluate arbitrary code and how that tends to eat up memory over time.

7:31 4Clojure doesn't run on Heroku.

7:31 denlab: thanks !

7:31 cemerick: ah, sorry. Thought it and tryclj were tied at the hip for some reason.

7:32 Raynes: Yeah, Heroku bounces tryclj I think.

7:32 But not reliably.

7:32 You've noticed it down a couple of times.

7:32 Wow. I'm going to have severe blood loss from this nosebleed.

7:33 Oops. I didn't restart it in a tmux session.

7:33 It's probably going to die again when I log out.

7:34 * Raynes will just not log out for a while, so as to not disturb denlab.

7:34 cemerick: lpetit: BTW, thank you for the debugger in ccw. Saved my ass last night. :-)

7:35 denlab: thanks !

7:35 lpetit: cemerick: you're welcome. And don't we forget cgrand initiated the debugger

7:35 so kudos to him too

7:36 cemerick: lpetit: sure, but he's never in irc anymore, so he can't get any kudos ;-)

7:37 Raynes: I miss all of our IRC brethren.

7:37 cgrand helped me write my first macro.

7:37 He will always hold a place in my heart. <3

7:38 cemerick: Everyone <3's cgrand. :-)

7:38 It is too bad he's not around here anymore, but that's life.

7:38 Raynes: lpetit is the sneakier frenchman, I'd say. He always sneaks in a little talk about ccw at the conferences. :>

7:39 cemerick: Yeah, lpetit has a certain craftiness about him. :-P

7:39 lpetit: Raynes: and now that Relevance sponsorizes me, the sneaking will be even heavier :-p

7:40 cemerick: WAT?

7:40 cemerick: you heard me

7:40 crafty, I tell you.

7:41 lpetit: cemerick: actually, I don't understand the meaning of it

7:42 cemerick: ha

7:42 cunning, full of surprises

7:42 Raynes: Sneaky.

7:43 cemerick: crafty > sneaky, insofar as the latter can have a negative connotation

7:44 lpetit: interesting, I didn't know that I could project this kind of image

7:45 cemerick: all the better for keeping people on their toes

8:14 jjcomer: I'm looking into parser combinators, in clojure. Does anyone have a suggestions as to which library I should work with (or should I just be porting parsec to clojure myslef :) )

8:14 lpetit: jjcomer: it would just be the nnthiest port :-)

8:16 clgv: since I am about to write a test. what do you guys recommend to use for it?

8:17 lpetit: what kind of test?

8:18 clgv: unit test style. I am testing 2 functions

8:19 lpetit: do you want it more to be for building a non regression test suite, or are you starting to write code in a TDD style?

8:19 clgv: no TDD for that particular task right now

8:20 the code is complete but I want to be sure that I can trust it ;)

8:20 lpetit: plain old out of the box clojure.test library, then ?

8:22 clgv: last time I used that I somehow hat the desire for more^^

8:23 lpetit: then I'll let other advocate their favorite alternative ;)

8:23 clgv: hmm I am reading lazy-test and midje pages right now

8:24 * algernon likes midje, but haven't tried much else yet, as midje satisfied his needs.

8:26 clgv: ah midje had these nice analysis semantic for results

8:30 * clgv finished reading and decides midje it is

9:04 _phil: is it possible to provide a "value function" for a defrecord/deftype? i.e. i might have a deftype x having [a b c d] as fields, but then i just reference x i want some function to provide a value for x

9:04 then=when

9:05 IDeref comes close

9:05 but not quite

9:05 i still need to write @x instead of just x

9:06 joegallo: i do not think such a thing exists

9:06 it sounds to me like [a b c d] might be metadata on x, though, where x is your actual value.

9:06 raek: you cannot extend the meaning of local variables

9:06 joegallo: otherwise i guess you should just become happy with IDeref

9:07 raek: _phil: perhaps a function of zero arguments solve the problem?

9:08 you'd have to write (x) to acquire the value, though

9:09 _phil: raek: yea, (x) or @x, not a big difference :)

9:10 other question, in what interface is conj defines?

9:10 defined*

9:10 wasnt able to find it while snooping through the source, there is cons but no conj

9:11 raek: yes, it's called cons in the java sources for some reason

9:11 joegallo: IPersistentCollection, but yeah, it's cons

9:11 _phil: oh, thanks a lot

9:18 clgv: humm "lein deps" and "lein clean" are pretty slow in leiningen 1.7.0 - they were much faster before. is there a reason for that?

9:21 joegallo: italian strike

9:21 clgv: it ran over a minute

9:21 joegallo: until leiningen gets better working conditions, clgv, the slowness will continue

9:21 clgv: joegallo: huh? it was much faster on both of these tasks in 1.5

9:22 joegallo: i'm just messing around, i have no idea

9:26 dribnet: anyone know how to adjust leiningen java compile ordering? I'd like aot -> java -> the rest.

9:26 jkdufair: is anyone using windows as their primary dev environment? even though i live there most of the time, it still feels like a foreign land

9:26 a few tips would be welcome

9:27 lpetit: jkdufair: not a foreign land for Clojure with e.g. Counterclockwise (shameless plug)

9:28 jkdufair: ah hm. maybe i should give it a try. i suppose i was supposing emacs. which is embedded somewhere in my mitochondrial dna. but maybe i should act like i'm in rome

9:28 lucian: emacs works fine on windows

9:29 lpetit: no, stay with emacs if you use emacs

9:30 lucian: with msys it's almost bearable

9:30 jkdufair: lucian: i've been using cygwin emacs and it works pretty well, but a few things freak out because java expects windows paths

9:30 lucian: also, console2 or mintty

9:30 jkdufair: i.e. lein trampoline chokes

9:30 lucian: jkdufair: works fine without cygwin

9:30 jkdufair: i tried native win32 emacs but clojure-jack-in fails and hacking it to work for a few hours got me nowhere

9:30 lucian: i see

9:30 jkdufair: lucian: do you use clojure-mode and lein?

9:30 lucian: not on windows

9:30 * lucian doesn't have to use windows anymore

9:30 jkdufair: indeed

9:32 i ended up trying lein swank from cmd.exe. worked great. slime-connect. great. C-c C-k. *crash*

9:32 lucian: i was using msys + bash + console2

9:32 jkdufair: ah. i'll look into that

9:51 Raynes: semperos: http://clojars.org/org.clojars.ninjudd/data.xml

9:51 clgv: well midje's tabular is great for my randomized test, although there could be a more specialized macro for randomized tests

9:51 Raynes: And the reason it's still a snapshot is because… well, I'm not sure anyone really knows.

9:53 jkkramer: semperos: Raynes: it's recently undergone a rewrite by Ryan Senior. I believe they're trying to get the new version to work with the build system

9:53 semperos: understood

9:53 jkkramer: i'm using a checked-out, locally installed version myself

9:53 semperos: Raynes: thanks, saw the one on Clojars, it's a bit old at this point

9:53 Raynes: jkkramer: I see. I believe the old version had the same problem.

9:53 semperos: I'm happy to locally install it myself

9:54 Raynes: semperos: You can push a version to clojars if you need something to depend on.

9:54 semperos: just makes it harder to add to a larger project with other developers unless I add my own org.clojras.semperos... version

9:54 jkkramer: the new version is nice, works much better with huge xml files that don't fit into memory

9:55 semperos: I'm all for improvements :)

9:55 thanks for the info, guys

10:10 Raynes: jkkramer: That's pretty spectacular. Did he do it in like a day? This must have happened really quickly. The original version was pretty non-trivial.

10:11 jkkramer: Raynes: there have been dev list posts on it periodically for a few months, I think

10:11 Raynes: Then I suppose he was rewriting it while they were still trying to get a release out for the old version, because that was pretty recent.

10:13 cemerick: yeah, Ryan's been working on it for a while

10:18 Raynes: Man, Python is so weird.

10:20 cemerick: How are you and Vim getting along?

10:21 cemerick: so-so

10:21 I'm trying to make it my baseline editor, e.g. replacing sublime and textmate

10:22 Raynes: You used ST2?

10:22 cemerick: Wrote the whole book in it.

10:22 * Raynes is surprised what he said about ST2 in his blog post didn't piss people off.

10:22 cemerick: *shrug*

10:22 Raynes: I guess you can't fight the truth.

10:22 cemerick: it's ok, hardly sublime

10:22 Raynes: It's a good text editor. I just strongly disagree with the choice to use textmate bundles.

10:23 cemerick: Oh, is it compatible with them?

10:23 Raynes: I'd rather it support a fraction of what it supports right now and have sane syntax definitions.

10:23 Yes.

10:23 The Clojure one is a couple thousand lines of XML and still doesn't get it right. :\

10:24 cemerick: compound regexes FTW!

10:24 anyway, I presume sublime will eventually go the way of TM, which again leaves me without a reliable editor. Vim seems as reasonable a candidate as any.

10:24 * lucian uses emacs + evil

10:24 cemerick: BBEdit would probably be another option.

10:25 lucian: all the extensibility of emacs with the sane keybindings in vim

10:25 and some extra confusion on top

10:25 Raynes: cemerick: I was going to paste the tmLanguage file for you, but (I swear to God) it is too big to paste in refheap.

10:25 lucian: I'm impressed with evil-mode. I'd have used it even before I started using Vim had I know it was so excellent.

10:25 I love text objects, in particular.

10:26 lucian: it's a really, really good vim mode

10:26 i've been using it for 2 months or so without learning even one emacs keybinding :)

10:26 jkkramer: can ST2 or TM2 handle proper lisp indentation?

10:26 Raynes: My problem with evil-mode is just that it's so confusing. There is overlapping functionality so I always question "Should I use the Emacs way or the evil way?" and my hands twitch in the meanwhile.

10:26 jkkramer: Can it handle it? Perhaps. Does it? God no.

10:27 cemerick: jkkramer: ST2 doesn't do too badly. I wouldn't want to use it more than occasionally though.

10:27 too badly compared to other non-lisp-ready editors, that is

10:27 Raynes: I'm not sure what the capabilities are. I don't think any sort of intelligent structural indentation is possible. These are just big fat XML files.

10:28 jkkramer: yuck

10:28 Raynes: cemerick: The point where I gave up was where I turned on vintage and tried to reindent some code with =ab and it just completely warped it.

10:28 cemerick: Raynes: I have no idea what you just said. :-)

10:29 Scriptor: vintage?

10:29 cemerick: At the moment, I'm happy enough to have learned about a vs. i :-P

10:29 lucian: Raynes: i always use the vi way

10:29 Raynes: Go screw up some indentation in a Clojure source file in Vim and then type =ab.

10:29 Scriptor: ST2 has a Vim emulation mode called vintage.

10:29 Scriptor: = automatically fixes indentation

10:29 ohh, for sublime

10:31 pdk: vim is good enough at getting lisp indentation wrong on its own

10:31 Raynes: pdk: Howso?

10:31 Scriptor: vimclojure seems to handle it alright

10:32 * lucian nods

10:32 Raynes: I got that impression at first as well until I turned on fuzzyindentation in VimClojure.

10:32 hhutch: cemerick: i haven't ever felt like I quite got a good vim+nailgun workflow down, are you happy with it so far?

10:32 lucian: but i fell in love with M-x package-install

10:32 Raynes: I haven't bothered with nailgun.

10:32 TimMc: Augh, how did this plugin ever work?

10:32 Raynes: Lein2's reply repl should further enforce my indifference to those in-editor REPLs.

10:32 cemerick: hhutch: oh, I'm not using vim for Clojure dev.

10:32 TimMc: It's completely broken now, and I'm using teh smae version of lein as when I wrote it.

10:32 clojurebot: excusez-moi

10:33 hhutch: cemerick: ah i misunderstood

10:33 Raynes: TimMc: What plugin?

10:33 cemerick: hhutch: I'm hacking on counterclockwise right now. :-)

10:33 jkkramer: i'm looking forward to giving CCW another try

10:33 TimMc: Raynes: lein-jit

10:34 hhutch: nailgun works, but i always hear so much about emacs+clojure that i'm giving it a try, and if i didn't have EVIL mode, i'd go crazy

10:34 lucian: is there some joke about CCW? where does the name come from?

10:34 Raynes: I need to give CCW another shot. The last time I tried it, I couldn't really figure out how to work it.

10:34 lucian: evil is nice indeed

10:34 jkkramer: I like what emacs lets you do, but not how it makes you do it. CCW seems saner

10:34 lucian: and as annoying as elisp is, it still beats vimscript

10:35 hhutch: lucian: i still find evil to be kind of flaky. i'm always forgetting what mode i'm in

10:35 Raynes: lucian: Brainfuck beats VimL.

10:35 TimMc: In nastiness or readability?

10:36 Ah, the latter, from context.

10:36 ejackson: oh lord, Vim and Emacs all at once, i'll never be worthy.

10:36 lucian: hhutch: it's slightly different, yes. things like :e vs :badd and so on

10:36 cemerick: hhutch: nailgun will be going away soonish

10:36 replaced by jark, AFAIK

10:36 hhutch: cemerick: replaced with ?

10:36 oh

10:37 cemerick: That's all sorta blocking on me at the moment. o.0

10:37 Raynes: cemerick: I think the VimClojure fellow is rewriting his repl stuff with nrepl.

10:38 cemerick: Raynes: Yup, Meikel wrote the bencode impl for nrepl. :-)

10:38 Raynes: I don't know what you just said.

10:38 TimMc: b-encode?

10:38 Raynes: Okay, that makes more sense.

10:38 cemerick: don't worry about it :-)

10:38 I'll make more noise about that later in #leiningen.

10:39 hhutch: cemerick: you mean the jark written by isaac praveen ?

10:39 cemerick: yup

10:39 hhutch: interesting

10:39 Raynes: lucian: I'd go back to Emacs and use evil-mode, but there are a lot of other things I like about Vim that make it hard. For one, I could never (ever, ever) get mouse support to work properly in a terminal emacs. In Vim, the distinction between macvim GUI window and terminal Vim is basically nil.

10:40 cemerick: Martin can't-remember-his-name wrote an nREPL client in O'caml, which is obviously crazy fast to start when compiled down to a native executable.

10:40 …which helps in the vim environment a lot. :-)

10:40 TimMc: Hah, "O'caml"

10:40 cemerick: It's the Irish version.

10:40 Raynes: lucian: Another thing that bothers me is that people treat evil-mode and friends as if it were training wheels for vim users -- I don't get that. evil-mode seems to be an all-around better alternative to some bizarre Emacs keybindings that I never bothered to remember when I did use it.

10:41 lucian: Raynes: indeed, but that's less of a problem with evil itself

10:41 Raynes: =ab is much better than "copy this text and then run reindent-region"

10:41 lucian: it's new enough and complete enough that if you tell folks in #emacs you're using it and don't want to learn emacs you'll get no more than suggestions to try anyway :)

10:43 Raynes: lucian: Do you use Emacs on OS X?

10:43 lucian: no

10:44 Raynes: Just wondering if anyone else had ever experienced that weird fringe rendering bug where linum-mode line numbers get skewed and unreadable.

10:44 dunib: Raynes: why were you trying to use a mouse in the terminal? the concept seems strange and uncomfortable

10:44 Raynes: The only solution seems to be to put a gap to the left of the numbers which is pretty hideous.

10:44 jlf: Raynes: that is/was a known issue but i don't recall if there's a resolution yet

10:44 lucian: Raynes: wfm on ubuntu

10:44 Raynes: lucian: It's an OS X specific thing.

10:45 lucian: i see

10:45 jlf: Raynes: you might search the emacs-devel archives

10:45 Raynes: dunib: Because I scroll and select with the mouse if my hand happens to be sitting on it.

10:45 I'm not a super l33t haxxor man who never touches his mouse.

10:45 Haven't reached that point of ascension yet.

10:45 jlf: Thanks.

10:46 TimMc: What issues are you having with that plugin, specifically?

10:46 TimMc: Raynes: Done broke.

10:46 Raynes: (If you've already told me this, sorry, I've been talking editors with people)

10:46 TimMc: Let me get the fix out the door first.

10:46 dunib: Raynes: you managed to get vim to scroll in a terminal? whenever I scroll in the terminal it tricks my by showing scrollback.

10:47 hhutch: Raynes: i wouldn't buy into that hype... the only reaso you should pay attention to that "don't touch the mouse" is because you actually have a mouse which is far away from the home row. a touch pad you can reach with your thumb is a completely different thing

10:47 Raynes: hhutch: I've mostly survived with my mouse so far. But man! The seconds of my life that I've lost by reaching for my touchpad!

10:47 lucian: touchpads are awesome

10:48 they're the reason i still use mice at all

10:48 Raynes: dunib: Seems to work out of the box for me. Well, I might have set something...

10:48 lucian: thinkpad nubs are nice to

10:48 Raynes: dunib: It probably wouldn't work in tmux or screen session.

10:48 lucian: i think even desktop keyboards should come with a touchpad beneath

10:48 hhutch: i guess it helps to have ginormous hands like i do. my thumb reaches the touchpad on most laptops without my hads leaving the homerow

10:48 * cemerick misses trackballs where trackpads are now

10:48 Raynes: cemerick: I have a trackball. :D

10:48 cemerick: as do I!

10:49 Raynes: I bet mine is better.

10:49 cemerick: heh, probably

10:49 I miss the ones that used to be built into the laptop, tho.

10:49 Powerbook Duo 230 FTW

10:50 Raynes: cemerick: http://www.kensington.com/kensington/us/us/p/1444/K72327US/slimblade%E2%84%A2-trackball.aspx

10:50 I have this.

10:50 Also, yay for unicode in a URL.

10:50 hhutch: 68030 ?

10:50 cemerick: hhutch: absolutley

10:50 hhutch: wow, you *could* run netbsd on that

10:50 cemerick: loved that laptop

10:50 hhutch: but no JVM

10:50 :(

10:51 cemerick: Raynes: I looked at that. Ended up getting another trackman wheel for $25.

10:51 Raynes: Your life is empty.

10:51 cemerick: Been using the same trackball for ~8 years now, I think.

10:51 Raynes: Unfortunately, I haven't used my trackball much lately.

10:51 cemerick: You're right. It is.

10:51 Raynes: I have a magic mouse and magic trackpad.

10:51 cemerick: Thus, my move to vim. It'll get me more friends.

10:51 Raynes: And my crappy ancient built in touchpad that doesn't work very well.

10:52 hhutch: does anybody use a wacom bamboo as a touchpad?

10:52 Raynes: My magic mouse was a bit of a bad decision.

10:52 hhutch: Raynes: how so?

10:52 cemerick: hhutch: tried to — not nearly as smooth as the built-in

10:53 Raynes: I bought it because it is smaller than a trackpad and I figured I could use it while on the go. Unfortunately cars + mouses don't work very well.

10:53 hhutch: cemerick: did you try any other touchpads? like the apple?

10:53 Raynes: If I let it go for a second, it slides into oblivion.

10:54 dunib: hhutch: no, nobody uses a bamboo as a touchpad. because they rely on the stylus for information, you can smudge your fingers all over them, and it does nothing.

10:54 cemerick: hhutch: nah, the trackball is far better for me

10:55 clgv: I wonder whether interleaving :when predicates in a 'for works like intended? (for [[k1 v1] m :when (map? v1) [k2 v2] v1 :when (map? v2) [k3 v3] v2] ...)

10:56 dunib: Raynes: the apple magic trackpad's pretty good. but to use it off a desk, it requires two hands. well, unless you enable some tap-to-click feature.

10:56 hhutch: dunib: no, there's two different models of bamboo... one is called a pen&touch, it has a capacitive touch layer

10:58 Scriptor: my main gripe with my hp is the multi touch

10:58 on my mac the comination of vim with a good trackpad nearby was pretty good

10:58 almost never used C-d or C-u for scrolling

10:59 unlink`: Are closures idiomatic in Clojure for encapsulating state? I would use vars to hold my refs, but I actually want multiple copies of my function running with different state at the same time.

11:00 cemerick: unlink`: very

11:00 unlink`: It doesn't look particularly idiomatic, but this could be accomplished like (fn [] (let [aref (ref {}) otherref (ref {})] (fn my-func [x y] ... )))

11:04 cemerick: That is how you would accomplish it?

11:05 cemerick: unlink`: hard to know since I don't know what the domain is, but that's fine AFAIC.

11:06 I very often use partial to accomplish similar things.

11:06 And middleware of all sorts is based on the same kind of composition.

11:07 unlink`: cemerick: Fair enough. The particular function is a consumer of real-time data and is doing its own local bookkeeping of such.

11:22 TimMc: Raynes: https://github.com/timmc/lein-otf/commit/36de0ba7ac27c6498168e49fb35144be9223320e

11:23 Raynes: The plugin works by swapping out the project's :main namespace for one of its own -- which *used* to get that namespace included and compiled AOT. Somehow that stopped happening.

11:23 Raynes, technomancy: I fixed the plugin by also specifying :aot [lein-otf.loader].

11:24 Raynes: Strange.

11:24 I'm pretty sure that's still how it works.

11:24 No idea why it wouldn't work there.

11:25 TimMc: It used to! :-(

11:25 Raynes: TimMc: In other news, your usage of commas there makes me want to strange a kitten.

11:25 strangle*

11:25 TimMc: Oh, in the nick-prefixing?

11:25 Raynes: I've never stranged a kitten before.

11:26 No.

11:26 (assoc-in ,,, ...)

11:26 TimMc: There's always a first time.

11:26 nachtalp: Raynes: it's only fun if you don't get caught

11:26 TimMc: Oh, hah! Yeah, I've stopped doing that.

11:29 technomancy: Raynes: so the data.xml that we use for "lein2 pom" never saw an actual release before being scrapped and rewritten?

11:29 Raynes: technomancy: Apparently, yes.

11:29 technomancy: lovely

11:29 Raynes: technomancy: I'll fix pom (if fixing is necessary) when the new one is released. If that ever happens.

11:29 technomancy: yeah, I'd like to get off the snapshot before the preview, but that seems unlikely

11:29 thanks

11:30 Raynes: technomancy: We're on a snapshot of reply as well.

11:30 technomancy: that we can surely take care of

11:30 Raynes: Might want to talk to Colin about doing alpha releases and such instead of snapshots.

11:41 pandeiro: ibdknox: did wrap-aleph-handler used to be in the noir.core ns? trying to understand this: https://gist.github.com/1257857

11:47 ah nm it's in aleph.http

11:55 `fogus: Putting together a 1-page ClojureScript cheat-sheet. Feedback is welcome :-) https://github.com/fogus/clojure-cheatsheets/blob/master/pdf/cljs-cheatsheet.pdf?raw%3Dtrue

11:58 Visual issues aside. Anything missing content-wise?

11:58 lpetit: fogus: <3

11:59 dnolen: `fogus: awesome!

12:00 `fogus: I'd like to create another cheatsheet for CLJS vs. jQuery (to the death)

12:00 dnolen: `fogus: heh

12:01 `fogus: But not sure what to put there yet.

12:03 devn: `fogus: was it you that built a little ruby metadata lib?

12:03 `fogus: BTW, repo at https://github.com/fogus/clojure-cheatsheets

12:03 devn: I don't think so.

12:04 devn: hm, nevermind :)

12:04 `fogus: devn: I have https://github.com/fogus/duckstrings -- is that what you mean?

12:05 And this https://github.com/fogus/clj.rb

12:06 pandeiro: `fogus: an example of :use-macros maybe?

12:06 `fogus: pandeiro: I have a require-macros use in the namespace section.

12:07 pandeiro: `fogus: i saw but i have seen :use-macros in some code but i'm not sure of the exact syntax

12:09 `fogus: pandeiro: Got it. Thanks!

12:11 jkdufair: very nice cljs cheatsheet

12:12 `fogus: Thanks. Suggestions welcomed

12:13 pandeiro: Updated

12:14 lpetit: fogus: is there a leiningen cheat sheet like this floating around ? A CLJS oriented (with library mgt addressed) one ?

12:15 `fogus: lpetit: Not sure... but if I have time today there might be ;-)

12:16 lpetit: fogus: when you're at it, would you please create one for CCW as well ? ;)

12:16 * `fogus faints

12:20 lpetit: fogus: what does WJW mean ?

12:23 pandeiro: `fogus: ibdknox/crate (hiccup impl) as a templating solution might be better to mention than pinot, which i understand chris is deprecating

12:24 `fogus: pandeiro: Oh? Would love some verification from ibdnox

12:24 ibdknox ^^

12:25 pandeiro: `fogus: i forwarded you the announcement from the noir list

12:25 `fogus: great, thanks

12:26 muhoo: what does CCW mean?

12:26 TimMc: CounterClockWise

12:26 Clojure plugin for Eclipse

12:27 lpetit: New beta of CounterClockWise just released to the wild http://ccw.cgrand.net/updatesite-betas

12:57 hagna: so I have (:require [hobbit.bitly :as bitly]) but the line (def *bitly* (bitly/Bitly. "a" "b" "c")) fails with Unable to resolve classname

13:00 Bitly is a defrecord I checked

13:00 what's wrong?

13:02 `fogus: hagna: Try adding an (:import bitly.Bitly) and then changing to (Bitly. "a" "b" "c")

13:02 hagna: `fogus: can I do that in the repl?

13:03 clojure.core=> (:import bitly.Bitly)

13:03 CompilerException java.lang.RuntimeException: java.lang.ClassNotFoundException:....

13:04 `fogus: I think so

13:04 TimMc: hagna: There are two reasons that fails: :import is a keyword, bitly.Bitly is an unknown symbol.

13:04 `fogus: hagna: https://gist.github.com/ae4d5034a2649a4a40e1

13:06 Raynes: (import bitly.Bitly)

13:06 TimMc: Doesn't matter because import is a macro.

13:07 `fogus: Long time no IRC. :D

13:07 hagna: `fogus: thanks

13:07 `fogus: Raynes: This company of mine... making me work and all! Well I never!

13:08 TimMc: Raynes: It doesn't matter once you use import instead of :import, yes.

13:08 hagna: `fogus: we're working

13:08 `fogus: For the newcomers: https://github.com/fogus/clojure-cheatsheets/blob/master/pdf/cljs-cheatsheet.pdf?raw%3Dtrue FEEDBACK WELCOME

13:08 Raynes: `fogus: What is the email address you're most likely to receive email at? I've sent you a couple of emails over the past few months for various reasons, but I'm not sure you received them.

13:08 * `fogus foot in mouth

13:08 `fogus: Raunes: The one at the top of blog.fogus.me

13:09 hagna: Raynes: um (import bitly.Bitly) didn't work in the repl

13:09 Raynes: maybe I need to require that ns first?

13:09 technomancy: `fogus: so you're liking LaTeX? thinking of using it for my clojure west slides

13:10 there's a solemn dignity surrounding Computer Modern that you just don't see much of these days

13:10 `fogus: hagna: I don't think import will work on a class that is not implicitly import3ed

13:11 technomancy: It's fantastic! I'm sad that I've only now discovered it.

13:11 Raynes: I didn't have that same conclusion.

13:11 technomancy: are you using auctex or org or just straight up latex?

13:11 `fogus: technomancy: WRT Computer Modern... the font?

13:11 technomancy: `fogus: yeah

13:12 ahem; the typeface

13:12 `fogus: technomancy: not sure exactly.

13:12 technomancy: Sussman had it in his strange loop slides and I was all "this guy is the man"

13:12 `fogus: I'm a LaTeX n00b

13:12 technomancy: I know correlation is not causation, but it doesn't hurt

13:13 cemerick: technomancy: Computer Modern is even more sublime in something sane like Keynote. :-P

13:13 `fogus: I vow to never miss another StrangeLoop as long as I shall live!

13:13 * `fogus WHOOOOOOSSSHHH

13:13 technomancy: lol, keynote

13:13 cemerick: the mocking, it slows me not

13:13 * Raynes likes keynote.

13:14 technomancy: `fogus: supposedly org has some pretty sweet export-to-latex capabilities

13:15 Raynes: And checkboxes.

13:15 cemerick: Raynes: I had used powerpoint within virtualbox for ages. :-|

13:15 Raynes: Nothing like plain-text checkboxes to make the sunlight shine though on a cloudy day.

13:15 `fogus: technomancy: I am at least 20 years (at best) behind the formatting scene

13:16 technomancy: `fogus: that's precisely the right place to be

13:16 considering it hasn't progressed at all in 20 years

13:16 cemerick: There's a "formatting scene"?

13:16 hagna: da scene please

13:16 `fogus: YAY

13:17 technomancy: hiredman: was it org-beamer that you used for the safe manual?

13:17 `fogus: "there's a community?"

13:17 technomancy: or sorry, Manuel.

13:19 hagna: https://gist.github.com/1781759 so what is wrong with importing bitly here?

13:20 `fogus: Who is going to Clojure West?

13:20 nachtalp: `fogus: if you plan to use a lot of references in your latex-docs you might want to check out citeulike.org - helped to keep me sane back in the day

13:21 `fogus: nachtalp: Are you kidding. I live at citeulike

13:21 ;-)

13:22 hiredman: technomancy: just the org-mode latex export

13:22 beamer is a latex package for slides I believe

13:22 technomancy: gotcha

13:22 nachtalp: `fogus: nevermind then :) - you'll love the bibtex export ;)

13:24 apwalk: `fogus: me + 4 co-workers. :)

13:29 `fogus: apwalk: ?

13:29 apwalk: going to clojure west

13:29 `fogus: apwalk: ahhhhh. Say Hi if you have the chance.

13:30 Raynes: `fogus: I'll be there in spirit.

13:30 apwalk: certainly will. i'm psyched to be able to go

13:31 TimMc: hagna: Does that gist work?

13:32 `fogus: TimMc: My gist?

13:32 TimMc: No, hagna's.

13:33 `fogus: k

13:33 hagna: TimMc: no

13:33 TimMc: this one does though

13:34 https://gist.github.com/1781893

13:39 Raynes: hagna: https://refheap.com/paste/688 I cleaned that up a bit.

13:40 hagna: Also, the big problem here is that I didn't write any examples on using the library in the README. I apologize for the trouble you've been having figuring it out.

13:40 hagna: Raynes: it's not just you

13:40 :)

13:40 Raynes: thanks though

13:40 mfex: `fogus: re cljs cheatsheet: deftype access is (.-b a) with the new syntax

13:47 `fogus: mfex: Thanks

13:52 jcrossley3: `fogus: hi. are you open to including the tests in the core.cache jar? i'll send a PR if so.

13:54 `fogus: jcrossley3: Do you mind generating a patch? I will create a ticket if you don't mind providing the overview text for your pull req

13:57 jcrossley3: `fogus: overview text? i just want to re-use some of your test fn's for my impl.

13:57 `fogus: I guess I don't understand the question

13:58 jcrossley3: :)

14:00 `fogus: if clojure.core.cache.tests were in the core.cache jar, i could refer to, say do-dot-lookup-tests in my own tests for my CacheProtocol implementation.

14:00 hagna: Raynes: dang this isn't the way to call shorten (hobbit.core/shorten *bitly* "a" "b")

14:02 jcrossley3: `fogus: not a huge deal, just saves me from having to worry about that big copyright notice at the top of said file, but still ensure my cache behaves reasonably. :)

14:02 ibdknox: `fogus: I'm confirming that's the case :)

14:03 `fogus: jcrossley3: Do you know an easy for me to make them appear in the jar?

14:03 lynaghk: `fogus, do you know if anyone on core is looking at instant literals in ClojureScript? I have a client who wants 'em but right now ClojureScript gets angry with "No method in multimethod 'emit-constant' for dispatch value: class java.util.Date"

14:05 I'd be happy to dig into it and submit a patch, but I wanted to check with you first; there's nothing on JIRA or obviously on cljs branches.

14:06 `fogus: lynaghk: They're only available in Clojure ATM

14:06 amalloy: `fogus: since you're here, http://dev.clojure.org/jira/browse/CLJ-929 is an issue i recently came across with the property-access syntax in jvm-clojure

14:06 ibdknox: lynaghk: sorry I haven't responded to you about the libs thing, I'm still thinking what the best course of action is

14:07 lynaghk: ibdknox: oh, no problem. It warms my heart when people think before talking =)

14:07 ibdknox: `fogus: we should actually chat at this conference :)

14:07 lol

14:07 lynaghk: haha a rarity ;)

14:08 lynaghk: `fogus: okay, I will dig into it then, thanks.

14:08 dnolen: lynaghk: ibdknox: thx for sending that out - I think the proper solution is to solve at the level of the build tool - lein

14:09 `fogus: (inc ibdknox)

14:09 lynaghk: dnolen, yeah I got your email. So your preference is to just make people explicit about it--if they want a JAR containing JS they'll have to add it to project.clj's :deps of course, but also to some other build-tool options?

14:10 dnolen: `fogus: lynaghk: sounds like something that could be solved with support for cljs_init.clj, Clojure will do the right thing - but you need to add a dispatch case to the CLJS compiler.

14:10 lynaghk: rather than have clojurescript aggressively suck in everything on the classpath like how it does for clj and java code

14:10 *it = jvm clojure.

14:10 dnolen: `fogus: lynaghk: actually given that Clojure supports it, probably should just add the emit-constant case.

14:11 jcrossley3: `fogus: er... i'll get back to you on that. :)

14:11 ibdknox: lynaghk: dnolen: yeah I'm not sure I like the idea that all js code gets sucked in, but it should be virtually automatic for the end user to take a CLJS jar and use it if it contains externs/libs/whathaveyou

14:11 dnolen: ibdknox: that's what I'm thinking.

14:12 `fogus: dnolen: emit-constant for Date?

14:12 dnolen: lynaghk: I think the optimal experience for folks is something that works with their existing lein workflow

14:12 `fogus: yes

14:12 ibdknox: dnolen: it *seems* reasonable that that could be at the level of lein, but I'm not sure if everything is there for that to be possible

14:12 it might be with the classpath changes

14:13 then we just need to create a convention for either using a manifest, or named dirs, or something. dnolen: your suggestion was the project.clj?

14:14 dnolen: ibdknox: there needs to be convention as far as the jars, something describing the js to include and the externs.

14:14 `fogus: dnolen: I created a case for this that should avoid outright failure, but in the current tagged literal sense the capability is not yet in CLJS

14:15 amalloy: I think there is an older card about that... looking

14:15 dnolen: ibdknox: ideally I can grab jQuery just like I grab any Clojure dep. The jQuery jar includes the externs .js etc. It's foreign lib, so it should no get compiled via GClosure but appended to the top of the output.

14:15 `fogus: dnolen: http://dev.clojure.org/jira/browse/CLJ-927

14:15 dnolen: ibdknox: basically users should have to deal w/ any of this stuff - build tool deals w/ it.

14:15 shouldn't

14:16 `fogus: so you can't just emit Date because of limitations around JS Date object?

14:16 ibdknox: dnolen: I agree, but if we tie this to lein, it basically makes dealing with this any other way an incredibly painful experience

14:16 dnolen: which is not necessarily bad, just a point

14:17 dnolen: ibdknox: why should anyone deal with it any other way? Clojure doesn't provide anything sophisticated compilation features, no sure CLJS

14:17 nor

14:17 ibdknox: fair

14:17 `fogus: dnolen: I don't think that's it (although I haven't dug deeply in js/Date). It's only that the path for emission doesn't exist yet

14:17 ibdknox: dnolen: but adding things to the classpath is the only step in Java-land

14:17 CLJS is much more involved

14:18 dnolen: ibdknox: no argument there, but I think solve it with lein - only fix those parts in CLJS compiler that make fixing at lein difficult.

14:19 ibdknox: emezeske: this is something that should likely end up prototyped in lein-cljsbuild ^

14:21 Raynes: brehaut: Hi.

14:21 brehaut: Raynes: hi

14:21 lynaghk: dnolen: `fogus: I just added an emit-constant for java.util.Date that writes out "new Date(epoch-time)" in the cljs compiler and it seems to work fine

14:22 emezeske: ibdknox: was afk, catching up

14:22 lynaghk: Is there something else that needs to happen for instant literal support?

14:22 `fogus: lynaghk: With the #inst "..." format?

14:22 dnolen: lynaghk: `fogus: I didn't think so

14:22 lynaghk: yep

14:22 ibdknox: like magic

14:22 lynaghk: ibdknox, that's what powers *all* compilers.

14:23 ibdknox: hehe you should've seen the VB compiler ;)

14:23 `fogus: lynaghk: Does it all allow me to override the emit type?

14:24 lynaghk: I'm not sure what you mean; I haven't used instants until about 20 minutes ago

14:24 `fogus: The #inst and #uuid features in Clojure are easy to emulate, but they are built on a generic feature to allow user-specific emission types as well as new tagged literals

14:25 dnolen: `fogus: that can't happen in a normal way in CLJS - would need to be a special form of some kind.

14:25 `fogus: dnolen: Agreed.

14:25 CLJS has 2 readers

14:25 emezeske: ibdknox: Ahh, I see, so when you depend on a jar that contains JS, the externs (right now) need to be added to the end-project manually? Is that the problem?

14:25 lynaghk: emezeske: and the JS itself, within the JAR.

14:25 ibdknox: emezeske: externs/libs and so on.

14:26 * `fogus has 1/4 of a blog post about tagged literals

14:26 `fogus: not that 1/4 helps

14:26 lynaghk: heh

14:26 dnolen: `fogus: also not something you can modify at runtime in CLJS, so seems like a broken thing to try and emulate. Thus my cljs_init.clj idea.

14:27 emezeske: lynaghk, ibdknox: I see dnolen mentioned that the JS could be prepended to the gclosure output, is that the desired approach?

14:27 lynaghk: dnolan: cljs_init.clj would be a file that customizes the reader for generating cljs at compile time?

14:27 dnolen: emezeske: I think that would be awesome.

14:27 ibdknox: emezeske: it depends on the JS included, you don't want externs ending up in there

14:27 `fogus: dnolen: Unless you limit yourself to the CLJS/CLJ subset of features. Not ideal

14:27 ibdknox: emezeske: if it's a compiled lib, yep :)

14:27 emezeske: ibdknox, dnolen: I see, that makes sense

14:27 lynaghk: emezeske: not really; I'm just trying to get libraries into the closure compiler at the same time as the cljs code

14:28 ibdknox: lynaghk: that's the :lib case, and should also be automatic

14:28 given some either naming convention or specification

14:28 lynaghk: ibdknox, right.

14:28 emezeske: ibdknox: is there any really good documentation on the :externs and :lib stuff? (other than the compiler itself)

14:29 dnolen: `fogus: CLJS is already very limited, most things cannot be done in a good / first-class / reified way because of stratification between compiler/runtime.

14:29 lynaghk: Still, I'm concerned about it being automatic because it'll just blow up anyone who uses anything below :advanced optimizations.

14:29 emezeske: ibdknox: I need to understand it better to make cljsbuild handle it nicely

14:29 lynaghk: emezeske: http://lukevanderhart.com/2011/09/30/using-javascript-and-clojurescript.html

14:29 ibdknox: lynaghk: I think it should be specified

14:29 emezeske: lynaghk: thanks

14:29 lynaghk: emezeske: that is where I learned everything I know about closure.

14:30 emezeske: ibdkno, lynaghk: I agree that it should be explicit

14:30 ibdknox: lynaghk: or somehow made explicit. Anything in externs/* in the jar is treated as an extern. Or there's a specification in a project.cljs file

14:30 lynaghk: I'm leaning more towards the latter

14:30 dnolen: `fogus: I don't mean "most" things, but that lot of dynamic features need to become static in CLJS, breaking the interface that Clojure folks are used to.

14:31 emezeske: ibdknox, lynaghk: Yeah, there could be entries in the :cljsbuild config for which jars you want externs/libs to be pulled from

14:31 lynaghk: ibdknox, I think we're talking about a broader issue here. The subset I'm interested in is getting JS into JARS into the closure compilation step. Externs are a feature beyond that, and auto concat of non-closure-happy JS is another feature too.

14:32 `fogus: dnolen: but readers will likely not change after compilation

14:33 mrBliss: dnolen: question about core.logic: how can I 'refresh' an expression? with refresh = replace all *unbound* lvars by new lvars.

14:33 technomancy: emezeske: hey, would you be interested in getting lein-cljsbuild working on lein2?

14:33 mrBliss: dnolen: or, how can I see if an lvar is unbound?

14:34 technomancy: I think we are pretty close to putting out a preview release and would like to ease the upgrade path by making sure plugins are in order

14:34 dnolen: `fogus: oh yeah - good point

14:34 emezeske: technomancy: yeah! I don't think I'll have time to do that until the weekend though

14:34 technomancy: emezeske: no worries

14:34 dnolen: mrBliss: there's a goal for that, lvaro I think? but note that makes your program non-relational

14:34 emezeske: technomancy: is it possible to make plugins multi-compatible (with lein 1 and lein 2)?

14:35 lynaghk: ibdknox, emezeske: so projects need to specify their JS goodies (source, externs, foreign-libs) in project.clj, and lein will walk through all of those and concat everything for the cljs compiler?

14:35 dnolen: mrBliss: the first questions doesn't make sense to me :)

14:35 technomancy: emezeske: that's the hope

14:35 emezeske: technomancy: okay, that makes things easier.

14:35 technomancy: might not always be worth the hassle, but I think it won't be too tricky for the majority of plugins

14:35 mrBliss: dnolen: I'm trying to implement let polymorphism in my type inferencer

14:35 lynaghk: technomancy: does lein2 have cake's killer background-jvm magic merged in?

14:36 dnolen: mrBliss: https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic.clj#L1192

14:36 mrBliss: I don't think you need to check groudness for that, have you looked at Oleg's version?

14:36 technomancy: lynaghk: no, keep an eye on Jark for that

14:36 emezeske: lynaghk: maybe something like that. I'm ill-equipped to come up with a great solution at the moment; I need to mess around with JS libs a bit first, to understand it.

14:37 Raynes: emezeske: Ping me if you need help migrating.

14:37 lynaghk: technomancy: thanks for the tip, I hadn't heard of this.

14:37 mrBliss: dnolen: yes, but I don't fully understand it ;-) It differs quite a bit from Ambrose's type implementation. Thanks for the tip about lvaro!

14:37 emezeske: Raynes: thanks a bunch!

14:37 technomancy: emezeske: my hope is that the docs (README.md and docs/PLUGINS.md) cover enough for you to figure out the upgrade, but if not feel free to drop by #leiningen

14:37 lynaghk: emezeske: that's what I've been up to the past few days = )

14:38 emezeske: technomancy: sounds good.

14:39 dnolen: mrBliss: sure, interested to hear how it goes

14:39 mrBliss: dnolen: apparently, I'm already using lvaro. I assume Oleg's version is the one on this site: http://kanren.sourceforge.net/

14:40 lynaghk: dolen, fogus: does an emit-constant for java.util.Date make sense for CLJS, or do you want to hold off until you figure out the reader(s) situation? All I know is that adding it to cljs gets #inst "..." working.

14:40 dnolen: lynaghk: probably should wait based on what `fogus said.

14:41 lynaghk: or you should look deeper into how it's done in CLJ and come up with a comparable syntax/solution.

14:41 lynaghk: the problem is that the user should be able to redefine how #inst "..." is read, and it's not clear how to implement that with cljs?

14:42 dnolen: lynaghk: yes

14:45 lynaghk: dnolen: okay, thanks. In the mean time I'll just define the date multimethod in my project's compile.clj script.

14:49 dnolen: any opinions about generic math in CLJS? Dart has it.

14:50 `fogus: dnolen: link(s)?

14:53 dnolen: `fogus: no link, I just looked at the Dart generated source.

14:55 `fogus: main downsides - need type-hints for fast math, users extend arithmetic operators to any type - operator overloading hell

14:55 hiredman: seems like a significant departure from clojure

14:56 `fogus: dnolen: yikes!

14:57 dnolen: `fogus: yeah, but it means we can't support rationals - but perhaps that's just the reality of using JS as a host?

14:57 sorry ratios

14:58 `fogus: understood. Yeah, that's quite a pickle

14:59 So I was sad to see the hate for ':' as whitespace in map literals. :-(

15:00 hiredman: `fogus: do you also wnat to support null as a synonym for nil?

15:01 json map support is just a horrible idea

15:01 `fogus: hiredman: That is the main sticking point. There is no good answer for that one -- hence no ':'

15:01 dnolen: `fogus: : as whitespace less useful then real JSON literal support ;)

15:01 well for CLJS anyway

15:02 `fogus: hiredman: I'd be happy to hear your thoughts. As it stands your objection is over my head

15:03 hiredman: `fogus: in my mind json map is very clearly a bad investment. you are spending a lot of complexity and corner cases for a very small reward

15:04 `fogus: hiredman: Using Clojure data on the wire and subsuming JSON is small reward?

15:04 hiredman: you are not subsuming json

15:04 at all

15:04 `fogus: not without null no

15:05 hiredman: even with null

15:05 `fogus: What else is missing?

15:05 hiredman: the reason we use json at work is to be interoperable with other languages

15:05 `fogus: right

15:05 hiredman: perhaps I am misunderstanding what you mean by subsuming

15:06 `fogus: With null support Clojure literal data is a super-set of JSON. That's all I mean

15:06 Oh an ':'

15:07 s/an/and/

15:07 hiredman: even if the clojure reader could use json, I would not use it to do that

15:07 adiabatic: Sounds like eval().

15:07 cemerick: I wonder what happens in 7 years when JSON is that shoddy serialization format no one wants to use anymore.

15:07 technomancy: I don't want to see a : and have to think about whether I'm in a map or not

15:07 `fogus: adibatic: The reader doesn't do eval

15:08 tremolo: cemerick: we will usher in the new and brilliant era of yaml

15:08 hiredman: it's the kind of thing that leads to xml literals

15:08 dnolen: cemerick: I don't see JavaScript going anywhere in 7 years, so I doubt that will ever happen.

15:08 well not "ever", just not anytime soon

15:08 hiredman: cemerick: it already is

15:08 cemerick: hiredman: true that

15:09 `fogus: technomancy: I hope you're not mixing JSON and Clojure literals. :p

15:09 hiredman: You know, '<' is open in the reader! ;-)

15:09 hiredman: :(

15:09 `fogus: please take it to #scala

15:09 adiabatic: I like YAML enough, but it hasn't really caught on in the programming languages that I like. I blame _why.

15:10 * `fogus was the maintainer of the Scala XML literal support at one point

15:10 hiredman: leave the poor clojure reader alone

15:10 `fogus: I am shocked, shocked, that the person pushing for json literals in clojure was the maintainer of xml literal support in scala

15:10 `fogus: hiredman: Ignoring ':' in map literals is very very far from XML literals

15:10 mfex: `fogus: what about ' around strings in json?

15:11 `fogus: hiredman: pushing?

15:11 mfex: ' is not legal in JSON

15:11 dnolen: `fogus: unless I'm missing something, what wrong with #json { ... } ?

15:11 `fogus: If I were pushing it then I'd have a branch with an impl by now

15:12 hiredman: :(

15:12 `fogus: The thing after the #json has to be a legal Clojure form

15:12 dnolen: ^^^

15:13 amalloy: `fogus: ignoring : isn't sufficient to get you there, because it's not internally consistent. {a b} is valid reader syntax, which should surely be the same as {a: b} but different from {a :b}

15:13 `fogus: hiredman: I'm just curious what the argument against it is.

15:13 technomancy: it's a feature. it doesn't solve a problem.

15:13 hiredman: `fogus: it is a complex set of edge cases with little reward

15:14 `fogus: amalloy: You're assuming that people are likely to hit that edge case. I suspect that JSON data would be isolated to an argument to (read). Clojure literals would still be Clojure literals

15:14 dnolen: technomancy: hiredman: well it solves a pretty big CLJS problem - interacting with JS libs is the pits right now.

15:14 hiredman: `fogus: what is the argument for it? so you can copy and paste json stuff into the repl?

15:15 dnolen: please don't burden clojure with the problems of clojurescript

15:15 technomancy: cheshire.core/parse will always be there for you

15:15 amalloy: i don't really care if people hit that edge case. there is an edge case, whereas for the reader now there are no edge cases and everything is clean and well-defined

15:15 `fogus: hiredman: Dominating the Internet pipe? ;-)

15:15 cemerick: Was going to make a wagging the dog reference /ht hiredman

15:15 dnolen: hiredman: I don't see how it burdens you, if you don't want it don't use it.

15:15 hiredman: dnolen: I already am unhappy with the field access changes

15:15 `fogus: ammaloy: There are edge cases in the reader.

15:15 dnolen: hiredman: why? if you don't use it?

15:16 `fogus: hiredman: Are you just opposed to change? I've not heard any push back from you WRT the field access change so far.

15:16 dnolen: amalloy: uh, clojure.core// ?

15:16 hiredman: dnolen: because the language you use matters, adding complexity to the langauge makes it more difficult to track down problems

15:17 cemerick: dnolen: each new wrinkle adds to cumulative mental overhead, esp. for newcomers.

15:17 hiredman: `fogus: I made a suggestion or two on the clj jira ticket

15:17 adiabatic: And explain the rules to new people.

15:17 hiredman: cljs

15:17 dnolen: hiredman: I don't see how it causes you problems, you're not going to use #json

15:18 hiredman: dnolen: because when I do have a problem with the language (which happens, you cannot treat a language and runtime as a blackbox) I now have to deal with this garbage in my mental model

15:18 `fogus: hiredman: I can't find it

15:19 hiredman: it might have been on the clj ticket

15:19 dnolen: hiredman: I don't see any real argument besides "I don't like it"

15:20 `fogus: hiredman: Is the property syntax causing you real pain? I completely understand the desire to keep things "pure", but the prop lookup solves a real problem in light of ClojureScript.

15:20 mfex: what's the argument to not put all the json stuff in a library? Especially why does the cljs case need to use the clj reader for json rather than something custom?

15:21 `fogus: mfex: It's already in a library -- a few even

15:21 hiredman: ferd__: the property lookup syntax is more of a matter of taste, I proposed adding a new special form for field access

15:21 er

15:21 `fogus: -^

15:21 mfex: therefore, why the need to move it down/up into the language?

15:21 cemerick: dnolen, `fogus: "because it'd be handy in cljs" doesn't seem like it should be sufficient

15:22 I mean, it obviously is, but…

15:22 dnolen: mfex: well, CLJS repurposes the CLJ reader. There's a strong desire from rhickey to keep the languages the same - for good reason IMO.

15:22 hiredman: it doesn't cause me pain so much as "oh geez thats's ugly" everytime I see it

15:22 `fogus: cenerick: It's not jsut handy. It resolve a fundamental ambiguity in CLJS

15:22 dnolen: cemerick: it has nothing to do w/ being handy, marshaling data in CLJS -> JS is crazy slow

15:22 pandeiro: how do i write a BigEndianHeapChannelBuffer from netty to a tmp file? i tried (slurp) and instantiating a java.io.BufferedReader to no avail

15:22 cemerick: There's a pretty bright line between cljs and Clojure for me.

15:23 I suspect for many others as well.

15:23 `fogus: cemerick: I realize I may not have responded to your actual point

15:23 hiredman: as big as between clojure and clojureclr

15:23 dnolen: cemerick: well Rich Hickey doesn't seem to think so.

15:23 mfex: dnolen: where does the json come from that you can only use the clj reader? I agree on keeping them the same, I'm just looking for examples. Why would you write json in cljs source code for example?

15:23 dnolen: cemerick: otherwise that thread about property access would have been a lot shorter.

15:24 cemerick: clearly, no

15:24 dnolen: mfex: to talk to GClosure, jQuery, Raphael, etc.

15:24 hiredman: dnolen: I thought there was going to be a js-object special form or something

15:24 Raynes: I'm not sure I'm a fan of Clojure getting changed because things might be handy in ClojureScript.

15:24 dnolen: hiredman: nope

15:24 hiredman: why not?

15:25 `fogus: Raynes: What are you referring to. There are 2 threads here

15:25 dnolen: hiredman: because that's not how Rich Hickey thought it should be solved? I proposed the js-object macro, chouser mentioned that it wasn't ideal

15:26 hiredman: dnolen: so basically this is all moot and we should just ask rich what the hell he wants

15:27 mfex: dnolen: then what about #json{:clojure "map"} that turns into json, w/o the need for clj to able to read json?

15:27 * `fogus lost track of the conversation

15:27 Raynes: `fogus: {foo: ..} syntax.

15:27 hiredman: `fogus: there are way more than 2 threads here

15:27 mfex: for the interop case

15:27 `fogus: hiredman: agreed. I'm not concurrent

15:28 dnolen: mfex: sorry if not clear, CJLS repurposes the CLJ reader.

15:28 hiredman: an important subtext is generally "what the hell is core doing now? why aren't any of the issues we care about actually addressed, and why are patches just sitting in jira"

15:30 http://dev.clojure.org/jira/browse/CLJ-855

15:30 we are looking to move to 1.4-beta2 from 1.2 at work and clj-855 is the blocker

15:31 jcrossley3: `fogus: simplest way is to declare them as resources: https://gist.github.com/1782891

15:31 hiredman: new features are great, but lets fix stuff and apply patches

15:32 `fogus: hiredman: As far as I can tell there are unanswered questions surrounding that tikect.

15:32 * cemerick has occasionally maintained and used local forks

15:32 cemerick: hiredman: though I can see your hesitation to do that in this case

15:32 mrBliss: dnolen: do you mind taking a look at an example of my need for 'refreshing' an expression? https://gist.github.com/1782865

15:32 * hugod uses a local for too

15:32 hiredman: we are infact on a fork of 1.2 at work

15:33 https://github.com/scgilardi/clojure/commits/mantle

15:33 amalloy: yeah, we were using a fork of 1.2.1 until like yesterday when we got 1.3 working (and actually 1.4 as well)

15:33 hiredman: is anyone using clojure in production not on a fork?

15:34 `fogus: jcrossley3: Thanks. I will look at that

15:34 hiredman: (muttering and feet shuffling all around)

15:34 lancepantz: hah, as amalloy said, we're actually putting our first non fork of clojure in production today

15:34 hiredman: relevence isn't on a fork I guess

15:34 pjstadig: it's open source, so that's an advantage (having a fork)

15:34 lancepantz: we had actually been on a fork of 1.2.0

15:35 pjstadig: though i do think Clojure/core moves a bit to slowly for me at times

15:35 `fogus: I've not yet been on a project using a fork, but I can't speak for all of the Relevance projects

15:35 pjstadig: on the other hand i wouldn't want to add a bunch of junk too quickly either...isn't that the point of the preceeding discussion?

15:35 hiredman: pjstadig: it is an advantage for us, but not for the clojure community for everyone to be on a fork

15:35 lancepantz: we were on a fork of 1.2.0 because of the keyword hashing bug

15:35 brehaut: lancepantz: wasnt that fixed in 1.2.1 ?

15:35 lancepantz: then 1.2.1 added other patches that broke something else for us

15:35 cemerick: I've been using my own version of c.l.Agent for some time. *shrug*

15:35 lancepantz: brehaut: ^

15:36 hiredman: cemerick: do tell

15:36 brehaut: lancepantz: sorry, NZ internet lag

15:36 lancepantz: i think it was something with protocols

15:36 hiredman: lancepantz: /-/_/ or something with type names

15:36 cemerick: hiredman: nothing fancy; just parameterization of the threadpool an agent lives on

15:36 pjstadig: lancepantz: you are mistaken, there are no bugs in clojure

15:36 lancepantz: hiredman: i think that's it actually

15:36 pjstadig: only additive changes :-p

15:36 hiredman: cemerick: very interesting

15:36 lancepantz: :)

15:36 dnolen: mrBliss: well, you're in some dangerous territory there. you're using lvaro and cut. If you're never getting to the next case, the first case is always succeeding. I don't have time to dig into that at the moment.

15:37 hiredman: I had a thing for making agents run on the EDT, showed it to rich, he did not approve

15:37 mrBliss: dnolen: the first case should fail though, that's the problem. Thanks.

15:37 brehaut: lancepantz, hiredman: 1.2.1 that was an awkward time for name munging changes to drop imo

15:37 hiredman: yep

15:38 pjstadig: yeah i would have preferred to just get in the keyword memory leak fix

15:38 or no

15:38 the infinite recursion

15:38 cemerick: hiredman: hah, that's cute

15:38 mrBliss: dnolen: Is there a way I can get in touch with Ambrose?

15:39 dnolen: mrBliss: try to message him via GitHub. I will say, refresh sounds like a bad idea to me.

15:39 cemerick: Parameterization of the threadpool is quite straightforward, and I think he was fundamentally in favor, but it got lost in the shuffle in the early days.

15:40 hiredman: cemerick: I guess I would like to see kind of the opposite actually, more expose of the clojure threadpools and more control over them, because does every library need its own threadpool?

15:41 mrBliss: dnolen: I can't message him via GitHub because he didn't provide an email address.

15:42 dnolen: do you have any other pointers?

15:42 cemerick: hiredman: well, who controls them? N libraries trying to change threadpools around isn't any better.

15:43 dnolen: mrBliss: book some time to grok the Oleg version :) seriously it's not a lot of code and probably worth the effort.

15:43 cemerick: Stuff like that is the sort of thing app containers provide, i.e. these libraries use agents that need a threadpool with characteristics X, Y, and Z.

15:43 hiredman: cemerick: I guess, I don't have a clear anwser

15:43 adiabatic: sure, but what about the next library that has to waste time writing yet another thread pool?

15:43 cemerick: Presumably there's a lot of overlap, and you'd end up with a suitable optimization.

15:44 hiredman: it's a lot easier when you only care about what you're doing. :-)

15:44 mrBliss: dnolen: can you provide a link or is it the one on http://kanren.sourceforge.net/ ?

15:44 dnolen: mrBliss: that's the one

15:45 mrBliss: dnolen: ok, thanks for the help

15:46 hiredman: cemerick: in theory you just need two like clojure provides, unbounded for long running tasks and bounded for short

15:46 just like in theory you only need one event polling loop

16:41 jcrossley3: `fogus: do you know of anyone who's attempted to implement CacheProtocol for a shared, distributed cache like memcached or something else?

17:08 beffbernard: Hi, I'm looking to return the nth value of a lazy seq and my current approach is pretty ghetto.. like so (last (take 100 ( … ))

17:08 what's the "right" way? or an existing function that does the same thing

17:09 dnolen: beffbernard: nth

17:09 ,(nth 500 (range 1000))

17:09 clojurebot: #<ClassCastException java.lang.ClassCastException: clojure.lang.LazySeq cannot be cast to java.lang.Number>

17:09 beffbernard: haha so obv

17:09 dnolen: oops

17:09 ,(nth (range 1000) 500)

17:09 clojurebot: 500

17:09 beffbernard: thanks

17:11 brehaut: beffbernard: meta suggestion ##(apropos 'nth)

17:11 lazybot: java.lang.RuntimeException: Unable to resolve symbol: apropos in this context

17:11 brehaut: ,(apropos 'nth)

17:11 clojurebot: (nthrest nth nthnext take-nth rand-nth)

17:11 brehaut: ~botsnack

17:11 clojurebot: Thanks! Can I have chocolate next time

17:17 beffbernard: another quick question. Is there a lazy-seq representing natural numbers?

17:17 i'm currently doing this (iterate inc 1)

17:17 cemerick: beffbernard: see `range`

17:19 AimHere: (iterate inc 1) is probably what you're looking for, unless you want to make the numbers stop

17:20 beffbernard: cemerick: almost but the unbounded range includes 0.. but no biggy

17:20 amalloy: ,(rest (range))

17:20 clojurebot: (1 2 3 4 5 ...)

17:20 brehaut: just to be pedantic, (iterate inc 1) is not a lazy sequence, the tail of (iterate inc 1) is

17:21 beffbernard: brehaut: ahhhhh

17:21 brehaut: ,((juxt class (comp class rest)) (iterate inc 1))

17:21 clojurebot: [clojure.lang.Cons clojure.lang.LazySeq]

17:22 AimHere: Eep. (range) can be called without arguments? Damn, I learn so many little bits

17:22 brehaut: ussually not a problem, but there are some cases where it matters

17:22 ,(realized? (range))

17:22 clojurebot: false

17:23 brehaut: ,(realized? (iterate inc 1))

17:23 clojurebot: #<ClassCastException java.lang.ClassCastException: clojure.lang.Cons cannot be cast to clojure.lang.IPending>

17:23 cemerick: and brehaut wins today's Extravagant Usage of juxt Award ;-)

17:23 technomancy: ...

17:23 beffbernard: ,(realized? (rest (range)))

17:23 clojurebot: #<ClassCastException java.lang.ClassCastException: clojure.lang.ChunkedCons cannot be cast to clojure.lang.IPending>

17:23 technomancy: wow, that suddenly makes realized? a lot less useful

17:24 amalloy: well, it's not *that* sudden. brehaut's been going on about it for a while

17:24 brehaut: amalloy: huh? only a couple of minutes

17:24 amalloy: brehaut: was it not you who was complaining a couple weeks ago?

17:24 brehaut: nope

17:25 amalloy: oh. well, people have been complaining for a while. realized? really is pretty useless

17:25 jyaan: I just checked out clojurescript from github and then ran script/bootstrap, but script/repl and script/repljs throw: Exception in thread "main" java.lang.NoClassDefFoundError: clojure/main

17:26 amalloy: (defn my-realized? [x] (or (not (instance? clojure.lang.IPending x)) (realized? x))

17:26 jyaan: Am I missing something here? I looked at the scripts and they should be taking care of their own classpath. I'm on OSX 10.5, btw

17:27 brehaut: is it possible to have a lazy chunked seq ?

17:28 dnolen: jyaan: should just work, nothing went wrong w/ bootstrap?

17:28 jyaan: Didn't see anything

17:28 odd

17:28 I'll try re-cloning first I guess

17:29 Btw, I really like the libraries you've been working on lately. Thanks!

17:29 dnolen: jyaan: thx!

17:32 jyaan: Still getting that exception, and there were no errors from bootstrap

17:34 lynaghk: jyaan: are you running them from bin or clojurescript root?

17:34 jyaan: clojurescript root

17:34 lynaghk: hmm

17:34 jyaan: also tried setting CLOJURESCRIPT_HOME but nothing changed

17:34 lynaghk: do you have $CLOJURESCRIPT_HOME set in your environment?

17:34 try unsetting it; you may have set it incorrectly.

17:34 jyaan: really weird considering it just loops over the files in lib and such

17:34 good idea

17:35 nah it's the same

17:36 I'll try printing the variables in the script to see what's going on

17:36 lynaghk: Don't know what to tell you

17:36 ah, yes, always a good idea.

17:37 dnolen: jyaan: have you checked that you can run the jar, java -cp clojure.jar clojure.main ?

17:37 jyaan: I believe I've found the problem

17:38 Its variable for setting the classpath is empty

17:38 So sometihng is going wrong in that for loop

17:48 technomancy: any other lein plugin authors that missed it from earlier; I've updated the plugin docs to cover upgrading your plugin to work with lein2: https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md

17:48 if you get a chance I'd love to get some feedback on that

17:49 jyaan: This is what script/repl ends up running: java -server -cp script/../lib/*:script/../src/clj:script/../src/cljs:script/../test/cljs clojure.main

17:52 which means none of that stuff is expanding into actual files

17:52 for next in lib/*: src/clj: src/cljs: test/cljs; do

17:52 CLJSC_CP=$CLJSC_CP:$CLOJURESCRIPT_HOME'/'$next

17:52 done

17:52 that's the for loop lol

17:52 so I'm just going to separate them and it should run I think

17:53 Except for the colon in front of the $ that wasn't there originally

17:56 Yea I got it working; I'm guessing they were separate before and someone tried to combine them and broke it

17:58 Bleh it was compiled for 1.6

18:07 devinus: can anybody succinctly describe the clojure concurrency model to me?

18:07 how does it map to processes:threads ?

18:11 TimMc: devinus: There's the STM stuff, and there's also the agents/futures stuff... which are you asking about? Only the latter really involves new threads.

18:11 There's documentation on the threadpools that send and send-off use.

18:12 devinus: TimMc: sorry, agents

18:12 i'm trying to visualize how agents map to processes and threads

18:13 TimMc: I think there are 2 queues that lead into threadpools, and each processes agent messages as they come in.

18:21 hiredman: devinus: they don't

18:22 agents are about identity

18:26 SirDinosaur: question: how do i add the dependency for clojure.algo.generic.math-functions if i'm using lein?

18:28 Raynes: SirDinosaur: In your project.clj, add [org.clojure/algo.generic "0.1.0"] to :dependencies

18:29 SirDinosaur: Raynes: thank you so much

18:39 Raynes: Hahaha, wow.

18:39 I was wondering why there weren't any new pastes on refheap and then I realized about 30 minutes later that I was looking at my local server.

18:51 mebaran151: if I have a def that relies on something outside my program (like (def current-time (System/current-time-millis))) will my defs be executed only once and fixed at compile time or every time my program starts?

18:52 technomancy: mebaran151: yes

18:52 err

18:52 if you do AOT, it will be fixed at compile tim

18:52 e

18:53 mebaran151: I see

18:53 so I if I want to be able to AOT my code, I should probably embed those properties in startup functions

18:53 technomancy: yep

18:53 you can memoize them if you like

18:53 hiredman: technomancy: that is not true

18:54 mebaran151: it will be run everytime the code is loaded

18:54 mebaran151: basically I want to use seesaw to read a preference from the registry

18:54 technomancy: oh, right; it's just defonce

18:55 mebaran151: and not embed my own regisry values as a result

18:55 hiredman: well, no, defonce will do the same thing, it well execute it when it is loaded

18:55 jsut once you've loaded the code, if you reload the defonce it won't clobber the existing value

18:56 mebaran151: so if I AOT'ed a file with (def my-time (System/currentTimeMillis)) every time I start my program it would rerun System/currentTimeMillis

18:57 technomancy: hm; I assumed vars would be loaded as .class files even if they're not functions, but I may have been thinking of something else

18:59 hiredman: well what the compiler emits for that is something like (.setRawRoot #'my-time (System/currentTimeMillis))

18:59 (bytecode of course)

19:00 amalloy: inside of my_ns__init.class, right?

19:00 hiredman: where (System/currentTimeMillis) is emited as something like (invoke-static System currentTimeMillis)

19:00 amalloy: yes, as a static init

19:01 JohnnyL: if [] is fater than () why is clojure slower than java and slower than sbcl?

19:02 faster

19:02 amalloy: that question is all premise and no content

19:02 hiredman: JohnnyL: please either ask a question that makes sense or troll somewhere else

19:02 technomancy: JohnnyL: () is faster than [] because it's more aerodynamic

19:02 emezeske: JohnnyL: [] is faster to type than () because you don't need to hold the shift key

19:03 JohnnyL: ah, so the clojure community sucks.

19:03 amalloy: yeah, unlucky

19:03 technomancy: yep, you figured it out

19:03 please don't let our secret become known

19:03 jyaan: Lol

19:03 JohnnyL: inherit from lisp?

19:03 amalloy: emezeske: swap the 90/() keys! makes my life so much easier

19:03 emezeske: Come to think of it, you guys are a bunch of jerks!

19:03 technomancy: emezeske: NO U

19:04 emezeske: amalloy: That is actually pretty appealing to me...

19:04 JohnnyL: The Great Computer Language Shootout make clojure about halfway in speed for all tested languages.

19:04 Thats why I ask.

19:04 amalloy: i swapped all the numbers for symbols. inconvenient on occasion, but pretty awesome for coding

19:04 TimMc: JohnnyL: And you believe that site?

19:04 JohnnyL: Getting facts about a lanugage is not trolling btw.

19:04 * emezeske wonders if he types numbers or symbols more.

19:04 TimMc: It doesn't know shite about benchmarking.

19:04 JohnnyL: But responding *like* a troll is.

19:04 jyaan: Keep in mind that it's the Language Shootout GAME

19:05 emezeske: JohnnyL: I don't think people meant to troll you. There was some kidding around, because I don't think anyone understood your question.

19:05 TimMc: amalloy: That's pretty fantastic.

19:05 jyaan: Read the disclaimers on that site and that should explain some confusion

19:05 TimMc: emezeske: Also because he was being an ass.

19:05 JohnnyL: http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php

19:05 TimMc, lick me.

19:05 emezeske: TimMc: Hahaha, I should probably speak for myself :P

19:06 jyaan: Yep that's it

19:06 technomancy: alioth shootouts are pretty famous for being hugely biased against languages hosted on virtual machines

19:06 amalloy: "which language has the best support for calling into native libs written in C?"

19:06 jyaan: C?

19:06 kiras: heh

19:06 clojurebot: #<ClassCastException java.lang.ClassCastException: clojure.lang.Cons cannot be cast to clojure.lang.IPersistentStack>

19:06 brehaut: jyaan: you may be surprised then :P

19:06 technomancy: amalloy: "which language has lots of people sitting around with nothing better to do than write up benchmarks?"

19:07 JohnnyL: technomancy, the same that has people sitting on irc making fun of people asking questions.

19:07 I take it you guys are pretty much into linux.

19:07 brehaut: unix

19:08 jyaan: Yea there are lots of Mac and *BSD users

19:08 JohnnyL: brehaut" curious.

19:08 linux isn't unix.

19:08 brehaut: never is anything else people call unix these days

19:08 but nevertheless

19:08 s/never/neither/

19:08 JohnnyL: thats what I thought.

19:08 brehaut: bah

19:09 unix is still a useful category of OSs even if the oses in the category are not (strictly) unix

19:09 jyaan: linux seems a lot more unix-like than mac imo, but mac is one that paid the standardization fees

19:09 AimHere: Unix has about three meanings, one of which Linux could qualify

19:09 jyaan: Right

19:10 AimHere: Wait, what's the third?

19:10 AimHere: Unix the original codebase and derivatives therefrom, Unix the trademark, and Unix, the way of doing things

19:10 jyaan: Ohh

19:11 brehaut: anyway it hardly seems curious that there are lots of mac and bsd users

19:12 jyaan: No kidding, take a look at any Google talk for example, nearly every speaker is using a Mac

19:13 technomancy: jyaan: http://p.hagelb.org/lein-os.png <- for lein users

19:13 AimHere: The only exception I've seen in the Clojure talks on Blip has been the old English dude who did the data structures in Scala that Clojure nicked, and he used Windows of all things

19:13 brehaut: Phil Bagwell

19:13 AimHere: That's the fellow

19:14 jyaan: Yea that's about what I'd expect I think; Lots of people like me tend to use both Linux and Mac

19:14 brehaut: self selecting survey http://lein-survey.herokuapp.com/results

19:14 jyaan: For most development

19:14 technomancy: brehaut: true

19:14 jyaan: Then mainly just Windows for testing and maybe some games

19:15 brehaut: technomancy: im not sure why its a surprise that a lot of us mac people dont have a package manager

19:15 jyaan: Actually Bagwell's versions weren't immutable

19:15 Well macports is out there

19:15 hiredman: I ended up with a mac because I was tired of maintaining my personal freebsd machines

19:15 technomancy: not having a package manager just feels so stone-age

19:15 jyaan: If it weren't I would have a hard time

19:15 Yes agreed

19:15 hiredman: of course now I have to maintain a linux vm :(

19:16 jyaan: It's such an annoyance having to go out and search for things and set it up manually

19:16 brehaut: technomancy: but lein installs most of my developer dependancies, and apps are stand alone bundles in /Applications/

19:16 technomancy: installing software by hand is a way of teaching your subconscious that it's OK for humans to perform tasks that should be done by a computer

19:16 kiras: i think i might be encountering the problem described here: https://github.com/technomancy/leiningen/issues/354 however it seems like it should be resolved by using 1.7.0-SNAPSHOT, which i am currently using. before i reopen (if i even can), would someone mind taking a look at my project.clj to see if i'm missing something obvious? https://gist.github.com/1784697

19:16 brehaut: technomancy: anything that isnt lein or mac land lives in my linux VM and is managed by apt

19:17 jyaan: Well it should be fairly clear at this point that the old way won't last much longer

19:17 brehaut: hiredman: what vm software do you use for the linux VMs?

19:17 jyaan: Even looking at mobile, things are in app stores which are really just repos as well

19:18 hiredman: brehaut: just one, under virtualbox

19:18 jyaan: This is the biggest pain in Windows I think, because about all you have is Cygwin

19:18 mebaran151: jyaan: there's actually a package manager for windows surprisingly

19:19 jyaan: I heard about an open-source project for that but it didn't look very convenient at the time

19:19 mebaran151: I use pik for ruby stuff I have to write, but there was one I played with that worked alright

19:19 AimHere: The most important package manager for Windows is called 'Steam'

19:19 jyaan: Lol

19:19 mebaran151: haha

19:19 Apage43: AimHere: I have that one on my Mac too :)

19:19 it's a lot more useful on windows though.

19:20 jyaan: Windows really needs to ditch the whole everything-has-its-own-update-program-and-daemon

19:20 Especially how they try to organize things with nagging

19:22 But it's workable; With Cygwin and Emacs I can get by on there

19:23 mebaran151: it's nuget, which actually works alright

19:23 I install Emacs myself though

19:25 I tend to stay away from cygwin, because it lives in the uncanny valley: all the tools I really need come in mingw packages these days

19:25 jyaan: uncanny valley??

19:25 lazybot: jyaan: Uh, no. Why would you even ask?

19:25 mebaran151: jyaan: the uncanny valley of almost unix but not quite so

19:26 jyaan: Yea there are a few issues like encoding

19:26 Not too bad if you just stick to utf-8 for everything

19:26 AimHere: It outwardly looks and moves like Unix, but it's dead inside

19:26 mebaran151: so silly little things blow up and it doesn't do unix well enough to be worth the hassle

19:26 technomancy: what's \\b in emacs-regex-speak?

19:26 jyaan: word boundary

19:26 mebaran151: the only thing that sadly doesn't work is clojure-jack-in for lein

19:26 jyaan: i was using it

19:27 so it works

19:27 mebaran151: but lein swank and slime-connect works okay

19:27 hmm

19:27 jyaan: maybe something changed recently, idk

19:27 technomancy: jyaan: nice, wrong channel and I still got an answer; thanks. =)

19:27 jyaan: haha yea

19:27 i like regex :)

19:27 mebaran151: I get error in process filter: non-hex digit

19:27 jyaan: oh hm, actually you're right

19:27 mebaran151: is there a quick fix or an update?

19:27 jyaan: you have to use lein.bat

19:28 mebaran151: I am using lein.bat

19:28 jyaan: I remember getting that error, let me see if I can remember exactly what I did

19:28 seancorfield: mebaran151: you have stuff in c:\users\... and the \u introduces a unicode escape sequence so it's expecting hex, not sers

19:29 if you can get it all installed in c:\work or something, it'll work fine

19:29 mebaran151: I do have stuff in users....

19:29 jyaan: i didn't have to do that though

19:29 i had my stuff in C:/users/jyaan/projects/

19:29 brehaut: i really wish linus et al had thought that maybe a decent UI would be a good thing on a VCS when they made git

19:30 jyaan: er, well c:\\.. etc..

19:30 seancorfield: jyaan: yeah, it seems to depend on how it calculates the path

19:30 and which version of windoze folks are running

19:31 i have a VM with Win XP and emacs etc all works just fine - with the identical config to my ubuntu and mac machines (i have it dropbox, shared to all three, and symlink my .emacs.d folder)

19:31 took me a while to figure out how to do a symlink on windows :(

19:32 jyaan: haha

19:32 I still haven't quite got that tfigured out I think

19:32 Chandon: The clojure.parallel library claims to be deprecated. Does something replace it?

19:33 jyaan: At least with Java you don't have to deal with all the Windows stuff so much these days

19:34 Maybe pmap? I don't know abotu clojure.parallel though

19:34 seancorfield: I also badly miss the Emacs/Unix keyborad shortcuts when in Windows

19:35 seancorfield: which ones?

19:35 kiras: jyaan: i miss the vim keyboard shortcuts when i'm everywhere ;)

19:36 jyaan: You can use C-a C-e C-k C-b C-f M-b M-f in both GTK and OSX

19:36 brehaut: anyone got a good article to read on tuning the memory usage of the JVM for clojure?

19:36 (one that assumes the reader knows next to nothing about tuning the JVMs memory settings)

19:36 kiras: jyaan: this might be of interest to you: http://www.emacswiki.org/emacs/XKeymacs

19:36 jyaan: You have to set the keybinding mode to "Emacs" with gconf

19:37 mebaran151: jyaan: I'm on Win 7 Pro

19:37 have to be for work :(, though it's less unpleasant than I remembered

19:37 aperiodic: brehaut: i just apply everything in http://groups.google.com/group/clojure/browse_thread/thread/c8f69037b26e2856?pli=1

19:37 hiredman: brehaut: watch out for copyng strings around, they are immutable and have no structural sharing

19:38 jyaan: aperiodic: nice

19:38 aperiodic: also, i recently learned that keywords live in the permgen

19:38 hiredman: if you are messing about with big globs of say json encoded data it can hurt

19:38 aperiodic: not true

19:39 brehaut: hiredman: yikes. ive got a couchdb based site. thats basicly all it does

19:39 jyaan: I had a feeling it would be in permgen

19:39 hiredman: the strings backing keywords are interned which generally means they end up in the permgen

19:39 amalloy: jyaan: the gtk emacs bindings just make me sad

19:39 jyaan: Lol

19:39 amalloy: Yea they don't always works

19:39 amalloy: a few things work, which lead me to assume more will, and then i'm fumbling around completely

19:40 i'd rather just remember the windows bindings, even if they're less good

19:40 jyaan: amalloy: Yea there are lots of apps that override

19:40 amalloy: not just that; so much is missing like mark/kill

19:40 jyaan: amalloy: nah I hate dealing with all the arrow-key stuff

19:40 aperiodic: hiredman: well, right. lots of distinct keywords => bunch of allocations in the permgen was the point i wanted to make

19:41 hiredman: brehaut: byte arrays and seqs of byte arrays

19:41 or something like erlnag's io lists

19:41 http://prog21.dadgum.com/70.html

19:41 aperiodic: hiredman: would i probably know it if i were copying strings around?

19:41 amalloy: hiredman: strings do a little bit of structural sharing; mostly the kind that makes you sad

19:42 brehaut: hiredman: i think i might have missed something, is that as an alternative to strings?

19:42 aperiodic: hiredman: as opposed to sharing their reference

19:42 brehaut: amalloy: you mean like split and substring?

19:42 amalloy: yes

19:42 hiredman: aperiodic: just about anything causes a copy

19:42 brehaut: yes, I guess seqs of strings work too

19:43 just avoid call str to build up strings

19:43 brehaut: hiredman: right. that makse sense

19:43 hiredman: .getBytes

19:43 so easy to call, but the pain is forever

19:44 aperiodic: hiredman: if they're immutable, why are they so prone to being copied?

19:44 hiredman: because they are backed by mutable arrays instead of trees

19:45 for example the byte array returned by .getBytes is mutable, but the string is not, so it needs a defensive copy

19:45 aperiodic: is there an easy way to verify whether or not an operation causes a copy (identical?)?

19:46 hiredman: aperiodic: anything that creates a "new" string

19:46 concat

19:46 I guess with the notable exceptions amalloy mentioned

19:47 at least str doesn't use concat

19:48 aperiodic: hiredman: good to know, thanks!

19:49 brehaut: im very glad enlive defaults to producing a seq of strings right now

19:50 kiras: would someone please take a look at this for me and tell me if i'm doing something wrong or if it looks like a bug in leiningen? https://gist.github.com/1784697 i think it might be the same issue as this: https://github.com/technomancy/leiningen/issues/354

19:50 brehaut: hiredman: thanks for the pointers

19:52 hiredman: https://github.com/hiredman/iolists is something I started on after running into an issue at work with oomes from copying strings around and thinking for the 4th or 5th time "iolists would be useful here"

19:52 haven't used it in anger yet

19:52 technomancy: kiras: on 1.6 or 1.7?

19:53 kiras: technomancy: i started with 1.6 then moved to 1.7 and am now at 1.7.0-SNAPSHOT, according to lein version

19:54 technomancy: kiras: probably a bug then, but I've never used native dependencies myself so I'm not really sure

19:54 brehaut: hiredman: is that dynamically extending the Word protocol as new array types are discovered?

19:54 technomancy: go ahead and re-open that issue and paste your project.clj file

19:55 hiredman: brehaut: to new array types

19:55 brehaut: thats extremely cool

19:56 kiras: technomancy: ok... i would like to re-open the issue, but github says that i don't have permission to do so. is that normal?

19:56 technomancy: kiras: didn't realize that was possible; sorry

19:56 I re-opened it

19:57 kiras: technomancy: thanks :) just out of curiosity, what do you think the chances are this will be fixed soon? i have a feeling this might be considered a low priority issue for most users?

19:59 technomancy: kiras: it's true there are very few users of native dependencies

19:59 if you are interested in helping, it could be fixed soon

20:01 kiras: technomancy: i would be interested in helping. i am trying to make a game using clojure and i need access to lwjgl. i'm not really sure where to start though. any thoughts?

20:02 technomancy: native-dependency support consists of three steps: 0) find which jars have native deps, 1) extract them to the filesystem, and 2) add them to the java.library.path

20:02 the first thing to do is find out which step is failing

20:03 kiras: technomancy: ok. i seem to have the proper native dependencies installed to the various "native/os" directories. that seems to imply that it is the last step that is failing. do you agree?

20:04 technomancy: yeah

20:04 so the code for handling that is in src/leiningen/compile.clj

20:04 in get-jvm-args

20:05 so you'd want to check the value of native-arch-path

20:09 kiras: technomancy: thanks. i'll take a look at that.

20:11 mebaran151: so is there any secret to getting jack-in to run on windows?

20:11 Frozenlo`: mebaran151: I did it yesterday, what is your question?

20:12 mebaran151: I'm on Win 7 and I'm having process filter issues

20:12 I can do slime-connect, which is more than adequate, but just doing a clojure-jack-in seems a lot nicer

20:13 Frozenlo`: Sure is.

20:13 WHat happens when you M-x clojure-jack-in?

20:13 mebaran151: error process filter

20:14 Frozenlo`: No more info? Like "can't find project.clj"?

20:16 kiras: technomancy: i'm not very experienced with git. would you mind telling me what branch i should be on?

20:16 technomancy: kiras: oh, sorry; "git checkout 1.x"

20:17 kiras: though I would be interested in knowing if the same problem is present in the master branch

20:19 anyone know whose this is? http://clojars.org/clj-rpm/newrelic

20:19 kiras: technomancy: thanks, that seems to work. i could try to look into whether the problem exists on the master branch. i was unable to find either get-jvm-args or native-arch-path in compile.clj when i was on the master branch though.

20:20 technomancy: kiras: maybe just check in "bin/lein repl"?

20:20 wait, so when working from the 1.x branch, native dependencies are working for you?

20:24 kiras: technomancy: i'm not entirely sure what you mean. with all the versions i have tried, the native dependencies get downloaded and extracted into the native/os directories. but when i am using emacs/slime or lein repl, the native path doesn't seem to be added to java.library.path

20:25 technomancy: oh, ok; I thought you said it worked.

20:25 kiras: technomancy: it is only just now, however, that i have used git to download lein's code and started switching between branches and the such.

20:25 technomancy: ok, sure. with bin/lein from the 1.x, can you put a println in to see the value of native-arch-path?

20:32 kiras: technomancy: i will try that.

20:35 technomancy: #<File /home/kiras/projects/practice-001/native/linux/x86_64>

20:36 technomancy: so that directory exists?

20:38 kiras: technomancy: no, it doesn't... it seems that the native libraries are unpacked to native/linux and architecture is not taken into account

20:39 technomancy: kiras: oh, ok; that sounds bad

20:39 kiras: technomancy: so i suppose one of the questions is, where exactly should the libraries be?

20:39 technomancy: lemme see

20:39 that actually sounds like a problem with the jar you're consuming, not leiningen

20:40 the extraction location within native/ depends on the path of the JarEntry

20:41 kiras: technomancy: yeah, after seeing the difference in native-arch-path and the actual location i was wondering if that could happen...

20:41 technomancy: i will have to try another jar or possibly create my own.

20:41 technomancy: yeah, unfortunately creation of native-dependency jars is totally undocumented and fairly manual

20:41 that's on my hit list after lein2 is released

20:42 kiras: technomancy: do you happen to know of a working jar with native dependencies i could test on quickly?

20:42 technomancy: any improvements to that would definitely make me happy :)

20:42 technomancy: kiras: here's a list of all the jars (c. last summer) that have native components: http://p.hagelb.org/find-native.clj

20:43 all clojars jars anyway

20:43 kiras: technomancy: thanks :)

20:43 technomancy: sure

20:43 we could use some help improving the native situation for sure

20:44 clj_newb: Is there a builtin for transforming all the values of a map with function TRANSFORM? I currently have: (into {} (map (fn [k v] {k (TRANSFORM v)}) m))

20:44 but I suepect there is a more idiomatic way to write this montrosity

20:46 technomancy: clj_newb: I wish there were!

20:46 kiras: technomancy: i wouldn't mind assisting where i am able to, although i don't know that my help would be very helpful. :)

20:46 brehaut: yeah (into {} (map (juxt first (comp TRANSFORM second)) m))

20:46 clj_newb: technomancy: woot, this can be my first contrib to clojure.contrib

20:46 technomancy: can you come up with a good name, push it through the approval process, and then mention me in the acknolwedgements?

20:47 amalloy: hahaha

20:47 technomancy: clj_newb: there is clojure.walk/keywordize-keys, but there needs to be something more general

20:47 brehaut: mapmapvalues and mapmapkeys :P

20:47 but really why would you give up an oppertunity for juxt and comp

20:48 technomancy: clj_newb: (zipmap (map transform (keys x)) (vals x)) is a bit better

20:48 clj_newb: brehaut: haskell point free style?

20:48 brehaut: clj_newb: clojure point free style

20:48 technomancy: but I really wish map-keys and map-values were in core

20:48 amalloy: brehaut: remember knit, my theft of ***? (into {} (map (knit identity f) m))

20:48 brehaut: amalloy: oh yeah! even bette :D

20:50 clj_newb: I like the name map-values

20:52 technomancy: it bothers me that clojure.walk/keywordize-keys and clojure.walk/stringify-keys are not implemented in terms of map-keys

20:52 it just seems so obvious

20:52 I'll have to give stuartsierra an earful next time he comes online; wtf

20:52 hiredman: and it really should just be a reduce

21:00 mebaran151: Frozenlo`: nope, I think it's \U escape issue; seems pretty common

21:15 dnolen: the T programming language was pretty neat

21:17 brehaut: dnolen: thats one of the precursors to scheme?

21:21 hiredman: ~def update-in

21:23 brehaut: hiredman: the burdens of AR type checking

21:23 hiredman: hmmm?

21:23 brehaut: lens vs update-in

21:23 hiredman: ah

21:24 AR?

21:24 clj_newb: what is the inverse of read-string?

21:24 aja: brehaut: I think PG had an essay on T. I seem to recall reading it.

21:24 amalloy: pr-str

21:24 brehaut: aja: http://www.paulgraham.com/thist.html

21:25 and its not actually PG, its olin shivers i think

21:25 clj_newb: amalloy: thanks

21:25 aja: brehaut: Ah.

21:25 brehaut: (hosted by pg so understandable mistake)

21:27 dnolen: brehaut: no T was a pretty incredible language, one of the first experiments to see if a Lisp language could be very efficient, it also had objects at the bottom (cons was not primitive)

21:27 brehaut: this is a pretty mind blowing read http://www.paulgraham.com/thist.html

21:28 brehaut: influenced Self, this is also a killer read for the Clojure programmer http://cs.au.dk/~hosc/local/LaSC-4-3-pp223-242.pdf

21:28 brehaut: yeah it is

21:28 dnolen: Organizing Programs w/o Classes ^

21:29 brehaut: T was after Scheme

21:29 brehaut: oh hmm. somehow i have that remembered backwards

21:29 aja: Heh. It was a response to a project called 'nil'.

21:32 brehaut: i find the whole notion of CPS as an intermediate representation/optimization target amazing and mind boggling

21:32 aja: My new language name is going to be '()'

21:33 brehaut: aja: i predict poor marketability due to search engine impedance

21:34 aja: brehaut: :-). Previously known as "the C# Problem"

21:34 brehaut: hah yeah

21:59 i_s: Just finished my first program, a sudoku-solver. Would love to get critique/tips: https://github.com/isaksky/sudoku-clojure/blob/master/src/sudoku_clojure/core.clj

21:59 particularly if there is a better way to do the function in line 92

22:01 brehaut: yikes

22:02 aja: i_s: Heh. Google "Norvig Sudoku" which is sort of the last word on how to attack that problem and links to a Clojure implementation of his solution.

22:03 brehaut: or alternatively bird's functional pearls ;)

22:03 jtoy: hi all

22:04 brehaut: http://www.cs.tufts.edu/~nr/comp150fp/archive/richard-bird/sudoku.pdf

22:05 i_s: will check those out, thanks

22:07 well mine already works, so i was wondering more about clojure style and so forth

22:07 aja: brehaut: Nice link, thanks. That book has been on my wish list for a while.

22:16 i_s: Effectively critiquing another's code is difficult work. Better to compare your implementation to the others that were offered and then ask more specific questions in here. (Why is x better than y? Which would be preferable, u or v?)

22:21 i_s: aja: ok, in that case I have a specific question. Is it ok to use doseq and swap for this function? https://github.com/isaksky/sudoku-clojure/blob/master/src/sudoku_clojure/core.clj#L92 Or is there a good functional way to do it?

22:29 aja: i_s: It's a taste thing, but you function looks a little imperative to me (lots of conds and cases). Consider the search function in the sample I cited, which (a) doesn't limit itself to one level of search and (b) employs structures like apply and filter instead of branching.

22:32 i_s: aja: will look into it, thanks

22:39 aja: i_s: Bear in mind that this is just my opinion. I'm still pretty new to to clojure myself (more comfortable in vanilla common lisp or old-school C), so I dn't feel particularly qualified to be dispensing advice.

22:42 i_s: ok

23:07 is there a way to splat lists in clojure? e.g., splat [2 3] so that for (disj #{1 2 3} [2 3]), it returns #{1}?

23:09 i.e., I have [2 3], but want to evaluate (disj #{1 2 3} 2 3)

23:10 dnolen: ,(apply disj #{1 2 3} [2 3])

23:10 clojurebot: #{1}

23:10 dnolen: i_s: ^

23:12 i_s: sweet, thanks dnolen

23:25 clj_newb: clojure is

23:26 _ <-- fill in the blank

23:58 muhoo: a language :-P

Logging service provided by n01se.net