7:58 clgv: hmm, I want something like prismatic/plumbing for more complex calculations involving similar calculations on nested sequence of maps ^^
7:59 currently I wire together several levels of runs of functions generated with it on different collections
7:59 borkdude: lol, for the first time in years I wrote (130 - y) instead of (- 130 y)
8:02 numbers don't implement IFn and apply a function argument to themselves and the rest of the args? I'm disappointed now
8:03 clgv: borkdude: :P
8:03 borkdude: if IFn were a protocol you could fix that for java.lang.Long ;)
8:03 borkdude: yeah :)
8:04 clgv: all numbers evaluate to themselves except 42 which evals to the universe and everything ;)
8:05 borkdude: :)
8:08 gfredericks: clgv: changelog done
8:09 borkdude: just yesterday somebody wanted numbers-as-ifn to do repeat; I don't think there's any obvious impl
8:11 clgv: gfredericks: :D
8:11 gfredericks: we were just fooling around ;)
8:12 gfredericks: you should all be ashamed of yourselves!
8:12 what if rich came in here and saw that kind of speculation!!??!
8:13 clgv: gfredericks: chances of that happening are not that high concluded from my sample data over the last months ;)
8:13 at least not at this time ;)
8:39 gfredericks: clgv: I started thinking more about this locals idea
8:39 I realized you could have macros that add more locals to existing exceptions
8:40 Glenjamin: is this some sort of throw macro that does more work in dev builds?
8:40 gfredericks: actually you can't quite do that without messing with the stacktrace
8:40 Glenjamin: no just in a library
8:41 clgv: gfredericks: you mean adding them on the way up the callstack when they "pass through" your new macro? that was exactly my use case then ;)
8:41 Glenjamin: yeah, but you'd set a dynamic var or something and it does locals capture and things
8:41 gfredericks: clgv: yes that -- but you can't easily replace the map on an ExceptionInfo object I don't think
8:42 clgv: gfredericks: ah well, not to bad to create a new ExceptioInfo since that documents where these locals come from
8:42 gfredericks: Glenjamin: macros have access to locals without modifying clojure
8:42 clgv: gfredericks: I'd call it rethrow or similar
8:42 Glenjamin: but you're talking about attaching to the exception object?
8:42 gfredericks: clgv: yeah but then you lose or at least obscure the original stacktrace
8:42 Glenjamin: sure
8:42 ex-info lets you attach arbitrary anything
8:43 clgv: gfredericks: well you create an indirection, but you'd expect that from the source provided you know what "rethrow" does
8:43 gfredericks: clgv: not very good for "adding this just in case I need it" uses
8:43 clgv: gfredericks: that's a macro I wanted to write myself but even better if it ends up in catch-data
8:43 gfredericks: clgv: now if throw+ added a bit of mutability to the map...
8:44 clgv: gfredericks: I dont understand the problem with creating a new exceptioninfo object that gets the old as cause and as the current locals
8:45 gfredericks: clgv: depends on how obscured the original stacktrace is
8:46 clgv: gfredericks: I usually dont care about how complicated exceptions are. but then again I cheat since I have a graphical view similar to clojure's inspector that I use to view exceptions ;)
8:47 gfredericks: clgv: I just mean it shouldn't be any more difficult to find out where the original exception was thrown
8:47 I feel like having a length-20 cause-chain could make that difficult
8:48 clgv: but you only get additional exceptions added when you use the macro...
8:48 gfredericks: yes
8:49 clgv: otherwise you need to substructure the locals meta to provide information about the call site
8:49 gfredericks: I guess you're thinking it would only be added during debugging?
8:49 chouser_log: having trouble with the computer that logs this channel ...will be offline for a while.
8:49 clgv: currently, this is not the case but could be added...