how do i include a java gateway class into my clojure project?

@samlinncon: look for leiningen's :java-source-path option

@samlinncon: :javac-options may also be useful. just decide where you put your java sources, define the source path (and jvm options, if needed) in your project.clj, done.

okay,i need to include an external java file in my project

do the threading macros produce lazy seqs?

somehow my google-fu fails me

ouch, nevermind, that question is nonsense

hi folks! I am asking this before doing any research, so sorry for being lazy. Do you know if there is any http client lib that respects the http cache headers like a browser would?

I don't know i f there is a clojure library that wraps it, but apache httpcomponents has this: https://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html

should be fairly straightforward to call into that from clojure

Random question: does a call to (om.next/class->any reconciler SomeClass) generate a n anonymous instance of a component SomeClass on the fly, or does it return an actual, matching instance in your application?

Woops wrong room

Meant for #C06DT2YSY

cool, thanks @jbaiter

hey @marcosmatos @jbaiter the excellent https://github.com/dakrone/clj-http is clojure's wrapper for the apache http components project

Ha, I am looking right now at the clj-http code, it doesn't say anything about cache on the docs

thanks for the tip =D

yeah- you have to setup your own cache, but incorporating that cache should not be difficult. see https://github.com/dakrone/clj-http/issues/129

see core.cache for a suitable in-memory cache https://github.com/clojure/core.cache

clojure core.* libs are full of surprises, I didn't know about core.cache

is there a way to tell prismatic schema that I only want clojure not clojurescript? We are using it on a non cljs script app, but it schema downloads google closure and we don’t want that in prod.

hey @roberto schema seems to be packaged in part as cljx files, a clj/cljs solution that preceded the reader conditionals approach introduced in 1.7. you may be able to produce a clj-only artifact for inclusion in your app by examining the https://github.com/lynaghk/cljx workflow

on a related note, is there a way to make one field in a schema depend on another? say I have a field that is a set of strings, and another field that is a string. I would like to verify at runtime that the string-field has a value that is in the set-field

treat the set as an enum?

Does anyone know how to create test fixtures which selectively apply to test vars in a namespace? Ideally something like (use-fixtures :each :functional test-system-fixture) to only run that fixture on tests with :functional true in the test var metadata. This is to avoid creating separate namespaces for separate fixtures. I know leiningen retains fixtures when it does test filtering by selectors — but i’m actually looking for something like the inverse where all tests are run, but the fixture only applies to a subset. Selectively applying fixtures instead of selectively executing tests which have fixtures.

@bjr Fixtures can't do that, but you can make a macro or function and call it in each test that needs it.

@stuartsierra: Right, but that reintroduces the repetition fixtures are so good at removing.

Is it really that different from repeating the metadata on each test?

No, it’s really not a big deal.

hey all... is there a good free platform for hosting clojure on that provides a database backend?

should I be looking at heroku or something?

I just feel it would complement test selectors very well if fixtures could do that.

and I see monkey patching clojure.test to add this goes deeper into refactoring test discovery and execution than i’d like to go

I wrote clojure.test, but in retrospect I think "fixtures" were a mistake.

That’s interesting. How so?

@triss Heroku has a free offering and a free database plan. Here's a guide https://devcenter.heroku.com/articles/getting-started-with-clojure#introduction

"Fixtures" don't do anything you can't do with functions/macros. And they can lead to implicitly shared state across tests.

thanks @codefinger

Tying fixtures to namespaces was a mistake, too. The boundaries don't line up well. E.g. sometimes you want a "fixture" in many namespaces, sometimes only on some tests in a namespace, as in your case @bjr.

Yeah. I suppose there is this rabbit hole of functionality that could be added, but in the end, it can never be more expressive or as simple as writing your own functions or macros to do the exact same thing.

exactly

Well then. I guess it’s time to write some ‘fixture’ macros — they’re probably even going to be the same amount of code as the fixture fns I already have. Thanks @stuartsierra .

You're welcome

so I'm using a core.async using database client (https://github.com/apa512/clj-rethinkdb/blob/44d4023937d5944a8a454b173204943aa20f6227/src/rethinkdb/net.clj) and as soon as I create as many connections as the core.async excutor has threads closing any connection just blocks forever on a <!! line (https://github.com/apa512/clj-rethinkdb/blob/44d4023937d5944a8a454b173204943aa20f6227/src/rethinkdb/net.clj#L95)

