#clojure log - Jan 03 2015

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

1:11 djames: ,(some-> 0 inc)

1:11 clojurebot: 1

1:12 djames: ,(some-> 0 (fn [x] (inc x)))

1:12 clojurebot: #<sandbox$eval51$G__50__52 sandbox$eval51$G__50__52@788223f0>

1:12 djames: WAT?

1:13 ,(-> 0 inc)

1:13 clojurebot: 1

1:13 djames: ,(-> 0 (fn [x] (inc x)))

1:13 clojurebot: #<IllegalArgumentException java.lang.IllegalArgumentException: Parameter declaration 0 should be a vector>

1:14 djames: WAT?

1:14 I suppose no one ever promised that macros wrapping special forms would work.

1:15 (fn 0 [x] (inc x))

1:15 ,(fn 0 [x] (inc x))

1:15 clojurebot: #<IllegalArgumentException java.lang.IllegalArgumentException: Parameter declaration 0 should be a vector>

1:16 djames: It makes sense now

1:21 amalloy: djames: yeah, it's nothing to do with special forms though, as i think you figured out

1:22 djames: amalloy: yeah, macroexpansion time happens before all of it

2:16 Elements: Hi

3:30 crocket: Is http://www.braveclojure.com/ a comprehensive material on clojure?

3:36 HELLo?

3:48 TEttinger: crocket: I'd say yes

3:48 you probably also want docs like grimoire and clojuredocs

3:48 ~grimoire

3:48 clojurebot: grimoire is a nifty set of api docs at http://grimoire.arrdem.com/

3:49 crocket: grimoire sounds evil

3:49 TEttinger: heh

3:49 it

3:49 it's an old word for book, IIRC

4:24 kenrestivo: i think you mean olde.

4:25 also, it means a magickal reference text, http://en.wikipedia.org/wiki/Grimoire

5:21 jonasen: Why is there no 'boolean?' predicate in clojure (or cljs)?

5:21 Bronsa: jonasen: there's true? and false?, boolean? is just (or (true? x) (false? x))

5:22 agreed it would be useful to have in core, there's already a ticket in jira for adding a bunch of predicates

5:22 but it's low priority

5:22 jonasen: Bronsa link?

5:22 Bronsa: jonasen: http://dev.clojure.org/jira/browse/CLJ-1298

5:22 jonasen: Bronsa thanks!

5:23 ha! I had already voted on that issue

5:24 Bronsa: heh

7:11 masnun: ,(+ 23 34)

7:11 clojurebot: 57

7:12 mi6x3m: masnun: did you expect this result?

7:12 masnun: mi6x3m I was actually testing the bot

7:12 mi6x3m: ;)

7:13 masnun: ,(println "Hello bot!")

7:13 clojurebot: Hello bot!\n

7:13 hellofunk`: would an http client as described on this page be referring to a browser? http://www.http-kit.org/

7:14 mi6x3m: hellofunk`: for example but not only, http client means anything sending HTTP requests

7:14 it could be a browser, but it could also be plain wget or even your own clojure code

7:14 hellofunk`: mi6x3m: oh i see, so that clojure code could be a server making an http request to another server

7:14 and thus the server would be a client

7:15 mi6x3m: hellofunk`: yep

7:15 but http kit is a library for both purposes hellofunk`

7:15 it can serve and it can request

7:15 depends on what scenario you need it for

7:16 hellofunk`: i am trying to understand where the lines are drawn between jetty, ring, and http-kit. my guess is that ring is a higher level api that can operate on either jetty or http-kit, each of which is a server layer, is that right?

7:16 mi6x3m: hellofunk`: to begin with, http-kit is very low level

7:16 you can do whatever you want with it

7:17 jetty is a sophisticated server technology

7:17 hellofunk`: mi6x3m: but jetty and http-kit server similar purposes, i.e. you wouldn't use both in an app, you'd choose one or the other, right?

7:18 mi6x3m: hellofunk`: you wouldn't normally use http-kit to host web applications :)

7:18 because you'll have to implement everything jetty already provides

7:18 it can server html content indeed, but this is all it does

7:19 hellofunk`: mi6x3m: really? it seems to be quite popular and i am looking at it for serving websockets since i gather that jetty/ring (the typical standard combo) doesn't do this so well

7:20 mi6x3m: hellofunk`: take a look at what jetty provides https://wiki.eclipse.org/Jetty/Feature

7:22 hellofunk`: hm, it seems http-kit is where people typically turn to when they want to serve sockets, for example, sente: https://github.com/ptaoussanis/sente

7:24 mi6x3m: hellofunk`: yes, because jetty is heavy and people rarely need everything :)

7:25 hellofunk`: it says this: Why http-kit? Besides being a great web server, it currently offers by far the best high-concurrency support which is something Sente needs to lean on for WebSocket and long-polling connections.

7:25 this implies that it handles sockets better than jetty, hence its popularity?

7:25 mi6x3m: I cannot judge. If people prefer it over Jetty it must be the case

7:26 hellofunk`: in a socketless app, if you only use ajax, how can your server arbitrarily choose to send info to the browser? doesn't ajax require the browser to initiate the data transfer?

7:27 mi6x3m: hellofunk`: it does, doesn't sound feasible

7:28 hellofunk`: perhaps that's where long-polling comes into play, which i should read up on

7:37 nuwanda_: long-polling or server sent events

7:47 hellofunk`: in a typical ajax scenario, when the browser initiates an XHR, is this a blocking action? if the server takes several seconds to respond, does the browser just wait, or does it continue doing other things?

7:49 mi6x3m: hellofunk`: well you never experience a blocking firefox do you :)

7:50 hellofunk`: looks like xhr can be either sync or async depending on how it is used: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests

7:50 mi6x3m: hellofunk`: even if it's sync the browser will let you do other things

7:50 the JS execution might block

8:05 hellofunk`: mi6x3m: here is the magic phrase from the Chord library page: Currently, Ring’s standard Jetty adapter ~does not~ support Websockets. http-kit is a Ring-compatible alternative.

8:05 so that explains the http-kit popularity I think: it is more or less required for websocket use currently

