#clojure log - Jan 07 2014

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

0:04 tommo_: is there way to shutdown/clear the clojure runtime from java?

0:08 seancorfield: not sure what you mean there tommo_ ?

0:08 there's (shutdown-agents) ...

0:09 dnolen: huh I guess an Om cursor is maybe a lens zipper?

0:10 tommo_: nvm seancorfield, it seems i spent 15 minutes debugging, then ask then fix it :p

0:11 i thought the rt was somehow keeping old code even after loading new

0:14 problem was that i was def'ing a context for my functions when the proxy method was called, and ofc it would only bind once so after 1 run it would be invalid

1:02 vdmit11: Hi folks. Is it possible to hint Java interfaces, not Classes? I call a Java method that returns objects that have a certain interface, but different classes. Then I call instance methods of the object and get reflection warnings. I want to fix them, but can't figure out how to provide interface hints to the compiler. Is there any way to do that?

1:08 Oh, sorry for the stupid question. I just forgot to (import) the interface from a corresponding package.

1:50 t3soro: (hello clojurians)

3:05 qrada: hey, can you pattern match 'empty list' in clojure? ie, (defn t ([] "empty") ([l] l)) , im recursing on 'l' and am wondering if i can 'break' out by matching on empty list some how

3:13 noidi: there's no built-in pattern matching in clojure, but there are libraries for that

3:13 https://github.com/clojure/core.match

3:14 https://github.com/jamii/strucjure

3:14 qrada: cool thanks

3:17 alew: Is Quartzite the best option for scheduling in Clojure right now?

3:20 noonian: looks pretty good

3:24 http://clojure-libraries.appspot.com/cat/Scheduling

3:26 alew: It's too bad here are like 3 or 4 clojure library listings

3:26 TEttinger: clojure toolbox is (was?) good

3:26 not sure if it's still up-to-date

3:27 noonian: that list matched my google search pretty well

3:28 also https://github.com/james-henderson/chime

3:28 andrew__: why is this filtering numbers less than 5 rather than greater than five, as it suggests? (filter (partial > 5) [1 3 6 9])

3:28 noonian: ,(doc filter)

3:28 clojurebot: "([pred coll]); Returns a lazy sequence of the items in coll for which (pred item) returns true. pred must be free of side-effects."

3:29 alew: you want remove

3:29 noonian: it keeps the ones that the predicate returns true for

3:29 andrew__: noonian exactly; 1 is not greater than 5, yet it returns 1 (and 3)

3:29 noonian: ,(filter (partial > 5) [1 3 6 9])

3:29 clojurebot: (1 3)

3:29 alew: ,(remove (partial > 5) [1 3 6 9])

3:29 clojurebot: (6 9)

3:30 noonian: ,(> 5 6)

3:30 clojurebot: false

3:30 noonian: because 5 is only greater than 1 and 3 in that collection

3:30 whilo_: dnolen: have there been attempts to implement https://github.com/webyrd/slpKanren with/in core.logic?

3:30 andrew__: ahh, i read it as "show me only those that are greater than 5"

3:31 noonian: yeah, the partial binding make (fn [n] (> 5 n))

3:31 t3soro: the thing gets expanded to (filter #(> 5 x))

3:32 noonian: ,(filter (partial < 5) [1 3 6 9])

3:32 clojurebot: (6 9)

3:33 alew: Cronj looks really nice

3:33 andrew__: ,(println "thanks")

3:34 clojurebot: thanks\n

4:01 * FiLoSsOfIe hello

4:29 sm0ke: Can core.async be somehow wrapped for use from java?

4:45 how do i define a interface in clojure

4:45 clgv: sm0ke: there is definterface

4:46 sm0ke: clgv: thanks

4:46 clgv: sm0ke: (definterface AwesomeNumeric (^int doSomething [^int x ^double y]))

4:46 sm0ke: as well as ^void

4:47 sm0ke: clgv: does that interface resolved to namespace.AwesomeNumeric?

4:47 what if i want something else

4:48 clgv: sm0ke: try full qualification. I am not sure whether it works but remember vaguely

4:48 ,(aporpos "interface")

4:48 clojurebot: #<CompilerException java.lang.RuntimeException: Unable to resolve symbol: aporpos in this context, compiling:(NO_SOURCE_PATH:0:0)>

4:48 clgv: ,(apropos "interface")

4:48 clojurebot: (gen-interface definterface)

4:49 sm0ke: sucks

4:49 ,(definterface org.pig.IClojure (^int dosome [^int x]))

4:49 clojurebot: sandbox.org.pig.IClojure

4:49 sm0ke: hmm thats a problem

4:49 clgv: if definterface does not allow fullqualification, the maybe gen-interface does

4:49 sm0ke: ah nice

4:49 there is gen0interface

4:50 clgv: but I did not use it, yet

4:50 sm0ke: ,(gen-interface :name org.ping.IClojure :methods [[dosome [int] int]])

4:50 clojurebot: org.ping.IClojure

4:51 sm0ke: thanks clgv

4:52 clgv: sm0ke: so the definterface is the more idiomatic version if you need the current namespace as package of the interface - which is probably often the case

4:53 oh right, I already used gen-interface to support arbitrary numerics...

4:53 +primitive

4:53 sm0ke: well not really , i dont think clojure people name their namespaces as org.clojure.my.hi.hello.wtf

4:53 which quite common in java

4:53 which is*

4:54 clgv: sm0ke: yeah. but my.lib.impl.IAwesome fits as well ;)

4:56 sm0ke: did you sometime feel the raging anger while trying to navigate thorugh a java package folder ?

4:56 fking nonsense

4:57 folder after folder, folder after folder, thats what source magaement is to java

5:00 oh and once a colleague of mine named a folder 'con', and the development supposed to be working on windows as well

5:17 shock_one: Is there a function like take-nth, but with step? I want to take 1st, 4th, 7th,.. elements of a sequence.

5:20 lumafi: doesn't take-nth do exactly that?

5:20 ,(take-nth 3 (range 1 10))

5:20 clojurebot: (1 4 7)

5:33 clgv: sm0ke: I prefer flat hierarchies for packages/namespaces as well

5:33 * ucb waves

5:47 sm0ke: how do i cancel a promise/ future ?

5:48 ,(def p (promise))

5:48 clojurebot: #'sandbox/p

5:48 sm0ke: ,(future (prn @p))

5:48 clojurebot: #<SecurityException java.lang.SecurityException: no threads please>

5:48 sm0ke: ,(prn @p)

5:48 clojurebot: Execution Timed Out

5:49 sm0ke: ,(cancel p)

5:49 clojurebot: #<CompilerException java.lang.RuntimeException: Unable to resolve symbol: cancel in this context, compiling:(NO_SOURCE_PATH:0:0)>

5:53 CookedGryphon: sm0ke: ,(doc future-cancel)

5:53 sm0ke: yeah i but found that

5:53 CookedGryphon: what about promise?

5:54 CookedGryphon: what do you mean cancel a promise? That doesn't make any sense, tehre's nothing running to cancel

5:55 just don't deliver it, and stop waiting to deref it

5:55 sm0ke: CookedGryphon: CookedGryphon exactly

5:55 what do you mean by stop waititng to deref it

5:55 there should be a way for me to canel promise so that waiting thread gets exception

5:56 CookedGryphon: deliver nil

5:56 sm0ke: a weird thing would be to deliver an Exception

5:56 CookedGryphon: or something else which tells you to stop waiting

5:56 you're still delivering a value, that value is just "no value"

5:56 sm0ke: 'hollow promises'

5:56 lol

5:57 CookedGryphon: then yeah, have whatever you do with it in a (when-let [value @p] ...)

5:57 or something

5:58 sm0ke: hmm if just dont deliver a promise, and there is no one derefing it it should be garbage collected right

5:58 right?

5:59 ugh

5:59 CookedGryphon: I would guess so..?

6:17 sm0ke: how do i asynchronously execute a function after t time

6:19 clgv: sm0ke: no. just if there is no reference to the promise (or the referencing entity of the promise) anymore the it is garbage collected

6:20 sm0ke: ok

6:20 makes sense

6:21 just how java gc works i guess

6:23 Southy: TimerTask and Timer java interop will let you do async scheduled tasks

6:23 sm0ke: yea was thinking the same

6:24 but its a bit more effort i would have to proxy TImerTask

6:24 Southy: any idomatic way?

6:24 simple

6:24 clgv: sm0ke: there are clojure libs for timed events

6:24 sm0ke: i saw this at at

6:24 but seems outdated

6:25 clgv: sm0ke: http://clojurequartz.info/

6:25 sm0ke: pulling in quartz for one time scheduling is overkill

6:26 CookedGryphon: I use at-at for one time scheduling

6:26 (x seconds in the future etc)

6:26 and schejulure for cron-job style tasks

6:26 sm0ke: hmm i guess a macro around Timer and TimerTask would be more simple

6:26 and performant

6:26 clojurebot: Excuse me?

6:27 CookedGryphon: clojurebot disagrees

6:27 sm0ke: haha

6:27 ?

6:27 ??

6:27 lazybot: sm0ke: Definitely not.

6:27 sm0ke: easter eggs!

6:28 CookedGryphon: anyway, at-at is fairly simple and performant, I'd just use that

6:28 alew: quartzite is really hacky if you want persistent stores

6:29 Southy: looking at source for at-at, it is using java.util.concurrent.ScheduledThreadPoolExecutor which has good perfomance and is great if you want to add in more than 1 scheduled execution

6:31 sm0ke: i doubt its better than TimerTask though

6:31 i mean its meant to be used for scheduling right

6:32 and iirc a Timer can have multiple timer tasks

6:32 so its must be using a threadpool as well

6:33 well http://docs.oracle.com/javase/7/docs/api/java/util/Timer.html mentions its uses same thread pool

6:33 well not really!

6:33 hmm it seems it advises to use java.util.concurrent.ScheduledThreadPoolExecutor instead

6:33 :P

6:35 at-at it is then

6:36 CookedGryphon: if your needs are very basic, then just using scheduledThreadPoolExecutor directly isn't very painful

6:36 but if you're going to start writing wrappers to hide the java calls, just use at-at

6:37 sm0ke: oh and Timer seems to be singlethreaded too

7:10 with clojure i find myself spawning threads by putting a (thread) form in a namespace.

7:10 si14_: how do you profile "lein repl"?

7:10 sm0ke: is this an antipattern for librariies?

8:08 darthdeus: how can i tell lighttable to stop "processing" when it constantly shows this thingy? http://i.imgur.com/a70VRqY.png

8:17 expez: after running cider-jack-in a repl is started which major mode is nrepl-repl-mode. It should be cider-repl-mode, right?

8:18 canassa: darthdeus: I think there is a command for stoping it when it get stuck

8:20 shock_one: Is there a site like clojuredocs, but up to date?

8:23 clgv: si14_: what do you want to profile?

8:23 si14_: runtimes of evaluations you do in the repl?

8:24 si14_: clgv: no, repl loading itself. it ends with timeout after every "lein clean"

8:24 *ends with timeout once, than starts on second try

8:24 darthdeus: i think there's a bug in luminus ... the sample app returns Content-Length: 4

8:24 clgv: si14_: according to technomance the time consumed by "lein help" is an upper bound for "lein repl"

8:24 darthdeus: even though there's shitton of html

8:25 clgv: si14_: or phil hagelberg ;)

8:26 si14_: if you use :aot that is probably not true

8:26 si14_: clgv: yes, but in my (arguably large) project it's not the case :) yes, I'm using AOT for one of namespaces

8:28 clgv: si14_: well so the runtime is aot dominated. you can use "lein compile" and profile that one with linux tools

8:28 si14_: "time lein compile" should work

8:30 si14_: clgv: it's very slow even after prior "compile". lein repl takes ~35 seconds compared to 8 for lein help

8:32 clgv: si14_: well it also depends on how many namespaces have to be loaded - I assume there are many reference (at least transitively) in your :main namespace