is there some simple way of avoiding this or is this to be considered a bug in the DB client?

Without looking at the code, sounds like a bug to me.

I opened an issue w/ repro here: https://github.com/apa512/clj-rethinkdb/issues/132

(async/go-loop []
  (when-let [query (async/<! send-chan)]
    (log/trace "Sending raw query %s")
    (write-query out query)
    (recur))))

Also if there's some crucial mistake in core.async usage shouldn't that show up earlier (i.e. before there are as many things as executor threads?

Cursory look: write-query appears to be doing blocking I/O, which is a no-no

And it's missing exception handling.

and trace is missing an argument

^^

I wouldn't use that library if I were you.

the core.async usage is suspicious, to say the least.

sometimes the most "idiomatic" clojure is wrapping the java library

Sorry, probably not a useful recommendation to you at the moment.

New on this project, don't want to pull the carpet under a running thing I don't yet fully understand

yeah, understood

But yeah, I'd equally prefer just some dull wrappers around the Java API

You could be a good boyscout and fix the library.

For now that's what I'll do I guess (or at least I'll try to 😉 )

Removing core.async isn't an entirely bad idea.

but again, i didn't look too closely at the lib

yeah, still in the process of understanding why it was used in the first place. Also there's an in-progress PR of exposing a core.async api as well /cc @danielcompton

@ghadi: why is the blocking-io in the go-block a no-no btw? Isn't that part of the point?

blocking/suspension in go-blocks is managed by the go-block mechanisms. In order to have it be visible, it has to be a channel operation #{alt! alts! <! >!}

those are the only things that the go-macro understands

it can't just see arbitrary code and know it needs to be able to suspend there.

So what happens is that you call some I/O, and it ties up a thread in the go-block thread pool until the I/O completes.

If you use only channel operations, I've tested >2M go-blocks running.

I/O needs to be moved and managed explicitly.

@martinklepsch: (not to steal @ghadi thunder) the idea is in "letting it park": i.e. free up the real OS thread while going doing something, I/O in this case. ideally, an async I/O would be used in a go block where the responses would be put on a channel once they are ready.

options include doing your i/o in a thread block and interacting with those operations from go-blocks using channels

so basically this (write-query out query) might be better written like this (<! (thread (write-query out query)))

Thanks for your help @ghadi and @tolitius, I guess I'll take a closer look at the Java driver thats available and see if I can get something simpler working based on that.

@martinklepsch: I didn't write the core.async connection stuff and would be happy to see it ripped out. The RethinkDB Java driver has just had the first thread safe release, so I'd be happy to have that take over all of the connection handling stuff.

Hey guys! I'm trying to build a REST API with Compojure using the compojure-app default template. My question is: Given this template, what is the best fit for the connection to the database? where to put that code? Im using Monger to manage MongoDB

I just want to avoid the replication of the connect code

@enyert: Not sure it's the best approach, but so far I've been happy creating a db namespace, putting my connection code into db.core and any queries into db.queries. Makes it easy enough and is easy to change if you find a way you like better in the future.

http://www.luminusweb.net/docs/database.md has some good ideas that will apply as well

@shaun-mahood: Thx you! 😃

@danielcompton: ah cool. I somehow interpreted that PR as a sign that you like the current approach. If you're interested I'd be open to pairing or similar to get this into a reasonable state.

Alternatively maybe it's also reasonable to just start from scratch and taking the things that are good over (e.g. query mapping) @danielcompton

I think/thought (not so sure now) that presenting a core.async interface would be good, but I'm ambivalent on it for connection handling

Got some free time, looking for a Clojure project to help with. Anyone want average Clojure dev, 1.5yrs exp?

@i3ic have a look at #C05006WDW

@martinklepsch: would be keen to pair on a rewrite

hey folks. i need to convert from stream processing to batch processing. do you have any advice on clojure or java libraries to use where i can keep adding items to a queue and have a handler fire on a whole accumulated batch when the batch size is reached?

There is something for that.

I forget what it is though, sorry.