I'm making it a goal to stop going down the path of making generalized tools before I specifically need one

Rabbit holes all the way down, that's the story of my life 🙂

I've definitely been there

Is there a predicate for exceptions? e.g. (= (foo (/ 1 0)) false)

slack needs a paren balancer 🙂

That looks like a job for macros

not sure if there's an existing one though

I'm not even sure how I would implement a macro like this. My lack of Java knowledge is showing. It's essentially a pure version of try.

Why not just use try?

yeah, seems like you can even make foo as a macro that wraps try

I wasn't aware I could have try return a value rather than perform an effect

the last statement in the body would return with a catch

http://clojuredocs.org/clojure.core/catch

(defmacro try-result [body]
  (try ~body
       (catch Exception e
         false)
       (finally
         true)))


(= (try-result (/ 1 0)) false)

might require some edge cases, but the base case works

Does Slack not support Clojure highlighting?

does that make sense @sophiago?

Yes, thank you. I was trying that outside a macro

the problem is you want to delay evaluation, other than a macro, which doesn't require anything funky like eval and escaping list forms, there isn't a straightforward way to do that

that is, delay evaluation of whatever may cause the exception

Yup, makes total sense now. I did actually try wrapping it in a delay before using try so that was at least the direction I was thinking

I think delay you'd eventually have to run it through the try catch pattern

once you force

(let [divide-by-zero (delay (/ 1 0))]
  (try (force divide-by-zero)
       (catch ArithmeticException e
         false)
       (finally true)))

the problem with this is you won't be able to make a function that takes the expression as an argument

cleanly that is

(defn try-result-fn [expr-literal]
  (let [divide-by-zero (delay (eval expr-literal))]
    (try (force divide-by-zero)
         (catch ArithmeticException e
           false)
         (finally true))))

(try-result-fn `(/ 1 0))

maybe that's not terrible, but not sure how evil eval is in the clojure community 🙂

I have to run to a meeting, but your macro is always hitting the catch block in my use cases. I think due to the type of exception: (try? (apply concat [[1 2 3]])) => false

my mistake, I misused finally as an "else" case. Rookie move 😞

@theeternalpulse there are lots of java devs who do the same thing 😛

(defmacro try-result [body]
  `(try
     ~body
     (catch Exception ~'e
       false)))

this seems to work, I'm sadly lost when doing macros and using stuff like ~'

I guess I'm not understanding what is ultimately trying to be accomplished that a standard try-catch-finally block can't accomplish

I'd advise not do simple abstractions of something already simple like try-catch, it hides a lot if you make it too generic

@sophiago The "pure" version of a try in other languages is a Result m***d

Definitely goes against Clojure philosophy

but a full one of that thing is usually overkill

anyways, this is the macro i use

I'm not seeing the point of that

If it fails it will catch. If it didn't catch it didn't fail

Im sure someone else can think of a better use, but my logic for parsing a message from kafka was basically just to convert it from json to a map

but kafka doesnt like throwing an exception at that level

so my function to parse the string from kafka was (fn [msg] (attempt (cheshire/parse-string msg)))

It might be just self justification, but as long as something is a pure function and doesn't do something convoluted I think its pretty much in the safe zone for not violating the clojure philosophy.

