check this https://clojure.wladyka.eu/posts/form-validation/ let me know if it is useful

TL; DR; I did https://github.com/kwladyka/form-validator-cljs to solve this - this is very small library bo do the job

I believe file-response just wraps the file in an inputstream. per the https://github.com/ring-clojure/ring/wiki/Concepts : > The contents of the stream is sent to the client. When the stream is exhausted, the stream is closed. you can make a proxy of an inputstream (using reify) that deletes the temporary file when closed.

you may also want to have some process that cleans up temporary files that are older than a certain threshold in case an exception in the handler causes the input stream to not clean up after itself for some reason

depending on how quickly the temporary files fill up disk space, another quick and dirty solution is just to have a process that deletes temp files older than X minutes

Thanks @U7RJTCH6J, I’ll probably go with the approach of periodically deleting the tmp files. Although I was primarily wondering if there was a way of knowing when a respone has finished in compojure. In Express/Node.js there is an event that is fired on response end, where you could handle cases like this.

there maybe, but I think it might depend on which server implementation you use (ie. http-kit, jetty, etc)

(I went looking, just for fun. I haven’t used any of the tools below) https://github.com/quicwg/base-drafts/wiki/Implementations https://github.com/ztellman/aleph wraps Netty, but Netty only has unofficial, partial support for QUIC: https://github.com/protocol7/quincy

Ah, those links are great. Thanks a lot! We're both in the same boat, just looking at QUIC for fun 🙂

maybe looking at the implementation of into will give you the answer: https://github.com/clojure/clojure/blob/30a36cbe0ef936e57ddba238b7fa6d58ee1cbdce/src/clj/clojure/core.clj#L3333-L3341

No it doesn't actually (or I can't see it)

For small maps, that's an optimization.

It is documented somewhere.

The answer should be in the source of hash-map and not in the source of into.

https://clojuredocs.org/clojure.core/array-map#example-57392e25e4b071da7d6cfd0c See this.

Sorry if my answer comes across as rude. Try to think of "why do you care?" not as "you should never care about such question", because I think you should ask such questions. The question "why do you care?" is meant from the perspective of "I think that, I you reflect on it as long as you care to, you will probably arrive to the conclusion that it isn't all that important of a distinction"

I took @andy.fingerhut’s original comment as frank directness ("let's find the facts"), but I'm also inclined towards direct communication.

yup. @andy.fingerhut no worries, I dnd't perceive it as rude 🙂. but such answers (which sometimes I give myself) might be perceived differently especially by beginners to the community.

@U05509S91 agreed. I'm often trying to balance "encouragement" and "fact-finding" myself. I sometimes find that getting totally obsessed with facts can inhibit any action, in a totally unproductive way. But this is hard stuff. I've found differentiating between observations and judgements to be helpful.

I think I got mis-pinged here 😄

Worth noting that I made this exact mistake before, not knowing that you could extend multimethods with interfaces (`IPersistentMap` in this case)

(defmulti mm class)

(defmethod mm clojure.lang.IPersistentMap
  [x] "matched")

(mm :not-a-map)
;; Unhandled java.lang.IllegalArgumentException
;; No method in multimethod 'mm' for dispatch value: class
;; clojure.lang.Keyword

(mm (array-map :a 1)) ;; => "matched"
(mm (hash-map :a 1)) ;; => "matched"

Yes multimethods dispatch with isa? so you can built whole hierarchies (with derive etc) but I bet beginners will have a hard time debugging issues like that coming from inconsistencies

Running into this issue actually led me to learn about hierarchies and derive etc. In general while learning Clojure I found that bugs stemming from my misunderstanding would show themselves pretty obviously, and the process of solving them brings about a better understanding of the language and its idioms

(Not an argument for keeping inconsistencies in the language, of course)

> Yes multimethods dispatch with `isa?` [...] I wasn't aware of that. Thanks! So for our case of hash maps, we could use the fact that

(isa? clojure.lang.PersistentHashMap clojure.lang.IPersistentMap)

@teodorlu exactly