8:07 mi6x3m: hellofunk`: in conjunction with Ring

8:07 hellofunk`: mi6x3m: yeah but just about everyone uses Ring, don't they?

8:08 mi6x3m: hellofunk`: no doubt about that, Ring is great

8:08 hellofunk`: so unless you go agaist the grain and choose not to use Ring, then if you want websockets, you need to use http-kit

8:09 mi6x3m: hellofunk`: without ring you can use jetty with websockets also

8:09 hellofunk`: mi6x3m: sounds painful to use jetty directly without ring

8:31 what is the point of this in a project.clj: :exclusions [org.clojure/clojure]

8:33 nuwanda_: that's inside a dependency right?

8:34 hellofunk`: nuwanda_ yes

8:34 nuwanda_ no actually it is inside the defproject but not inside the :dependencies

8:35 nuwanda_: weird, never seen it like that

8:36 hellofunk`: nuwanda_ : https://github.com/james-henderson/chord/blob/master/example-project/project.clj

8:37 mi6x3m: hellofunk`: it excludes over all dependencies

8:38 nuwanda_: ;; Global exclusions are applied across the board, as an alternative

8:38 ;; to duplication for multiple dependencies with the same excluded libraries.

8:38 from leiningen's samples

8:38 hellofunk`: and why would you exclude a dependency on clojure itself?

8:38 nuwanda_: i'm guessing not to shadow the clojure you're adding as a dependency on your own project

8:39 but haven't read anything about that, just something I've assumed since i've seen it

8:39 for the first time

8:39 mi6x3m: hellofunk`: well you are including clojure yourself :)

8:40 hellofunk`: mi6x3m: so you include it yourself and then tell any other libraries that have already included it to exclude it, perhaps thus preventing multiple versions of clojure getting into your app?

8:40 mi6x3m: hellofunk`: bingo, this will effectively force the libs to use your clojure

8:41 hellofunk`: mi6x3m: which means that those libs could *possibly* behave differently than the authors intended if future versions of clojure change a bit

8:42 mi6x3m: hellofunk`: ehm, yes, but the intention would probably be to use fixes for knowl issues :)

8:42 hellofunk`: also, consider this. you are creating an ueberjar

8:42 adding 3 versions of clojure gets very heavy

9:07 donbonifacio: how can I make a function that is variadic and may receive the variadic arg as a vector?

9:07 (boo "a" "b") same as (boo ["a" "b"])

9:11 AimHere: There's two or three ways, depending on what you're trying to do

9:13 mi6x3m: donbonifacio: (defn boo [& args] ...)

9:13 gfredericks: donbonifacio: that's not built in, you have to do it by hand; not built in because it's ambiguous and so generally a bad idea

9:13 mi6x3m: ah, wait, you want to get them as a vector

9:13 hm, you can write a macro?

9:13 donbonifacio: yes, I just did a side function

9:14 starting to dislike variadic for generic usage

9:14 gfredericks: donbonifacio: do you know about apply?

9:14 donbonifacio: yes

9:14 AimHere: Couldn't you multimethod it?

9:15 donbonifacio: I used apply already for converting variadic to hashes, but this one with vector was more troublesoume

9:16 justin_smith: the caller knows whether they are providing a single collection or separate args, so why not let them decide whether to use apply or not?

9:18 AimHere: For this particular case, will you be able to tell from the number of arguments which case you're dealing with?

9:20 donbonifacio: nop, didn't find a way to know with one was it

9:21 gfredericks: ,(defn additatify ([nums] (reduce additatify nums)) ([x y & zs] (reduce + (+ x y) zs)))

9:21 clojurebot: #'sandbox/additatify

9:21 gfredericks: donbonifacio: you can't in general, because it's ambiguous -- in general you might want to call a function with just one arg which happens to be a vector

9:22 donbonifacio: yes, lesson learned gfredericks

9:22 from now on, explicit vector/hash via params

