in a function, is thre a easy wa yto force all arguments to be strict

i.e. if they're lazy seqs, realize them all instead of keep them as thunks

(this is to get better error msgs)

sometimes, something bad happens during an lazy seq; but instead of having the error trigger when it's 'created', it's stored as a thunk, and does not get evaluated until it's needed

and by the time it's needed, I can't make sense of "what was the stack frame when this was incorrectly constructed" ?

doall

or if you just want to realize them, it depends on the collection, I think. last might work. You can map a nothing-fn across it

doens't plain map just create a new lazy list

/clj (let .[x (map println (range 10))] 20)

is a sequence the right data structure in this case, though ? sounds like you need a vector instead

I'm not sure; I did not reailze the importance of this issue until just now. 🙂

(let [x (into [] (map println (range 10)))] 20)

lol 🙂

dammit

I get you waht mean

(into []) and mapv both work

i would go for mapv then

I'm asking stupid questions now becuase I can'tif gured out where my bug is.

Is reduce laxy ?

Does it return a thunk or a value ?

@qqq reduce is not lazy.

Unless you do async the stacktrace should still tell you a lot. Also naming local functions help stacktraces

it's #react it seems I'm creating a lazy list somewhere

then, at some point, when react tries to render it, it realixes the list, and then it goes "oh shit, this function call fails since the args don't match up"

so I get a bunch of react stack frames instead of the correct stack frames

@qqq (Integer/parseInt "3fd" 16) 1021

oh, the 16 gives the base, I'm an idiot 🙂

I was trying to figure out how it inferred 'hex' from '3fd'

@qqq (Integer/decode "0x3fd") 1021

anyone familiar with this eastwood error?

Local name 'G__36720' has been given a type tag 'null' here:
nil
dbgx for case :op :local tag=null (class form)=class clojure.lang.Symbol (sequential? form)=false form=
G__36720

in a recent core.async release there were some changes to how locals "closed over" by go blocks were handled, which involved some fiddly bits with type hints

https://media.giphy.com/media/WM1l6qQipStRm/giphy.gif

me right now

@noisesmith can you share the affected code?

@bronsa - sure, I’ll make a gist with the pre/post - I still have the edits in history and the good state is safely in git

thanks

@bronsa this is the raw code but not the full ns, if you need a runnable reproducing case I can try to do that later https://gist.github.com/noisesmith/3aa431f238df82f05a159f4ff8ac1816

yeah no worries this should be enough

thanks

thank you, having eastwood around is great

does anyone know any simple clojure library that would let me write bytes out to kafka to a specified topic?

specifically, the latest kafka, 0.10.2 (but honestly, i guess it doesn't matter for producing so much?)

I use clj-kafka, but honestly any of the various kafka wrappers out there will do it I bet, and it’s not hard to do from regular old interop either

clj-kafka has a redis dependency that my tech leads are balking at

just somewhat overwhelmed by the number of out of date choices

that is really weird - you don’t even need the redis dep…

@socksy the number of alternatives is, to me, a sign of how easy it is to just access the api directly

(wish I had that stuartsierra rant about wrapper libraries handy, seems applicable here)

redis is for consumer locking etc that most libraries are using zookeeper for

right, I know

and redis isn’t the thing people should be using…

> If you see a Clojure library wrapping a Java library, examine it to see if it adds any new power or abstraction over the Java API. If it doesn't, use the Java library.

I swear I saw that in a blog post … can’t find it though

well for this library it's claiming speed at least is a reason to use redis there (after all, it's the "kafka fast" library :))

as for accessing the java library directly, there's a hell of a lot of verbose code involved with opening and closing and setting up properties and filling in classes that i would rather not do

the properties will accept a hash-map of string to string, all the wrappers are doing is letting you use keywords

i'm just looking at kinsky a bit closer, and i see that i could probably swap out the opinionated serializers with any old thing that returns bytes

really? I didn't know that worked

clojure hashmaps implement java map interfaces I suppose?

yeah, the kafka api isn’t so bad - it’s actually scala code internally with a java facade so it’s not like it is mutable or wacky oo factory zone

right, exactly

