Fork me on GitHub

I've noticed a common use of comp to use a function that is passed in as an argument. For example


(comp f vals) v (f vals). Why the comp?


Can you show an example ? From what you have here, (comp f vals) is not the same as (f vals) . Perhaps you meant apply? If vals is a list of (say) 3 values (1 2 3), and f takes 3 arguments, then (apply f vals) would be the same as (f 1 2 3).


What I've sen is functions which use (comp f arg) where I would normally just do (f arg) or maybe (apply f args) and I wasn't sure why you would use comp. I've seen this more than once, so thought there must be a reason. Is there any situation you would use comp when you just have a single function to evaluate?


@theophilusx That doesn't make sense. (comp f arg) is not the same as (f arg) nor is it the same as (apply f arg). Can you link to examples of functions that you think are using (comp f arg) in this way?


Unsure if this is the right channel to ask this question... I'm designing a microservice on AWS, and its artefact is an orchestration of a couple of SQS queues, 3 Lambdas, APIGW, among other things. How do I structure my code, and write my build program (invokable with cli-tools) so that it produces three artefacts, one per lambda? I'd like to stick to one git repo if possible. Some amount of domain logic will be shared b/w the three lambdas.


@jaihindhreddy What sort of artifacts do you want to build? Basic JVM uberjars? Is the JVM/Clojure startup time acceptable for Lambda for you?


Assuming uberjars are fine, you're talking about a monorepo with multiple subprojects -- which is what we have at work -- and we build uberjars with depstar / CLI / deps.edn.


Each subproject has its own deps.edn file and treats the other subprojects as :local/root dependencies (via ../<subproject> paths) as needed.


Since depstar builds the requested JAR/uberjar based on the classpath, you would just cd into each lambda subproject, and build the JAR based on the classpath created from the deps.edn file, just as if you were running the lambda locally (but running hf.depstar.uberjar as you main namespace instead of whatever is in the lambda code).


Does that help?


At least one of those is latency sensitive, but doesn't do much computation, so I'm thinking Graal Native image.


Never tried Graal though, and not sure how it works with Clojure.


But yeah, the monorepo route makes sense.


There's a #graalvm channel so you can check that out. There are some restrictions that go with it (can't use Spec, for example, at the moment, and certain "dynamic" things) but startup times are awesome.


@seancorfield Sorry, typo on my part - should have been ((comp f) v). One example is (defn process-map [f m] (into {} (map (fn [[k v]] [k ((comp f) v)]) m))) which I think is just poor code, but wasn't sure. I can think of a couple of alternative ways to do the above which are shorter and I think clearer. However, I saw this ((comp f) v) construct a couple of times and was wondering if there is something subtle I'm not understanding


No reason whatsoever since (comp f) is just f. Probably a leftover code that used to be something like (comp f g).


@p-himik Thanks. That was my suspicion, but thought I'd check


I've seen this a few times, people asking how to build several services together because of shared code. Wondering if this is common to Clojure (I'm a Clojure newbie). What I would do in Java though is, isolating that code to it's own project and build that as a dependency for the other services. You would also be able to have independent build routines for each then.


I don't know if it's more or less common in Clojure than in other languages. Having multiple projects, potentially multiple git repos, instead of one single big codebase is an open question IMO. I've had a very annoying experience in a previous work where we had many common libraries, each living in their own git repo, each used in multiple projects.

Alper Cugun11:12:21

There’s a lot of folklore around it but once you’ve worked in a monorepo, you probably won’t want to go back.


> many common libraries It sounds wrong. Maybe you made libraries from things which are used only in 1 project or split them too much. Like a micro libraries ;)


I'm sure if we were a bigger team I would have found advantages to that, but as it stand, our small 3-man team dev spent a lot of time time doing commit -> pr -> release -> update dependencies of all relevant projects whenever we needed to make a change in one of our common libs. Which was often. Working there I dreamed at night of working with a monorepo.

💯 1

you could use ci/cd for this purpose. If detect new version of X, then update dependency in project and test it with new dependencies. If pass make a auto commit with new ver. of your library.


This is probably the way which I would choose if I would find myself always bump version in each project after release.


But for sure not keeping everything in one repository. It always end with a mess and complexity made by developers.


Yes, context definitely matters. I don't think he was talking about a monolith though (one big code base). But they can also be so small that having them in the same project could make sense (has it's pros & const). Also Alper also brings up monorepo, which many companies seem to be using now (never used it myself). You could also group small utility projects into a super pom, then use it as a dependency in your services. It's maybe just a personal preference, but I feel that edge/outward facing services should be as independent as possible.


anyone could give me a help with specs?


I have defined these predicates and spec but when I execute the above line in repl I get false as result

(invalid_transfer? {:uuid_account "745286b0-24d3-4b17-ab24-d1265e9fb8d1" :transfer_data {:uuid_account_destination "44444444444"}})


but should return true because it’s missing the amount keyword


amount is missing from (s/def :unq/transfer (s/keys :req-un [::uuid_account ::transfer_data]))


but amount is inside ::transfer_data how can I validate nested keywords?

👍 1

(s/def :unq/transfer (s/keys :req-un [::uuid_account :unq/transfer_data]))


fixed version, note :unq/transfer_data


oh, that’s it. Thanks @U45T93RA6, my tests are passing now :man-facepalming:

🍻 1

qq, how do you pass a map as an arg with lein run -m?


lein run -m my-ns/my-fun {:opt1? true}


obviously this doesn’t work, but I am wondering how to format the hasmap to make my-fun using it


such that it calls (my-ns/my-fun {:opt1? true})


fun q! the following turned out to work:


Yup, that would turn the sequence of strings into a hash map from string to string, pairwise.

👍 1

user=> (let [{:as opts} (range 4)] opts)
{0 1, 2 3}


Don't you just need quotes around it?


@U0K064KQV That would pass it in as a string which would then need to be parsed (read as EDN).


The suggested solution is to provide the key value data without { } and without : -- just as strings on the command line, and then use & {:as opts} to automatically turn that into a hash map (string -> string).


But quoting it on the command-line (as a regular EDN hash map) and then parsing a single argument (first args) from -main [& args] would be another reasonable approach.


Either way, the function on the receiving end is going to need to do some work if the goal is to pass values that are not strings (such as true).

👍 1

Ah I see. What's the machinery at play here? Does destructuring auto parses string into maps in any function as well? Or is that specific to the way clojure.main bootstraps the main fn?


Oh I see, the keyword will actually be a string


The given solution just creates a map of string to string

👍 1

Right. So either you quote the EDN as-is and the receiving function must parse it (read it back as EDN from a string) or you pass the key/value pairs as plain sequential values on the command line and deal with them as a hash map of string -> string which still may require some parsing.


Bottom line, you can't pass actual Clojure data directly into the target function without at least some parsing in a wrapper function) @U07C4S0EM

👍 2

ok, thanks guys!