Fork me on GitHub

Quick Q — I’ve got f(g n k v) and g n [k v], how do I “lift” x y out of the vector for use in f ? Feels like I gotta do something with partial and apply



user=> (defn x [a b c d] 42)
user=> (apply x (list* "a" "b" ["c" "d"]))


cool! thanks


I've never used list* so far. Interesting. Wonder if I've been missing out. 😉


@bradford: apply accepts singular arguments before the final list


Yeah, I would favor apply over list*.


@stuartsierra: Do you see list* used in the wild much? I can't recall ever coming across it but I've only been doing clojure about 8 months now so your experience outweighs mine quite a bit. simple_smile


And what is the * meant to signify?


I've used list* on rare occasions. The * is an old convention from Common Lisp used to denote an "alternate" version of a core function.


Ah, I see. Thanks.


Speaking of naming conventions, I've got one that I wrestle with. Sometimes I will have a situation where I've got several variations of some function and then I pass a particular version off to some other function where it gets called. No problem there. So they all get named somewhat similarly. Then I'll have one odd duck where rather than just define a function I need to define a function that returns a function. And I always wonder if I should somehow name that one differently. Does that make sense?


I’ve seen people use [something]-factory if it’s a function that can return a number of different functions. But if it’s a function the return value of which just happens to be a function, I wouldn’t sweat a special name. It reminds me in a way of Hungarian notation from a billion years ago.


Speaking of naming, is there any community consensus around naming of database methods - thinking CRUD stuff mostly


I like to name functions for the thing they return. So a function returning a function would be named "…-fn"


So basically the opposite of what I just said. [laughs]


So you’d have stuff like …-int?


No, I don't suffix everything.


Say a function returns a user's age, I would call it age. If it returns a function to calculate a user's age, I'd call it age-fn.


Ah. Right. I do the same because age is conceptual. But, to me, a function is just another type so adding -fn describes the type returned rather than the concept. Although I guess age-fn does both at the same time.


I don't hold to this pattern everywhere, but I find it helpful to prevent confusion in the unusual case of a function-returning-function.


Makes sense.


I like that as a default naming convention. Haven't come across it in most of the code I've read so far.


Sometimes I do use the -fn approach but it doesn't always feel right.


I have a similar issue when it comes to parameter names that expect the argument to be a function. Sometimes I use names like age-fn or age-f or sometimes get-age-f depending. I haven't settled on a convention I'm 100% happy with.


Sometimes it's enough to point out that the argument needs to be a function. Other times I feel like it is more important to emphasize what that function is meant to do or what it should return as a value.


@meow: list* is mostly there to help bootstrapping some clojure features like apply and syntax-quote


@bronsa: Cool. Thanks for the info. It's good to know the history behind a lot of these language decisions. Clojure (and its community) is great that way. Honor the past, just don't get stuck in it.


@stuartsierra: Just read your recent blog posts. I'm a big fan of your writing. Hope you never stop. simple_smile


Hello all, bit of a general question, imagine I have a fn like swap!. It applies a function atomically, using something like CAS to transition state. If I do (my-swap! x f) and (f x) is identity of x is it valid for the mechanism under the hood to ignore the CAS update? Does this invalidate the concurrency semantics of swap!? I don't think it does, as the resultant history (if operation is dropped) is possible anyway... I am thinking this is a potential optimization to my faraday-atom library...


I notice this optimization isn't performed in clojure.lang.Atom (at a glance)


Though the AtomicReference swap in that case is very cheap


@danstone: it depends on what other behavior might be attached to the CAS. For example, updating an AtomicReference has ordering guarantees related to the Java memory model.


@stuartsierra In this case its persisting state to an external store (dynamodb) using what is called a conditional-put.


I just imagine dropping the operation is similar to it simply completing immediately in this context


@danstone: In that case, Dynamo is in control of the state. How do you know the CAS is going to succeed without going to Dynamo?


I don't, thats why I am unsure here. The fact is I am saying compareAndSet(x, x) here... Which means, I think it is possible in any history of concurrent operations for this to be a noop.


