Fork me on GitHub

@emccue: I failed to express this clearly: I'm using portkey in production. It works fine for me. I haven't had any problems with it. There's also #portkey , where the authors hang out on if you run into issues.

Garrett Hopper01:04:11

I'm attemping to integrate with lwjgl for game dev in Clojure, but I'm having some trouble with threading and error handling. Is there any way to route errors from thread to the main thread without dereferencing a future and making the main thread hang?


Im not sure off the top of my head


The cleanest solution is probably going to be core.async


but thats just a feeling: i havent researched it at all


@ghopper I used lwjgl in the past, though only for 2D games and as such decided multi-threading was of little benefit for the headache. If you like it, play-clj will feel very familiar. It's a binding overtop libgdx which itself is very similar (or uses even?) lwjgl for some features. There's a #clojure-gamedev channel, too.

Garrett Hopper01:04:50

Yeah, I think there might be some good error handling core.async constructs. I am actually using libgdx, @the2bears. I need to have multi-threading for the sake of having the game running and a repl for interaction. Thanks for the channel link.


not sure if this is helpful: I looked at lwjgl, played with jogl, and ended up going with cljs + webgl; for whatever reason, webgl just seemed easier to use


can def-type be used to speed up arithmetric, because compiler does not know what (::x obj) is, but it can know that (.-x obj) is an int <-- is this possible, or is this unrealistic ?


they can, deftype fields can have type hints


it will not store primitives tho


Looking for recommendations for a persistent scheduling/job library similar to Ruby’s Sidekiq for Clojure. Ideally using Postgres as backend.


quartz does that I guess. it has some jdbc locking scheme. I can't actually say I've used it though.


it tells the compiler that the function is a one-off


I forget all the implications of that


I got a question with regards to using the generators in clojure.spec.alpha. I created and tested a generator using clojure.test.check.generators, which works fine on its own, but I can not figure out how to wrap it in a way that it would be suitable to use with clojure.spec generators, if this is possible.


yeah, that would be an option but wanted to see if there’s an option that doesn’t imply adding more infrastructure


Using Postgres using locks is a good option as well


@newres does wrapping it with`constantly` work? or something like (fn [] g)?


@gfredericks I tried it but I could not get it to work. I also tried rewriting it with clojure.spec.alpha.gen, as if I understood correctly it should essentially be a wrapper around test.check.generators but then I get something along the lines of 'CompilerException java.lang.AssertionError: Assert failed: Arg to one-of must be a collection of generators (every? generator? generators), compiling:(core.clj:21:28)' which also makes me scratch my head.


@newres have some code you can share?


@gfredericks I want to do something along the lines of (def spec-gen (sgen/fmap #(apply str %) (sgen/vector (sgen/char-alpha) 0 100))) where sgen is the clojure.spec.gen.alpha. I am trying to check if it works by attaching it to a spec and generating values for it, but I am running it all kinds of errors. Either the gen is not correct, or the way I want to attach it to the spec is wrong (I am using and adding this as a gen).


you can tell if something is a generator by calling clojure.test.check.generators/generator?


with-gen wants you to supply a 0-arg function that returns a generator


@gfredericks well (print (gen/generate spec-gen ) seems to work so I think the generator is valid, so it must be in the way I attach it to the spec.


how do you attach it to the spec?


using spec-tools i use st/create-spec and with the key :gen value spec-gen


maybe i need to try with with-gen first see if that works differently


ah, ok it seems when i put in the generator it has be to be wrapped in a function call as a value


then it seems to work with s/gen to get the generator attached from the spec. I thought putting just the gen under :gen key would work and I probably got confused by the error message


Thanks @gfredericks for helping to sort this out!


are there plans to spec the most important functions from the core library? like reduce


there's a lib that aims to do just that: . It states it might cover fns one day, but nothing new for now, I suspect since specs is still in alpha and subject to changes we wont see much change on core specs until it stabilizes

👍 8
parrot 4

(it's just my interpretation of the state of things)


that’s correct


but fair warning that the most generic core functions (like reduce) are polymorphic enough that they are hard to spec in ways that actually provide much value


any eta on the spec changes by the way?


so I can't do Haskellish (a -> b -> a) -> a -> [b] -> a with spec?


it's useful because you know your reducing function's types have to align with the data you have


sorta, but specs aren't types


yeah, I just want :thinking_face: constraints


no guarantee that "lastname" type is passed onto your function from an actual "lastname", it will be a predicate (ex: string?), so it has pros/cons


reduce doesn’t have those kinds of guarantees


heck, alright then thanks for taking your time to answer 👍


reduce takes a 2-arity function, an init value (anything), and something reducible


there isn’t any way with spec to connect the arg of the inner function to the values of the outer reducible

😞 4

and there isn’t even an easy way to spec “reducible”

Garrett Hopper23:04:14

Is there a way to write a primitive Java float besides (float 0)? Having (float) all over the place when calling lots of Java API methods isn't very pretty.

Garrett Hopper23:04:58

:thumbsup: Thanks


Clojure fundamentally doesn’t believe in floats :)

Garrett Hopper23:04:02

Haha, fair enough. 🙂 I was a little suprised when I found out 0xFF00FF syntax worked, so I thought maybe there was hope.