Say you need a data model for contacts in a quick application you're building. Where would you go to find a decent, complete, battle driven data model for that?

hey folks, can i consider this (doall (map @profiles connections-ids)) under side effect of @profiles?

What is the intended result?

What's the operation that removes a thing from a set?

thre is disj

Thanks!

I have a list of maps like this ({:type "G", :location [2 1], :hp 300} {:type "G", :location [5 5], :hp 250}) and I would like to apply a function to the :hp key for an element where the :location is [2 1] for example. I'd like to have the resulting list. Is there an idiomatic way to do this "select for update" logic?

Hi. Why repl is a big deal for clojurians? Is there any difference with other repls?

I used to program in C# for my job. Almost the only way to interact with your code is to press f5 and run the entire application or set up unit tests. There was a program called LinqPad that was a quick way to evaluate and interact with code and scripts and it was amazing. You can write a little code and exercise it and see how it behaves rather than setting up a unit test and 4 mocked objects injected in. Python and ruby both have repls as well but they are different a little. I think stu halloway put it best in that a lisp's repl allows your tools to run in your code rather than the opposite where the code runs in your tools.

Thanks 👍

Does Clojure have a package manager/build tool like cargo of rust or mixof Elixir? Sorry my questions are dumb.

you most probably want lein: https://leiningen.org/

but there's also deps.edn a newer take on package management. It is unabashedly not a build tool though. https://clojure.org/guides/deps_and_cli

Can someone explain to me the reason why derefs will trigger transaction retries? I am not sure, but as I understood it, the STM system will try to guarantee that the ref values seen during transactions are the same as they were at the beginning of the transaction. Am I correct?

I'm implementing an algorithm with many recur places and complex data structures. I'd like to be able to trace and see how the execution flows. What would be a good way to instrument the code to dump tracing messages and the contents of the data to the console or file?

I want to transform:

(def data   [{:id {4 67} :person_id {12 74}}])

; or

(def data-2 [{:id {4 67} :person_id {12 74}} {:id {12 83} :person_id {14 89}}])

((4 67 12 74))

((4 67 12 74) (12 83 14 89))

(map 
  (fn [m] 
    (reduce (fn [acc [k v]] (concat acc (first v))) '() m)) 
  data-2)

Not off the shelf solution, but you can call vals on a map to get the … vals

oh wait, its maps in maps

why is that, don’t you want to have like maps of keys -> lists/sets/vecs?

You could do this... (->> data (map vals) (map #(map vec %)) (map flatten))

Should really clean up that map map though

it's a terrible solution

What would you recommend as an alternative?

what the heck is 4 as a key? 😛 totally non-descript

{:id [4 67] :person-id [12 74]} or {:id #{4 67} :person-id #{12 74}} or {:id '(4 67) :person-id '(12 74)}

You seem to not care that they are key value pairs ie one is associated with another. So don't use an associative data structure

(thats vecs/sets/lists respectively)

i wasn't sure if the id maps were actually being used for lookups, otherwise the first probably makes the most sense

{4 67} would represent a before and after value.

is it actually a mapping, thats the question you should ask yourself ^^

In my mind, yes. But I might be too close to this at this point 😜

So all instances of 4 will become 67. Thats why I initially thought map could be a good option.

well, thats a bit conflicting with your desire to flatten them to lists

Are you trying to maintain a history of IDs for these records?

Yes.

maybe I am just misunderstanding

Imagine a db value is updated from 4 -> 67 and you need to remember this. That is what I have in mind.

The need to flatten them comes when I have to transform them to something a sql query can use.

right makes sense

It would be complicated to update those maps multiple times like if {4 67} turned into {5 4 4 67}

Maybe just maintain current ID and set/vector of past IDs? Then it would be easy to collect these, if this is the only option for maintaining history of a record

yeah, you could maintain history in a vec instead right by treating it as a fifo

user=> (def data [{:id {:old 4 :new 67} :person-id {:old 12 :new 74}}])
user=> (->> data (map vals) (flatten)
  #_=>      (map :old))
(4 12)
user=> (->> data (map vals) (flatten)
  #_=>      (map :new))
(67 74)
user=> (interleave 
  #_=>    (->> data (map vals) (flatten)
  #_=>       (map :old)) 
  #_=>    (->> data (map vals) (flatten)
  #_=>       (map :new)))
(4 67 12 74)

probably a cleverer way to do it, but it certainly looks clearer to me what’s happening if I were to read it a week later

bikeshedding: would prefer :current and :previous

I like that alternative @lilactown.

lol I figure @tkjone can put his own spin on the names according to his domain. but the point is: names are good!

haha indeed.

But now you can't keep more then a single prior id

ofcourse you can, you make :previous a vec or a list

You can find just as good a name without this no. Just call it {:ids-over-time [2 45 67]}

Hum, ya, maybe that's clearer to split out the current and the prior ones. But it seems harder to work with. Depending what you need to do

as long as things are consistently collections or consistently scalars ^^

But I do like the suggestion of say {:current-id 45 :prior-ids [2 34 67]} in terms of readability. Though it also brings some question. Like the code must now maintain the invariants of coordinating the two. Making sure to conj to prior and update current when a new id is added. And its unclear if prior-ids include current or not.

Catch to the above: there will never be multiple prior-ids. Its only going to be something like 1 -> 15*

Eh, if this was persistent data, like the model for a document store. I would design for future extension in mind, and so I'd make it a vector just in case in the future we need further history.

I'm getting a NullPointerException clojure.core/name (core.clj:1546) in a function that turns a keyword into a vector. Any ideas why?

Clearly something is null and passed to name

Got it, I'm using a library that returns that...

@tkjone Anyway, no right answer here. I think using keys like current and prior does make it more readable, so if you really don't need more then one prior, it seems a pretty good choice.

Thanks all!

@nikola Are you sure the input keyword sometimes can't be nil?

@didibus it's a result of a call to an external library function

Ya, I'd add a check, in between.

Oke, will do

Also, just test your keyword to vector function. What does it do if you give it nil? Does it throw that error?

To be sure its not a bug inside your function

I have a log entry as a map that contains a :timestamp which is a java.time.OffsetDateTime. How should I print it to an edn file? pr-str gives me :timestamp #object[java.time.OffsetDateTime 0x67573db5 "2018-12-05T00:15:30.151200+05:30"]

I want it to show with #inst

you can implement print-method for it, like here: https://gist.github.com/defndaines/0b5c37c8c585e975d8c5b70271a1dce1

What's the difference b/w print-method and print-dup? Which should be implemented when?

This worked beautifully:

(defmethod print-method java.time.OffsetDateTime
  [dt out]
  (.write out (str "#inst \"" (.toString dt) "\"")))

I keep forgetting that read and print are extensible via multimethods.

😅