It is possible of course if I contend with other threads/machines for x to become y in the spin loop, in which case I will arrive at a different answer. Both are possible


My idea is that it doesn't actually matter which one is picked, it may make an outcome more unlikely, but it is still correct (I think?)


I think if this was local state with ordering guarantees for threads seeing the new value of the reference in respect to wall clock time, then it would be different


But wall clock time is irrelevant in this case, as the network can slow down acknowledgement of each concurrent swap for however long it wants


To put it another way. I have two functions `(defn f [n] (case n 0 0 (inc n)) (defn g [n] (inc n))` Lets start the ref at 0. Here are the possible histories if I apply the 2 functions concurrently (assuming the state transition semantics of a clojure atom) f -> g == 1 g -> f == 2 If there is no contention and f is called first, 0 is set to 0(noop) If there is contention between f and g, we may arrive at a history in which f does not set the ref to 0 if it doesn't complete before g. However it is just as likely that it does complete first. There is no way to distinguish between the valid history (f -> g) and one in which I didn't call f at all. Perhaps there is some subtlety here that I am missing?


I think it is important to be clear I am not surfacing a compare and set operation, Just a function like swap! that promises to apply your function atomically and not invalidate or discard your operation due to a race condition.


@danstone yes, if atomic semantics are implied by the surface api, but underneath there is a codepath where the atomic read is not performed, then as @stuartsierra was suggesting, the resulting behavior may be surprising, per


it sounds though like the use case for your swap! may be more limited than a general purpose swap!


@jonahbenton: The CAS itself is remote, the only thing I do locally is apply the function. That said, I don't see why this wouldn't be valid for local atoms as well.


Obviously I am applying f to a value that is read in a way that reflects all writes so far up until the point the read was acknowledged.


@danstone so you are applying f to a local copy of a value maintained at dynamo, and if that application provides a new value, you do conditional put at dynamo?


That sounds about right


i see- it's a potential optimization to avoid the network round trip


I avoid the conditional-put part of the deal


(f x) == x is not going to happen very often for most users, but it turns out a lot of our operations do something like (if (pred x) (do-stuff x) x)


right. so is it fair to say: x represents a deref'd dynamo value, current as of the time of the last deref. when (pred x) is true, (do-stuff x) may either result in a change to x, or not. Without this optimization, both outcomes will hit dynamo; with this optimization, only the path where x has changed will hit dynamo with a conditional put.


@jonahbenton: I gotta go catch a train, but will be more than willing to continue this further if you (or others) PM me?


sure, quick response- with this optimization, it sounds like you miss a signal from (putitem key x x) that the value at dynamo for key has changed to something other than x, so anything following (do-stuff x) may be incorrect


This may or may not be a problem depending on what happens in (do-stuff x), and in the outside world that triggered the action. Given how tricky the context might be I propose that the optimisation is simply not worth the potential consistency issues in general.


@sgerguri: It could save a lot of money in provisioning costs simple_smile


In all my examples I am of course assuming pure functions


The core proposition is this. The semantics of an atom are such that there is no guarantee in the ordering of operations applied with swap! from seperate threads. They can be re-ordered due to retries, imagine a long running task and a short running one, the short running one can be dispatched after the long running one and still be executed first. There is no dispatch ordering or global ordering like there is in say, an agent (where each operation is applied in order according to receipt time by its internal queue). If this is true, then we have to accept multiple potential histories (outcomes) for any set of concurrent operations against the atom. Where (f x) is a noop we can safely say that this operation is irrelevant, a valid history is one where this operation doesnt happen.The only caveat I can see is one has to be willing to accept the change in likelyhood from one potential history to another. However outcome likelyhood is already skewed torwards short-running tasks for example, I don't think random outcome distribution from a set of ops is a property atoms have as it stands.


I'm convinced that this optimisation is a good idea for cases where the CAS operation is remote or incurs significant cost.


^^ I hope I'm not just being stubborn but I remain unconvinced that this optimisation will actually break the atomic transition model or any consistency properties of it


And I really thought there would be some kind of subtle gotcha here