i am not sure i can make that statement blankly about all scala code, but yeah :)

sure - but it’s decent scala as that goes

good to know

I think I found clojure with a go backend a while ago, but forgot what repo it was. Does anyone know of such a repo?

I wonder how that works w/o dynamic loading in go

honestly “reimplement <lispy thing> in <foo>” hits my conceptual spam filter, there’s so many 5% done projects like that out there

@iwankaramazow there were a few

I remember reading in the readme that the author Didn't have the time anymore to continue.

that’s the usual status of such projects

Anyway, not that important

for the printed return value of an atom, like #object[clojure.lang.Atom 0x2a926e85 {:status :ready, :val nil}], what is 0x2a926e85? Is that the unique id of the atom? Or a thread id?

system.identityHashCode()

basically the memory location, not that you can do anything with it

https://github.com/clojure/clojure/blob/21a7d5192d7503c58dc97256617beae7c330b7bd/src/clj/clojure/core_print.clj#L113

rgr. For the purposes of a unique id?

#object literal printing is relatively recent

http://www.javaworld.com/article/2073618/java-s-system-identityhashcode.html

It isn't guaranteed to be unique because it is a hash

"That being stated, there are situations in which the hash code returned by System.identityHashCode(Object) is "unique enough" for the problem at hand."

Understood

here's the clojure iml (https://github.com/sio-iago/realworld-starter-kit/) for the realworld project (https://github.com/gothinkster/realworld/issues/57)

Under what conditions will an atom be in either a :pending status or a :failed status?

agents, I have a better idea of there

an atom would be in neither ever

so, this, for an atom, is generally superfluous? https://github.com/clojure/clojure/blob/21a7d5192d7503c58dc97256617beae7c330b7bd/src/clj/clojure/core_print.clj#L422

the deref code is shared between all kinds of things that implement IDeref

understood

atoms are an interface IAtom these days, so you could maybe make your own thing that implements IAtom and triggers those states when printing

I'm implementing a "SharedAtom" idea and I'd like to keep into to the Clojure ref structure as much as possible. I'm building in in ClojureScript, but since Clojure reference types have semantics closer to "shared" scenario, I'm looking at what Clojure does, beyond ClojureScript.

Basically two atoms that synchronize between two thread contexts (like a worker and the main thread)

atoms are basically a mutable cell with the ability to compare and swap the contents, you would have to deviate from that a lot to get a pending or a failed

actually, maybe failed would be a result of printing out you custom atom when it couldn't reach its backing store

don't update functions attempt to run 500 times on atoms and then give up?

Currently, one side is an "owner" and the other a "subscriber" of sorts. The owner has a synchronous context over the value. So a swap! could return the value immediately. From the subscriber context, any mutations (`swap!`) must be asynchronous operations.

not too familiar, just something i thoughtt i remembered

I've got compare-and-swap going apparently fine right now

I don't know, but if that is the case, that failure would (should?) show up on the thread running the cas

(with 10 retries, but I would like to know the Clojure default)

clojure doesn't have a limit

runs in a for (;;) { ... } loop

ah

So, I do plan on having a Pending implementation within this SharedAtom, so that I can implement callbacks on the asynchronous return value. But I'm not sure if I should queue up future swap!s on that queue, or let callers bang away in a race.

atoms are synchronous

they are. But mutations on the subscriber side of a SharedAtom can't be.

I would strongly advise you against calling what you are creating an atom

it doesn't sound atomic in anyway

They're derefs/reads can appear to be though... But I suppose the subscriber could be working with an old value...

I was thinking about calling it a Molecule

stale reads are not atomic

right

Any ideas for a better name for what it is?

quark? :)

I'm going to be implementing something similar to agents, but this particular structure is simpler. No threadpool. Just a dedicated thread (worker) attached to the atom-like thing

I would get rid of the shared mutable ref

share information over channels maybe

eh?

I would stick a queue between the bits you want to send data to each other, instead of a mutable reference

ah

atom -> schmatom?

🙂

I liked quark

Molecule signifies multiple atoms being linked together though, which is nice.

no that is terrible

because of the "atomic" idea?

atoms are not coordinated more than one atom is a race condition