8:35 si14_: clgv: with empty :main namespace it's down to ~18secs, thank you. still ~2x larger than "lein help"

8:47 hyPiRion: si14_: there is some work in progress to speed up `lein help`, although I'm not sure whether it would decrease repl times

8:47 See technomancy/leiningen#1403

8:47 lazybot: Speed improvement for the "lein help" command (with nicer code) -- https://github.com/technomancy/leiningen/pull/1403 is open

8:48 clgv: si14_: do you see output whether it recompiles the namespaces?

8:51 mdrogalis: hyPiRion: Yay profiles update. Thanks :)

8:59 si14_: clgv: no, I don't (not after "lein compile" at least)

8:59 clgv: si14_: on different projects of mine: 9 sec, 6sec - on a pretty large with aot due to :main 29sec

9:00 hyPiRion: mdrogalis: np =)

9:00 si14_: clgv: stange. I've tried VisualVM during startup, but the output of it's sampler makes no sense to me

9:00 clgv: si14: 9sec on the large one after compilation was done once

9:01 si14_: you probably want instrumentation

9:01 * si14_ clgv: what do you mean?

9:01 si14_: (sorry for erroneous /me)

9:01 clgv: si14_: "time lein help" => 7.7sec

9:02 sI14_: in profiling you usually have "sampling" and "instrumentation"

9:03 si14_: the latter really writes down information about every single function invocation, often only for previously specified functions to avoid too much overhead

9:03 * si14_ clgv: ah, I see. Thank you!

9:03 si14_: argh. hate this feature of irccloud

9:12 jballanc: anyone know a relatively easy way to do "not-listo" in core.logic?

9:33 dnolen: jballanc: you could probably do it with the nafc constraint

9:33 nafc + project + seq? predicate

9:34 clgv: jballanc: "not" in logic programming is often done via explicit failing - afair from prolog

9:36 jballanc: dnolen: for some reason all those combinations I tried, but couldn't get quite what I want :-/

9:36 it's ok, though, I think I've found a place where conda is actually useful :)

9:37 I'm trying to write an explicit flatten goal

9:37 dnolen: jballanc: it's a hard problem we inherit from a prolog like model

9:37 jballanc: yeah, my problem was finding the right base case

9:38 the base case for an already flattened list duplicates the base case for a singly nested list

9:38 but if I use conda to check the singly nested list first, things seem to work

9:40 btw, the "flatteno" in the core.logic tests doesn't make sense to me...seems to match any degree of flattening?

9:41 ...including none?

9:42 dnolen: jballanc: it's just the miniKanren one verbatim, I cannot attest to it usefulness

9:42 jballanc: ah, ok

9:42 dnolen: jballanc: we've included a lot of things from The Reasoned Schemer as it's still a good source of information

9:43 jballanc: and you can work through it easily with core.logic

9:43 jballanc: yeah, now I just need to get a hold of a copy ;-)

9:43 dnolen: jballanc: for 0.9 I'm probably going to do a pretty serious reorg so that the library is laid out more sensible.

9:43 sensibly

9:43 and minikanren stuff will probably move back to a prelude namespace like it used to be

9:44 jballanc: that makes sense

9:44 if I manage to get this little project working maybe I'll have to blog about it...

9:45 I have a project with > 1000 Java class files and crazy mixed-up interdependencies

9:45 trying to use core.logic to split it into chunks of modules that can be compiled independently

9:45 ...so that I don't need 2+ GB RAM for the build! :P

9:51 teslanick: Perhaps of mild amusement to #clojure - Yesterday I implemented PersistentVector in javascript: https://gist.github.com/nhusher/4ec5c83a263fb5ec2fe9

9:52 * FiLoSsOfIe ce fac puturosiiiiii ?

10:06 clgv: teslanick: did you compare it to the implementation of clojurescript performancewise?

10:06 si14_: dnolen: what was the reasoning behind negation-as-failure? can't properly wrap my head about this. it seems that negation works in FOPL and can be computed efficiently via resolution.

10:06 dnolen: doesn't it?

10:08 avshalom: hi all, is there anything wrong with nested pmaps? e.g. (pmap f1 (pmap f2 list)) Will this work as I hope it does: dishing out work to all the processors, allowing the inner and outer pmaps to maximally saturate the cpus?

10:08 teslanick: clgv: I haven't - I was mostly cargo-culting my way through the PersistentVector class file to see how it works.

10:09 avshalom: i am wondering if the inner pmap has to "materialize" before the outer one will execute

10:12 augustl: avshalom: never used pmap, but if it's like map, it's lazy, so it will run f2 then f1 on the first item first, not f2 on all items in list then f1 on all items in list.

10:14 llasram: avshalom: `pmap` is sometimes convenient for quick-and-dirty parallelization, but doesn't have anything explicit to nicely handle nested or otherwise concurrent pmaps

10:14 augustl: avshalom: ....I think

10:14 llasram: avshalom: Your best bet is to use Clojure 1.5's reducers library with `fold`

10:15 That'll use a fork-join pool to intelligently run any degree of nested computation in parallel

10:18 logic_prog: why don't people just use erlang? :-)

10:18 stuartsierra: avshalom: `pmap` is fairly naive, but it will help spread the work over multiple CPUs for simple cases.

10:18 clgv: avshalom: pmap uses futures and is semi-lazy

10:18 augustl: why does (first (filter #(do (println %) (> % 1)) [1 2 3])) print 1 2 3? I expected it to print 1 and 2, and then stop since first doesn't need to consume the lazy list anymore

10:19 stuartsierra: clojurebot: chunking?

10:19 clojurebot: No entiendo

10:19 stuartsierra: augustl: Chunked sequences. It's a performance optimization, some lazy seqs evaluate 32-at-a-time.

10:19 augustl: stuartsierra: Just tried on (range 0 100) after your clojurebot query, and it only printed to 31 :)

10:20 stuartsierra: for fewer nonliner allocations I suppose?

10:20 avshalom: thanks for the info. I will research your responses

10:20 stuartsierra: Yes. Chunked Seqs can allocate arrays of 32 elements instead of 32 linked nodes.

10:21 augustl: stuartsierra: cool, thanks for the info!

10:21 stuartsierra: np

10:23 augustl: was a little worried there for a sec, I've been using (first (filter ...)) as an example of the composability of lazyness (no need to write a separate find-first)

10:24 katox: did anyone have problems with prn (with enable-console-print!)?

10:24 dnolen: si14_: you need to look at Prolog

10:24 si14_: we have a Prolog model and we inherit the same problems

10:24 augustl: logic_prog: something something always using message passing something something!

10:24 katox: the output seems somewhat unreliable in my code while (.log js/console ...) is always there

10:24 si14_: dnolen: yeah, I mean, what was the reasoning in Prolog :)

10:24 stuartsierra: augustl: In general, combining lazy seqs with side effects leads to unexpected results.

10:24 dnolen: si14_: let me google that for you :)

10:25 augustl: stuartsierra: the docs for "filter" says pred shouldn't have side-effects. Is that a style thing, or a technical reason?

10:25 * si14_ dnolen: I know that it's "natural" to introduce NAF in Prolog to negate things. I just don't understand why it can't be explicit, as in FOPL

10:25 augustl: I'm guessing it's more that you shouldn't rely on anything other than this fn being called with a value. No ordering of the call to pred etc etc.

10:26 si14_: (sorry for erroneous /me)

10:26 dnolen: si14_: just read up on Prolog style resolution you'll see why it's hard.

10:27 si14_: dnolen: but there is "resolution" as in FOPL and it works (AFAIK answer-set programming is similar), doesn't it?

10:27 stuartsierra: augustl: It's because of chunking.

10:27 dnolen: si14_: "works"

10:27 si14_: efficiency

10:28 si14_: dnolen: you mean exponential complexity?

10:29 stuartsierra: augustl: All the higher-order seq functions are meant to be used with pure functions. Use doseq, dorun, or doall to introduce side effects.

10:32 katox: the prn snippet: https://www.refheap.com/22564

10:33 if I change prn to (.log js/console ...) it seems to work fine

10:34 any ideas?

10:43 andyf: Bronsa: ping

10:43 Bronsa: andyf: pong

10:52 andyf: Sorry, got interrupted there. I think the recent trim changes you made to t.a(.j) cause ASTs to be created that leave out some expressions in some cases.

10:53 I guess a TANAL ticket with test case would be in order.

10:53 Bronsa: what do you mean? (let [a 1 b 2] (do 3 4)) => 4 is intentional

10:54 andyf: Bronsa: As in, you are intentionally doing simplifications in the analyzer as a sort of early compilation step?

10:55 Bronsa: And this is new behavior with recent changes?

10:57 Bronsa: I ask because a test case that was previously detecting a misplaced docstring no longer detects one, because the misplaced docstring isn't in the ast. It isn't all cases, just one where there are multiple methods defined for the fn.

10:57 Bronsa: andyf: oh, I see why this might be a problem for eastwood

10:58 andyf: Bronsa: I am guessing this might be an optional step I could leave out when using t.a(.jvm) from eastwood?

10:59 Bronsa: andyf: well, it's explicit in the docstrings that the passes run by default on the AST are to produce an AST for tools.emitter.jvm

11:00 andyf: Bronsa: That makes sense, and I don't want to change that goal. I am just hoping we can also perhaps support a subset of the passes that do a bit less.

11:00 Bronsa: andyf: yes, it seems reasonable.

11:00 andyf: Bronsa: I am happy if that subset of passes is in Eastwood, not t.a(.jvm) code.

11:04 Bronsa: andyf: it's simply a matter of copying run-passes removing the trim pass, it's probably easier if that's done on the eastwood side right now

11:04 andyf: Bronsa: Sounds good. I will give that a try and let you know if I have any troubles.

11:05 On the plus side, I may be close to getting the changes into eastwood so it analyzes subforms of top-level do's separately, so simple-check and other code that uses it should work (among other things).

11:05 Bronsa: andyf: while you're at it, you can probably leave out the collect & clear-local passes since I don't think eastwood needs any of that information

11:06 pepijndevos: wtf: ClassCastException clojure.data.avl.AVLNode cannot be cast to clojure.data.avl.IAVLNode

11:07 Bronsa: pepijndevos: a classloader issue maybe?

11:07 andyf: pepijndevos: Bronsa: I have seen that when running Eastwood on data.avl. I haven't tracked down the cause yet.

11:07 pepijndevos: probably. The fn has a lot of typehints. Removing those solves it

11:08 andyf: Most likely a problem in Eastwood, not data.avl

11:08 Bronsa: andyf: I know, it's not a problem in data.avl

11:08 pepijndevos: It has some fancy interface generation going on

11:09 Bronsa: andyf: I'd think the recent change in the ns lint order should have fixed that

11:10 andyf: I've seen errors where ClassCastException some.Class cannot be cast to some.Class, that's caused by the out-of-order ns evaluation

11:12 andyf: Bronsa: OK. Like I said, I have only noticed them, but haven't tried to investigate the cause yet.

11:12 Bronsa: I still see them after the dependency order changes went in.

11:13 vdmit11: Does referencing a keyword create any objects? Are there any objects created during invocation of this function: #(= % :keyword) ?

11:14 Bronsa: andyf: weird, there might be something more going on that I haven't considered then

11:14 gfredericks: vdmit11: I can't imagine so

11:15 pepijndevos: gfredericks, vdmit11 the keyword has to live somewhere right?

11:15 Bronsa: pepijndevos: it's interned at compile time

11:15 vdmit11: pepijndevos: yep, but is the keyword created only once or a new instance is created on every call of the function?

11:16 pepijndevos: Bronsa, what does interned mean?

11:18 Bronsa: pepijndevos: the first time a keyword is encountered, a new instance is created and put in a table, when it's encountered again instead of creating it again the same instance is used.

11:18 pepijndevos: Bronsa, right, so if I enter :foo in the repl. a new keyword is created

11:18 provided I never used :foo before, which is unlikely :P

11:18 Bronsa: yes

11:19 vdmit11: Bronsa: thanks

