Fork me on GitHub

@shriphani interesting. it sounds like what you want to do is remove the entire dependency from your project.clj and instead make sure it is visible from -Djava.ext.dir. the then classloaders should both be sun/misc/Launcher$ExtClassLoader


Hi all. Can anyone suggest the following code results in a Assert failed: Args to tuple must be generators exception?


@paulspencerwilliams: prop/for-all expects bindings to be generators, gen/sample returns sequence of values


@immoh: just picked up on it - I needed to lose gen/sample and it works. Well. It fails, but for a good reason now 😉 Thank you.


@solicode: no, you’re right, I don’t need to transpose. Your suggestion is good!


I need to get the value (not just booleans), so I’m using reduce as @jaen suggested.


(map #(reduce (fn [a b] (or b a)) :default-value vs) as bs cs …)


@jonahbenton: about that advice from yesterday about java.ext.dirs , how do I guarantee that the resulting jar works with lein deploy.


@shriphani: gotcha, yeah, one doesn't have that level of control with an uberjar. Capsule solves this problem:


@jonahbenton: is there a simple example? The minimal config doesn’t seem too descriptive


@shriphani hmm, i don't see one offhand; the basic idea is that you add the capsule plugin to your profile, and a :capsule key to your project, then you can use lein capsule to package the app. A capsule is a .jar file that includes a shim class plus your packaged app. The shim explodes your packaged app- including the JDK you want if specified- and runs it in accordance with your configuration, specified in the project.clj :capsule key, including memory settings and all the bells and whistles. The reference to the :capsule key is here: The :capsule options you probably care about are: * [:types :fat] - you may want to package a specific JDK with your application * [:execution :runtime :jvm-args] - specific memory settings, etc * [:paths :native-library-path] - where to find your library on the file system. This should correspond to a directory local to your project and capsule should include it at packaging time


I see. And when I finally do lein deploy clojars (say), it is going to just work ?


well, you will get a .jar file from capsuling, and that jar file is runnable with java -jar, but lein deploy may not know where to look for that jar file after capsuling


lein tasks expect to find artifacts in target/ and names artifacts in accordance with maven coordinates; capsule by default writes to capsules/ and needs you to specify the capsule name, including version, by hand. but maybe by fiddling with capsule's output directory and with the capsule name lein deploy can be tricked into pushing a capsule


hm interesting.


and if a third party includes this project’s coordinaties in their dependency (say), then would it all still work ?


hmm, i don't believe so. capsule is for producing runnable applications that require additional configuration or packaging beyond what's possible with an pure java jars and uberjars. A third party would not able to utilize a capsule .jar as a library both because a capsule on the inside doesn't look like an uberjar, but more importantly due to the same limitations that were already being worked around. if it was possible to smoothly package and utilize native code in the existing jar and uberjar formats then solutions like capsule wouldn't exist


but if what you're trying to do is produce a library that consumes this other library, you should be able to just do that


it would be incumbent on the consumer to manage their own jvm configuration


you can just use capsule for your own internal testing


e.g. have one project, a library, that consumes this native library, and have a second project that uses capsule that consumes the first and tests and so forth


then you can push the first library and point to the second as an usage example


@jonahbenton: would the first library in your example use java.ext.dirs or would it include this as a dependency ?


@mikeb: I'm trying out Foundation in my app, and I've run into a couple of issues. To begin with, as soon as I started interacting with the database, I got a bunch of debug logging in the REPL. I'm sure this is very handy for development, but it should be off by default! I was able to use an insert query to write to my database, but when I tried a select query, I got this result:

(pg/qry-> conn (pg/select :users {}))

=> NullPointerException   clojure.lang.Reflector.invokeNoArgInstanceMember (
That query should simply evaluate to SELECT * FROM users;, right? I did get the same result when I used a template query:
(pg/qry-> conn (get-users {:offset 0 :limit 30}))
Any idea what I'm doing wrong? ...come to think of it, I should open an issue instead. Slack is not great for async communication...


Is it possible to mutate slots in a defrecord? I feel like I need to do this to implement a java interface which has an "init" method which sets up state that might be used later by a "process" method.


not in a defrecord, but only in a deftype @cddr. It's intentionally obtuse: mark the field with ^:volatile-mutable unless you really know what you're doing


then you can use set! from within the body of the deftype


this sets up a java mutable field with the volatile marker


Thanks. Is this an "idiomatic" thing to do when interoping with java or is there a better way?


Or maybe I need to provide more info about the java interfaces


it's an unfortunate reality of interop with interfaces that assume mutation


you can also use a non-mutable field in your defrecord that is an atom


that's the other common alternative


you can reset! / swap! it , etc.


Yeah I thought about that. But I got stuck at how to initialize it as an atom. Is there a way of defaulting fields in a record?


commonly you see a defn that serves as the constructor


btw, if you do (defrecord Foo [a b c]) you get two extra functions for free: ->Foo for a positional constructor taking a b c, and map->Foo taking a map


Yeah but I don't have control over construction. I just have to give the java code the name of a class that implements the interface (this is samza)


you can build in the defaulting using map->Foo




which is the field you need to remember?


kafka & samza are really stupid about this


local storage


i only see

process(IncomingMessageEnvelope envelope,
                      MessageCollector collector,
                      TaskCoordinator coordinator)


Oh sorry. Actually it's InitableTask




just use an atom until it doesn't work for you anymore


oh, you can't provide a constructor..


Not as far as I can figure out.


volatile-mutable it is then


But you may have to gen-class...


OK Thanks.


hey @shriphani: the first library would not/could not refer to java.ext.dirs. there is no way to specify that sort of external-to-the-jvm configuration in a library. the second project- like a sample or test application- would be where an example or roadmap could be provided


@amacdougall: I think there's a problem with the way you've defined the db spec. it should be (def-datasource ...) with the dash, not a standard def with a map.