9:49 justin_smith: hellofunk`: mi6x3m: it is only possible to get one version of a dep. I guess the global exclusion makes it super clear that you want them to get their own clojure version, but an explicit clojure dep should override the other transative deps anyway.

9:51 mi6x3m: justin_smith: I see, so leiningen does assume backward compatibility?

9:52 justin_smith: mi6x3m: it's as much about the underlying libs as that. The jvm only allows one version of a class (unless you do weird stuff) so only one version of the dep can be loaded.

9:53 mi6x3m: justin_smith: oh

9:55 nuwanda_: I'm confused, than what exactly does ":exclusion [...]" do?

9:55 justin_smith: it prevents that library's dependency from being included from any of your deps

9:55 Glenjamin: it means "don't include this transitive dependency of this module"

9:55 justin_smith: which means either you don't actually need it, or the end user is assumed to provide a version

10:45 SagiCZ1: does any one of you know C#? what is your opinion on how its inheriting works in comparision to what clojure does? it seems extremely convoluted and complicated to me..

10:52 mi6x3m-alt: SagiCZ1: in what regard

10:52 it's a pretty standard OOP inheritance

10:54 SagiCZ1: mi6x3m-alt: there is volatile, override, new and all kinds of other modifiers that seem unnecessary to me

10:55 mi6x3m-alt: SagiCZ1: well to you but there are scenarios to those. C# is quite flexible.

10:56 SagiCZ1: mi6x3m-alt: the question is, is there any scenario you can't achieve with clojure that you can in C#?

10:57 mi6x3m-alt: SagiCZ1: no, they are both Turing complete :) both on a serious note, C# also considers nativeness

10:57 and has a tight integration to .NET as a whole

11:03 SagiCZ1: what do you mean by nativeness?

11:06 mi6x3m-alt: SagiCZ1: non-managed code

11:09 zilti: What's the best way to run a function in a separate thread "indefinitely"? .run it? Put it in a future? Use a core.async/thread?

11:10 gfredericks: no reason for core.async if you're not using channels

11:11 AeroNotix: zilti: what problem are you trying to solve?

11:11 zilti: I'm using channels

11:11 AeroNotix: I write a server receiving stuff over a ZeroMQ socket, and want the receiving loop running in a thread.

11:12 AeroNotix: zilti: and the function has some kind of loop?

11:12 ,doc future

11:12 clojurebot: #<CompilerException java.lang.RuntimeException: Can't take value of a macro: #'clojure.repl/doc, compiling:(NO_SOURCE_PATH:0:0)>

11:12 zilti: AeroNotix: Yes. It distributes the incoming stuff over core.async-channels

11:12 AeroNotix: zilti: I'd probably just use a future for ease of implementation

11:12 worry about more complicated things later

11:13 zilti: AeroNotix: Okay. I wasn't sure if the runtime is okay with an indefinitely running future due to what it was designed for. Thanks!

11:13 AeroNotix: meh

11:13 it's easy to use (there are better things, sure)

11:16 mi6x3m-alt: zilti: I am using the following for this task in my app: (async/go (while true .... ))

11:16 i think it does what you need

11:16 (and that I am understanding you correctly)

11:17 AeroNotix: mi6x3m-alt: seems easier to just use future, no dependency if you don't need it.

11:17 zilti: mi6x3m-alt: I thought about using core.async/thread

11:17 AeroNotix: I'm using core.async anyway, so that isn't an unneeded dependency for me

11:18 mi6x3m-alt: zilti: they seem to be pretty equivalent in that case

11:18 AeroNotix: The question remains, by being finicky about this, you seem to think there are tradeoffs between different approaches. What do you think those are and what are you trying to *solve*

11:18 mi6x3m-alt: zilti: go has some extra functionality

11:19 zilti: mi6x3m-alt: For what I understood, core.async/thread creates a new thread while async/go uses one in the allocated thread pool thus possibly exhausting it after some threads, but I might be wrong with that

11:19 mi6x3m-alt: zilti: I believe it's more about the parking of threads

11:20 AeroNotix: zilti: if you're worried about that, then just use Thread itself directly

11:20 zilti: AeroNotix: I wasn't sure if there were downsides in the specific ways of running something in a thread

11:20 Ent_: ,(partition 2 -1 [1 2 3 4 5])

11:20 clojurebot: ((1 2) (1 2) (1 2) (1 2) (1 2) ...)

11:20 mi6x3m-alt: zilti: yes that seems to be it, the parking allows you not to block an OS thread but to reuse it for something else if your operations are currently blocking it

11:20 I suggest you use go

11:20 zilti: AeroNotix: So for now I'm just using a future, I'm fine with that

11:21 hellofunk: what happens if a library you depend on is removed from clojars? i assume that your app will no longer work when lein cannot download it, is that right?

11:21 zilti: mi6x3m-alt: I doubt it's gonna park my thread when I'm not using the <! functionality?

11:22 AeroNotix: hellofunk: removing things from clojars is non-trivial.

11:22 mi6x3m-alt: zilti: no, it will only park it if you use that and it blocks

11:22 AeroNotix: and entirely manual, and entirely upto the discretion of those in-charge of Clojars..

11:23 hellofunk: AeroNotix: ok, so library authors cannot on their own remove a library they have published to clojars, correct?

11:23 AeroNotix: zilti: mi6x3m-alt core.async/go should be only really used if you're using the parking operations. Otherwise it's just dumb.

11:23 hellofunk: correct.

11:24 mi6x3m-alt: AeroNotix: well intuitively it's better to always use parking instead of blocking a thread

11:24 hellofunk: AeroNotix: it just occurred to me the disaster that would ensue if libraries you depend on were to disappear, so that is a bit reassurring

11:24 mi6x3m-alt: with an exception to the resources the parking may be using of course

11:24 but how significant would that be?

11:24 AeroNotix: meh, I'm done with this discussoin

11:24 Nothing useful is coming out of it

11:25 zilti: mi6x3m-alt: I'd have to look if ZeroMQ parks or blocks the thread when "receive" is called, but other than that I can't influence that

11:25 hellofunk: AeroNotix: which discussion, go or clojars?

11:25 AeroNotix: hellofunk: go

11:25 zilti: it's a socket read, correct?

11:25 mi6x3m-alt: AeroNotix: a discussion is useful :) we are considering 3 different alternatives

11:26 zilti: AeroNotix: Yes, a read from a ZeroMQ socket

11:26 AeroNotix: zilti: so your thread blocks on that read

11:27 zilti: AeroNotix: I assume so, yes. If ZeroMQ blocks, my thread blocks.

11:27 AeroNotix: Yes.

11:28 mi6x3m-alt: zilti: wait, zeromq would not park, the parking is offered by async

11:28 AeroNotix: mi6x3m-alt: hence why using go blocks for something like this is dumb

11:28 there's no reason to use them unless you are using parking operations *inside the go block*.

11:29 mi6x3m-alt: AeroNotix: oh, now I see, yes, you are perfectly correct

11:29 (inc AeroNotix)

11:29 lazybot: ⇒ 5

11:29 mi6x3m-alt: it barely makes sense if the blocking is somewhere else

11:29 zilti: mi6x3m-alt: But since async can't know when it should block except when using <! it doesn't make sense

11:29 mi6x3m-alt: yeah no sense at all

11:29 AeroNotix: and since it's a macro, they need to literally be present in the go block itself.

11:30 not some function that the go block calls.

11:30 afaicu

11:30 zilti: yes, correct

12:08 AeroNotix: What's the function that allows you to update a key in a map with a function, if the key already exists, call the function with the two entries

12:09 justin_smith: with the two entries?

12:09 kryft: I have a simple ring server that uses postgresql; the code worked fine for months, but recently I started getting "ident authentication failed" PSQLExceptions. At first I assumed that something must have changed in the server's postgresql installation (I don't administrate it), but it seems that I can access the db fine through psql or python

12:09 So I wonder if it might have something to do with clojure, jdbc or the jvm

12:10 AeroNotix: oh just update-in

12:10 justin_smith: &(update-in {:a 0} [:b] (fnil inc 0))

12:10 lazybot: ⇒ {:b 1, :a 0}

12:10 AeroNotix: yeah that's it

12:10 justin_smith: I didn't understand what you meant by "two entries" in this context

12:10 AeroNotix: I meant the two values under the key

12:11 justin_smith: ?

12:11 what two values?

12:11 AeroNotix: the old and new

12:11 justin_smith: that's not how update-in works

12:11 AeroNotix: No, but I can do similar things

12:11 with update-in

12:11 justin_smith: sure

12:11 AeroNotix: enough that I don't need what I originally wanted

12:13 oh there's merge-with

12:14 justin_smith: merge-with

12:14 justin_smith: that sounds a bit closer to the logic you were describing, yeah

12:41 AeroNotix: https://gist.github.com/AeroNotix/8eca7a25a80c46c19dd9 how do I do this without eval?

12:42 (aimed at gettings vars of symbols in macros)

12:44 hmm, gist updated. Maybe something like that?

12:45 oh there's a resolve function which kinda does this

12:52 justin_smith: AeroNotix: keep is the equivalent of (remove nil? (map ...))

12:52 &(keep rest [[1 2] [1] [3 4] [3]])

12:52 lazybot: ⇒ ((2) () (4) ())

12:52 justin_smith: oops

12:53 &(keep next [[1 2] [1] [3 4] [3]])

12:53 lazybot: ⇒ ((2) (4))

12:53 andyf: justin_smith: You mean, (keep identity ...) is the equivalent of (remove nil? ...) ?

12:54 justin_smith: andyf: actually I meant what I said, he had (remove nil? (map ...)) and it can be replaced by (keep ...)

12:54 because keep wraps up the functionality of remove nil? and map

12:54 andyf: sorry, missed the context

12:54 justin_smith: np

12:55 I could have been a bit more clear - (keep f coll) is the equivelent of (remove nil? (map f coll))

14:15 gfredericks: does anybody know if openjdk has anything special about their crypto classes? I tried pasting the AES code and compiling it on my own and it seems to run ~13x slower

14:27 arrdem: dnolen_: ping

14:27 dnolen_: arrdem: pong

14:28 arrdem: dnolen_: https://github.com/clojure-emacs/cider/issues/702#issuecomment-68606220

14:29 dnolen_: just curious if you have feedback / alternate fix

14:29 masnun: I have setup lazybot in one of my IRC rooms. When I run the jar file, it takes around 500MB memory. I want to run the bot on a VPS where 500MB is more than I can allocate to it. Is there any way to make the bot take less memory?

14:30 Bronsa: arrdem: cljs frequently has both foo.clj and foo.cljs, it's not only for cljs.core

14:30 dnolen_: arrdem: no feedback other than that needs to work

14:30 arrdem: ok that was my understanding.

14:30 dnolen_: arrdem: namespaces in general shouldn't be expected to be unique across platforms, that conclusion is correct

14:31 arrdem: thanks guys I'll dee what I can do.

14:31 dnolen_: arrdem: also you should prepare yourself of cljc, where the platform is mixed due to feature expressions

14:31 arrdem: s/dee/see/g

14:32 dnolen_: s/of/for

14:32 andyf: dnolen_: Probably the easiest way to prepare for that, if one relies on tools.namespace, is to wait.

14:32 arrdem: dnolen_: yeah that's gonna be as andyf points out an issue of pushing tools.ns forwards.

14:33 andyf: or push for the desired changes after they are understood.

14:35 arrdem: (add-watcher feature-exprs #'arrdem)

14:36 kryft: Can I somehow pass a flag like -Djava.net.preferIPv4Stack=true to lein repl_

14:37 Ah, apparently :jvm-opts in project.clj should work

14:38 andyf: Does anyone know if the current feature expressions proposal means that Clojure's require/use behavior would change to look for a foo/bar.cljc file if no foo/bar.clj file existed?

14:41 dnolen_: just shipped out ClojureScript 0.0-2655, only change is that require no longer has :reload-all semantics & there is explicit support for :reload & :reload-all in `ns` and `require` forms

14:43 arrdem: andyf: I believe that's correct

14:43 andyf: Yeah, looking at the wiki design page, it seems to say that. Looking at the latest Clojure/JVM CLJ-1424 patch now to see if it actually does that.

14:48 Bronsa: What is the current & after-feature-expressions behavior intended to be if there is foo/bar.cljs and foo/bar.clj? after-feature-expression it appears to be: Clojure/JVM reads only foo/bar.clj, ignoring foo/bar.cljs. ClojureScript reads only foo/bar.cljs, ignoring foo/bar.clj. Does that sound correct?

14:49 arrdem: cljs ignores foo/bar.cljc? really?

14:49 Bronsa: andyf: I have absolutely no idea :P I won't bother looking into the proposed impl until a decision is taken

14:50 andyf: arrdem: There was no foo/bar.cljc in my example

14:50 Bronsa: understood.

14:50 arrdem: andyf: my bad. understood.

14:50 Bronsa: andyf: what you said sounds intuitively correct to me though

14:51 arohner: wow, lein figwheel is fucking magical once you get it set up

14:51 andyf: Maybe I should play around with the demo build of with-feature-expressions that someone published recently.

14:51 arohner: highly highly recommended for all Om/react projects

14:52 dnolen_: https://github.com/levand/fx-hello-world

14:52 arohner: figwheel rocks

14:52 andyf: This one, by Luke Vanderhart, in case it wasn't obvious what I meant: https://github.com/levand/fx-hello-world

14:55 bbloom: dnolen_: arohner: https://twitter.com/BrandonBloom/status/550827517662470146

14:55 and https://github.com/brandonbloom/cljsd/blob/master/README.md

14:55 i'm still kinda "meh" on figwheel

14:56 arohner: bbloom: I like that approach, but the 'push' nature of figwheel is amazing

14:56 bbloom: arohner: i'd rather achieve push via "re-evaluate this file"

14:57 arohner: sure

14:57 I miss not seeing compile errors when I C-c C-k

14:57 dnolen_: bbloom: Working on the compiler means at least 50% time I never want to see a browser. For the other cases I prefer figwheel.

14:58 bbloom: i'm using cljs for a personal project now, but i'm doing something highly crazy... i'm quite happy with my entirely unreproducible custom hackery

14:58 dnolen_: bbloom: but that is an interesting approach

14:58 bbloom: but w/o going to disk doesn't solve the slow start problems that drive me crazy

14:58 bbloom: i basically build all the cljs code in clj in memory and then define a single macro that emits everything

14:58 then i just call the cljs compiler with that one macro

14:59 dnolen_: bbloom: also you can't shared analysis information across processes

14:59 bbloom: works fine for my uses & lets me mostly do everything in clj until i need :-)

14:59 dnolen_: bbloom: in any case - if it works for you, great!

14:59 bbloom: i just clojure.core/eval that macro when i need to test jvm-side :-)

15:00 i'm sure any sane clojurist would view this as the ramblings of a mad man

15:00 but it works for my particular needs

15:00 and it's a personal project, so screw other programmers :-)

15:00 arrdem: we're all mad here

15:00 arohner: bbloom: being a clojurist, I'm quite used to *everything* being viewed as the ramblings of a mad man

15:00 arrdem: beat me to it!

15:00 bbloom: heh

15:01 arrdem: andyf: so I suppose this means we want a ClojureScript cheatsheet build at some point..

15:03 andyf: arrdem: I can help, but believe it or not, I haven't ClojureScript'd, so would likely miss some finer points, if not big things.

15:06 dnolen_: someone should work on parallel compilation for ClojureScript seems like a simple optimization w/ likely some nice gains especially for larger projects - http://dev.clojure.org/jira/browse/CLJS-957.

15:07 bbloom: dnolen_: would be super cool

15:15 andyf: Bronsa: arrdem: In partial answer to my earlier question, the answer for Clojure/JVM is that require/use/load of "foo/bar" will look for foo/bar.clj first, and if not found, will look for foo/bar.cljc. The latter file will be ignored if both exist.

15:16 My guess is that it would be an unusual situation for both files to exist.

15:23 Bronsa: What does ClojureScript do when there are two files for the same namespace, i.e. /src/cljs/cljs/core.cljs and /src/clj/cljs/core.clj - does it read and use both?

15:24 Bronsa: andyf: only the cljs, it uses the clj just for macros

15:24 andyf: But it must read/analyze/compile/etc. the .clj file in addition to the .cljs file, or it will not do the correct thing?

15:26 Bronsa: andyf: when you require foo.bar, it will just load foo/bar.clj using c.c/load if it finds one in the classpath

15:26 andyf: no manual analysis

15:29 andyf: it sounds like arrdem is saying here https://github.com/clojure-emacs/cider/issues/702#issuecomment-68606220 that there can be both a .clj and a .cljs file with the same namespace. I am curious whether ClojureScript ignores one of those files in such a case, or pays attention to them both. Perhaps his issue was specific to processing files inside of the ClojureScript implementation itself, though, not the typical ClojureScript

15:29 project.

15:31 arrdem: andyf: specifically that was for cljs itself, but I would guess that if you require and require-macros that cljs will happily load both implementations of "the same" namespace.

15:32 * arrdem also in the has not clojuescript'd camp

15:39 TimMc: Maybe the next time we get roped into a frontend project at work we can use Clojurescript.

15:39 I want an excuse to try Om. :-P

15:46 arohner: not quite a clojure question, but how TF do you get chrome to respond with "net::ERR_INVALID_RESPONSE", in a standard ring app?

15:46 some urls work fine, and other reliably cause that error. The response looks fine to me, according to clj-http

15:47 hrm, it might have something to do with a ring-defaults option

15:54 kenrestivo: andyf: it'd be cool if eastwood could catch (defn foo [{:keys [bar baz]}] (something bar)) <== baz is destructured but not used

15:57 cfleming: arrdem: When I added CLJS support to Cursive, I had to add language as a data item to all my internal structures - indexes etc

15:57 arrdem: You definitely need to know the language to

15:58 arrdem: Oops

15:58 arrdem: Resolve properly

15:59 arrdem: cfleming: yep. shouldn't be too bad, just need to do it and rebuild.

16:18 cfleming: andyf: It is very common to have both a clj and cljs namespace with the same name and file structure

16:20 andyf: This is used by :include-macros or :refer-macros

16:27 seangrove: dnolen_: What do you think about a hand-written js-lib that pulls in mori as a dep, but exports a js-style API (camelCase, map(coll, fn) vs map(fn, coll), plus a chaining fn to easily chain things)?

16:27 I'd be happy to do that, and I think it'd obviate a lot of the need for something like immutablejs

16:27 And the API's change slowly enough that maintaining it by hand shouldn't be too bad

16:28 bbloom: seangrove: what's the difference between that and mori?

16:29 seangrove: bbloom: Just JS sugar

16:29 bbloom: is it literally camelCase instead of snake_case ?

16:29 seangrove: camel case, arg order, and a chaining API

16:29 immutable-js is cool, but it's missing a lot of the work that's gone into cljs data structures, obviously

16:30 bbloom: this is half a thought, but aren't transducers essentially a chaining api?

16:30 mi6x3m-alt: Bronsa: hey, do you think you might release tools.analyzer soon?

16:30 seangrove: bbloom: Yeah, they could be (and more efficient at that) - I haven't thought this all the way out, just thinking about the three args I hear against Mori

16:31 Needs to be chainable (js devs love their chaining apis even with the batshit insane hard-coded return semantics), camelCase, and with the callback (or fn) last (like node or swift)

16:31 bbloom: seangrove: my assumption is that wrapping mori is a waste of time, as it's a direct wrapper of cljs

16:31 an alternate wrapper that is more js friendly may make sense, but i'm skeptical

16:32 over time, i've learned to not really care too much about two libraries with incompatible naming conventions, but i understand it causes many folks to freak out

16:33 seangrove: bbloom: Trying to find a way to help direct more energy into cljs data structures rather than splitting into immutablejs vs mori

16:33 mi6x3m-alt: Bronsa: ignore my last statement, the necessary versions are out already :)

16:33 seangrove: bbloom: And the js community clear prizes... erm... convention over other salient aspects

16:35 bbloom: seangrove: *shrug* data types are a cross-cutting concern. unless you can clearly win as THE ONE AND OBVIOUS CHOICE for data structures in js land, you're never going to escape duplication of efforts. and no matter what you do, i don't expect cljs' impl to bend to the will of node.js folks et al, so it seems like a lost cause to reconcile

16:35 seangrove: But yes, bypassing Mori would make sense since it's doing the same thing, I just wonder if it isn't the same thing with slightly different compiler settings.

16:35 chenglou: Any thoughts, having used both?

16:35 bbloom: iirc mori is mostly generated anyway, so yeah, probably just slightly different code generator

16:36 otwieracz: Hello.

16:36 seangrove: bbloom: I'll chew on it a bit, seems like it's a weekend or two project, not too much more than that, and could have some nice implications for use in e.g. immutablejs, etc.

16:37 But maybe that differing needs and FB's inability to pull cljs development their way would be a deal-breaker

16:37 chenglou: I love mori lol

16:37 the perf's superb. I don't care about some micro benchmarks on iteration speed

16:38 there are much bigger perf gains to be had in mori

16:38 but yeah js people want js API. Swap argument order (callback last), camelCase and chaining would do the thing

16:38 it's either that or everybody flocks to immutable-js

16:39 which is fine by me. I don't care much

16:39 bbloom: i see no chance of mori gaining real popularity

16:39 or anything built on cljs' structures

16:39 the npm world is too volatile

16:39 chenglou: well, immutable-js sure is popular

16:40 bbloom: somebody will open a cranky github ticket and twitter will asplode b/c cljs is not "the node way" or something and then somebody will release a persistent data structures "micro framework" or some shit :-P

16:40 otwieracz: I an trying to follow http://docs.opencv.org/2.4/doc/tutorials/introduction/clojure_dev_intro/clojure_dev_intro.html

16:41 AeroNotix: Can I put defmethods into different namespaces?

16:42 justin_smith: AeroNotix: absolutely

16:42 AeroNotix: ah, cool.

16:42 chenglou: bbloom: but we already did lol

16:42 bbloom: and the wrapper's goal is exactly to be "the node way"

16:42 bbloom: chenglou: exactly

16:43 AeroNotix: justin_smith: do I need to namespace-qualify the defmethod's target in the other namespace/

16:43 ?

16:43 bbloom: chenglou: that's exactly what happened and exactly what would happen again, since everything happens in a loop in node land

16:43 justin_smith: AeroNotix: yes, it belongs to that namespace, so needs to be qualified properly

16:43 AeroNotix: justin_smith: thanks

16:46 dnolen_: seangrove: I honestly don't have that much time to maintain mori & w/ ImmutableJS it's somewhat less compelling to maintain.

16:46 seangrove: that said I definitely see the value - ImmutableJS has lots of bugs we've ironed out and way more functionality

16:47 seangrove: one weird problem is that JS users don't have the CLJS compiler to optimize calls to multi-arity / variadic fns

16:47 seangrove: so they take a significant perf hit

16:48 seangrove: but maybe that doesn't matter?

16:49 seangrove: there's also the alterior motive to let ImmutableJS win & not create competition though that's a longer term strategy

16:49 er I meant Mori has way more functionality of course

16:50 chenglou: dnolen_: got 2 mins?

16:50 dnolen_: I have something really interesting that you might wanna check

16:50 dnolen_: chenglou: sure what's up?

16:50 chenglou: kk sec, putting the last touch

16:55 dnolen_: https://rawgit.com/chenglou/react-state-stream/master/index.html

16:56 dnolen_: I didn't bother porting it to cljs because I still don't know om/reagent too well. But I think I've found the general API for tweening & unmounting transition

16:56 check the readme for more details

16:57 dnolen_: I like how simple it is (mixin's like 40 lines of code). We could have first-class support for it in React in the future and it's not animation-specific.

16:59 convenience link https://github.com/chenglou/react-state-stream

17:00 dnolen_: chenglou: very cool, will need to read over it a few more times but this looks really promising!

17:01 chenglou: =). Feedback appreciated. This basically boils down to "how do you express a flash timeline in code without FRP"

17:03 dnolen_: chenglou: huh what's in mori that's missing from ImmutableJS? I thought there were LazySeqs there

17:04 rhg135: dnolen_, great work on cljs; the node repl is amazing

17:05 dnolen_: rhg135: thanks, glad to hear it you're liking it!

17:05 chenglou: dnolen_: immutable-js lazy seqs don't cache (it's all or nothing)

17:05 dnolen_: chenglou: ah right, that'll make a big difference

17:06 chenglou: so when I'm consuming the tail at each frame, it uses O(n^2) for each get

17:06 rhg135: i do have one question though, how are you suppose to use macros?

17:06 chenglou: after a minute it's like 10k operations and it's recursive, lol

17:06 dnolen_: rhg135: (require '[cljs.repl :refer-macros [doc]])

17:07 rhg135: dnolen_, i mean like in core.async where it's an entirely different ns name

17:07 dnolen_: rhg135: there's actually a pretty interesting proposal for macro usage inference that will hopefully get rid of this http://dev.clojure.org/jira/browse/CLJS-948

17:08 rhg135: wow, thatd be nice

17:08 dnolen_: rhg135: hrm, actually that's probably an oversight, could add require-macros special fn in the meantime

17:09 rhg135: ah ok

17:09 i figure :refer-macros didn't exist when core.async started

17:10 dnolen_: rhg135: that's right

17:10 rhg135: fixing this now

17:11 rhg135: thx, dnolen_

17:11 dnolen_: rhg135: thanks for the feedback

17:11 chenglou: will definitely poke around at this and get back to you

17:12 chenglou: Cool

17:12 andyf: cfleming: Thanks for the info. Is it true that ClojureScript _only_ pays attention to .clj files if a .cljs file has :refer-macros or :include-macros ?

17:12 rhg135: dnolen_, i did run into a NPE with piggieback from the cljs.repl.node/setup fn but since it works sans nrepl i filed an issue with piggieback

17:12 andyf: kenrestivo: Could you create a Github issue with an example (that one would suffice)?

17:13 seangrove: bbloom: Missed your PDS "microframework" - like that idea, I'm on it

17:13 dnolen_: andyf: those are sugar - (:require-macros ...) is the trigger to load .clj files

17:16 bbloom: seangrove: *sigh*

17:20 dnolen_: rhg135: cutting 0.0-2656, in line in Hudson behind some tests but it should be out in a hour so I imagine - will push out a new mies when it does

17:22 rhg135: dnolen_, cool, i don't do many webapps so i never did do much cljs but node seems perfect for me

17:23 kenrestivo: andyf: sure, thanks

17:26 hellofunk: dnolen_ brings holiday productivity to a whole new standard. inspiring, actually

17:30 dnolen_: rhg135: released

17:30 andyf: kenrestivo: Have you tried option '{:add-linters [:unused-locals]}' and/or :unused-fn-args ? Those might already do what you want. They are disabled by default because they can be fairly noisy.

17:31 kenrestivo: oh, ok, will do.

17:31 rhg135: dnolen_, thx, restarting repl

17:33 kenrestivo: oh, cool, unused-locals works

17:33 andyf: good. I should have thought of that when you first asked instead of suggesting creating the issue -- a little slow today :)

17:34 rhg135: dnolen_, maven central takes a while sometimes but ill retry in a while

17:34 dnolen_: rhg135: it's usually really fast, 15 minutes or so

17:35 cfleming: dnolen_: CLJS-948 looks interesting, I think that would be a good change if there are no wider implications

17:36 dnolen_: cfleming: pretty sure there isn't, it's riding on a convention that's already in place and it requires something explicit - the inference is not really an implicit thing

17:37 cfleming: dnolen_: I was hoping for something that would make it explicit on the macro def whether it was for CLJS or CLJ, but it still looks like a nice change

17:37 dnolen_: cfleming: yeah that's probably never going to happen

17:37 rhg135: it'd be nice for core.async to follow it (since it helps with the oh-so-common asynchrony in js) but ya

17:37 cfleming: dnolen_: I know, I'll have to try to index that somehow

17:38 dnolen_: rhg135: agreed probably something to reconsider in the near future

17:39 rhg135: in om it's pretty seamless

17:39 i was writing code for a while then i realized "isn't go a macro"

17:40 cfleming: dnolen_: BTW I think I'll have the macroexpander in the next drop

17:41 dnolen_: cfleming: sweet!

17:41 cfleming: dnolen_: clj only for now, but respects &env and allows arbitrary subforms to be expanded

17:42 dnolen_: chenglou: this is really nice and simple

17:42 chenglou: I don't see the need for infinite streams in this case, seems like if mori.seq(foo) => null, you know you don't have to invoke rAF again

17:43 chenglou: maybe I missed something?

17:43 rhg135: i can't wait for the next cursive it sound like it's a fairly major improvement over an already useful tool

17:44 cfleming: rhg135: Thanks, lots of good stuff coming up - I'm hoping to add the node REPL in the next couple of releases too

17:44 andyf: cfleming: Does this macroexpansion always start with outermost forms until it gets to some form selected by the user for expansion? There are at least some cases where the inner expansions are affected by outer ones.

17:45 rhg135: cfleming, in my testing it seems to work fine in the normal editor just not in the repl editor

17:45 chenglou: dnolen_: is that what I'm taking about in the perf optimization section? Like, conceptually repeat(s) is the same as [s]

17:45 cfleming: andyf: Yes - I always macroexpand from the top level form, but only display from the form the user selected

17:45 chenglou: The lazy seq with a single state left

17:45 dnolen_: chenglou: or lazy seq w/ no more states to go to, the seq is exhausted

17:45 andyf: Did you write your own, or found one that works well?

17:46 dnolen_: chenglou: you can just set state to the final value then

17:46 cfleming: andyf: I add a metadata tag to selectively expand subforms too

17:46 andyf: I'm using a hacked version of riddley

17:46 andyf: So it's only clj right now, I need to investigate the cljs expander but will probably do something similar

17:46 andyf: I haven't yet looked terribly carefully at the file/line/col tracking during macroexpansion in Eastwood, but probably will some day.

17:47 chenglou: dnolen_: yes that's exactly what I was gonna do. I didn't bother simply because I didn't want to deal with mapping over the old seq then finding out that the seq wasn't long enough

17:47 cfleming: andyf: I was surprised how much of that is thrown away

17:47 andyf: I had to modify the expander to maintain the tags I'm interested in

17:47 dnolen_: chenglou: also in the examples seems you could just use plain JS objects

17:47 andyf: Any possibility of publicizing your hacks to riddley?

17:48 cfleming: andyf: Absolutely. In fact if it's EPL I assume I'm required to do so.

17:48 hellofunk: cfleming: i'm about to try Cursive on a new project starting this week, looking forward to really kicking its wheels

17:48 dnolen_: chenglou: instead of mori hash maps I mean

17:48 cfleming: hellofunk: Great, I'm interested to know how you find it

17:48 chenglou: dnolen_: they'd mutate throughout the whole seq though

17:49 hellofunk: cfleming: i'm sure i'll have plenty of questions so i'll hit up the mailing list

17:49 crack_user: hello guys

17:49 cfleming: hellofunk: Sounds great

17:49 dnolen_: chenglou: I just mean that they are small, so might be faster to Object.extend is what I mean

17:49 chenglou: and you don't need to bother with clj_to_js which I know is slow

17:51 chenglou: True. I ported this over from immutable JS to Mori yesterday so it's really not optimized

17:52 I'm not worried about perf for now though =)

17:52 dnolen_: chenglou: ah k :)

17:54 chenglou: Was really fast to rewrite the few lines of immutable JS though. Which is why I thought an idiomatic JS helper (easy to make easy to maintain) for Mori might be a good idea

17:57 dnolen_: chenglou: right, I'd be OK w/ a more idiomatic JS naming scheme for mori's API

17:58 ticking_: dnolen_: I just stumbled upon reference-cursors, they're exactly the explicit cursor thing I asked for a few days ago :D, thanks for always thinking ahead!

17:58 dnolen_: chenglou: well I like it! seems cool and straight forward

17:59 ticking_: (inc dnolen_)

17:59 lazybot: ⇒ 9

17:59 justin_smith: (inc dnolen)

17:59 lazybot: ⇒ 19

17:59 chenglou: Thx =)

17:59 dnolen_: ticking_: heh

18:01 chenglou: the cancel transition logic is very slick

18:01 chenglou: I like it a lot. I think that was the only real challenge in (react) transitions. How to animate during unmounting

18:02 The TransitionGroup add on is basically a hack

18:02 Have you seen the two examples I have in the readme

18:02 Photos swiping and orientation change

18:03 Oh wait, cancel transition? I think I'm talking about something else lol

18:16 mi6x3m-alt: is x.y.z-clj a good name for a clojure wrapper around a java library?

18:17 scottj: mi6x3m-alt: not if you don't own x.y.

18:18 mi6x3m-alt: scottj: define "own" ?

18:18 scottj: mi6x3m-alt: if it's com.foo and you don't own foo.com.

18:18 mi6x3m-alt: scottj: no, it's not domain-like

18:18 it's words

18:20 scottj: is the java library yours? (you created it or are the maintainer etc)

18:20 mi6x3m-alt: scottj: nope, 3rd party work

18:20 scottj: then it's a bad name imo

18:21 mi6x3m-alt: I think you are indeed right

18:28 can one set a default profile with leiningen?

18:28 like dev-32?

18:29 Kristien: Playing with core.async and Om

18:29 It's so fun

18:30 mi6x3m-alt: Kristien: the combination or the parts are fun? :)

18:30 Kristien: both :p

18:31 It's for a tool I'm working on, all I have to do now is swap out the timeout for a websocket: https://gist.github.com/rightfold/66ea8d6514aa740032d0

18:53 ed-g: Is there a library that will let me parse a date-time with time zone? clj-time only parses UTC

18:55 justin_smith: ed-g: to-time-zone

18:55 ed-g: justin_smith: thanks!

18:55 justin_smith: ed-g: to-time-zone

18:56 err, sorry (client issues0

19:40 ambrosebs: is there a macro for (and (-> a ...) (-> a ....) (-> a ...) (-> a ....))

19:40 where ... is different in each case

19:43 theme2: ambrosebs, something using apply?

19:44 ambrosebs: just wondering if there's a clojure.core threading macro for this pattern

19:45 hyPiRion: not afaik

20:29 weavejester: Has anyone come across a good way to manage core.typed and core.typed.rt dependencies in Lein?

20:30 The only way I can think of doing it is with a custom deploy profile and some aliases to override "lein deploy"

21:35 hiredman: can't you just stick one in the dev profile and the other in your regulard depdencies?

21:42 ambrosebs: weavejester: yes dev profile is how I would do it https://gist.github.com/frenchy64/0b389202c7dc3778bd52

21:44 weavejester: ambrosebs: How does Lein know that core.typed overrides core.typed.rt?

21:44 ambrosebs: core.typed depends on core.typed.rt

21:44 and there is no overlap on files

21:45 weavejester: ambrosebs: Oh! I see

21:45 That makes things a lot easier

21:45 ambrosebs: good

21:46 weavejester: Is this all on the wiki somewhere, or could I add a page on it?

21:46 ambrosebs: took me a month to figure out the best way :)

21:46 please document it

21:46 weavejester: It's a clever solution :)

21:46 ambrosebs: thankfully cemerick did the dirty work for me

22:05 justin_smith: ambrosebs: what about (doto a (-> ...) (-> ...) (-> ...)) - not complete, but may be a nice way to do it

22:07 ambrosebs: justin_smith: I was looking for an idiomatic solution without writing a macro

22:14 kenrestivo: aha, doing async/>! inside of a swap! or a send or a send-off causes core.async to lock up hard.

22:15 i suspect this is unsupported, but i don't remember seeing that in any docs.

22:15 hiredman: kenrestivo: there is no "inside" of swap! or send

22:16 they are higher order functions

22:16 justin_smith: I would have suspected it was a bad idea based on the fact that swap! retries

22:16 hiredman: >! only works inside go blocks, the go macro does not descend in to functions

22:37 kenrestivo: hiredman: "inside" meaning from within the swap fn

22:38 hiredman: thanks! i was told it did. that makes perfect sense.

22:56 hiredman: I could be wrong, but as far as I recall it doesn't and it never has (and it is crazy that it doesn't error out)

22:58 http://dev.clojure.org/jira/browse/ASYNC-98

23:02 kenrestivo: i had expected it would not. i only tried because someone told me it did.

23:03 also, now i'm finding it locks up when inside a async/thread, using async/alts!! on a channel that is being fed from a go block.

23:04 i.e. (let [c (async/go "foobar")] (async/thread (loop [] (async/alts!! [c some-other-chan (async/timeout 1000))) ... the timeout never fires, everything just locks hard

23:05 (that's an oversimplified example, the real failing code has got a lot more moving parts)

23:05 hiredman: what makes you think the timeout never fires?

23:06 kenrestivo: i think i made a grave error by using core.async without a) better documentation available, and b) not being anywhere near as smart as rich hickey and tim baldridge

23:06 i don't know if it fires, but the alt!! never returns

23:06 which it would if the timeout fires, i expect

23:06 hiredman: what makes you say that?

23:06 kenrestivo: um, because the code just locks up

23:06 lines following the alt!! call never execute

23:07 hiredman: how do you know?

23:07 kenrestivo: the next line actually is (log/trace "this works now")

23:08 hiredman: if you take out the alts!! does that happen?

23:08 (do you have trace logging enabled?)

23:08 kenrestivo: yes i do. and i know the alt call is being called because i have another log line right before it

23:08 will try removing the alt completely, interesting idea.

23:13 hiredman: thanks for your epistemological questions. found a bug somewhere else that may be causing this.

23:20 rhg135: dnolen_, apparently i thought it'd be 0.0-2656 and it's 0.0-2657 but it works fine

23:20 (inc dnolen_)

23:20 lazybot: ⇒ 10

23:37 dnolen_: rhg135: cool

Logging service provided by n01se.net