11:19 Bronsa: actually, it looks like a new keyword is created every time https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Keyword.java#L36

11:20 but anyway, if it's in a function that gets done only once in the static initializer

11:24 vdmit11: then, another question; consider the code: (let [foo 1] (defn get-foo [] foo)) Are there any instances created during when I invoke (get-foo)?

11:24 Bronsa: no

11:26 vdmit11: because foo is resolved during defn evaluation and then (get-foo) always returns the same object?

11:31 pepijndevos: I'm struggeling with binery tree search :( I'm trying to implement NavigableMap on top of it.

11:32 It's not hard to write a specific case, like floor for a tree sorted by the default comparator.

11:32 But I'm trying if it's posisble to write one function that takes the comparator of the tree and a predicate.

11:32 gfredericks: vdmit11: right

11:51 stuartsierra: vdmit11: You can use the `identical?` function to test if things are the same object.

11:59 CaptainLex: What'

11:59 s preferred case style for Clojure? Is it train-case?

12:00 jcromartie: lisp-style-is-like-this

12:00 stuartsierra: CaptainLex: The most common convention is hyphens-for-locals-and-functions, CamelCaseWithInitialCapital for protocol/record names.

12:01 CaptainLex: Thought so. I'm slipping haphazardly between that and CamelCase in this project. I'll weight the hyphens for the future!

12:01 Thanks!

12:15 mikerod: train-case?

12:15 never heard that, I thought of it as kebab-case

12:15 especially after seeing https://github.com/qerub/camel-snake-kebab

12:18 jcromartie: Enlive is really shaping up to be a boon for our development process.

12:19 our UI designs get folded into the working app faster than I've ever seen

12:19 dnolen: CaptainLex: I like to use CamelCase only for types, records, and protocols, everything else hyphens

12:22 TimMc: clojurebot: kebab-case is ⟜better-with-unicode-

12:22 clojurebot: Roger.

12:22 jcromartie: kebab-case?

12:22 clojurebot: kebab-case is ⟜better-with-unicode-

12:22 jcromartie: clojurebot deals admirably with unicode

12:23 TimMc: That's like saying "Bob is amazingly good at not punching random strangers."

12:23 it's kind of a baseline

12:24 jcromartie: hah

12:25 rasmusto: CamelCase?

12:26 hansel-han: jcromartie: I just started playing with Enlive after a full year of Hiccup-everything. (Not that Hiccup-to-represent-html is an incompatible alternative) But I'm really liking this concept of transforming a tree to render templates

12:26 logic_prog: whoa

12:26 we're tlaing POPL papers in clojure ?

12:27 justin_smith: logic_prog: tla is the best tla

12:27 logic_prog: what is tla?

12:27 justin_smith: it's a tla!

12:28 http://en.wikipedia.org/wiki/Three-letter_acronym

12:29 logic_prog: popl = premier conference on programming languages

12:29 justin_smith: fla

12:29 logic_prog: wtf is fla?

12:29 abc

12:29 thk

12:30 wow; so tla; much #$%; many ???

12:30 lazybot: logic_prog: Oh, absolutely.

12:30 justin_smith: logic_prog: four letter acronym, of course

12:30 not to be confused with fla, five letter acronym

12:31 TimMc: ETLA, Extended Three-Letter Acronym

12:31 justin_smith: nice

12:31 TimMc: ^ from Wikipedia. Learned something today.

12:31 bbloom: dnolen: ThisCaseStyle is called PascalCase, camelCaseIsLikeThis

12:31 dnolen: bbloom: right I always forget the actual name

12:31 bbloom: dnolen: remember that a camel has humps on his back, not on his head :-P

12:31 technomancy: but... camels have heads

12:31 dnolen: haha

12:31 technomancy: this terminology is zoologically troublesome

12:32 TimMc: your face is zoologically troublesome

12:32 technomancy: oh snap!

12:33 TimMc: >all^i^g^a^tor^ca^se

12:34 TEttinger: վ vs. U

12:35 armenian all the things!

12:35 TimMc: 'ARMENIAN SMALL LETTER VEW' (U+057E)

12:35 TEttinger: vev or vew

12:36 I wonder if there's a way to fetch the unicode info the JVM knows about a char

12:38 TimMc: j.l.Character doesn't seem to help...

12:38 justin_smith: http://docs.oracle.com/javase/6/docs/api/java/lang/Character.html I am not finding much here

12:39 ahh, java 7 has getName

12:39 logic_prog: someone needs to create hackernews for clojure

12:39 people can post code snipplets

12:40 justin_smith: ,(Character/getName (int\a))

12:40 clojurebot: #<CompilerException java.lang.IllegalArgumentException: No matching method: getName, compiling:(NO_SOURCE_PATH:0:0)>

12:40 jjl`_: java.lang.ClassFormatError: Invalid method Code length 67858 in class file << what on earth does this mean?

12:40 TimMc: &(java.lang.Character$UnicodeBlock/of 0x57e)

12:40 lazybot: ⇒ #<UnicodeBlock ARMENIAN>

12:40 justin_smith: ,(System/getProperty "java.version")

12:40 clojurebot: #<SecurityException java.lang.SecurityException: denied>

12:40 TEttinger: jjl`_, I have gotten that

12:41 when you make incredibly huge literals, it results in that

12:41 here

12:41 jjl`_: i have no incredibly huge literals

12:41 TEttinger: hm

12:41 pastebin?

12:41 https://dl.dropboxusercontent.com/u/11914692/weapons-map-too-large.clj is too big to load, for example

12:41 https://dl.dropboxusercontent.com/u/11914692/weapons-map.clj but this works

12:42 gfredericks: runaway macros can give that error

12:42 jjl`_: TEttinger: https://github.com/jjl/mapmapper <- here, it's open source. i just pushed

12:43 TEttinger: using midje for tests. the broken test is mapmapper.sql.transform_test

12:44 gfredericks: this gives an error I haven't seen before: (eval `(apply + [~@(range 100000)]))

12:44 "Invalid this class index 3171 in constant pool in class file"

12:44 justin_smith: ,(Character/getName (int \☃))

12:44 clojurebot: #<CompilerException java.lang.IllegalArgumentException: No matching method: getName, compiling:(NO_SOURCE_PATH:0:0)>

12:44 TEttinger: I wonder if that second facts fn, when macroexpanded, is too large

12:45 justin_smith: &(Character/getName (int \☃))

12:45 lazybot: java.lang.IllegalArgumentException: No matching method: getName

12:45 justin_smith: bleh, no java 7 on either bot :(

12:45 jjl`_: TEttinger: you mean just break it out into two?

12:45 justin_smith: works locally with java 7

12:45 TEttinger: I'd try it, jjl`_.

12:46 it could be a runaway macro, like gfredericks said

12:46 jjl`_: yeah, splitting it appears to work

12:47 that's quite annoying though

12:47 hiredman: yet another data point confirming my decision to avoid midje

12:48 justin_smith: hiredman: what's that (I avoid it already but am morbidly curious)

12:49 hiredman: justin_smith: whatever jjl`_ is dealing with

12:49 logic_prog: dnolen: you run http://swannodette.github.io/ right?

12:50 jjl`_: hiredman: i very much like midje. the autotest functionality saves me so much time it'd be worth putting up with a LOT of rap

12:50 dnolen_: logic_prog: yes

12:50 logic_prog: dnolen: okay good, I need to sue you for violating one of my patents

12:50 dnolen: I'm kidding, but can you please write more blog posts ?

12:50 dnolen: they're really insightful, and I'd like to learn more from them

12:51 dnolen_: logic_prog: heh, they take a ridiculous amount of time to do

12:51 hiredman: jjl`_: sure, saving you time, which you can then spend on irc asking about why it doesn't work :)

12:51 dnolen_: logic_prog: I think 1-2 posts a month is about all I can really do

12:51 jjl`_: hiredman: i was going to be on irc anyway... also, more importantly, testing got a lot less tedious. that alone is worth using it for

12:51 * technomancy makes a weekly reminder to rant about how terrible it is that everyone reinvents autotest for themselves instead of making one proper higher-order task

12:52 dnolen_: logic_prog: if you want more just look at the related repos and ask me questions here or in #clojurescript

12:52 jjl`_: in any case, on balance, i'm very happy with having moved to midje a couple of days ago

12:53 Bronsa: wtf.

12:54 logic_prog: dnolen_: so after reading your om/react blog posts, I went off and wrote a variant of react (without the key part of tree matching) in pure cljs (well, cljx) -- and it also has the "time travel" feature you mentioned

12:54 dnolen_: I think part of the problem is that I don't know *xyz* is possible until I read it on the blog post

12:54 dnolen_: for example, I didn't realize the power of core.async until I read the async posts

12:54 dnolen_: and I didnt' realize the idea of "virtual dom" until reading the react/om posts

12:55 dnolen_: as in part of th eproblem is *where to look* rather than *undersgatnding what is looked at*

12:55 dnolen_: that I think is what I really like this series of blog posts -- the choice of topics and how concisely theyre explained

12:55 CaptainLex: Whoa, did I just miss a netsplit?

12:55 logic_prog: dnolen_: to mix criticism with praise, the STLC posts are rather weak though

12:56 justin_smith: CaptainLex: freenode has been weird for me lately

12:59 dnolen: logic_prog: yeah, I didn't really get to finish that line of thought

13:00 logic_prog: dnolen: can you write a series of blog posts on lein middleware? :-)

13:01 dnolen: I've been trying to read up on it, but there seems to be almost no documentation

13:01 dnolen: I think it'd really benefit the clojure ide community if people started ahcking on middleware for fun

13:01 jjl`_: logic_prog: writing thereof?

13:01 logic_prog: jj`_: ?

13:01 dnolen: logic_prog: I will probably never write any such thing :)

13:01 logic_prog: dnolen: why not?

13:01 jjl`_: logic_prog: you'd like to see docs on how to write middleware?

13:02 logic_prog: jjl`_ : yes

13:02 dnolen: logic_prog: I'm not really interesting the talking about the in/outs of lein and it's documented elsewhere

13:02 logic_prog: technomancy: hmm, do you blog? ^^

13:03 technomancy: logic_prog: yes, but I kind of don't want more people using lein middleware

13:03 jjl`_: logic_prog: there's quite a lot of pre-written stuff to look at and learn from :)

13:03 logic_prog: technomancy: why not?

13:03 jjl`_ : can you point me to a good example on github?

13:03 jjl`_ : I was trying to get cljx lein middleware to work, but I couldn't find documentation

13:03 technomancy: if I blog soon about lein it'll be about how people need to stop writing plugins for one-off things and just use aliases to lein run

13:04 logic_prog: because middleware can do crazy things that are difficult to debug, as your current problem seems to indicate

13:04 jjl`_: logic_prog: first result on duckduckgo for "leiningen middleware" seems like a sane one https://github.com/dchelimsky/lein-expand-resource-paths

13:04 technomancy: if you have a problem that can't be solved without middleware, we should talk

13:05 logic_prog: cemerick: you wrote cljx + lein's cljx middleware right?

13:05 technomancy: noted, I will go bother cemerick now

13:05 technomancy: because it means we're missing some functionality in lein

13:05 middleware is there in case you need to get stuff done before we can get around to fixing lein

13:05 logic_prog: cemerick: see what technomancy is saying? :-) why does cljx need lein middlware?

13:05 cemerick: logic_prog: the Next Generation of it, yeah