@qythium I think sooner or later every clojure programmer will go through this process despite the fact that clojure is notorious of how easy it is to reason about, despite its dynamic nature

And, of course, the reference covers this: https://clojure.org/reference/multimethods#_isa_based_dispatch I'll add my often last step to @qythium’s process: figuring out that the "weird" topic is actually explained well in the reference or a guide.

Sure if I am working with types that is

Because to me, I think I would reach for "I want to dispatch on some type" using Haskell, Elm or Rust, whereas in Clojure I'm more inclined to (a) just (cond ...) a bunch of predicates, and possibly (b) to use "less dispatch things", rather work with a more general map where I know what type is "under" each keyword.

Well, I have a more open approach to things. I am sure that there is a time and place for everything. Multimethods and protocols are great tools for runtime polymorphism. Sometimes I use multimethods sometimes protocols and sometimes (cond ,,,) it depends on the context

If you just want lein deps :tree, then it's clj -Sdeps.

This is for my docker image. What I want to do it install all the dependencies and cache it. (Of course change it when the dependencies change).

Ah, I see. I just run something like clj -e '(println "Test run successful")' on a clean ~/.m2 folder and then cache the whole dir.

But now idea if tools.deps supports something like this.

Okay nice. Let me try that. Thanks @U2FRKM4TW

clj -Spath is sufficient

Even more simpler. Thanks @U064X3EF3

I guess it wouldn’t be a queue anymore if you add to the front. Or did I misunderstand you?

Well, it would approach a double-ended queue I guess, unless I am missing something obvious

The persistent queue is a FIFO queue so it makes no sense to prepend.

Maybe you should look into finger trees

https://github.com/clojure/data.finger-tree

Thanks, that would indeed be a solution, but ideally I was hoping for something that would work out of the box with CLJS

Sorry I have no idea if there is any lib in CLJS for that. I don't know if you can get away with JavaScript arrays..

i think its a great idea to extend the persistent queue to be a deque

@U11BV7MTK That's why I am wondering if I am missing something obvious. The fact a persistent queue is implemented with a seq followed by a vector for easy popping from the start and appending to the end looks like it can just as easily be used for prepending and popping from the end.

i agree with you. looking at it in java the fields are private so its a bit annoying (`f` and r are the seq and vector respectively). looking at cljs now

but in cljs this makes it much easie:

deque.impl> (.-front #queue [1 2 3])
(1)
deque.impl> (.-rear #queue [1 2 3])
[2 3]

But then, in CLJS, can you easily rebuild a queue by providing a seq and a vec?

right

(defprotocol IDeque
    (-rcons [q e])
    (-lcons [q e])
    (-rpop [q])
    (-lpop [q])
    (-rpeek [q])
    (-lpeek [q]))

(extend-protocol IDeque
  PersistentQueue
  (-rcons [q e] (conj q e))
  (-lcons [q e] (PersistentQueue. (meta q)
                                  (inc (count q))
                                  (conj (.-front q) e)
                                  (.-rear q)
                                  nil)))

deque.impl> (-rcons #queue [1 2 3] :new)
#queue [1 2 3 :new]
deque.impl> (-lcons #queue [1 2 3] :new)
#queue [:new 1 2 3]

Neat!

Too bad it's not that simple in clj. I don't see any way we can overcome the fact that the seq and vec are private.

private is just a suggestion. it gets verbose and reflecty maybe but it can be done

Yes but doesn't such dark magic incur a debt to performance ?

yeah definitely

Which is not what we want for a data structure. Should someone bother with opening a ticket about it? I mean, what are the chances of this grabbing some attention?

As to the original question, turning the queue implementation into a dequeue implementation adds some pathological performance corner cases. Consider:

(-> (dequeue (range 100))
    (.lpop)
    (.rpop)
    (.lpop)
    (.rpop))

good point!

I think this is one of the problems that the finger trees linked above are aimed at solving

Fair enough, yes. However, before diverting to deques, I was actually mostly interested by being able to prepend (a deque without rpop I guess). Then, I believe we wouldn't have that kind of problems (I might be mistaken).

If your set of operations are: rpush, lpush, lpop (and not rpop), yes you could easily make your own using a list for the head and a vector for the tail, following the same implementation as PersistentQueue. It's a somewhat uncommon set of operations for a data structure, so that's a good enough reason for it to not be supported in the official clojure.lang bag of functions, but there's no reason you can't make and use it yourself!

I have not used jsonista, but I have used regex to extract substructures from JSON text. Is that what you are looking for?

hmm you would first need to read the entire structure in memory for regex, no?

No. (re-find) will scan the text. If you have specific nodes you are looking for.

Maybe try this: https://github.com/dmillett/clash/blob/master/src/clash/core.clj#L168

It depends what you want out of the underlying JSON. A transducer can be setup with a parser --> extractor for you data to handle large amounts.

ok thanks, I'll have to keep that in mind. for now, I found it simple do it with a java lib com.jayway.jsonpath.JsonPath/parse (I'm not a purist 🙂 ) but I'll have to benchmark memory consumption of it

apply doesn't realize lazy values

the function might do it, but apply itself never does

user=> (apply (fn [x & _] x) (range))
0

sorry! I had a misunderstanding

There is a small part of this talk that describe this problem And show that if clojure compiler where build in clojure, it could be solved way more elegantly https://www.youtube.com/watch?v=eDad1pvwX34

~21:00

cons, seq, map, and filter are sequence abstractions. They’re designed to be lazy. They can be backed by any number of concrete data types or, potentially, none at all (e.g. infinite sequences). list, vector, and PersistentQueue are all concrete data types. They are designed to hold all contents in memory and to be very efficient at various operations, depending on the type. For example, list has a very efficient prepend operation, but poor indexed access. vector has a very efficient append operation and very efficient indexed access. In clojure, peek, pop. and conj are queue functions. They’re only available on concrete data types which implement the IPersistentStack interface. (That includes lists, vectors, and PersistentQueue.) This restriction is to quasi-guarantee that peek and pop will be extremely efficient (usually requiring no more than a single allocation). This also guarantees that each function keeps the same data type as the original collection (unlike sequence functions).

Yes, I understand that all of this is organized for the sake of efficiency, yet I sometimes find it a bit odd. For instance, regarding how conj fits in all that :

(class (conj (range 1))) ; Cons, you can conj to a seq
(pop (range 1))          ; Throws

I have been using Clojure for years but once in a while I reconsider something that basic

I honestly didn’t know conj worked on sequences. I agree that’s odd. Though, I would never use it for them intentionally. I would never even use cons for sequences intentionally. Ordinarily, you shouldn’t be dealing with individual items or indices when operating on sequences. You should always consider them as a sequence. conj is kind of an oddball operation. It’s the default way to add to a collection (as opposed to cons in other lisps). For stacks, it means “push.” For sets, it means “add.” For lists, it means “append.” For maps, it means “add this key-value pair.”

My rule of thumb that allows me to not think about it: map, filter, concat are for sequences. conj, peek, pop, assoc are for when you want to control the concrete data type.

My solution

(letfn [(index-by [f coll]
          (into {}
                (map (juxt f identity))
                coll))]
  (let [els [{:id 1} {:id 2}]
        els-by-id (index-by :id els)]
    (assoc-in els-by-id [1 :v] 42)))
      
=> {1 {:id 1, :v 42}, 2 {:id 2}}

> My goal is to assoc a keyword with the value to be `someList` when the ids are successfully matched

So you want your output to look like {'abc [a b c d]}?

Oh I think I see what you want

Like this? -

(defn my-transform
  [v1 v2 some-list]
  (let [ids (set v2)]
    (into []
          (comp (filter (comp ids :id))
                (map #(assoc % :someList some-list)))
          v1)))

=> #'user/my-transform
(my-transform [{:id "a"} {:id "b"} {:id "c"}]
              ["a" "c"]
              ["a" "b" "c" "d"])
=> [{:id "a", :someList ["a" "b" "c" "d"]} {:id "c", :someList ["a" "b" "c" "d"]}]