Re: Who Uses import-vars?

[platonovadim]

I've used `import-vars` before, most notably in `java-time`. Even though 
I've never had any problems with the imported vars, I'm aware many people 
dislike the method so I'm writing the APIs in `$project.core` namespaces 
now.

Would be great if anyone who had problems or is otherwise directly aware of 
the drawbacks contributed to the issue in the Potemkin project 
. I think Zach would be 
happy to include any and all real issues in the Potemkin's docs. 

On Wednesday, November 8, 2017 at 3:25:30 AM UTC+1, Didier wrote:
>
> I found private/public works fine. I put my public interface at the bottom 
> of the file with a nice comment header. Using another namespace like .impl, 
> I've always had the issue that nobody on my team can agree with what the 
> name convention should be for what an impl namespace should be called , 
> so private has had less controversy. It can lead to pretty large file, and 
> splitting namespaces across more then one file, even though supported, 
> messes up with a lot of tooling, so I also avoid that.
>
> I think, what I've struggled with is how to move an API to another 
> namespace, while maintaining backwards compatibility. This happens a lot 
> where I work, where we want to refactor the namespace structure, and move 
> things around, and rename namespaces, but we're not sure if there were 
> other packages that depend on it which would break. So I'd want to take the 
> existing namespace, and move all its vars in a new namespace, but where the 
> old namespace still exists as a frozen immutable interface that now maps 
> back to the new. Yet I've hesitated to use potemkin, because its non ideal. 
> I'm still hoping here for a better solution to this to show up.
>
> On Tuesday, 7 November 2017 13:42:16 UTC-8, Sean Corfield wrote:
>>
>> I’m with Timothy (and Alex) on Potemkin. For me, it’s been the source of 
>> some very weird transitive dependency bugs as well as strange binding 
>> issues across a number of projects where it has been dragged in by various 
>> third party libraries (e.g., clj-http). It’s made me very wary of it 
>>
>>  
>>
>> I have – very occasionally – used (home-grown) functionality to “import” 
>> vars from one namespace to another, but without the watchers or any other 
>> “magic”, and it’s been done only when the convenience of a loop to intern 
>> symbols dramatically outweighs the effort of writing the delegation 
>> functions by hand (expectations.clojure.test currently does that to expose 
>> much of the old expectations API as-is while I’m transitioning how the 
>> library works). I consider it very much an interim/transition solution, 
>> that should be avoided in normal production code.
>>
>>  
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>  
>> --
>> *From:* clo...@googlegroups.com  on behalf of 
>> Timothy Baldridge 
>> *Sent:* Tuesday, November 7, 2017 11:11:14 AM
>> *To:* clo...@googlegroups.com
>> *Subject:* Re: Who Uses import-vars? 
>>  
>> I structure my code very explicitly. Normally the most common constructs 
>> are put in a single file named after the library itself (not in core.clj, 
>> do that half your files will be named core). 
>>
>> https://github.com/halgari/odin/blob/master/src/com/tbaldridge/odin.clj
>>
>> Anything not in the API that should be unpublished to users is in other 
>> namespaces that are imported and wrapped by vars in the main namespace. 
>> This does several things:
>>
>> * Keeps the public interface in one place
>> * Allows for a different public interface than the private one. Notice 
>> how Odin has its own version of `when`, pulling that off require a bit of 
>> careful macro usage, so I'd rather write that once under a different name, 
>> then rename it to `when`. 
>> * It's now simple to say "anything in this namespace is public and will 
>> not change"
>>
>> Core.async uses a pattern much like this, the API is in 
>> clojure.core.async, most of the logic is under *.async.impl.*. 
>>
>> I don't recommend potemkin's import-vars at all. Clojure vars were not 
>> meant to exist in more than one namespace at a time, so potemkin pulls of 
>> its magic by linking two vars via watchers. This means that changes to one 
>> var can cause side-effects in the other. In addition, bindings don't convey 
>> properly (AFAIK), so if you using bindings on one var, the changes won't be 
>> seen in the other var. Remember: import-vars doesn't actually import 
>> anything, it simply creates a new var in the current namespace and links 
>> the two via a two-way binding. It's quite the hack, imo. 
>>
>> So I have to agree with Potemkin's tagline on github: it's an idea that's 
>> "almost good". 
>>
>> Timothy
>>
>> On Tue, Nov 7, 2017 at 11:13 AM, Nick 