13:06 jjl`_: in fact, that particular middleware would have made me less annoyed at lein a few weeks ago

13:06 cemerick: logic_prog: it probably doesn't. cljx was written before I (mostly?) understood what prep-tasks was for.

13:06 logic_prog: cemerick: can you put up a site where we can donate dogecoins for you to finish the next generation of cljx sooner?

13:06 cemerick: logic_prog: what's missing from it?

13:07 actually, gh-24 is not complete, but that's the only item I'm aware of

13:07 logic_prog: cemerick: I start lein not via "lein repl", but via ... let me pull up the code ... I'm not sure how to get cljx to integrate with it

13:08 cemerick: I start my nrepl server cia "(clojure.tools.nrepl.server/start-server :port 3001)"

13:08 cemerick: how can I fix that so that I can send a cljx reload-file to my nrepl server?

13:08 (i.e. ahve hte #+clj and #+cljs macros be processed)

13:09 cemerick: la slightly better rewrite. (1) I start nrepl with (clojure.tools.nrepl.server/start-server :port 3001) (2) I connect via emacs with M-x nrepl <cr> 3001 <cr> (3) I want to be able to send an entire *.cljx buffer to my nrepl

13:09 Question: what do I need to do to the way I start nrepl, to hook in cljx, so that the #+clj and #+cljs macros are properly handled?

13:09 cemerick: does my question make sense, or is it still a mess?

13:11 cemerick: logic_prog: You need to have cljx on the classpath, and include its middleware in your start-server call

13:11 logic_prog: cemerick: is there an half-working gist I can copy/paste code from?

13:11 cemerick: does this mean I need to add cljx as a _dependencies_ rather than a _plugins_ ?

13:12 cemerick: logic_prog: its plugin will add itself as a project dependency automatically

13:14 logic_prog: cemerick: can you take https://gist.github.com/anonymous/8303836 and fix it ? :-)

13:14 cemerick: it'll hopefullyt ake you < 5 mins, and I can learn from dissecting how it works

13:16 rasmusto: does cljs not like my-ns.foo hyphens?

13:16 cemerick: logic_prog: No gist. See the docstring here (https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L114); something like (start-server :handler (default-handler #'cljx.repl-middleware/wrap-cljx))

13:17 logic_prog: nope, sorry, busy. Teach someone to fish, etc. :-P

13:17 dnolen: rasmusto: should work fine

13:17 rasmusto: but on disk you need _

13:17 my_ns/foo.cljs

13:17 logic_prog: cemerick: trying to get this to work .... let's see

13:18 rasmusto: dnolen: ah, I'm guessing that's for index.html too, I think that's my problem

13:18 dnolen: rasmusto: yep

13:18 rasmusto: dnolen: awesome, thanks. I'll get back to om-fun.core then :>

13:18 dnolen: rasmusto: sweet!

13:20 logic_prog: cemerick: in order to use that line, I needed to add (:require [cljs.repl-middleware]), which, unfortunately, cuases a :

13:21 cemerick: Exception in thread "main" java.lang.RuntimeException: No such var: readers/source-logging-push-back-reader, compiling:(cljs/repl.clj:205:21)

13:21 cemerick: logic_prog: you're using a too-old version of ClojureScript and/or an explicit older version to tools.reader

13:21 logic_prog: cemerick: okay, let me try to fix that

13:22 cemerick: cljs was on 0.0-2120, trying 0.0-2138 now

13:23 cemerick: taht did not fix it, upgrading tools.reader from 0.7.10 to 0.8.4-SNAPSHOT now

13:24 dnolen: cemerick: I see you've come around to source maps

13:24 logic_prog: cemerick: i can start the server now. let's see if emacs connections actually work

13:25 cemerick: dnolen: was never against ;-P

13:25 logic_prog: cemerick: it appears to work now

13:25 cemerick: thanks for all your help with debugging

13:25 dnolen: cemerick: I so want a ClojureScript Chrome Dev Tools nrepl thing, that + source maps would just be so awesome

13:26 cemerick: logic_prog: glad it panned out :-)

13:26 logic_prog: cemerick: the initial line + pointers to upgrading cljs/tools.reader were really key

13:26 dnolen: I want that too (am using chrome + clojurescript). unlike me, you have talent, please write it :-)

13:26 dnolen: we'll be willing to lose 1 months worth of blog posts in exchange for it

13:27 dnolen: logic_prog: well considering how many other people works on source_maps who weren't familiar w/ the compiler I sure you can find a place to pitch in too.

13:27 s/works/worked

13:27 cemerick: dnolen: if you can write devtools extensions in js, then the path is clear. Though, what would having the REPL in devtools get you over a regular brepl?

13:27 dnolen: cemerick: evaluation in stack frame

13:28 cemerick: ah

13:28 si14_: dnolen: is it possible to add renderToString into Om?

13:28 dnolen: si14_: open an issue

13:29 si14_: dnolen: I'm playing around using Rhino to render the page, but I can't do it without it. I've tried to fake DOM for some time, but this wasn't successful.

13:30 *without renderToString

13:30 dnolen: si14_: we need it, open an issue I will add it and it'll appear in the next release

13:30 si14_: dnolen: ok, just wasn't sure that it worth an issue :)

13:31 cemerick: dnolen: it'd be nice to see if the existing brepl client-side stuff could be hoisted up into that environment when necessary, so all existing tooling could benefit. I don't fancy the notion of setting up whole separate compilation pipelines when there's already one sitting right there.

13:32 si14_: dnolen: done

13:33 cemerick: dnolen: oh, OT, unsigned-bit-shift-right needs to be added to the :refer-clojure :exclude in cljs/core.clj

13:33 dnolen: cemerick: ah right

13:34 cemerick: yes I think it should be able to hook to existing running brepl

13:34 cemerick: it's only to be able to eval and set namespace, everything else is gravy

13:34 si14_: thanks

14:09 katox: hmmm, the prn issue seems to point down to dynamic bindings

14:09 pandeiro: <dnolen> cemerick: I so want a ClojureScript Chrome Dev Tools nrepl thing,

14:09 that + source maps would just be so awesome <-- amen

14:09 katox: dnolen: is it supposed to be safe to use dynamic bindings with core.async?

14:10 dnolen: katox: not in ClojureScript yet, it works in Clojure

14:10 pandeiro: chrome, not content to be just a browser, or just an OS, is close to being a web dev IDE

14:11 katox: dnolen: I see, that must be the source of the prob here: https://www.refheap.com/22564

14:11 dnolen: that's missing in cljs?

14:11 stuartsierra: Oh darn, and here I was hoping core.async would finally kill dynamic binding. :P

14:11 technomancy: laziness already killed most dynamic binding

14:11 dnolen: katox: not just missing, how to convey binding properly in CLJS is a big open question

14:11 katox: don't expect it to work anytime soon

14:12 pjstadig: dynamic binding has its uses

14:12 katox: I don't really use it ... just bumped into this bug

14:12 So I investigated it more and it pointed me to dynamic bindings.

14:15 stuartsierra: are there any real alternatives? I'm aware of threading probs

14:16 stuartsierra: in most of my code I just pass some kind of ctx explicitly (not super nice)

14:16 stuartsierra: Dynamic binding is useful where true thread-local behavior is desired.

14:17 Passing arguments explicitly is more reliable and easier to understand.

14:17 tbaldridge: but most of the time, thread bindings are used when you want just don't want to refactor your code :-P

14:17 *when you just don't want to refactor...

14:17 jcromartie: we're having that very same argument

14:17 there's nothing simpler than an argument to a function…

14:17 stuartsierra: Frankly, I consider code which relies on binding conveyance across threads to be broken.

14:18 tbaldridge: stuartsierra: although that becomes a bit more of an issue in core.async where different parts of your fn could be run on different threads

14:18 jcromartie: you can always turn a bunch of arguments into a big map :P

14:19 stuartsierra: tbaldridge: Right, you shouldn't be using dynamic binding in that case.

14:19 jcromartie: we're trying to figure out the best way to handle the many *many* disparate services our app is using

14:19 we have a database and at least four other external APIs

14:20 and so going the argument route is just not working because while we have those 5 services now, it could be 6 next week

14:20 stuartsierra: jcromartie: https://github.com/stuartsierra/component

14:20 jcromartie: stuartsierra always has an answer

14:20 stuartsierra: Or at least a glib response :)

14:20 jcromartie: it's not really runtime state for the external APIs though

14:21 katox: stuartsierra: I'd expect namespaces to be something like this

14:21 stuartsierra: reloadable, discardable, with deps

14:21 tbaldrid_: katox: nah, namespaces should just be spaces for names

14:21 stuartsierra: ^ What tbaldridge said.

14:22 etehtsea: how can I test library under clojurescript?

14:22 I mean crosstesting for library that supports clojure & clojurescrupt

14:23 katox: tbaldridge_: that doesn't mean to be mutated all day along

14:24 tbaldridge_: katox: I'm not sure I understand, you just said that namespaces should be a place where you stick DB state. Or did I mis-read your comments?

14:25 katox: tbaldridge_: aw, didn't mean that ... that's too far fetched ;)

14:26 tbaldridge_: what I meant was that ns could be loaded as sort of objs with dependencies

14:26 tbaldridge_: unlike mutable top level globals

14:27 TimMc: katox: What you're talking about, I think, is "instancing" namespaces.

14:27 or whole libraries

14:28 technomancy: parameterized namespaces?

14:29 stuartsierra: It comes up from time to time (see http://tech.puredanger.com/2013/11/19/state-of-clojure-language-features/) but isn't likely to happen.

14:30 technomancy: if there were a way to bootstrap an ns equivalent macro it could be done outside the language

14:30 or if there were a way to use non-core functions in ns clauses

14:30 which is more reasonable and would be great in and of itself

14:30 TimMc: Or on the other end of things, I guess you'd have to alter var resolution/

14:30 tbaldridge: So how do you solve the problem where module A loads foo<int> and module B loads foo<float>, would those end up being two completely different namespace instances?

14:31 technomancy: tbaldridge: sure

14:31 stuartsierra: technomancy: Why the need for arbitrary ns clauses, when you can put arbitrary code at the top level of a file?

14:31 technomancy: stuartsierra: because that's hideous

14:31 stuartsierra: Ah, aesthetics.

14:31 tbaldridge: technomancy: like require?

14:32 I guess that comes after the ns is created, nvm

14:32 technomancy: also because lots of tooling reasonably requires ns to be the first form in a file

14:32 * TimMc hides his use of .importClass from technomancy

14:32 technomancy: ~guards

14:32 clojurebot: SEIZE HIM!

14:32 hiredman: tbaldridge: you use the existing namespace system to bootstrap a more full featured module system

14:33 (module foo) would create some randomly named ns and know how to map the foo in (module bar :requires foo) to the random name

14:34 pepijndevos: Does a function have its name on it, or only the var?

14:34 katox: hiredman: sounds like nix (http://nixos.org/nix/)

14:34 hiredman: sure

14:34 expez: How would you create a key to do lookup in a map based on the date? Use strings like "07-01-2014"?

14:35 hiredman: (module foo :parameters [A B C]) (module bar :requires (foo int float double)) or something

14:35 TimMc: expez: Maybe use JodaTime dates?

14:36 I wouldn't trust j.u.Date for that

14:37 hiredman: TimMc: pretty sure he is asking because he comes from a place where you can only have certain things as keys (like strings) not because he doesn't trust Date

14:37 TimMc: ah

14:37 expez: TimMc: Would it even work to use j.u.Date? That was my first thought, but it has millisecond resolution which would make it hard to lookup the keys?

14:37 ToBeReplaced: expez: you could (pr-str (Date.))

14:37 TimMc: expez: So you want to bucket the dates to a certain resolution, then.

14:37 ro_st: dnolen: om is looking awesome

14:38 mdrogalis: Yeah, time slice them with multiple tiers.

14:38 expez: TimMc: I just want to do general lookup, like get me the entry for 01-01-1999, I only need resolution of days.

14:39 TimMc: Sure, so format them to YYYY-mm-dd or whatever.

14:39 You'll get some weird looks if you use formats like 07-01-2014, of course.

14:40 ToBeReplaced: expez: just use j.u.d with pr-str -- pr-str will print edn-flavored values like #inst{yadda} and then you're in data land

14:40 pepijndevos: How do you get "Returns the least key strictly greater than the given key, or null if there is no such key." from a binay serach tree?

14:40 TimMc: ToBeReplaced: That doesn't help with bucketing to the day level.

14:41 pepijndevos: I think there's a JDK 7 data structure that supports this.

14:41 ToBeReplaced: TimMc: you'd only have to bucket if someone created j.u.d's with hours/minutes/econds

14:41 TimMc: Fair.

14:41 ToBeReplaced: doesn't sound like his/her use case

14:41 pepijndevos: TimMc, definitely. Are you siggesting I look at the Java code? Fair suggestion.

14:42 expez: ToBeReplaced: doesn't all j.u.d have that resolution?

14:42 TimMc: pepijndevos: No, just that if you're on JDK 7 you may already have a data structure you can use that way.

14:43 pepijndevos: TimMc, I know, but I'm implementing it for AVL trees.

14:43 whilo_: dnolen: have there been attempts to implement https://github.com/webyrd/slpKanren with/in core.logic?

14:43 ToBeReplaced: expez: yeah, but you don't have to use it -- if you don't fill it in you just get zeros past year/month/day... similar to a DateMidnight

14:43 TimMc: pepijndevos: Ah, so this is a general algorithmic question.

14:43 not API

14:43 pepijndevos: yea

14:43 I figured it out for the inclusive case(floor, ceil)

14:44 expez: ToBeReplaced: aight, thanks

14:44 TimMc: Ah, I get it now -- with repeated keys you may need to iterate.

14:46 pepijndevos: No repeated keys here.

14:47 Oh, I know...

14:47 maybe

14:47 TimMc: (and by "repeated" I mean "neither greater nor lesser")

14:47 pepijndevos: oh

14:48 I think I'm not handling the 0 cse of compare correctly. Now I return the node if it matches the predicate, but it might need to descend further.

14:49 ro_st: dnolen: what problem is rhizome meant to solve?

14:51 pepijndevos: nowait, that's already to late. If I hit 0, I'm at the wrong node.

14:54 jtoy: is there a simple way to use a different version of a library from github? I just found a bug and i want lein to use my version instead

14:54 technomancy: jtoy: `lein install`

14:54 joegallo: :exclude the version you don't want, and add the version you do want

14:55 jtoy: technomancy: sorry, I mean just by pointing my projects.clj to github, I dont want to install the lib on every box

14:55 TimMc: jtoy: You may wish to republish the library to clojars with your fix, like org.clojars.jtoy/the-lib

14:56 that's a good way to use a bugfix fork

14:56 jtoy: ok, I'll try that

14:56 dnolen: ro_st: you want to render something that isn't in the app state that need component local state

14:57 whilo_: not that I'm aware of

14:58 ro_st: dnolen: aha

14:58 dnolen: ro_st: it's just a way to graft something onto the render tree, cause render is driven by data in app state

14:58 ro_st: what's missing from om, dnolen? what prevents us from using this to build real apps right now?

14:59 dnolen: ro_st: not much, a lot of big things are in, the api will likely change, the issues currently cover what I'm thinking about

15:00 ro_st: we've got a lot of cljs to build in the next while. i can't think of a better way to do it. been listening to that podcast. seems like a perfect match for persistent data structures

15:01 #js just runs whatever you tag through clj->js?

15:01 dnolen: ro_st: no, no conversions

15:01 ro_st: i've not kept up to date with the cljs announcements :-|

15:02 chronno: ro_st: Which podcast?

15:02 bbloom: ro_st: the #js is a shallow object or array constructor call

15:02 dnolen: ro_st: I would like Om to have more optimizations but what there isn't slow and I think there are enough hooks to optimize if you need it

15:02 jcromartie: ,(cycle ["maybe" "maybe not"])

15:02 clojurebot: ("maybe" "maybe not" "maybe" "maybe not" "maybe" ...)

15:02 jcromartie: that's how I feel

15:02 ro_st: http://javascriptjabber.com/

15:02 http://javascriptjabber.com/073-jsj-react-with-pete-hunt-and-jordan-walke/

15:02 chronno: ro_st: thx

15:04 ro_st: thx bbloom

15:04 dnolen: ro_st: I was concered about React and doing highly interactive UIs, my experience doing a generic draggable + sortable addressed my concerns

15:04 ro_st: React rocks

15:04 ro_st: just been playing with that and the typeahead

15:04 dnolen: ro_st: and Om makes it play extra nice w/ CLJS

15:04 ro_st: it's awesome!

15:05 time to skill up on react. i'm sold on react, simply because of how battle tested it is. facebook.com probably only comes in second to google itself in terms of client diversity

15:06 dnolen: ro_st: Google Closure + React is sweet combo

15:07 ro_st: looks like the meat of learning react is the component lifecycle

15:07 dnolen: ro_st: yes

15:07 ro_st: i'm getting flashbacks to the Flex framework

15:07 -shudder-

15:07 looks like this time it's actually working as it should!

15:07 GC + React is sweet combo becaus?

15:08 dnolen: ro_st: cross browser issues

15:08 ro_st: ah right

15:10 dnolen: not many issues for om - looks like there's relatively little to get it to where you want it?

15:10 dnolen: ro_st: yeah Om is not destined to do much

15:10 ro_st: as a wrapper, all the meat is in react i guess

15:11 do the react guys know about om? have you spoken with them? i wonder what they think

15:11 dnolen: ro_st: oh they know :)

15:11 ro_st: my Om post was a huge hit, like 80,000 visits in 2-3 days

15:11 ro_st: crikey

15:11 dnolen: basically half my traffic for the year

15:11 ro_st: well deserved

15:12 dnolen: ro_st: the React devs rock, very helpful

15:13 mrhanky: how to catch Error and Exception in clojurescript?

15:13 catch js/Object e ?

15:14 bbloom: mrhanky: (catch :default e ...)

15:14 ro_st: it looks like a great complement to pedestal's dataflow stuff. keen to see how the new core.async redesign turns out. we want to build large clientside apps that need that sort of capability. until om, we were just going to go with dommy. but now, i think we have our toolkit

15:14 mrhanky: bbloom, :default catches all?

15:14 dnolen: mrhanky: yes

15:16 ro_st: dnolen: the behaviour of react where it'll first write missing dom nodes and then decorate listeners is fully supported with om, too?

15:16 dnolen: ro_st: we don't change any of that

15:17 ro_st: so we could produce html for existing work sessions on the server and have it all wire up nicely

15:17 i guess the diff capability handles all that

15:17 katox: ro_st: I'd expect pedestal guys to reafactor to take om into account

15:17 dnolen: katox: I doubt that, I think they'll probably just simplify their front end story

15:17 ro_st: katox: let's hope so! i'd love to see what brenton thinks about om

15:17 ya. their rendering story is already pretty separate from the rest

15:18 katox: dnolen: too bad, pedestal is just too heavyweight

15:18 dnolen: katox: I think it's in the process of lightening up

15:18 rkneufeld: katox: it should be slimming down with 0.3.0

15:18 ro_st: rkneufeld -wave-

15:18 * rkneufeld waves

15:19 ro_st: ya. 0.3 looks like it'll have a lot less -stuff- in it

15:19 katox: https://github.com/pedestal/pedestal/blob/master/app/examples/walkthrough.clj if you're interested in seeing where the thinking is

15:19 rkneufeld: I couldn't say what the timing of that is going to be, but its in good hands. I pulled out some of the new stuff as its own little library to play with it: https://github.com/rkneufeld/cornice (by no means official)

15:19 ro_st: have you looked at om, rkneufeld?

15:20 rkneufeld: ro_st: yeah, really exciting stuff. It has gotten us very excited.

15:20 mrhanky: thanks dnolen

15:20 katox: ro_st: I'll have a look, thanks

15:20 ro_st: rkneufeld: cornice is pedestal-app 0.3 but cljx-ified?

15:21 katox: ro_st: though I think I can get 80% of what I need from an om atom, cursors and a few wrapper funcions

15:21 rkneufeld: *prototype* of 0.3.0

15:21 I know product folks over here have been mulling over design and are planning a more careful rewrite.

15:21 ro_st: of course, of course

15:21 katox: for small apps, sure

15:22 pedestal is aimed at apps that have data streaming in and out of the browser continuously-ish

15:22 ie, state is altered by more than just key/mouse/client-side ajax request

15:23 dgaffney: hey folks - I have a little web app that I run that has been working reliably for basically all recorded time

15:23 just a few minutes ago it started spewing out some anger about a case statement not having a matching clause - does this sound familiar to anyone?

15:26 hiredman: it means what it says, case throws if it doesn't have a matching clause or a default

15:27 dgaffney: I know - it's weird that its getting thrown now - nothing outside of its context has changed. It's a case statement on a section of a url's path. All the case statements in this code have defaults. could it be happening in some lower dependency?

15:28 mrhanky: is there any difference between (:use [foo :only (bar)]) and [bar] ?

15:28 technomancy: mrhanky: http://p.hagelb.org/import-indent.html

15:29 hiredman: dgaffney: add logging

15:32 katox: stumbled upon this https://github.com/jalehman/omtut-starter/

15:32 technomancy: mrhanky: semantically there is no difference, but they imply different indentation rules which communicate something to a reader

15:32 (a human reader)

15:32 katox: updated to lates om, nice

15:35 ro_st: katox: nice - dnolen, i think you tweeted that when it came out? looks like he's upgraded it again - might be worth plugging it again?

15:37 dnolen: ro_st: heh, I'd like things to settle down a bit more before I start recommending tutorials

15:37 mrhanky: thx technomancy

15:37 dnolen: ro_st: this is pre-pre-alpha software still

15:37 ro_st: -grin- true

15:39 mrhanky: can you guys recommend clojure lecture?

15:41 ro_st: videos.lispcast.com is nice for beginners

15:46 jcromartie: neat

15:53 bbloom: dnolen: LOL: https://news.ycombinator.com/item?id=7019531

15:54 dnolen: bbloom: pretty good

15:54 I really don't understand the proliferation of promise libs in the JS world when everyone has to implement a *SPEC*

15:54 you think they would just join forces and fix one thing

15:56 bbloom: nevermind that promises are totally the wrong thing....

15:56 values are trees... but communication is sequential!

15:56 :-)

16:00 teslanick: dnolen: People didn't agree on a spec until fairly recently, so it's a little bit understandable.

16:01 dnolen: bbloom: between Promises and Web Components it great to see the world is standardizing dumb shit

16:05 bbloom: dnolen: i'm so over standardization

16:05 shep-werk: reiddraper: all those closes you just did? I think your link for merge into contrib was wrong

16:05 bbloom: dnolen: defacto standards are the only standards that count

16:06 teslanick: hipster

16:06 dnolen: bbloom: sadly that doesn't mean bad paths won't be traveled

16:07 bbloom: I remember browser vendors pushing back on the jQuery selector approach

16:07 reiddraper: shep-werk: indeed, thanks

16:07 shep-werk: reiddraper: but congratulations on the inclusion!

16:07 teslanick: I don't think I've heard anyone opine that promises were bad; I've not used them extensively, but they seem pretty ok to me.

16:07 dnolen: bbloom: the problem is that people need to solve their problems *today* and waiting for the right solution may mean you encourage and propagate and optimize bad ones

16:08 bbloom: dnolen: my biggest complaint is that people do that w/o admitting it

16:08 reiddraper: shep-werk: thanks :)

16:08 shep-werk: should be easier to contribute again once the move is complete

16:09 bbloom: dnolen: they lie to themselves & say they are doing it "right".... why? why not just admit you're hacking it b/c you got shit to do? that's totally fine by me. i get that. if you try to perfect everything, you'll never finish, but that doesn't mean you can't admit "i don't understand that, so i'm doing this"

16:10 shep-werk: reiddraper: I'm one of those people who is on the fence about CAs, but I imagine there are lots of people who can replace me :-)

16:11 reiddraper: shep-werk: fair enough -- it's a nontrivial subject

16:17 shep-werk: reiddraper: to make it more amusing to myself, I've considered making my own project with a CA - I think I'm bordering on being hypocritical :-)

16:18 do you know what kind of work is involved in transitioning to a CA? I assume it's get approval from all prev contributors?

16:19 reiddraper: shep-werk: that's what I've had to do with simple-check, yes

16:19 stuartsierra: shep-werk: http://dev.clojure.org/display/community/Moving+Projects+Into+Contrib

16:21 shep-werk: thx stuartsierra

16:21 doesn't seem like too much work

16:24 technomancy: depends on how much you like turning down patches for nontechnical reasons

16:26 katratxo: hi all, i need some help figuring out where those `nil` are comming from? i have 2 sequences of uuids (strings) and i want to compare them https://www.refheap.com/22575

16:28 hiredman: katratxo: read the docstring for diff?

16:29 * jcromartie just learned about ex-info and ex-data

16:29 jcromartie: seriously, what the heck

16:29 katratxo: hiredman: i checked it but i can't spot my mistake :s

16:30 gtrak: jcromartie: it helps out slingshot

16:31 katratxo: hiredman: `things-only-in-a` has a nil which is not present on none of the seqs

16:32 shep-werk: katratxo: All sequential things are treated as associative collections by their indexes, with results returned as vectors

16:32 katratxo: shep-werk: yeap, i just re-read it, sorry

16:32 hiredman: shep-werk thanks

16:32 shep-werk: katratxo: np - I just learned about diff thanks to you :-)

16:33 marissagrove: Can anyone suggest a core.async tutorial for a relative clojure newb?

16:33 dnolen: marissagrove: tbaldrid_'s video from Clojure Conj is good

16:34 marissagrove: http://www.youtube.com/watch?v=enwIIGzhahw&feature=youtu.be

16:35 marissagrove: dnolen: Thank you!

17:09 stuartsierra: Is Jim Crossley here?

17:10 corecode: is there some reader magic that allows (.length "foo"), but does not allow me to (let [s "foo", lfn .length] (lfn s))?

17:10 Bronsa: corecode: yes ##(macroexpand-1 '(.toString ""))

17:10 lazybot: ⇒ (. "" toString)

17:11 corecode: macro magic!

17:11 thanks.

17:11 Bronsa: not really a macro

17:11 corecode: reader magic, ok.

17:11 Bronsa: not even in the reader :)

17:11 corecode: oh?

17:11 what then?

17:11 Bronsa: it's part of the macroexpander

17:12 corecode: ok

17:12 fair enough

17:12 hiredman: it is the compiler, you can only use literal symbols for method names

17:12 arrdem: ,(nth (range 10) -3)

17:12 clojurebot: #<IndexOutOfBoundsException java.lang.IndexOutOfBoundsException>

17:12 corecode: i'm just asking, because i'm trying to prototype a language with clj

17:12 arrdem: dang

17:13 Bronsa: corecode: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6506

17:13 arrdem: corecode: what are you building?

17:13 corecode: and accessing subordinate symbols seems better than using keywords

17:13 arrdem: i am investigating a circuit description language

17:14 arrdem: as alternative to schematic entry

17:14 arrdem: corecode: cool!

17:15 corecode: well, i'm not experienced in language design, so i don't quite know how to start

17:15 arrdem: corecode: the best thing to do is probablty just write a Clojure DSL TBH.

17:15 corecode: no need to build a full parser and associated mess when you can just host inside of Clojure or something else

17:17 corecode: yes

17:17 syntax is the least of my concerns

17:24 arrdem: corecode: do you know how Spice and other circuit systems do their internal modeling?

17:25 bitemyapp: arrdem: http://www.haskell.org/haskellwiki/Applications_and_libraries/Hardware_verification ?

17:25 arrdem: I'd have pasted you a link to Clojure equivalents but there isn't a wiki so...

17:25 justin_smith: bitemyapp: what about that one you made?

17:26 corecode: arrdem: netlists

17:26 arrdem: no?

17:28 bitemyapp: justin_smith: it exists, I bootstrapped some content. Got maybe 2 or 3 edits that weren't mine.

17:28 justin_smith: even if it languishes, it was worth it to discover that wiki gitit. Very nice.

17:30 justin_smith: yeah, it does look cool

17:32 corecode: bitemyapp: all these somehow seem to compile to vhdl. i'm talking about circuit design.

17:32 arrdem: bitemyapp: link to your wiki? I'll throw content at it at any rate...

17:32 bitemyapp: made it to 12.5 before sheer rage made me quit and resume coding

17:33 bitemyapp: arrdem: god damn.

17:33 arrdem: I beg of you, hit level 13 before I get home tonight.

17:33 arrdem: http://clojurewiki.com/

17:33 arrdem: bitemyapp: lol we'll see

17:33 bitemyapp: it's a Warmachine night so there like as not won't be a "tonight".

17:33 corecode: I mean... do you have a specific reason not to compile to the industry standard description language?

17:34 bitemyapp: arrdem: well. sometime then.

17:34 corecode: arrdem: you'd compile to whatever the input format to the layout package is

17:34 arrdem: bitemyapp: if I manage to track down where my processors are misbehaving, I'll go crush my jubilee with pugs. how's that sound.

17:36 bitemyapp: arrdem: <3

17:37 devinus: does anybody know what happened to (def newsletter) ?

17:40 eric_normand: devinus: I'm not positive if it's the reason, but the author had a kid

17:41 devinus: ah. damn, i really looked forward to that every week

17:41 eric_normand: does anyone know why clojuredocs.org has not been updated in a while?

17:41 arrdem: eric_normand: the owner is unresponsive IIRC

17:42 eric_normand: nobody has access to update it

17:42 bitemyapp: eric_normand: are you serious man? We've been griping about this for years.

17:42 eric_normand: it's like half the reason I made clojurewiki.com - The other being a total lack of wiki.

17:43 eric_normand: bitemyapp: it was a serious question. I assumed it was dead, of course. I just thought someone might have an answer.

17:43 arrdem: whelp, my second JVM tome arrived.. I now have no excuse besides Batbridge/Toothpick from getting started on CinC...

17:44 hyPiRion: arrdem: what's the issue?

17:44 arrdem: hyPiRion: ??

17:44 lazybot: arrdem: What are you, crazy? Of course not!

17:44 arrdem: lazybot: who asked you!

17:47 hyPiRion: arrdem: I somehow read tome as tonsil.

17:49 arrdem: (inc hyPiRion) ;; at least you're honest about being crazy

17:49 lazybot: ⇒ 28

17:50 hyPiRion: I thought that was evident when I started working on Swearjure.

17:59 corecode: i don't even know how to maintain a database of objects with everything being immutable...

17:59 :/

18:00 bitemyapp: corecode: ?

18:02 corecode: bitemyapp: for my circuit description language; i think i want to keep a graph of modules and their connections, but that requires mutating state, or recursing over the mutations (which is more difficult)

18:03 bitemyapp: corecode: you've never used a log?

18:04 justin_smith: corecode: you can recur and pass new versions of the graph to reach iteration in a loop, or, an atom with a map in it is perfectly cromulent

18:04 bitemyapp: corecode: http://www.martinfowler.com/eaaDev/EventSourcing.html

18:04 rasmusto: cdl == hdl? :p

18:04 bitemyapp: corecode: you can just fold the graph.

18:05 corecode: rasmusto: no, hdl typically is used for vlsi design

18:05 i.e. rtl

18:05 rasmusto: ah, is yours more lower level then? or analog or something?

18:06 corecode: rasmusto: just for circuits, i.e. pcbs

18:07 rasmusto: corecode: ah, makes more sense now. "Circuits" means a lot of different things to me

18:07 corecode: justin_smith: unsure about cromulent. atom it is for now.

18:09 arrdem: BOOYEAH. bytecode works, the assembler works, tests are clean.

18:19 jballanc: holy crap! I actually managed to write flatteno!

18:19 https://gist.github.com/jballanc/8308717

18:20 the only problem is that it seems I can't get it to ever terminate if run in reverse... :-/

18:21 dnolen: jballanc: yeah that's pretty normal.

18:21 hyPiRion: jballanc: for run* or run 1? It's obvious that it cannot terminate "in reverse"

18:21 jballanc: even for run 1, unless I give another constraint

18:22 dnolen: jballanc: conda is some voodoo, to be honest I never understood how to properly use it

18:22 jballanc: unfortunately I can't get a unique answer *and* avoid infinite recursion in reverse

18:22 dnolen: I didn't either until just now! :P

18:23 dnolen: jballanc: whenever you have two recursion things get gnarly w/ respect to termination

18:23 jballanc: subbing conde for conda gives answers like ((1) ([1])) when trying to flatten [[1]]

18:23 dnolen: jballanc: 2 recursions + appendo ... forget about it

18:23 jballanc: ...because a doubly nested list is also a singly nested list

18:24 so, it turns out that so long as I unify q to something before running unwrapo or flatteno it'll terminate in reverse

18:24 (cl/run* [q] (cl/== q [[[1 2]]]) (unwrapo q [1 2]))

18:24 ...but I think this'll work for my purposes

18:26 ah, I think that last match term on unwrapo is unnecessary

18:27 it took me a while to realize that the trick was to reverse the base cases for unwrapo and flatteno with conda

18:29 hiredman: jballanc: I can't imagine flatten is any less gross in the logic program as it is else where

18:29 jballanc: hmm...I feel like I should be able to get rid of that last appendo in flatteno too with the right pattern for matching o, but my brain is fried right now

18:30 hiredman: yeah, I spent the better part of the last 10 hours or so noodling over this :(

18:30 hiredman: instead of trying to write a flatten relation you should just get rid of need for it

18:30 jballanc: well, maybe not quite that many

18:30 dnolen: jballanc: crazy what 20 lines of code can do to your brain

18:30 technomancy: hiredman: but logic programming makes everything better

18:30 jballanc: heh

18:30 hiredman: ~flatten

18:30 clojurebot: flatten is rarely the right answer. Suppose you need to use a list as your "base type", for example. Usually you only want to flatten a single level, and in that case you're better off with concat. Or, better still, use mapcat to produce a sequence that's shaped right to begin with.

18:31 jballanc: hiredman: the issue is that if I don't have flatten, everything else further downstream just gets super gnarly

18:32 I need to be able to check membership, which is fine when you can iterate a list normally, but it's a bitch in core.logic

18:32 ...if the list isn't flattened, that is

18:32 with a flattened list, it's as easy as membero :)

18:33 dnolen: jballanc: in my experience I don't find data transformation particularly fun in core.logic

18:33 jballanc: it much better to put data in that's already in the right shape

18:33 jballanc: dnolen: yeah, definitely something I'm going to be keeping in mind going forward

18:33 hiredman: jballanc: if you know the nesting you don't need anything as general as flatten, if you don't know the nesting you are doing it wrong :)

18:33 dnolen: jballanc: core.logic works best when you're looking for patterns in data

18:34 jballanc: or generating data from existing patterns

18:35 jballanc: hiredman: so, the problem is I have > 1000 java class files, with mixed-up interdependencies, and I'm trying to figure out what order I can compile modules in such that all imports are satisfied either by the classes in the group being compiled or in a previously compiled group

18:35 so, I'm using (or trying to, at least) core.logic to construct a build order

18:36 hiredman: jballanc: use a graph library and do a topological sort?

18:36 jballanc: hiredman: yup, that's what I started with

18:36 but I have other plans for core.logic down the road

18:36 this was more of a push myself/core.logic to the limit and see what's possible

18:37 dnolen: jballanc: well rule of thumb, if you're doing anything more complex then concatenating lists, you probably want to do it in Clojure first

18:37 clojurebot: No entiendo

18:38 hiredman: and flatten is gross

18:38 jballanc: no argument here :)

18:38 hiredman: great, so you'll stop trying to use it, wonderful

18:39 jballanc: well it's definitely been a good katta

18:40 bah...I mean kata

18:40 wow...I had no idea the difference a "t" can make

18:43 the-kenny: dnolen: Is it expected that `first' on a MapCursor doesn't work? I thought it's implemented in all map types?

