Kovas,
On Mon, Aug 10, 2015 at 4:23 AM, kovas boguta <[email protected]> wrote: > > In this case, why not let the user decide what async strategy to use? IMHO callbacks are the simplest thing since you can layer different > async strategies on top of them. Offering a comparable interface using callbacks would require reimplementing significant portions of core.async's functionality. Backpressure, interchangeable inputs/outputs, early termination, etc. are all features used extensively by the AWS libraries. Not only internally - they're intrinsic to the API. Clojurescript now has built-in support for most of the functionality > of cljsbuild. This means we can build cljs projects without any > dependency on lein. What I've learned to do (from David Nolen) is to > just invoke the compiler directly from a script > My point was that the script you linked to may as well not exist, from the perspective of a Leiningen plugin interested in building your code. While cljs-lambda invokes cljsbuild currently, I understand that it doesn't need to - the bit it wants is retrieval of working compiler options for the current project. cljs-lambda isn't requiring that you use cljsbuild elsewhere, or trying to change how you build your code. Copying the compiler options from that script into some future [:cljs-lambda :compiler] key in your project file would look an awful lot like creating a cljsbuild profile you never intend to use, in order to allow cljs-lambda to retrieve it. The benefit is that existing cljsbuild users (cljs-lambda is a Leiningen plugin, after all) aren't required to maintain redundant build configurations. Generally, I understand that large pieces of functionality offered by third-party Clojurescript libraries (& Leiningen plugins) are less useful/necessary now than when first released, due to Clojurescript's rapid acceleration. And that this can confuse new users about exactly what's necessary - I certainly found it confusing over the last few weeks. I'm a lambda noob and somethings not working right. I find > cljs-lambda. Clearly this person has figured it out, but I'm afraid to > simply run the project b/c I see its already changing IAM stuff etc. > To be clear, there's a utility subcommand (designed for AWS beginners) which creates an IAM role if you ask it to. So I'm gonna look at the code to try to find the details I'm looking > for. But the code is complicated by cljsbuild/lein-plugin stuff and I > can't do it in 5 min so I go back to googling. > There's two cljsbuild-specific lines, IIRC. The rest (compiler map destructuring, etc.) would exist independently of the cljsbuild dependency. So, for me at least, a more a la carte approach probably would have > saved me some time and entice me to use the project.. maybe I'll take > another stab at digesting it soon. There's definitely more which could be done in that direction (e.g. separating building from deployment, or allowing the deployment of only some/one of the Lambda functions in a project). Take care, Moe -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