Re: [ANN] JMH-Clojure: Seamless JMH benchmarking for Clojure

[platonovadim]

This looks awesome! Now need to find a reason to benchmark something...

On Thursday, September 28, 2017 at 10:24:48 PM UTC+2, jgp...@gmail.com 
wrote:
>
> A data-oriented API to JMH 
> , the Java 
> Microbenchmark Harness.
>
> Much more information is available at the github page: 
> https://github.com/jgpc42/jmh-clojure
>
>
>

-- 
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: [ANN] Manifail 0.4.0

[platonovadim]

I did! After I wrote first few versions of Manifail though. One of the 
issues in Banach repo inspired me to add a `reset!` marker in addition to 
`abort!` - https://github.com/RackSec/banach/issues/12. 

I've tried expressing retry logic through streams at first too, but settled 
on a different approach in the end.

On Thursday, September 1, 2016 at 7:19:28 PM UTC+2, lvh ‌ wrote:
>
> Hi!
>
> On Sep 1, 2016, at 12:03 PM, platon...@gmail.com  wrote:
>
> Hello,
>
> I'm pleased to announce a release of Manifail 
>  - a failure/retry handling library 
> built on top of Manifold . 
> I know we have Diehard  already, 
> conveniently wrapping the Failsafe 
>  Java library. However, I wanted 
> to see if a more Clojurey approach was possible. In this case, an approach 
> which would let you express retry handling logic directly instead of 
> smearing it across callbacks.
>
>
>
> Cool! I was wondering if you had seen https://github.com/RackSec/banach 
> (something 
> we develop at Rackspace Managed Security), which includes a failure/retry 
> library. It seems to have a similar approach in being more clojure-y, but 
> uses combinators to produce behavior.
>
> Here’s the retry logic: 
> https://github.com/RackSec/banach/blob/master/src/banach/retry.clj
>
> lvh
>
>
> Please feel free to check out the readme 
>  and an example 
>  project!
>
> Github: https://github.com/tulos/manifail
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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] Manifail 0.4.0

[platonovadim]

Hello,

I'm pleased to announce a release of Manifail 
 - a failure/retry handling library 
built on top of Manifold . 
I know we have Diehard  already, 
conveniently wrapping the Failsafe  
Java library. However, I wanted to see if a more Clojurey approach was 
possible. In this case, an approach which would let you express retry 
handling logic directly instead of smearing it across callbacks.

Please feel free to check out the readme 
 and an example 
 project!

Github: https://github.com/tulos/manifail

-- 
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] boot-criterium 0.2.0 - Tasks that run your benchmarks!

[platonovadim]

Hello all,

we're pleased to announce boot-criterium 
 - a simple way to benchmark code 
using Criterium. 
The only prerequisites are JVM and Boot , 
the glorious build tool.

You can even call it from the command line!

boot -d tulos/boot-criterium \
>   bench -l "1.6" -g "'(reduce + (range 1000))" -Q -d org.clojure/
clojure:1.6.0 -- \ 
>   bench -l "1.7" -g "'(reduce + (range 1000))" -Q -d org.clojure/
clojure:1.7.0 -- \ 
>   bench -l "1.8" -g "'(reduce + (range 1000))" -Q -d org.clojure/
clojure:1.8.0 -- \ 
>   report -f table -O 

| :benchmark/goal |  :mean |   :variance |   :upper-q |   :lower-q | :
evaluation-count | :outlier-effect | 
|-++-+++---+-|
 
| 1.6 | 38.2482 µs |   4.2256 µs | 42.7620 µs | 31.0620 µs |   
  18966 |   :moderate | 
| 1.7 | 10.6118 µs |   1.3260 µs | 11.9993 µs |  9.2158 µs |   
  67692 |   :moderate | 