18:44 dnolen: the-kenny: can you be more specify, MapCursor implements ISeq

18:44 er I mean ISeqable

18:44 s/specify/specific

18:45 the-kenny: Nevermind :/ My bad

18:46 I was just updating a small Om test application I had lying around and used a wrong value

18:46 Sorry for bothering you

18:46 dnolen: the-kenny: it's no problem

18:47 the-kenny: I still have to build something bigger to get more used to it

18:47 s/it/om/

19:16 hansel-han: If you had a dedicated box with a webhost for years and, in a turn of events, you weren't around to pay the $300 bill for December (due the 3rd) so they parted the server out on December 27th, would a webhost probably have your data retained somewhere?

19:17 justin_smith: hansel-han: ouch - that seems very short sighted that they would part out the box of a long term customer because one bill was late

19:18 hansel-han: justin_smith: yeah, i agree. it's far from compelling

19:19 i'm just waiting back to hear if they at least have my data

19:20 justin_smith: did they at any point say "we have a data archive and backup service you can't refuse" by any chance?

19:24 benkay: has anyone ever set leiningen up to accept remote connections? i'd like to boot leiningen's REPL inside a Docker container inside a Vagrant VM (yo dawg i herd u liek virtualization) and then attach to that via Emacs/Cider on my host OS X box so that the stateful things I want to do to the machine on which my JVM processes is running are nicely isolated. thoughts?