is it correct that the ddos on clojars can lead to weird JVM errors?


@kephale: I don't see how it could affect the JVM. It could certainly cause weird errors in build tools like Leiningen.


yeah, i dont really mean the JVM itself, but i’m running some code that was unchanged since it last worked, and getting what seem like random errors with segfaults much deeper than my code


just sanity checking before i pull out anymore hair attempting to debug these


I doubt that was caused by a Clojars outage.


hum… things like … # j clojure.lang.Compiler$LetExpr.doEmit(Lclojure/lang/Compiler$C;Lclojure/lang/Compiler$ObjExpr;Lclojure/asm/commons/GeneratorAdapter;Z)V+30 … … # V [libjvm.dylib+0x4c3067] PSScavengeKlassClosure::do_klass(Klass*)+0x9 … … # C [libsystem_platform.dylib+0x1331] platformmemmove$VARIANT$Ivybridge+0x31 …


went away after i emptied my .m2/ and refetched


anywho, thanks for the reply @stuartsierra


hiya quick question. I have this (defonce accounts (atom (array-map))) and it gets populated as time goes on. I am writing tests and want to clear this out before and after a test. Any ideas? Do I use empty or some other clojure logic?


seems like accounts should be a function parameter


kephale: i've seen when actively open jars are touched, or if some deployment tool messes with /usr/lib/jvm that shit happens


@ghadi aha awesome, that sounds right then, i have 1000 lein processes open on the same NFS, some are ending/restarting as that goes


normally that works just fine, but it has had issues over the course of today


so what are you going to do


uberjar? containerize?


first pass just try using the clojars mirror and hope for the best, otherwise it will be uberjar and rewrite launch scripts


or possibly hard coding the offline flag into the lein run call


strace should tell you for sure if a process if being naughty, right?


kephale: the jars in ~/.m2/repository shouldn't be changing at all once downloaded - lein/mvn/whatever won't change the files, only download them if they are missing


@tcrawley: that is what i’d expected, but i’m almost entirely certain when saying that i hadn’t changed any of the code, then when launching this morning suddenly started getting segfaults from weird places, replacing .m2/repository seeeeeemed to resolve it on my dev machine, and now swapping over to your mirror seems to have resolved the issues on the cluster


FWIW, a decent number of the dependencies encapsulate natives as well


oh... that's a convenient fact to just drop as an afterthought 😃


it is possible that you had an incomplete jar in the repo (where the download was attempted while wasn't fully available), but the tooling should have caught that when trying to verify the checksums


and the mirror vs. should make no difference at this point, since the mirror is an rsync of the master repo


so should be identical


the suspicion was something like incomplete jars, which is why i swapped to the mirror, and i do spin up a bunch of processes at once, so i’m just wondering if there is a really timing sensitive thing with incomplete jars


anywho, i’ll report back when it becomes more clear… the combo of natives + potential incomplete transfers was just something i wanted to see if anyone had run into


it seems like incomplete jars would also just throw some form of ZipException instead of causing a segfault


but, computers are terrible, so who knows?


hehe, anyway thank you @tcrawley for getting the mirror up and everything else!


my pleasure!

Alex Miller (Clojure team)22:01:50

my mental model is that maven/lein will download a jar, check it against the md5, then replace it only if successful, so an incomplete jar shouldn't happen

Alex Miller (Clojure team)22:01:19

however, I have had the pretty weird experience of having a jar that was actually an html error page more than once


@danstone agree with the proposition that this optimization does not run the risk of making the history of changes in values seen by dynamo incorrect in the context of concurrency guarantees. That said, two potential gotchas come initially to mind: clojure atom + swap! have additional semantics- atoms have watchers and swap! returns newval. The equivalent to watchers on dynamo look to be streams. I have not used them but guess this optimization may produce surprising results for stream users, if e.g. the application expects to simply deliver a heartbeat value to dynamo via the atom, a stream user might not see the heartbeat. Similarly, the staleness of the newval returned by swap! on an atom with this optimization may be different than it would have been without it- the slower f is, the more stale it will be with this optimization.