Well, all swaps take place on the owning thread

there is no owning thread

atoms are not owned by a thread

Not it Clojure

But in ClojureScript, there's this thing I'm making, which is potentially interesting and useful, and I'm okay with not calling it an "atom" but the way you interact with it is very similar.

The fact is, if you want multiple workers to update the value in an atom in another worker, in clojurescript, the safety semantics we usually associate with "atoms" no longer hold in clojurescript. Those workers do not have a consistent view of that atom, like threads do in Clojure. So I'm thinking about what kind of thing might restore as much of that safety as possible.

quantoid (quantum entanglement)? strange atom? dark atom? :) it's all marketing/pr in the end, heh.

it doesn't sound like you have restored any safety

Well, I have compare-and-swap... and currently, operations are safely retrying. And the resulting value is as expected.

Many mutation operations are treated asynchronously in CLJS anyway, too. So, like, imagine you have this reactive-quark in place of a ratom in reagent. You swap or swap-off on the reactive-quark in your component action handler. Then, when the new value is calculated on the remote thread and asynchronously updated in your reactive-quark, all the necessary watchers are alerted and your components automatically update, like normal. But your work was done off the UI thread.

Does Set work on java.util.Set or only on clojure.lang.IPersistentSets?

A diatomic molecule is one with just two atoms. But too much overlap with 'datomic`

(I know it doesn’t error, but there are all sorts of values for which it returns incorrect results silently.)

Set meaning clojure.set?

sorry; yes

functions inside clojure.set do things like use clojure.core/disj which expects persistent sets

possibly related: https://github.com/clojure/clojure/blob/master/src/clj/clojure/data.clj#L118

I don’t think that should handle keys duplicately, but it does

I don't have first hand knowledge of it it would throw errors on java sets or not, but I expect it was written only considering clojure sets as valid inputs

(keys returns a seq, not a set)

yep

Is there still an eval bot in here? (set/union (keys {:a 1 :b 2}) (keys {:b 2 :c 3}))

that probably doesn’t do what you’d expect, although it’s accidentally safe

@lvh you can use /clj - but require clojure.set :as set

I would say the use of keys there is a bug

@john mote? almost the reverse of atom (mota)

@mobileink that's pretty good

@hiredman how so? keys looks sane; it’s the distinct-making that seems wrong

keys returns a seq, clojure.set requires sets

there's also dyad, if you wanna go greek.

I am pretty sure this actually well tread with in jira, clojure.set behavior being undefined on things that are not sets

@mobileink let's bring it #off-topic

sorry naming sets me off. 😉

https://dev.clojure.org/jira/browse/CLJ-810

https://dev.clojure.org/jira/browse/CLJ-1087

https://dev.clojure.org/jira/browse/CLJ-1682

etc etc

https://dev.clojure.org/jira/browse/CLJ-1953?focusedCommentId=43158&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-43158

so passing things that are not clojure sets is a bug

so passing the result of keys on a map is a bug

1087 is someone reporting the thing I noticed specifically; so yeah, it’s definitely a bug

I wonder how bad the perf penalty is

(I am trying to speed up diffing; I have a deeply nested map that when “unnested” into things that look like calls to assoc-in, it has about 1 million entries; diff is not very fast on it)

also I don’t care about things that are equal, and in my data structures the vast majority of those entries are equal

so clojure.data/diff spends a lot of time building a pretty big data structure that I then immediately throw away

https://docs.oracle.com/javase/7/docs/api/java/util/Map.html#keySet()

yeah, well, clojure.data/diff isn't much, and obviously isn't battle tested, maybe just ignore it and write your own that is faster without the bugs

an IPersistentMap isn’t an IMap automatically right? (I think the concrete type is)

OK, cool, thanks, that gives me some places to start

I had started doing that already and forgot how crazy slow non-type-based dispatch is

also carrying state on the stack (and writing something recursively) seems to work better than having to build e.g. a persistent vector with a path into a deeply nested map — which is unfortunate because the latter is much easier to paralellize

So I guess I’ll have to cheat a little with the parallelization 🙂