| 1.8 |  9.0259 µs | 525.3190 ns |  9.6581 µs |  8.3780 µs |   
  64428 |   :moderate |


Have fun!

-- 
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: [ANN] Clojure.Java-Time 0.2.0

[platonovadim]

Your best bet for a Clj/Cljs compatible library is `clj-time`. I think in 
the long run `clj-time` will release a version based on Java 8 as more and 
more libraries in the Java ecosystem will provide integration with the 
native Date-Time API. Joda-Time will fade into the past.

Writing a library that uniformly wraps Joda and Java 8 Date-Time API is 
complicated and, in my view, completely useless (I wrote wrappers for both 
so am extensively familiar with their internals).

On Friday, January 15, 2016 at 12:01:08 PM UTC+1, Daniel Compton wrote:
>
> There are few differences between java.time and Joda time for most 
> people's usage (I think), so a wrapper to support both would probably be 
> possible. 
>
>
> http://stackoverflow.com/questions/24631909/differences-between-java-8-date-time-api-java-time-and-joda-time
> On Fri, 15 Jan 2016 at 11:56 PM, Mikera  > wrote:
>
>> Looks awesome, I'd definitely like to use this whenever I can guarantee 
>> running on Java 8 or above.
>>
>> Question: is there any change of having a unified time API in Clojure? 
>> That supports both Joda time and Java time? And works with cljs? It is a 
>> bit frustrating to have to hard-code to specific time libraries rather 
>> using a good abstraction
>>
>>
>> On Wednesday, 13 January 2016 20:29:25 UTC+8, platon...@gmail.com wrote:
>>>
>>> Hello all,
>>>
>>> I've released a Java 8 Date-Time API wrapper some time ago but never 
>>> bothered to make a formal announcement. So here it is: 
>>> Clojure.Java-Time. 
>>> Please, feel free to check out the readme 
>>>  and 
>>> maybe even try using it :)
>>>
>>> Dependency vector: [clojure.java-time "0.2.0"]
>>>
>>> Have fun!
>>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Daniel
>

-- 
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] Clojure.Java-Time 0.2.0

[platonovadim]

Hello all,

I've released a Java 8 Date-Time API wrapper some time ago but never 
bothered to make a formal announcement. So here it is: Clojure.Java-Time. 

Please, feel free to check out the readme 
 and maybe 
even try using it :)

Dependency vector: [clojure.java-time "0.2.0"]

Have fun!

-- 
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] Clojure.Joda-Time 0.6.0

[platonovadim]

Happy to announce a new release of Clojure.Joda-Time[0] for those of us who 
have to operate on temporal entities in complicated ways.

Notable changes: 

* A brand new `joda-time.accessors` namespace which contains a bunch of 
accessors generated for every Joda-Time date field type, e.g. 
`day-of-month`, `max-day-of-month`, `with-day-of-month`, 
`with-max-day-of-month`, etc. The accessors work on both partials (local 
dates) and instants (date-time). There are also accessors for periods.
* Multi-arity constructors for date-times and partial dates (local-date, 
local-date-time, etc.)
* Support for the latest Joda-Time 2.8.1

Changelog: https://github.com/dm3/clojure.joda-time/blob/master/CHANGELOG.md
Codox: http://dm3.github.io/clojure.joda-time/

[0] https://github.com/dm3/clojure.joda-time

-- 
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: [ANN] Clojure.Joda-Time 0.6.0

[platonovadim]

Great to hear someone uses it besides myself (and my colleagues who were 
forced into it, hehe)!