19:25 (btw I have successfully booted `lein repl :headless :port 8191`, but am failing to connect to it from either the host vm or my host os x machine)

19:27 justin_smith: benkay: I use ssh -X to tunnel in in order to connect to a repl on a remote box

19:27 that should work w/ virtualization too

19:28 hansel-han: justin_smith: heh, dunno. but they just sent me this "I'm sorry but I can only confirm what billing has already said which is that the server has been parted out and the drives have been wiped. We're here at any time if you would like to have a dialogue about future backup strategies.

19:28 gonna assume that's a wipe

19:29 justin_smith: man, that sucks

19:29 hansel-han: i know that it's my problem that i backed up my forum to the same host i hosted it on (lesson learned) but for what it's worth, the webhost is wickedfire.com

19:29 er

19:29 wiredtree.com

19:50 benkay: justin_smith: do you repl raw or run an emacs instance on those machines?

19:52 darthdeus: hey guys, i'm having trouble with various clojure web thingies (now clojurescript) in chrome

19:53 before that i got weird content-length with luminus, and now with cljs i'm getting "exceed max line 4096"

19:53 even though the page renders in sfarai

19:53 akurilin: Woot, just managed to power through 150+ topics on the mailing list, almost catching up with it. Every page has around 3 announcements of new clojure.jdbc version :P