(feel free to yell at me; everyone

@emccue I think it's reasonable to encapsulate exceptions sometimes, and that seems like a reasonable use case, but the unwrapping and rewrapping of the success/failure values can be more trouble than it's worth, if it pollutes upstream code. Definitely a case of evaluating the trade offs carefully.

Wow, my meeting went for over two hours so I'm glad other found the discussion I provoked useful 😛

For perpetuity: I never use try/catch, but I very frequently have a pattern where an argument to recur will fail right before the predicate triggers the base case and have never come up with a uniform way to handle that.

I usually can get by calling the predicate on next of whatever coll I'm processing, but that usually ends up with unnecessary let bindings to prevent code duplication (even though HotSpot will often inline them) and then occasionally I'm faced with situations like what prompted this where there's no analog to (empty? (next ..))

wrote this little article-like introduction to Clojure for my fellow FE team members at my workplace https://github.com/geganizharadzeatamido/clojure-wiki-for-amido/blob/master/README.md

trying to convince them we should start using clojure in our projects 😄

@bravilogy the "Clojure for Java Programmers" videos could be useful: https://www.youtube.com/watch?v=P76Vbsk_3J0

@bravilogy: > Configuring and scaffolding your application can be a pain sometimes. A typical package.json file includes plugins that have nothing to do with the application I'm trying to build. There's usually at least 6 lines starting with babel- and another 6 - 7 lines of eslint-, not to mention enzyme- or jest-, in a typical package.json. And then there's a config file for jest, webpack, babel, polyfill, shim and etc. So I end up creating these random config files to actually get to the point where I can start working on my application. And I'm not even going to mention the version incompatibilities in some cases where one plugin doesn't like another. As much as I like Clojure(Script), the above paragraph perfectly describes how I feel about my project.clj files for any non-trivial Clojure project I write.

@bravilogy two pedantic notes: it's JVM bytecode and "code can be compiled at runtime" is an oxymoron

It's also just difficult to make statements like that about all Lisp dialects ever. Your intention behind that one isn't true for most.

The only reason I mention things like this are because I think the main turnoff to functional languages is the idea that they're purposefully obfuscated, when in reality misunderstandings just get passed on (not saying I haven't been guilty of that myself). You can draw an easy comparison with pointers: a shocking number of professional developers don't understand them, but few would claim they're some ivory tower academic concept. It's just a field that takes learning and the job market encourages shortcuts.

(by "field" I mean programming in general)

hmm I see what you mean @sophiago. should I remove those lines?

@bravilogy I do think those are very important things to mention. You can just substitute "JVM bytecode" for the first part. The second requires a bit more complicated explanation so I suppose I would rephrase it focusing on the benefits. Like basically describe what a REPL is and how compilation happens there too, but I would even find phrasing to ease them into the idea of working with a REPL.

I'm guessing you can draw on experience with something similar outside of Java. Python maybe? And then highlight the fact that code is actually compiled there and that should blow some minds.

yeah I actually think that I’m missing more about REPL

I just sort of mention it. And I think it’d be a good idea to perhaps show a few screenshots as well

I know for a fact that none of my team mates have any idea what REPL is

Yeah, I bet you can find a gif

easier to create it myself 😄

True 🙂

thanks for suggestions

Np. Thanks for putting up with my pedantry 🙂

I mostly came here for the pedantry

Reminds me of this: https://danielcompton.net/2016/07/11/people-are-worried-about-types 😄

Is it a good practice to include examples in docstrings for functions ? I see it's not used in Clojure core but I am not sure if there is a standard place to include example code for a function.

it's not a rare sight but bear in mind unit tests also serve as examples

Yes, good point. But most of the users just use the jar and docstrings for docs and hence thought adding examples there will give them quick access.

Hello guys

is this very bad practice ?

@abdullahibra please use preformat back-ticks. Your code is being bolded where you have an asterisk *

i'm in situation which need to make a recursion and save some state while make this recursion to the end.

so i thought i can use an atom for keeping this state while doing recursion, maybe i can use loop/recur

you likely want to use swap! instead, but you might want not to use an atom and use loop/recur

that's good

thanks 🙂

so this is a bad practice right?

yup

guys if i have a tree with multiple branches and want to find subtree of node A, how can i do this using loop recur

that's my current code

anybody there/

?

@abdullahibra not an expert on this, but I’d use zippers for traversing a tree like that instead of loop recur http://josf.info/blog/2014/03/21/getting-acquainted-with-clojure-zippers/

@abdullahibra first thing to try would be tree-seq

@abdullahibra that's easy with specter:

(def CHILDREN (path (srange-dynamic (fn [_] 1) count) ALL sequential?))

(def NODES
  (recursive-path [] p
    (continue-then-stay
      [CHILDREN p]
      )))