On Wednesday, July 15, 2015 at 10:55:51 AM UTC+2, Bruce Durling wrote:

 Great to have an update for the library I use so much. Thx! 

 cheers, 
 Bruce 

 On Wed, Jul 15, 2015 at 9:48 AM,  platon...@gmail.com javascript: 
 wrote: 
  Happy to announce a new release of Clojure.Joda-Time[0] for those of us 
 who 
  have to operate on temporal entities in complicated ways. 
  
  Notable changes: 
  
  * A brand new `joda-time.accessors` namespace which contains a bunch of 
  accessors generated for every Joda-Time date field type, e.g. 
  `day-of-month`, `max-day-of-month`, `with-day-of-month`, 
  `with-max-day-of-month`, etc. The accessors work on both partials (local 
  dates) and instants (date-time). There are also accessors for periods. 
  * Multi-arity constructors for date-times and partial dates (local-date, 
  local-date-time, etc.) 
  * Support for the latest Joda-Time 2.8.1 
  
  Changelog: 
 https://github.com/dm3/clojure.joda-time/blob/master/CHANGELOG.md 
  Codox: http://dm3.github.io/clojure.joda-time/ 
  
  [0] https://github.com/dm3/clojure.joda-time 
  
  -- 
  You received this message because you are subscribed to the Google 
  Groups Clojure group. 
  To post to this group, send email to clo...@googlegroups.com 
 javascript: 
  Note that posts from new members are moderated - please be patient with 
 your 
  first post. 
  To unsubscribe from this group, send email to 
  clojure+u...@googlegroups.com javascript: 
  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+u...@googlegroups.com javascript:. 
  For more options, visit https://groups.google.com/d/optout. 


-- 
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: Composing Stuart Sierra's components

[platonovadim]

I've also been investigating the nested system approach/problem.

The primary use case that I have is composing subsystems which are mostly 
independent modules using a higher order system to run in one process. The 
modules themselves can be easily extracted into separate applications thus 
becoming their own top level systems which makes it desirable to keep their 
system maps intact. 

Components inside modules might depend on the *whole* modules, not their 
constituent parts. This allows to have modules call each other through the 
API's in-process as well as being easily replaced by remote endpoints when 
separated into multiple processes.

This mostly works except for the components depending on other 
modules/systems, e.g.:

(require '[com.stuartsierra.component :as cmp])

(defrecord X [x started] 
   cmp/Lifecycle 
   (start [this] (if started (println Already started  x) (println 
Starting  x   this)) (assoc this :started true)) 
   (stop [this] (println Stopping  x   this) this))

(def sys1 (cmp/system-map :x (cmp/using (X. depends on dep nil) [:dep])))
(def sys2 (cmp/system-map :y (cmp/using (X. depends on sys1 nil) 
[:sys1])))
(def hsys (cmp/system-map :sys1 (cmp/using sys1 [:dep]), :sys2 (cmp/using 
sys2 [:sys1]) :dep (X. dependency nil)))

(cmp/start hsys)

Starting  dependency   #user.X{:x dependency, :started nil}
Already started  dependency
Starting  depends on dep   #user.X{:x depends on dep, :started nil, :dep 
#user.X{:x dependency, :started true}}

clojure.lang.ExceptionInfo: Error in component :sys2 in system 
com.stuartsierra.component.SystemMap calling 
#'com.stuartsierra.component/start
clojure.lang.ExceptionInfo: Missing dependency :dep of clojure.lang.Keyword 
expected in system at :dep

This happens because of the following:
1. Dependency :*dep* of *sys1* is started in *hsys*
2. *sys1* is started (:*dep* is started again, so the start/stop should be 
idempotent)
3. Dependency :*sys1* of *sys2* is started in *hsys*
4. :*sys1* cannot be started as it depends on :*dep* which isn't present in 
*sys2*

This scenario could be supported by the Component library in several ways:

1. introduce an IdempotentLifecycle protocol which will be respected by the 
Component library. Implement the protocol for the SystemMap. 
IdempotentLifecycles will not be started or stopped for the second time, 
also their dependencies will not be updated if they are already started.
2. do not fail if a component already has a dependency under the specified 
key. This is a hack compared to the first solution, but I might go with it 
in the short term.

Stuart, what do you think about that? Would you consider a PR implementing 
the first proposal?

On Wednesday, March 18, 2015 at 10:18:36 AM UTC+1, Stuart Sierra wrote:


 On Tue, Mar 17, 2015 at 5:47 PM, James Gatannah james.g...@gmail.com 
 javascript: wrote:

 FWIW, we've been using something that smells an awful lot like nested
 systems for months now. I never realized we weren't supposed to.



 It's not that nested systems *never* work, but from what I've seen they 
 cause more complications than they're worth. The 'component' model doesn't 
 forbid it, but it does not support dependencies between components in 
 different subsystems.

 I've found it easier to keep system maps flat and use namespaced 
 keywords to distinguish subsystem groups, even in large systems with 30+ 
 components.

 –S



-- 
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: Composing Stuart Sierra's components

[platonovadim]

A possible implementation for the idea expressed in the previous post - 
https://github.com/stuartsierra/component/pull/25


On Wednesday, March 18, 2015 at 2:41:46 PM UTC+1, platon...@gmail.com wrote:

 I've also been investigating the nested system approach/problem.

 The primary use case that I have is composing subsystems which are mostly 
 independent modules using a higher order system to run in one process. The 
 modules themselves can be easily extracted into separate applications thus 
 becoming their own top level systems which makes it desirable to keep their 
 system maps intact. 

 Components inside modules might depend on the *whole* modules, not their 
 constituent parts. This allows to have modules call each other through the 
 API's in-process as well as being easily replaced by remote endpoints when 
 separated into multiple processes.

 This mostly works except for the components depending on other 
 modules/systems, e.g.:

 (require '[com.stuartsierra.component :as cmp])

 (defrecord X [x started] 
cmp/Lifecycle 
(start [this] (if started (println Already started  x) (println 
 Starting  x   this)) (assoc this :started true)) 
(stop [this] (println Stopping  x   this) this))

 (def sys1 (cmp/system-map :x (cmp/using (X. depends on dep nil) [:dep])))
 (def sys2 (cmp/system-map :y (cmp/using (X. depends on sys1 nil) 
 [:sys1])))
 (def hsys (cmp/system-map :sys1 (cmp/using sys1 [:dep]), :sys2 (cmp/using 
 sys2 [:sys1]) :dep (X. dependency nil)))

 (cmp/start hsys)

 Starting  dependency   #user.X{:x dependency, :started nil}
 Already started  dependency
 Starting  depends on dep   #user.X{:x depends on dep, :started nil, :dep 
 #user.X{:x dependency, :started true}}

 clojure.lang.ExceptionInfo: Error in component :sys2 in system 
 com.stuartsierra.component.SystemMap calling 
 #'com.stuartsierra.component/start
 clojure.lang.ExceptionInfo: Missing dependency :dep of 
 clojure.lang.Keyword expected in system at :dep

 This happens because of the following:
 1. Dependency :*dep* of *sys1* is started in *hsys*
 2. *sys1* is started (:*dep* is started again, so the start/stop should 
 be idempotent)
 3. Dependency :*sys1* of *sys2* is started in *hsys*
 4. :*sys1* cannot be started as it depends on :*dep* which isn't present 
 in *sys2*

 This scenario could be supported by the Component library in several ways:

 1. introduce an IdempotentLifecycle protocol which will be respected by 
 the Component library. Implement the protocol for the SystemMap. 
 IdempotentLifecycles will not be started or stopped for the second time, 
 also their dependencies will not be updated if they are already started.
 2. do not fail if a component already has a dependency under the specified 
 key. This is a hack compared to the first solution, but I might go with it 
 in the short term.

 Stuart, what do you think about that? Would you consider a PR implementing 
 the first proposal?

 On Wednesday, March 18, 2015 at 10:18:36 AM UTC+1, Stuart Sierra wrote:


 On Tue, Mar 17, 2015 at 5:47 PM, James Gatannah james.g...@gmail.com 
 wrote:

 FWIW, we've been using something that smells an awful lot like nested
 systems for months now. I never realized we weren't supposed to.



 It's not that nested systems *never* work, but from what I've seen they 
 cause more complications than they're worth. The 'component' model doesn't 
 forbid it, but it does not support dependencies between components in 
 different subsystems.

 I've found it easier to keep system maps flat and use namespaced 
 keywords to distinguish subsystem groups, even in large systems with 30+ 
 components.

 –S



-- 
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.