19:54 justin_smith: benkay: raw repl on the server, tramp to edit files on the server

19:54 and nrepl on my host connecting to the ssh-tunneled local port

19:55 which is really the remote nrepl port of course (above I mean emacs-nrepl of course)

19:55 benkay: makes sense

19:55 thanks, justin_smith

19:56 justin_smith: np - using that workflow I was able to do the "remote machine with resources runs clojure, local machine with UI I want does the editing / repl UI" pretty smoothly

19:57 logic_prog: cemerick: is there a nice way to package *.cljx files into clojure libraries?

20:00 noonian: i've never used cljx but from the git page it seems like you could just add the cljx.hooks to your hooks vector and it should just work when it builds the jars

20:17 konr: what is that function that can divide a sequence in various equal parts, like [1 2 3 4 5 6] => [[1 2] [3 4] [5 6]]?

20:18 amalloy: &(doc partition)

20:18 lazybot: ⇒ "([n coll] [n step coll] [n step pad coll]); Returns a lazy sequence of lists of n items each, at offsets step apart. If step is not supplied, defaults to n, i.e. the partitions do not overlap. If a pad collection is supplied, use its elements as necessary to complet... https://www.refheap.com/22581

20:18 konr: thanks!

20:35 logic_prog: is there anything bad about using zeromq with clojure (besides idiots won't be able to use zeromq) ?

20:44 ToBeReplaced: logic_prog: nope, we've used jzmq in production

20:55 SrPx: Hello CLojure community. I've been developing a great, really cool structural editor for lisp-like languages. It runs mostly on the browser. So I would like to know, is there any project for a fast (as in, compilation time) Clojure compiler (or interpreter) running on the browser? This is very important for the feedback cycle of the editor.

20:56 seangrove: SrPx: No self-hosted ClojureScript compiling yet

20:57 logic_prog: ToBeReplaced: noted, thanks

20:57 SrPx: can we try your tool ?

20:58 SrPx: Sad :( logic_prog let me get it straight, it is still early and I don't know its future :/ I'm trying to create a language for it as it seems like there is no other way to do it as of now

20:58 which will take some time

20:59 logic_prog: SrPx: I played with something similar in the browser.

20:59 technomancy: there's a self-hosted clojurescript proof-of-concept

20:59 SrPx: there is?

20:59 logic_prog: SrPX: I think the easiest thing is to srite a mini scheme interpreter in clojure.

20:59 technomancy: just nothing blessed by cognitecht

20:59 logic_prog: SrPX: it should take about 100 lines of code.

20:59 seangrove: SrPx: It's a slightly strange idea, why do you need it in the browser?

21:00 SrPx: logic_prog: I know, my language is pretty much it already... actually just lambda calculus with arrays and numbers. it is working great, honestly, I've made cool things with it (ie sprite lamp, few games). the editor makes it so easy. but it is above me and my time constraints to get the language to work properly. too much theory... optimizers, stream fusion... i dont know what to do

21:01 seangrove: because... I love the browser

21:01 logic_prog: in theory, you can try to emascripten llvm the jvm

21:01 then you can get clojure in the browser

21:01 SrPx: I love the fact I can send a link to someone and he will see what I did without having to download. regardless of platform sex or religion

21:01 seangrove: SrPx: Yeah, but that's just final deployment

21:02 SrPx: logic_prog: llvm the jvm!?? hahah

21:02 seangrove: ... pardon?

21:02 seangrove: It's personal preference, but emacs + cider + clojurescript repl, is a very good workflow

21:02 Not for everyone though

21:03 benkay: so ubuntu universe is only carrying leiningen 1.7.3

21:04 SrPx_: Sorry my macbook fell out the window, lost anything?

21:04 benkay: just you know fyi etc

21:05 SrPx_: hmm if nobody said anything may I just ask another question that was bugging me other day

21:06 are hashes the "right" way to store data you would store on objects if you were using an OOP language? (wouldn't it be really slow?)

21:08 justin_smith: SrPx_: generally clojure hashes are fast enough (they are not just normal hashes) but there is defrecord when you need the equivalent of object field lookup for a performance boost

21:08 http://clojuredocs.org/clojure_core/clojure.core/defrecord

21:09 danneu: SrPx: coming from ruby? in general you just use maps.

21:09 SrPx: ruby? not really why

21:09 danneu: because you called them hashes

21:10 SrPx: justin_smith: interesting. thanks! that is what I needed

21:10 amalloy: SrPx: http://logs.lazybot.org/irc.freenode.net/%23clojure/2014-01-07.txt so you can stop asking whether you missed anything

21:10 teslanick: Where's that flowchar about when to use each thing

21:10 SrPx: may I ask some questions about performance, then? Clojure is pure? Does the compiler use it to apply aggressive inlining? Is there stream fusion or shortcut fusion so (map f (map g x)) avoids the intermediate representation?

21:11 teslanick: This: http://chasemerick.files.wordpress.com/2011/07/choosingtypeforms2.png

21:11 danneu: SrPx: well, map is lazy

21:11 it will compose f and g

21:12 SrPx: teslanick: wow some ways

21:12 technomancy: the main thingc about records isn't that they're faster but that they use less memory for their keywords

21:12 they're faster than multimethods, but that's different

21:12 amalloy: SrPx: no, none of the things you asked about happen. and clojure isn't really pure, it just encourages purity, so a lot of optimizations aren't possible

21:12 but the JVM is very good, and there are ways to further tune performance for the 1% of cases where it really matters

21:13 hiredman: technomancy: field lookup will be faster too

21:13 tommo: I'm having some problems binding a context var to 'this' in a proxy, https://www.refheap.com/22586

21:13 SrPx: danneu: on is it? Interesting! Thanks. About numeric computation. Something I never understood. If I am dealing with a game / bitmaps, for example, where I need to remap a very big array of pixels every tick. Won't persistent structures make this unbearably slow?

21:13 technomancy: amalloy: (map f (map g x)) will avoid the intermediate representation of (map g x), if that's what he's asking

21:13 tommo: also what's a more clojurish approach to something like that?

21:13 SrPx: amalloy: oh ... I see

21:13 hiredman: technomancy: no it won't

21:13 amalloy: technomancy: no it won't

21:13 danneu: SrPx: no, because editing the big map doesn't copy the whole thing.

21:14 teslanick: All the persistent data structures in Clojure use structural sharing.

21:14 technomancy: amalloy: the whole thing isn't in memory at once is what I mean

21:14 amalloy: it doesn't hold it all in memory at once, of course, just like the final result isn't all in memory at once

21:14 hiredman: amalloy: it would be more entertaining if we coordinated and switched off every other line

21:14 technomancy: I guess the question is ambiguous

21:14 SrPx: danneu: pardon, I mean, visualize a 1000x1000 arrays of floats. Suppose this arrays is updated 30x/s, that is, every single pixel is modified (as the character moves, for example). Is this a problem?

21:15 amalloy: technomancy: in the context of stream fusion i thought it was pretty likely he was asking about whether (map g x) ever actually exists

21:15 justin_smith: SrPx: clojure can use native arrays, and for a situation like that, I think it is called for

21:15 danneu: SrPx: in that cast you'd opt in to mutable data structures

21:15 teslanick: Probably. That's not a really the ideal place for a clojure data structure

21:15 justin_smith: SrPx: conceptually, those pixels would be generated based on your data, they are not your data

21:15 that is how I think of it at least

21:15 SrPx: amalloy: pardon? I'm not sure what you mean but you can ask me if you didn't understand! You guys are debating what I asked like I'm not here lol

21:16 justin_smith: sure, so?

21:16 teslanick: Clojure would be the thing before the image generation, so: (clojure gameState) => render => pixel buffer

21:16 justin_smith: SrPx: that's my rationale for "don't use persistend data structures there"

21:16 SrPx: persistent data structures are ubiquitous in clojure, but are not manditory

21:16 SrPx: oh there is those, okay! Learning a lot there. So it is NOT a problem that is inherently slow on the language at all, right?

21:17 amalloy: tommo: i don't understand that paste. how do you know you're having trouble binding *context*, if you never attempt to use it?

21:17 SrPx: there are * english is hard

21:17 tommo: at compile time amalloy: Caused by: java.lang.RuntimeException: No such var: cljscript/this

21:17 i think it may be a problem with the macro itself?

21:18 justin_smith: SrPx: there are tradeoffs but clojure does persistence in smart ways, for DSP or for raster data I would totally use arrays, but most of my data can be persistent data structures without a huge performance hit

21:18 technomancy: hiredman: I understand record field access is technically faster, but when someone says "use records for performance" that is almost certainly not what they're talking about

21:18 justin_smith: and that can be fixed where it matters, case by case

21:18 technomancy: ^ "the main thing"

21:18 amalloy: oh. yeah, the macro is qualifying this. you can paper over it with ~'this

21:18 although really i don't see any reason this is a macro at all

21:19 tommo: what's a more idiomatic way of doing it amalloy?

21:19 im just exploring different approaches

21:19 SrPx: justin_smith: uh huh I see, enlightening thanks

21:20 hiredman: ugh, and the metadata, and def the result of a def

21:20 amalloy: you just want (defn make-script [f] (proxy [...] (binding [*context* this] (f))), (def ^{...} script (make-script #(...))

21:20 SrPx: Well I really wish I could try to plug in my editor into clojure and see how it would go... you guys mentioned an interpreter running on the browser or I'm imagining this?

21:20 danneu: SrPx: what editor do you use

21:20 hiredman: (iterate terrible ...)

21:20 SrPx: one very cool editor for lispy like languages I made

21:21 hyPiRion: oh man, SrPx is rsm in disguise

21:21 tommo: o i see, makes sense

21:21 justin_smith: well nrepl is the protocol that the standard "lein repl" task uses

21:21 danneu: haha

21:21 justin_smith: you could implement a client of that :)

21:21 technomancy: SrPx: you can try the experimental self-hosting cljs fork, but it's probably pretty outdated at this point

21:21 SrPx: Who is rsm? :o

21:21 technomancy: that is bad :/

21:22 hyPiRion: rms*

21:22 danneu: SrPx: just have your editor talk to nrepl

21:22 that's how all the editors work

21:22 technomancy: SrPx: yeah, I don't understand why it wasn't continued

21:22 mabye just the standard hostility to development that happens from outside the core contributors or something

21:22 SrPx: really? why?

21:23 technomancy: http://p.hagelb.org/mystery.gif

21:23 danneu: SrPx: i like that you have your own very cool editor for lispy like languages though. yak shave cred goes a long way here.

21:23 seangrove: technomancy: Do you have those links on autoexpand?

21:24 hyPiRion: That's the third time I've seen that link today

21:24 * technomancy hastily adds to his todo list

21:24 technomancy: seangrove: not ... yet

21:24 SrPx: technomancy: hahaha

21:25 seangrove: hyPiRion: Better than the party-time/cool-jazzy-horse one

21:25 SrPx: saving that

21:25 technomancy: curating a healthy catalog of gifs is an important skill for any aspiring computorist

21:25 SrPx: Deraen: yak shave cred <- what does that mean? me no english

21:25 jcromartie: yak shaving spans all cultures

21:25 SrPx: wat

21:25 justin_smith: http://www.catb.org/jargon/html/Y/yak-shaving.html

21:26 teslanick: "Any apparently useless activity which, by allowing you to overcome intermediate difficulties, allows you to solve a larger problem. -- I was doing a bit of yak shaving this morning, and it looks like it might have paid off."

21:26 From - http://en.wiktionary.org/wiki/yak_shaving

21:26 justin_smith: someday I will figure out a project worthy of the name yak-electralysis

21:27 jcromartie: yakwax?

21:27 SrPx: This kinda of makes sense but I still have no idea wether he is supporting or joking about my editor c:

21:27 danneu: yakshaving http://i.minus.com/ibaDjk7AeIcvxv.gif

21:28 pdk: where can we find this editor

21:29 danneu: pdk: https://github.com/hraberg/deuce

21:29 pdk: that's pretty neat

21:29 seangrove: Deuce is not emacs!

21:29 jcromartie: yak shaving AKA "because you can't just do a thing"

21:30 seangrove: pdk: The SkillsMatter talk on it is pretty good

21:30 pdk: is the talk listed on the source page

21:30 SrPx: you guys seems interested in such a thing... maybe it would be a good idea to stop trying to create my own language and use clojure as the language :D

21:30 seangrove: Yeah

21:30 pdk: or compile your language to clojure!

21:31 SrPx: lolwat

21:31 seangrove: Just add instaparse, and you're done!

21:31 teslanick: I'm going to compile JS to clojure. And from there into clojurescript. And the circle of life will be complete.

21:32 seangrove: teslanick: Actually, a JS compiler in clojure could potentially be nice. We could do away with the closure compiler, possibly

21:32 SrPx: teslanick: well if you manage to fit the third cycle on your HD you won life indeed

21:33 ambrosebs: can anyone with maven-fu work out why core.typed's AOT'ed jar includes all the unit test namespaces?

21:33 pleeease? :)

21:33 hyPiRion: I think it would be easier to just port the closure compiler instead of building a VM for JS on top of the JVM, sir.

21:33 ambrosebs: it's getting big

21:33 teslanick: I hadn't thought of that. I was about to make a joke about the algorithms being embedded in the text of The King in Yellow.

21:40 bbloom: technomancy: the self hosting cljs port was deeply flawed

21:40 technomancy: i forget the guys name. he did reasonably good work, but overall he punted on the hardest problems

21:40 seangrove: Chouser?

21:40 clojurebot: Who??

21:41 bbloom: no no

21:41 https://github.com/kanaka/clojurescript that one, right technomancy ?

21:42 seangrove: bbloom: Ah yes, you're right

21:42 bbloom: he never managed to reify namespaces or vars. the google closure compiler can't run on the result at all.

21:42 seangrove: Joel Martin

21:43 bbloom: oh apparently chouser worked on it too?

21:43 or apparently just worked on it during the conj & kanaka has worked on it alone since

21:44 apparently he didn't get it to self host yet anyway

21:45 anyway, not to shit all over his work or anything, but there are hard problems to self host and still be production caliber. he didn't solve those hard problems. dnolen et al have prioritized other problems

21:46 dnolen: as I've said before we aren't even that far away

21:46 bbloom: especially with lots of little things that have lit up along the way, like constant tables, reified keywords/symbols, etc

21:47 dnolen: CLJS + Node.js port of tools.reader w/ symbol translation table + native macro expander would take us there pretty much there.

21:52 seangrove: Wow, react has the ability to fix a lot of things that are wrong with the browser. Very nice that they've normalized values/events/attributes on <select>, <textarea>, etc.

21:53 teslanick: Yeah, virtualizing the DOM lets you solve a lot of those problems elegantly.

22:01 dnolen: seangrove: React rocks

22:02 seangrove: dnolen: Yeah, I'm converting the last of our new app that doesn't use it over to it

22:02 An incredible improvement over the core.async-focused stuff we had

22:02 dnolen: seangrove: so much accidental complexity ... evaporated

22:02 seangrove: React for the core, core.async shell, it's all so much more straightforward now

22:02 dnolen: seangrove: yeah I think React is superior to anything built around mostly around core.async

22:03 seangrove: core.async just for the links between components

22:04 bbloom: core.async, a bad idea unless it's the only idea left, then it's a damn great idea :-)

22:04 seangrove: dnolen: That's what we ended up doing

22:04 bbloom: i feel like a proper core.async usage should be like ~20 lines tops

22:04 dnolen: seangrove: my favorite thing is w/ React/Om + core.async you can write these ridiculously concurrent client side applications

22:04 and actually know what the fuck is going on

22:06 seangrove: bbloom: I suppose I should thank you as well for pushing the right people to notice ;)

22:06 bbloom: seangrove: my pleasure, this excitement has been so enjoyable to watch

22:07 dnolen: so Om made me realize functional lenses are kinda of cool

22:07 bbloom: seangrove: i'm such a slow implementer compared to some other folks that i know the best way to get ideas across is to concurrently push 25 ideas to 5 or so solid implementers and hope to get like 3 of them to change the world for me :-)

22:07 dnolen: Om basically gives you a functional lens / zipper via Clojure collection operations

22:07 bbloom: seangrove: dnolen is a machine

22:07 seangrove: dnolen: I didn't realize what a functional lens / zipper was until that last blog post

22:07 Now it makes quite a bit of sense

22:08 bbloom: seangrove: this series is where it's at for zipper explainations: http://pavpanchekha.com/blog/zippers/huet.html

22:09 seangrove: Ah, progress

22:09 bbloom: seangrove: personally, i think kiselyov zippers are much easier to think about than huet zippers, if you realize the call stack maintains the traversal context, which is essentially update-in and friends like that that operate on key paths

22:09 seangrove: I feel like there's hope to move out of the swamp we've been digging into and drowning in

22:10 bbloom: seangrove: lenses are super cool too though. the *-in functions approximate them in many ways. who was it here in irc that was exploring that deeper? was that you?

22:10 dnolen: bbloom: the problem with zippers is the navigation api

22:10 bbloom: much more natural to be able to navigate via ILookup and IIndexed

22:11 bbloom: dnolen: that's the problem with HUET zippers, not oleg kiselyov's zippers

22:11 dnolen: i.e. lenses on records and vectors

22:11 bbloom: oh interesting

22:11 bbloom: dnolen: also perf of huet zippers is only really good if you plan on navigating around the tree kinda randomly & then more or less rewriting everything, where as an update-in style operation performs much better if you only want to change a sub tree here or there

22:12 dnolen: i've written about 2/3rds of my talk for next week, but i think the last 3rd i'll try to cover zippers in detail :-)

22:12 dnolen: bbloom: got it, cool

22:12 bbloom: sweet looking forward to it

22:13 bbloom: dnolen: in short though, huet zippers are the derivative of the data type & oleg's zipper's are the derivative of a traversal procedure over that data type :-)