(select [NODES #(= 'A (first %))]
  '(R (H (h 1) (h2)) (M (N (A (a 11)) (B (b 5))))))
;; => [(A (a 11))]

can re-use the exact same code for transformation:

(setval [NODES #(= 'A (first %)) (before-index 1)]
  '(Z 0) '(R (H (h 1) (h2)) (M (N (A (a 11)) (B (b 5))))))
;; => (R (H (h 1) (h2)) (M (N (A (Z 0) (a 11)) (B (b 5)))))

and it will perform much faster than zippers

my recursive solution is ugly ?

the output has a bunch of spurious nils so it's not a solution

you are right 🙂

specter is rescue here

Recursive solutions are often easier to read/understand. The problem with recursive solutions is that you incur stack depth correlated to tree depth. Tree depth may be unbounded in your data, but stack depth is quite finite (which eventually means you break with a stackoverflow error).

I have a recursive problem which actually seems very hard to do in a declarative/FP way. I'm wondering if there are any tricks for this kind of forward-backward recursion pattern. x_n is defined in terms of x_n+1 and y_n+1. y_n+1 is defined in terms of y_n. Every time I want to get x_n from x_n+1 I need to do the forward recursion from y_1 up to y_n+1. The imperative approach is to do the forward recursion and store it in a list, getting y_1 up to y_N. This list of y's then gets fed into the backward recursion which gets x_n from x_n+1 so get a list of x_1 up to x_N. Forming the initial list first seems very imperative. Is there a more functional declarative way?

wait, how can you derive x_n from x_n+1 ? isn't that backwards?

is there a cleaner way to handle this?

(every? (fn [k v] (empty? v)) (select-keys a [:name :type :value]))

or put another way, is it possible to get the val of a key (not as a coll with vals) without destructuring or knowing the key ahaid of time?

(every? empty? (map a [:name :type :value])

i could do (comp empty? first vals) i guess ..

oh yea that’s way nicer.

alternatively (every? empty? ((juxt :name :type :value) a))

but the map version reads nicer to me

@michaellindon Normal recursive function definition could be used here, and as long as they are pure functions, you can gain a lot of efficiency in some cases by memoizing the recursive function.

For example, this is a horribly inefficient way to write a function to calculate the n-th Fibonacci number, which takes exponential time if you do not memoize it: (defn fib [n] (if (< n 2) 1 (+ (fib (- n 1) (- n 2))))

But if you memoize it, it takes linear time in n.

The core.memoize library can help you in creating a memoized version of a function: https://github.com/clojure/core.memoize

Memoization only makes things faster if the function would be called multiple times with the same paramters, which is definitely the case for the slow-without-memoization version of fib I show above. In the function you want to calculate, it might be the case that x and y would only be called once for each value of n anyway, in which case memoization would not help speed things up.

I have seen code in the wild that puts a function's return type hint before the name of the function (right after defn) and also right after the fn name, right before the arg list. Which is correct or are they the same? @alexmiller had suggested the latter a couple weeks ago, but the source for core functions often shows the former.

@ajs it's different depending on the situation. It's one way for deftype (I think on the arg list) and the other for defns

We were discussing normal function definitions so perhaps it's confusing for everyone as he suggested the contrary

Hrm, I may have that backwards

But I know defn and deftype are opposite

He referred to the difference between type hinting the symbol for the function's name, vs type hinting the return value. But I still see the former in core functions.

yes, from the deftype docs:

Method definitions take the form:
  (methodname [args*] body)
  The argument and return types can be hinted on the arg and
  methodname symbols. If not supplied, they will be inferred, so type
  hints should be reserved for disambiguation.

Two examples: https://stackoverflow.com/questions/6484899/type-hinting-return-value-with-or-tag-meta and https://github.com/clojure/clojurescript/blob/r1.10.238-25-g9c1c727/src/main/cljs/cljs/core.cljs#L4201-L4204

That's clojurescript, it might be different there

ROFL, then there's this gem: https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L684

"let's just put the metadata everywhere, it can't hurt"

I hope there is a reason for that beyond guesswork by its author

Is it possible for a macro to include a type hint in its emitted syntax? It's hard to know since hints are stripped when things print to repl, like with macroexpand

if you want to type-hint the return type, you should put before the arg vector, the end.

yes, some core stuff does otherwise, that’s (mostly) historical

@ajs yes, macros can return type hinted code, but doing so requires some care

(source defmethod) is an example

Found this too: https://stackoverflow.com/questions/11919602/generating-clojure-code-with-type-hints

... I'm working with midje a lot lately, and one of the things that I find frustrating is that we can't assoc to Metaconstants. I was wondering if anyone could enlighten me about the rationale

@acripps Pretty simple, Midje is not Clojure, it's a testing DSL, and as such behaves differently than Clojure in many ways

But perhaps some examples would explain what's happening? "can't assoc into" is a bit vague, what's the error you're getting?

@tbaldridge I got that 😛 ... I've taken a look at the source and Metaconstant implements clojure.lang.Associative, but it explicitly throws on (assoc ...) ... I would personally find assoc on Metaconstants handy (more explicit than just passing in an empty map, or a pre-populated map for unit-testing functions). I am assuming that since the implementation explicitly prohibits this, there is a rationale, I just want to understand and find out if there's a more idiomatic way to unit test where a value that I want to pass in as a metaconstant would be assoc-d

I'm a big fan of JCuda: 1. I write some *.cu files 2. I call launch-kernel from Clojure, passing it float-arrays / grid/block sizes 3. Hypothetically, even if the Cuda code creashes, the JVM is still fine. Is there something like JCuda, but minus the GPU. So it would be like this: 1. I write some *.c files 2. I call launch-c-kernel from Clojure, passing it float-arryas / ... 3. Said C code runs IN A DIFFERENT PROCESS 4. Even i said C code crashes, my Clojure/JVM is still fine. 5. Communication between Clojure/C is via copying int/float-arrays (willing to pay this overhead in exchange for C-code crashes not crashing JVM).

@qqq, that's fairly simple to do, just need to fire up a c compiler and mmap some memory

You can use the JDK ProcessBuilder, or the JRuby guys (Charles Nutter in particular) have some ffi stuff for fork/exec, or there are probably some other options.

with ProcessBuilder you can create stdin/out pipes

if the amount of data you pass between is small, that might be ok

http://blog.headius.com/2009/05/fork-and-exec-on-jvm-jruby-to-rescue.html

prob not the newest take on that but the right ballpark

I need to do this at 60fps (iClojure is passing some data to C, C caculates some new data, and Clojure uploads it back to GPU.)

I should probably go for a long running C process with network i/o instead of forking a new C prog 60 times a second?

No, at 60fps you need mmap or a interprocess queue

I'm familiar with mmap from C land. How does CLojure use mmap ?

https://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html

but also look at https://github.com/real-logic/Aeron/wiki which is a high-speed 0 copy messaging system

yeah that’s a whole different ball of wax so forget everything I said :)

but also ask, why? If you care that much about performance, you'll lose it in the communication unless you're super careful

@alexmiller: sorry for dripping requirements bit by bit instead of stating everything upfront

and you haven't mentioned latency

Is 'C' using the data passed to it to calculate the new data? Then that's uploaded back to the GPU? Maybe the GPU could just manipulate the data itself, directly?

60fps with 100 frames of queuing is a lot different than real time 😄

Yeah cuda can mmap data from local memory (or the disk, which is mind blowing),

Let me take a giant step back. I'm building a clj/cljs app that uses OpenGL/WebGL. My currentproblem with CLJS is that calculating the data for the vertex buffer objects is causing lag. On the CLJS side, I intend to have C code (running in Webassembly) to do the calculations. On the CLJ cide -- I could do the code in Cuda, but I'd prefer for both sides to share code. One solution around this mess is to do GPGPU, but vertex-transform-feedback requires WebGL2, and iPads only support webGL1, which means I can at most use "render to texture" if I want to do these computations on the GPU. Thus, I'm currently leaning towards doing these cals in C / webassembly.

(as an aside: webcuda/webcl would solve my problems and make my life much nicer)

I'd look at the calculations code. This is a lot of work to get around something that shouldn't be a bottleneck. Remember, Minecraft was written in Java, runs on almost everything, and consistently renders about 512k cubes at 60fps.

And doesn't use GPU shaders

Yup, Minecraft was Java on top of LWJGL. Lightening in a bottle 🙂

I suspect Minecraft did not have code like this: (defn vec+ [lhs rhs] {:x (+ (:x lhs) (:x rhs)) :y (+ (:y lhs) (:y rhs))})

Also, I believe most minecraft cubes are static. I'm not familiar with scenes where, say, 1000 cubes are having their locations being modified independently (one uniform for all 1000 doesn't count).

Lastly, mine is a "text editor" of sorts, and people are much more tolerant of lag in fps than in wysiwyg editors.

that's probably your issue, to be honest, over use of GCs can kill performance. But rewriting that in JS/Java isn't a bad idea

Or even just switching to deftype vs maps helps a lot (I know that from personal experience)

We're getting a bit OT now, but handling 1000 objects each with their own transforms is exactly what GPUs are great for, can't you perform the transforms on the buffers during rendering, on the GPU instead of on the CPU?