I have a small app web generated with chestnut. I did a lot of hack to test a project, unfortunately when I do lein runit hangs... lein figwheelstill works btw

How can I debug it ?

is binding/dynamic vars 'good' ? then seem to brea purity / the notino of same input same uotput, since the code now depends on some implicit context of the dynamic var

@qqq i tend to avoid dynvars for exactly that reason

it depends; does the dynamic materially change behavior?

if it’s a log observer: don’t care

it's like the reader monad in haskell

say you're implementing a tex processor, you need to keep around a "tex-env"

which stores stuff like are you in :display, :text, :script or :scripsscript mode

among other things

`lein test` works, but lein test-refresh fails to find a (java) :import (that it doesn't need for tests) is there a way to turn off the imports during testing?

with protocols, there’s no way to dispatch on both IPersistentSet and java.util.Set and control which impl gets picked, right? I always want the “more derived” one but IPersistentSet doesn’t derive from Set

looks like it works…

kingfisher.core=> (defprotocol IFoo (f [this]))
IFoo
kingfisher.core=> (extend-protocol IFoo clojure.lang.IPersistentSet (f [_] 'clj))
nil
kingfisher.core=> (extend-protocol IFoo java.util.Set (f [_] 'java))
nil
kingfisher.core=> (f #{})
clj
kingfisher.core=> (f (java.util.HashSet.))
java

I know that #{} is also a j.u.Set but protocol dispatch seems to be doing the right thing

how can i test that a function gets called in the finally of a try block?

(a fn releases a resource, and I want to make sure it's called)

I don't want to use an other lib, and the best I can think of is with-redefs that mutates an atom in scope... that seems a bit heavy though...

you could make a protocol for acquisition / release, and for the test pass in an implementation that simply updates a state atom which you can verify, and pass in the real resource implementation at runtime

if you don’t want to change the functions arg list, make it call a higher order function that takes the extra arg (and test the higher order function)

hm, that seems like a clean way, but I may not have leeway to change the API that other pieces rely on

right - you shell out to the parameterized function for your logic

test the parameterized function

i'm not sure I'm seeing your vision, i have

(defn test-me [] (try (f) (finally (g))))

@noisesmith it's a coincidence that the clojure hashmap is dispatched through IPS rather than Set

@bronsa - OK - that’s good to know

user=> (defprotocol IFoo (f [this]))
IFoo
user=> (extend-protocol IFoo clojure.lang.IPersistentSet (f [_] 'clj))
nil
user=> (extend-protocol IFoo java.util.Set (f [_] 'java))
nil
user=> (f #{})
java

e.g. i see this in my repl

FWIW https://dev.clojure.org/jira/browse/CLJ-1807

altho IIRC alex said rich doesn't like the idea

@josh.freckleton

(defn use-resource [r ...])
(defn run-with-resource (partial use-resource real-resource))
(defn test-with-resource (partial use-resource (reify IResrc (get [...] ...) (release [...] ...))

this lets you substitute the side effecting part and test the acquisition / release behavior

your callers would be targeting run-with-resource, which doesn’t need to expose the real-resource argument

to me, the test shouldn’t even care that it’s called in the finally step - as long as it can verify that even when an error is thrown the resource is released

so my tests will carry around mutatable state, and I'll just need to check the state after a test was ran?

(mutatable state = resource)

right - like a promise that gets delivered, or a delay forced, or just swap! a key into an atom

whatever flavor you like

that makes sense. I like that, thanks for the help

the key there (to me) is that all the real logic should be in use-resource - in that case, run-with-resource shouldn’t need a unit test, as long as real-resource is trusted (it should also be kept simple for similar reasons)

last question, it's a java resource, so the methods I'm calling are, eg .try-something, can a protocol use periods in the name?

I would wrap the resource in a thin reify wrapper

I mean, you could also just reify or proxy your test object taking the same methods as the java resource, by implementing the same interface or class it does…

but I think the protocol/wrap method is more general

I get reification, but I don't quite see how that helps me write javanese method names with ., would you mind clarifying?

you would reify the Interface that defines the method

or proxy the class that defines it

but really I would prefer usually to abstract via the protocol method - doing the real method calls inside the methods of the protocol