22:13 an inside out tree tree vs a path pulled from the traveral's stack ;-)

22:16 seangrove: bbloom: Going to be recorded at all? I'd definitely be interested in hearing it

22:16 bbloom: seangrove: i'm pretty bummed that my fipp talk wasn't recorded last year, so i'm gonna bug david greenberg to make sure he brings the camera/stand this time :-)

22:17 seangrove: Ah, yes, that would have been nice too..

22:17 I think we'll hold off on the Om/react talk until next month for the ClojureScript SF meetup

22:17 Give people a chance to prepare a bit more, and for Om to become just a little less bleedy-edgey

22:29 dnolen: Now that I have the dev version of react, it's even nicer. Any chance there's something Om could do to fix this warning though? http://dl.dropbox.com/u/412963/Screenshots/9b.png

22:30 The "Check the render method of undefined"

22:30 I've noticed that Om could probably be slightly nicer about the names it generates for stack traces, etc.

22:35 technomancy: bbloom: ah, thanks for the clarification

22:35 seems like a shame for all that to be thrown away

22:36 I guess it was just poor communication or somthing

22:36 bbloom: technomancy: it was more like zero communication

22:36 technomancy: that would do it

22:40 dnolen: seangrove: I don't know how we can improve that one

22:42 seangrove: not sure what you mean about improving names in stack traces

22:43 seangrove: dnolen: I could be off, but whenever an error happens in the render method of some om/component, the call site is usually in a method calld e.g. t432534

22:43 But I'll come back to you with a specific example

22:43 (later)

22:43 Way behind for today as-is

23:07 sritchie: hey guys, is there a way to only have a compojure route match if a matched component passes a predicate?

23:08 technomancy: ~guards

23:08 clojurebot: SEIZE HIM!

23:08 technomancy: get it? because pattern matching?

23:09 yeah, um sorry

23:10 logicprog: are there any best practices when it comes to writing multi machine distributed clojure code?

23:11 tbaldridge: rabbitmq + core.async?

23:12 technomancy: I can confirm that sending sexps over rabbitmq is pretty great

23:12 logicprog: why not zeromq?

23:12 technomancy: zeromq doesn't provide the primitives you need

23:12 logicprog: I'm also tempted to have clj code run in individual node.is instead of one gigantic jvm

23:13 hmm,reading zeromq guide and liking it

23:13 technomancy: it's not a message queue; you have to build a coordination scheme on top of it before you could use it for that

23:13 seangrove: logicprog: best practice #1 - don't do it if you can avoid it at all

23:13 technomancy: it's not bad, it just does a lot less than what most people think

23:13 seangrove: logicprog: zeromq is more like sane sockets

23:16 ToBeReplaced: zeromq when you want/need brokerless messaging... it's a bad fit for anything that requires any kind of guarantees

23:17 that's a bit of a generalization, but that's what we're doing here, right?

23:56 andrew__: I'm reading a book on Clojure, and on one page it says: "Remember always that macros execute at read time, not runtime." Then on another page, it says: "Lisp is powerful, providing a compiler and macro system at runtime." This seems contradictory, doesn't it?

23:57 CaptainLex: andrew_: That's because you can use Clojure in two different wats

23:57 ways

23:58 You can use it as a compiled language, right, by writing normal files and then running a program like through lein run

23:58 Or you can use it at the REPL

23:59 At the REPL, the compilation and run steps happen really quickly

23:59 andrew__: and what is the other way?

23:59 oh, sorry, didn't scroll down

23:59 I see.

23:59 CaptainLex: So, the thing about macros executing at read time means

23:59 andrew__: the REPL would be the "read time" answer, while the file is the "runtime" version, yes?

Logging service provided by n01se.net