Re: dependency problem
(sorry previous comment was sent before I wanted :- )
Hi Alan,
I think you should keep commons-code 1.9 as far as is the last-version
required by any dep of your project
so ...
you could exclude globally (using :exclusions) your dependencies that are
causing the conflict and specified later in your :dependencies
:exclusions [org.clojure/clojure
commons-codec]
:dependencies [[org.clojure/clojure "1.7.0"]
[commons-codec "1.9"]
[twitter-api "0.7.8"]]
or just exclude it locally
:dependencies [[org.clojure/clojure "1.7.0"]
[commons-codec "1.9"]
[twitter-api "0.7.8" :exclusions
[commons-codec]]]
Hope it works for you!
Juan
El viernes, 13 de mayo de 2016, 12:41:43 (UTC+2), Juan A. Ruz @tangrammer
escribió:
>
> Hi Alan,
> I think you should keep commons-code 1.9 as far as is the last-version
> required by any dep of your project
> so ...
>
> you can
> :exclusions [org.clojure/clojure
>commons-codec]
> :dependencies [[org.clojure/clojure "1.7.0"]
> [commons-codec "1.9"]
> [twitter-api "0.7.8"]]
>
>
>
>
>
> El viernes, 13 de mayo de 2016, 10:27:34 (UTC+2), Alan Forrester escribió:
>>
>> I have been trying to use the Twitter API library by Adam Wynne:
>>
>> https://github.com/adamwynne/twitter-api
>>
>> and it appears to have a dependency problem.
>>
>> My project.clj file looks like this
>>
>> (defproject hash-tag-counting-thingy "0.1.0-SNAPSHOT"
>> :description "FIXME: write description"
>> :url "http://example.com/FIXME;
>> :license {:name "Eclipse Public License"
>> :url "http://www.eclipse.org/legal/epl-v10.html"}
>> :dependencies [[org.clojure/clojure "1.7.0"]
>> [twitter-api "0.7.8"]])
>>
>> And when I ran "lein deps :tree” I got
>>
>> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [commons-codec "1.8"]
>> overrides
>> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [clj-http "0.9.1"] ->
>> [commons-codec "1.9" :exclusions [org.clojure/clojure]]
>>
>> What is the recommended way to deal with a problem like this?
>>
>> Alan
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: dependency problem
Hi Alan,
I think you should keep commons-code 1.9 as far as is the last-version
required by any dep of your project
so ...
you can
:exclusions [org.clojure/clojure
commons-codec]
:dependencies [[org.clojure/clojure "1.7.0"]
[commons-codec "1.9"]
[twitter-api "0.7.8"]]
El viernes, 13 de mayo de 2016, 10:27:34 (UTC+2), Alan Forrester escribió:
>
> I have been trying to use the Twitter API library by Adam Wynne:
>
> https://github.com/adamwynne/twitter-api
>
> and it appears to have a dependency problem.
>
> My project.clj file looks like this
>
> (defproject hash-tag-counting-thingy "0.1.0-SNAPSHOT"
> :description "FIXME: write description"
> :url "http://example.com/FIXME;
> :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
> :dependencies [[org.clojure/clojure "1.7.0"]
> [twitter-api "0.7.8"]])
>
> And when I ran "lein deps :tree” I got
>
> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [commons-codec "1.8"]
> overrides
> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [clj-http "0.9.1"] ->
> [commons-codec "1.9" :exclusions [org.clojure/clojure]]
>
> What is the recommended way to deal with a problem like this?
>
> Alan
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[ANN] DEEP-IMPACT-AG/flowgic
Hi guys, here sharing an (alpha) approach to write logic flows in a declarative way https://github.com/DEEP-IMPACT-AG/flowgic One of the final purposes of this utility is to visualise the intended/written logic as you can see here https://cloud.githubusercontent.com/assets/731829/10277888/8a5bf848-6b59-11e5-96de-1b67fab4981b.png Looking forward your impressions and comments ... so I could keep improving it Have a good day! PS: it uses https://github.com/DEEP-IMPACT-AG/flowgic.graph to connect https://github.com/ztellman/rhizome as graph visualisation -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Flow control in Clojure
Hi Ditlev,
I was struggling with same flow-control logic and I reached to this (alpha)
solution based in describing logic flows
https://github.com/DEEP-IMPACT-AG/flowgic
so far It worked fine in my current code and i think that it also answers
the 2 points that Daniel Compton mentioned
> 1) decompose functions into smaller functions, regardless of these helper
> functions being of no use anywhere else.
> 2) define a bunch of helper functions in a top-level let-expression -
> again to avoid having functions which are too heavily indented?
Cheers!
El martes, 8 de diciembre de 2015, 21:18:18 (UTC+1), Ditlev Tøjner escribió:
>
> In designing our (by now) two clojure-based REST services we are
> struggling with managing flow-control.
>
> (Disclaimer: earlier backgrounds are with Python, C, Javascript and once
> upon a time Java/C# etc)
>
> What we'd like is to accomplish a series of steps which we feel are
> universal to REST-services.
> In the context of PUT/POST that is:
> ---
> 1. ensure that the content is of a given format (application/json)
>
> 2. receive & validate input
> 2a. if the input is invalid, return error output (in our case describing
> what went wrong)
>
> 3. create a new entry / update an existing entry
> (Note if you know the entire URI, then using PUT for both
> updating/creating is acceptable)
>
> 4. format a response (typically containing the created/updated object)
> ---
>
> Fig1 details how, after several passes, we're dealing with this. The
> approach is heavily inspired
> by Ref1 and essentially executes each step outlined above with the
> understanding that failure might
> occur. If a failure occurs, an error message is returned (of course).
>
> We chose an approach similar to Ref1 because we wanted to abort on errors,
> occasionally recover
> (such as update becoming create if no record is found) and we wanted
> detailed errors which
> precludes the use of (and ...).
>
> The astute observer may note that our model fails to capture the concept
> of recoverable failures
> - update-record* may fail for more reasons than simply not having a row
> (transient errors, actual
> logic-related errors etc) some of which are non-recoverable.
>
> As it stands, this means the function needs refactoring, *again*.
> What all this boils down to is this: given the unique interplay of
> immutability with LISP-style
> (AST) syntax - which techniques are successfully employed to avoid heavily
> indented code ? Is
> the only solution really to either:
>
> 1) decompose functions into smaller functions, regardless of
> these helper functions being of no use anywhere else.
>
> 2) define a bunch of helper functions in a top-level let-expression -
> again to avoid having
>functions which are too heavily indented?
>
>
> Does it ever get easier ? Are we missing something ? It seems extreme to
> reach for monads for
> something of this nature.
>
> References
> 1. https://brehaut.net/blog/2011/error_monads (Ref1)
>
> Fig. 1. - a PUT endpoint
>
> (defn update*
> "create/update a pin."
> [cid source rq]
> (err/attempt-all
>[_ (chk/mediatype-in? (get rq :content-type) ["application/json"])
> rq (clojure.walk/keywordize-keys rq)
> ;; data which can come from the user
> input (merge {:method "app"
> :seen_at (-> (at/now-utc) (at/->dt-utc-str))}
> (get rq :body)
> {:source_type (get source :type) :source_id (get source :
> id)})
> _ (av/input-valid? validate-pin-params input)
>
>
> ;; additional data extracted from URI & token
> record-data (merge input
>{:cid cid
> :uid (rq->uid* rq)})
> record (err/any (update-record* record-data)
> (new-record* record-data))]
>;; Success
>(rsp/created
> (url cid source)
> {:key-name "pinid"
> :body {:request (model/transform record)}})
>;; Failure
>err/handle-failure))
>
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: separation of concerns w/o encapsulation
Hi guys, when you talk about encapsulation do you mean using defrecords + protocols ? In this case, we are talking of choosing defrecords instead of plain functions. Maybe it would be better if we talk too about the drawbacks of this choice. For example, can we compose or extend protocol functions (I mean to extend existent component protocol functions). In some occasion, I wanted to use juxt/bolt [(formerly juxt/cylon) security component based system] in GoogleAppEngine but juxt/bolt uses http-kit and GAE dont' let you use this lib dependency. So at last I had to fork juxt/bolt to switch the http client library for plain java.net classes. So, I wonder myself which are the limits of reusability in component pattern. El viernes, 8 de mayo de 2015, 18:29:50 (UTC+2), Brian Craft escribió: Talk on the list about encapsulation usually comes back to some variation of you don't need it when you have immutable data structures. But in the long term I'm finding the problem of working w/o encapsulation is not the danger of data being mutated under you. Rather, it's the danger of all the module boundaries blurring over time, leading to the big ball of mud: a very fragile code base where everything depends on everything else. E.g. if you model your application with a plain data structure which you pass around to different modules, each concerned with a small part of that data structure, the tendency over time is for every module to become concerned with every part of that data structure. Then you have no separation, nothing is reusable, and the code is very fragile. How do you avoid this, practically? In OO it would be enforced with encapsulation, so the next developer (which might be me, six months later) trying to fix a bug, or add a feature, knows Oh, I shouldn't peek in here: this module isn't supposed to depend on that piece of data. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
wondering the reasons to choose defrecord vs reify in stuartsierra/component
Hi guys, I'm just wondering the pros/contras that justify to choose defrecord vs reify as component fn constructor. in the component README we can read To create a component, define a Clojure record that implements the Lifecycle protocol. Yes I know that defrecord creates an immutable persistent map which implements a protocol. but I think that the same thing can be achieved with reify (BTW: om way to define component) over a persistent map... Do you think there are more reasons to set defrecord as default base fn for components? Thanks in advance Juan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Which could be the best clojure alternative to replace play framework?
Hi guys, just looking for possible (and hopefully experienced) directions to replace Play Framework and its popular Akka support that as the doc page states https://www.playframework.com/documentation/2.0/JavaAkka: Akka provides a better platform to build correct concurrent and scalable applications Thanks in advance and have great clojure coding! Juan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: which are the pros and cons between stuartsierra/component and prismatic/graph?
Thanks to all for your good points! Sorry for the delay answering but I needed to review the docs first, now I'll try to be brave and summarise here Graph vs Component features and/or properties ... 1. *graph* and *component* solve dependency injection 2. *component* solves state management (Lifecyle protocol and SystemMap record) 3. *component* comes with reloaded workflow 4. *graph* lets you analyze, change and compose your functional computation 5. *component* forces you to use defrecord Ok, so I'm convinced now that component is great for state management! ... but, *how can you analyze, change and compose the internals (functional computation) of your defrecords???* I mean that component lib is really great for composing your system (and repl development including mocking components!) but forces you to use closed component that others projects can't *easily* extend [1] or change, so for example, which would be the good pattern to follow if you need monitoring/logging your system in *component (*having that defrecord limitation)? what do you think if you *write your components using graph*? So we keep + system composable using component + component composable using graph = example code here https://github.com/milesian/system-examples/blob/318f58383a7a4917c08147c3d0023e5bd5d93af8/src/milesian/graph_example.clj Thanks again! Juan [1] This was my own newbie attempt to extend defrecords tangrammer/defrecord-wrapper https://github.com/tangrammer/defrecord-wrapper , and milesian/aop https://github.com/milesian/aop the component integration one El miércoles, 4 de febrero de 2015, 13:46:33 (UTC+1), Juan A. Ruz @tangrammer escribió: Hi guys! Can anyone give some insight on the features or downsides of choosing component vs graph libs? Or maybe explain the advantages of using defrecords instead of plain fns? thanks in advance! Juan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
