Re: GraalVM's native-image incompatible with Clojure's eval?

[Jeroen van Dijk]

Hi Khalid,

Reflections [1] are a big problem too for Graalvm. Here is a thread of
playing with Clojure and Graalvm [2]. If you follow the links, you will see
some issues I ran into.

Hth,
Jeroen

[1] Ones that are and aren't caught by *warn-on-reflections*
https://github.com/dundalek/closh/pull/105/files#diff-336b8a8dffae65260f854867fc8529b5R9
[2] https://github.com/dundalek/closh/issues/93



On Mon, Nov 26, 2018 at 6:22 PM Khalid Jebbari 
wrote:

> Thanks a lot. So it means Clojure's `eval` is by design incompatible with
> SubstrateVM.
>
> Does anyone know of others hard incompatibilities ?
>
> On Monday, November 26, 2018 at 6:16:20 PM UTC+1, Gary Trakhman wrote:
>>
>> Yes, eval will generate classes in a dynamic classloader, load them, then
>> call methods on the newly formed class/object except for
>> too-simple-to-be-interesting cases.
>>
>> On Mon, Nov 26, 2018 at 11:43 AM Khalid Jebbari 
>> wrote:
>>
>>> Hi,
>>>
>>> I was doing a small experiment with Clojure and GraalVM and ended with
>>> this minimal reproduction case of an incompatibility between Clojure's
>>> `eval` and GraalVM's native-image tool (the program that compiles a JVM
>>> program to a native executable, based on the GraalVM's SubstrateVM
>>> compiler).
>>>
>>> Here's the Clojure program:
>>>
>>> (ns test-cli.main
>>>   (:gen-class))
>>>
>>> (set! *warn-on-reflection* true)
>>>
>>> (defn -main
>>>   "I don't do a whole lot ... yet."
>>>   [& args]
>>>   (println (+ 1 1)) ;; trick to force loading clojure.lang.Numbers, not
>>> working
>>>   (eval (read-string "(+ 1 1)")))
>>>
>>> Using Clojure 1.9.0 and GraalVM version 1.0.0-rc9.
>>>
>>> When I compile it with the
>>> option "--report-unsupported-elements-at-runtime" (which gives a more
>>> precised error message), here's the output when I try executing the
>>> resulting executable:
>>>
>>> Exception in thread "main" java.lang.ClassNotFoundException:
>>> clojure.lang.Numbers, compiling:(NO_SOURCE_PATH:0:0)
>>> at java.lang.Throwable.(Throwable.java:287)
>>> at java.lang.Exception.(Exception.java:84)
>>> at java.lang.RuntimeException.(RuntimeException.java:80)
>>> at
>>> clojure.lang.Compiler$CompilerException.(Compiler.java:6804)
>>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:7010)
>>> at clojure.lang.Compiler.analyze(Compiler.java:6773)
>>> at clojure.lang.Compiler.analyze(Compiler.java:6729)
>>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6998)
>>> at clojure.lang.Compiler.analyze(Compiler.java:6773)
>>> at clojure.lang.Compiler.analyze(Compiler.java:6729)
>>> at
>>> clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6100)
>>> at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5460)
>>> at clojure.lang.Compiler$FnExpr.parse(Compiler.java:4022)
>>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:7001)
>>> at clojure.lang.Compiler.analyze(Compiler.java:6773)
>>> at clojure.lang.Compiler.eval(Compiler.java:7059)
>>> at clojure.lang.Compiler.eval(Compiler.java:7025)
>>> at clojure.core$eval.invokeStatic(core.clj:3206)
>>> at test_cli.main$_main.invokeStatic(main.clj:7)
>>> at test_cli.main$_main.doInvoke(main.clj:7)
>>> at clojure.lang.RestFn.invoke(RestFn.java:397)
>>> at clojure.lang.AFn.applyToHelper(AFn.java:152)
>>> at clojure.lang.RestFn.applyTo(RestFn.java:132)
>>> at test_cli.main.main(Unknown Source)
>>> at
>>> com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:164)
>>> Caused by: java.lang.ClassNotFoundException: clojure.lang.Numbers
>>> at java.lang.Throwable.(Throwable.java:287)
>>> at java.lang.Exception.(Exception.java:84)
>>> at
>>> java.lang.ReflectiveOperationException.(ReflectiveOperationException.java:75)
>>> at
>>> java.lang.ClassNotFoundException.(ClassNotFoundException.java:82)
>>> at
>>> com.oracle.svm.core.hub.ClassForNameSupport.forName(ClassForNameSupport.java:51)
>>> at
>>> com.oracle.svm.core.hub.DynamicHub.forName(DynamicHub.java:1036)
>>> at clojure.lang.RT.classForName(RT.java:2204)
>>> at clojure.lang.RT.classForNameNonLoading(RT.java:2217)
>>> at clojure.lang.Compiler$HostExpr.maybeClass(Compiler.java:1041)
>>> at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:982)
>>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:7003)
>>> ... 20 more
>>>
>>> I'm no expert in Java/JVM and would like to understand the problem.
>>> According to the SubstrateVM documentation (
>>> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md)
>>> it can't compile Dynamic Class Loading/Unloading. Is Clojure's `eval` doing
>>> such dynamic loading? Or doing something else not supported by SubstrateVM
>>> as said in the documentation?
>>>
>>> Thanks *a lot* in advance for you answers.
>>>
>>> --
>>> You received this message 

Re: [ANN] tools.deps.alpha 0.5.452 and clj 1.9.0.394

[Jeroen van Dijk]

Hi Alex,

Thanks for this new release!

I just want to point out that for Linux, there is also the `brew install
clojure` option via http://linuxbrew.sh/ . Not sure how well spread this
tool is, but we've used it successfully to distribute an internal tool to
both our Mac and Linux users.

Thanks,
Jeroen

On Sat, Sep 15, 2018 at 3:36 PM Alex Miller  wrote:

> Just a small bug fix/enhancement release of these...
>
> * TDEPS-92  error and
> report on unknown alias key
> * TDEPS-12  add support for
> multiple classifiers in libs
> * TDEPS-95  fix bug
> preventing :default-deps from working
>
> If on Mac, use `brew upgrade clojure` or on Linux see
> https://clojure.org/guides/getting_started for updated scripts.
>
> --
> 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.
>

-- 
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 1.10.0-RC1 (please test!)

[Jeroen van Dijk]

Tested against closh (clojure shell): Uberjar works via boot, acts normally
when started.  (details

)

(For what it's worth the error between 1.9 and 1.10 on GraalVM is slightly
different, however both version don't work anyway yet [background
])

Jeroen

On Fri, Oct 12, 2018 at 9:28 AM Łukasz Korecki 
wrote:

> I've run tests against our biggest Clojure app (~40k LOC with tests) - no
> failures, Uberjar compiled cleanly as well.
> We're giong to deploy it to our testing environment early next week.
>
> Łukasz
>
> On Thursday, October 11, 2018 at 4:11:45 PM UTC+1, Alex Miller wrote:
>>
>> 1.10.0-RC1 is now available. You can try it with clj using:
>>
>>   clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version
>> "1.10.0-RC1"}}}'
>>
>> 1.10.0-RC1 is the same code as beta2 (only change are some changelog
>> fixes).
>> You can read the full 1.10 changelog here:
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>> *Note: This is a release candidate! Please try this release candidate
>> with your project and provide feedback (both whether it works as expected
>> and any issues).* If there are issues we will assess, otherwise we
>> intend to move towards a final release of 1.10.
>>
>>
>> --
> 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.
>

-- 
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] Datomic Cloud

[Jeroen van Dijk]

Congrats!

On Wed, Jan 17, 2018 at 3:06 PM, Stuart Halloway 
wrote:

> Datomic Cloud is now available! http://blog.datomic.com/2018/01/datomic-
> cloud.html
>
> --
> 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.
>

-- 
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: Using clojure.spec for api migrations?

[Jeroen van Dijk]

Oh I meant `clojure.spec/gen` instead of `clojure.spec/with-gen`.
`clojure.spec/gen` has an overrides option. I (think I) need something like
this to cleanly change the unforming action in a nested spec.

Jeroen

On Tue, Sep 6, 2016 at 8:00 PM, Jeroen van Dijk <jeroentjevand...@gmail.com>
wrote:

> Hi,
>
> I'm playing with the idea of using clojure.spec to make an API backwards
> compatible by using conform and unform to transform data from the old
> version format to a new format version. Below is an example of this in code:
>
> Say we have API change that involves changing the name of a nested key:
>
> (do
>   ;; Old api
>   (s/def :api.v0.input.nested/label keyword?)
>   (s/def :api.v0.input/nested (s/keys :req-un
> [:api.v0.input.nested/label]))
>   (s/def :api.v0/input (s/keys :req-un [:api.v0.input/nested]))
>
>   ;; New api
>   (s/def :api.v1.input.nested/key keyword?)
>   (s/def :api.v1.input/nested (s/keys :req-un [:api.v1.input.nested/key]))
>   (s/def :api.v1/input (s/keys :req-un [:api.v1.input/nested]))
>
>   ;; Migration specs
>   (s/def :api.v0-v1.migration.input/nested (s/conformer (fn [_] (throw
> (ex-info "Don't use as conformer" {})))
> (fn [x]
> (clojure.set/rename-keys x {:label :key}
>
>   (s/def :api.v0-v1.migration/input (s/conformer (fn [x]
>(s/conform
> :api.v1/input x))
>  (fn [x]
>(s/unform (s/keys
> :req-un [:api.v0-v1.migration.input/nested]) x
>
>   ;; Changes {:nested {:label :hi}} to {:nested {:key :hi}}
>   (s/unform :api.v0-v1.migration/input {:nested {:label :hi}}))
>
> So this kind of works, but I wonder whether there is an easier way or if
> I'm thinking about this the wrong way. I was hoping there would be
> something like with-unformer (like with-gen) that allows me to change the
> unforming action for a specific key without having to copy most of the old
> spec.
>
> Any suggestions or advise is appreciated.
>
> Thanks,
> Jeroen
>
>
>

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

Using clojure.spec for api migrations?

[Jeroen van Dijk]

Hi,

I'm playing with the idea of using clojure.spec to make an API backwards
compatible by using conform and unform to transform data from the old
version format to a new format version. Below is an example of this in code:

Say we have API change that involves changing the name of a nested key:

(do
  ;; Old api
  (s/def :api.v0.input.nested/label keyword?)
  (s/def :api.v0.input/nested (s/keys :req-un [:api.v0.input.nested/label]))
  (s/def :api.v0/input (s/keys :req-un [:api.v0.input/nested]))

  ;; New api
  (s/def :api.v1.input.nested/key keyword?)
  (s/def :api.v1.input/nested (s/keys :req-un [:api.v1.input.nested/key]))
  (s/def :api.v1/input (s/keys :req-un [:api.v1.input/nested]))

  ;; Migration specs
  (s/def :api.v0-v1.migration.input/nested (s/conformer (fn [_] (throw
(ex-info "Don't use as conformer" {})))
(fn [x]
(clojure.set/rename-keys x {:label :key}

  (s/def :api.v0-v1.migration/input (s/conformer (fn [x]
   (s/conform :api.v1/input
x))
 (fn [x]
   (s/unform (s/keys
:req-un [:api.v0-v1.migration.input/nested]) x

  ;; Changes {:nested {:label :hi}} to {:nested {:key :hi}}
  (s/unform :api.v0-v1.migration/input {:nested {:label :hi}}))

So this kind of works, but I wonder whether there is an easier way or if
I'm thinking about this the wrong way. I was hoping there would be
something like with-unformer (like with-gen) that allows me to change the
unforming action for a specific key without having to copy most of the old
spec.

Any suggestions or advise is appreciated.

Thanks,
Jeroen

-- 
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: clojure.spec generation question

[Jeroen van Dijk]

Thank you Rich!

Op di 31 mei 2016 om 19:12 schreef Rich Hickey <richhic...@gmail.com>:

> You are not labeling your preds, so ::not-predicate is taken as the label
> for ::and-predicate etc.
>
> Also, tuples are not labeled:
>
> (require '[clojure.spec :as s])
> (require '[clojure.spec.gen :as gen])
>
> (s/def ::atom string?)
>
> (s/def ::predicate (s/or
>:not ::not-predicate
>:and ::and-predicate
>:or ::or-predicate
>:atom ::atom))
>
> (s/def ::and-predicate (s/cat :pred #{:and} :args (s/+ ::predicate)))
> (s/def ::or-predicate  (s/cat :pred #{:or} :args (s/+ ::predicate)))
> (s/def ::not-predicate (s/tuple #{:not} ::predicate))
>
> user=> (prn (take 5 (gen/sample (s/gen ::predicate
> ([:not [:not (:or "")]] "L" [:not (:and (:and (:and "" (:or "tQ" "s" "")))
> [:not [:not "T"]])] "19f" [:not "8lC”])
>
> spec works the same under the hood as what Gary showed, e.g. s/or turns
> into gen/one-of etc.
>
> Rich
>
> > On May 31, 2016, at 11:32 AM, Jeroen van Dijk <
> jeroentjevand...@gmail.com> wrote:
> >
> > Hi Gary,
> >
> > Thanks for the feedback. I've tried it with test.check itself and I get
> better results (see below). So I'm guessing clojure.spec needs different
> input or it works differently underneath.
> >
> > Thanks,
> > Jeroen
> >
> > (require '[clojure.test.check :as tc])
> > (require '[clojure.test.check.generators :as gen])
> > (require '[clojure.test.check.properties :as prop])
> >
> > (def gen-atom (gen/elements (mapcat (juxt (partial str "f_a")
> >  (partial str "t_a")) (range
> 10
> >
> > (def gen-atom (gen/elements (mapcat (juxt (partial str "f_a")
> >  (partial str "t_a")) (range
> 10
> >
> > (defn gen-cat
> >  "Returns a generator of a sequence catenated from results of
> > gens, each of which should generate something sequential."
> >  [& gens]
> >  (gen/fmap #(vec (apply concat %))
> >(apply gen/tuple gens)))
> >
> > (def compound (fn [inner-gen]
> >(gen/one-of [(gen-cat (gen/elements [[:not]]) (gen/tuple
> inner-gen))
> > (gen-cat (gen/elements [[:or]])  (gen/tuple
> inner-gen)  (gen/not-empty (gen/list inner-gen)))
> > (gen-cat (gen/elements [[:and]]) (gen/tuple
> inner-gen) (gen/not-empty (gen/list inner-gen)))])))
> > (def gen-predicate (gen/recursive-gen compound gen-atom))
> >
> > ([:or [:and [:or "t_a3" "f_a5"] [:and "t_a5" "t_a6"]] [:or [:not "t_a5"]
> [:not "t_a1"]]] [:and [:and [:and "f_a4" "f_a4" "f_a9"] [:or "f_a2"
> "t_a5"]] [:and [:not "f_a3"] [:not "f_a1"]]] [:or "t_a5" "f_a6" "t_a7"
> "t_a3"] [:not [:and [:and [:not [:not "t_a5"]] [:and [:or "t_a4" "f_a7"]
> [:not "t_a2"] [:not "f_a6"] [:and "t_a5" "t_a4"] [:or "t_a8" "f_a0"]] [:not
> [:or "f_a8" "f_a2"]]] [:or [:or [:not "f_a0"] [:or "t_a9" "t_a7"]] [:not
> [:or "t_a5" "f_a6" "f_a1"]]] [:not [:and [:and "t_a0" "t_a3"] [:or "f_a2"
> "t_a5"] [:or [:not [:and [:or [:not "f_a1"] [:and "f_a0" "t_a8"]] [:not
> [:not "t_a7"]] [:or [:or "f_a1" "f_a8" "f_a7"] [:and "f_a9" "t_a2"
> [:not [:or [:or [:not "t_a7"] [:not "t_a8"]] [:or [:and "t_a3" "t_a0"]
> [:not "t_a6" [:not [:and [:and [:and "f_a9" "t_a7"] [:and "f_a6"
> "f_a9"] [:or "f_a9" "t_a0" "t_a8"]] [:and [:not "f_a4"] [:or "t_a3" "f_a4"]
> [:or "t_a3" "f_a3"])
> >
> > On Tue, May 31, 2016 at 3:14 AM, Gary Fredericks <
> fredericksg...@gmail.com> wrote:
> > At a glance, this is probably the normal increasing-size behavior of
> test.check, and the bias should only be present for the first few samples.
> E.g., if you do a (take 1000 (gen/sample ...)), it should be more uniform.
> >
> > Whether it's a real problem depends on how you're running you

Re: clojure.spec generation question

[Jeroen van Dijk]

Hi Gary,

Thanks for the feedback. I've tried it with test.check itself and I get
better results (see below). So I'm guessing clojure.spec needs different
input or it works differently underneath.

Thanks,
Jeroen

(require '[clojure.test.check :as tc])
(require '[clojure.test.check.generators :as gen])
(require '[clojure.test.check.properties :as prop])

(def gen-atom (gen/elements (mapcat (juxt (partial str "f_a")
  (partial str "t_a")) (range 10

(def gen-atom (gen/elements (mapcat (juxt (partial str "f_a")
  (partial str "t_a")) (range 10

(defn gen-cat
  "Returns a generator of a sequence catenated from results of
gens, each of which should generate something sequential."
  [& gens]
  (gen/fmap #(vec (apply concat %))
(apply gen/tuple gens)))

(def compound (fn [inner-gen]
(gen/one-of [(gen-cat (gen/elements [[:not]]) (gen/tuple
inner-gen))
 (gen-cat (gen/elements [[:or]])  (gen/tuple
inner-gen)  (gen/not-empty (gen/list inner-gen)))
 (gen-cat (gen/elements [[:and]]) (gen/tuple
inner-gen) (gen/not-empty (gen/list inner-gen)))])))
(def gen-predicate (gen/recursive-gen compound gen-atom))

([:or [:and [:or "t_a3" "f_a5"] [:and "t_a5" "t_a6"]] [:or [:not "t_a5"]
[:not "t_a1"]]] [:and [:and [:and "f_a4" "f_a4" "f_a9"] [:or "f_a2"
"t_a5"]] [:and [:not "f_a3"] [:not "f_a1"]]] [:or "t_a5" "f_a6" "t_a7"
"t_a3"] [:not [:and [:and [:not [:not "t_a5"]] [:and [:or "t_a4" "f_a7"]
[:not "t_a2"] [:not "f_a6"] [:and "t_a5" "t_a4"] [:or "t_a8" "f_a0"]] [:not
[:or "f_a8" "f_a2"]]] [:or [:or [:not "f_a0"] [:or "t_a9" "t_a7"]] [:not
[:or "t_a5" "f_a6" "f_a1"]]] [:not [:and [:and "t_a0" "t_a3"] [:or "f_a2"
"t_a5"] [:or [:not [:and [:or [:not "f_a1"] [:and "f_a0" "t_a8"]] [:not
[:not "t_a7"]] [:or [:or "f_a1" "f_a8" "f_a7"] [:and "f_a9" "t_a2"
[:not [:or [:or [:not "t_a7"] [:not "t_a8"]] [:or [:and "t_a3" "t_a0"]
[:not "t_a6" [:not [:and [:and [:and "f_a9" "t_a7"] [:and "f_a6"
"f_a9"] [:or "f_a9" "t_a0" "t_a8"]] [:and [:not "f_a4"] [:or "t_a3" "f_a4"]
[:or "t_a3" "f_a3"])

On Tue, May 31, 2016 at 3:14 AM, Gary Fredericks <fredericksg...@gmail.com>
wrote:

> At a glance, this is probably the normal increasing-size behavior of
> test.check, and the bias should only be present for the first few samples.
> E.g., if you do a (take 1000 (gen/sample ...)), it should be more uniform.
>
> Whether it's a real problem depends on how you're running your tests. I
> haven't yet looked into whether clojure.spec provides some default way of
> running test.check properties, so I'm not sure about that. But as long as
> you're running "enough" tests, e.g. >100, it should be fine.
>
>
> On Monday, May 30, 2016 at 4:05:52 PM UTC-5, Jeroen van Dijk wrote:
>>
>> I'm trying to generate logical predicates in order to test a function
>> that should return the predicate in DNF. The generation seems to be biased
>> towards one of the predicates. What am I doing wrong?
>>
>> (require '[clojure.spec :as s])
>> (require '[clojure.spec.gen :as gen])
>>
>> (s/def ::atom string?)
>>
>> (s/def ::predicate (s/or
>> ::not-predicate
>> ::and-predicate
>> ::or-predicate
>> ::atom))
>>
>> (s/def ::and-predicate (s/cat :pred #{:and} :args (s/+ ::predicate)))
>> (s/def ::or-predicate  (s/cat :pred #{:or} :args (s/+ ::predicate)))
>> (s/def ::not-predicate (s/tuple :pred #{:not} ::predicate))
>>
>> (prn (take 5 (gen/sample (s/gen ::predicate
>> ;;=>
>> ((:and (:and "")) "" "X" "G" (:and "yd" (:and "c" "" (:and "F" (:and ""
>> "8" "Hb" "U0d")) "C") (:and (:and "1" "e" (:and "ME01" "w" "Y4" "" "P4")
>> "J4m4" "8") "Q7c" "") (:and (:and (:and "" "dG"))) "

clojure.spec generation question

[Jeroen van Dijk]

I'm trying to generate logical predicates in order to test a function that
should return the predicate in DNF. The generation seems to be biased
towards one of the predicates. What am I doing wrong?

(require '[clojure.spec :as s])
(require '[clojure.spec.gen :as gen])

(s/def ::atom string?)

(s/def ::predicate (s/or
::not-predicate
::and-predicate
::or-predicate
::atom))

(s/def ::and-predicate (s/cat :pred #{:and} :args (s/+ ::predicate)))
(s/def ::or-predicate  (s/cat :pred #{:or} :args (s/+ ::predicate)))
(s/def ::not-predicate (s/tuple :pred #{:not} ::predicate))

(prn (take 5 (gen/sample (s/gen ::predicate
;;=>
((:and (:and "")) "" "X" "G" (:and "yd" (:and "c" "" (:and "F" (:and "" "8"
"Hb" "U0d")) "C") (:and (:and "1" "e" (:and "ME01" "w" "Y4" "" "P4") "J4m4"
"8") "Q7c" "") (:and (:and (:and "" "dG"))) "gw5"))


No :or's or :not's here. If I change the order of s/or above the bias
changes. What's a better approach?

Thanks,
Jeroen

-- 
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] components.md

[Jeroen van Dijk]

Hi Brian,

When looking at the Readme of Mount (I think) I already see global state
backed in.

(defstate ^{:on-reload :noop}
  mem-db :start (connect config)
 :stop (disconnect mem-db))


Do I misunderstand this or do we just disagree on what global state is?
What if I want to have several (different) `mem-db` instances, how would
that work?



On Fri, Apr 8, 2016 at 4:25 PM, Brian Platz  wrote:

>
> >> This is also something that wouldn't be possible with Mount as this
> library seems to promote global state.
>
> As a recent switcher from Component to Mount, and without trying to change
> the thread's topic into a this vs. that -- I'll simply say that I don't
> believe any of these tools promote global state, it is people who code
> global state, and that can be with any of these tools... or likewise
> avoided with any of these tools.
>
> Some tools (i.e. Component) probably make it more difficult to have global
> state, but I think it is heavy handed. For projects with a lot of
> components, I would spend a lot of time backtracking components all feeding
> into each other to figure out where some var was when working in REPL. I'd
> also repeatedly deal with errors when adding new components as I didn't set
> up the dependencies correctly at first... just several interlocking pieces
> that all need to be coordinated, and I sometimes forget one (or two).
>
> Mount probably makes it a little easier to have global state, but that is
> up to the developer - I have no more global state than I had before the
> switch. I find it easier to work in REPL and get access to a var, or conn,
> etc. when I need to eval something, and I think all these components are
> primarily there to make the REPL workflow better. Also, I'm out of the
> business of managing my dependencies, which my challenges might just root
> from an absent-mindedness that I possess. Once it is in production, the
> component stuff matters very little anyhow.
>
> All to say that these tools, assuming they provide the feature needs that
> have been outlined well in this thread, should not make anything 'not
> possible' and can have as much or as little global state as the developer
> chooses to code in. I cringe a bit when I repeatedly see that Mount
> promotes global state, I think that is a falsehood.
>
> -Brian
>
> --
> 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.
>

-- 
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] components.md

[Jeroen van Dijk]

>
>
>> > The thing that this doc also advocates (and I am against) is manual
>> dependency management, your app start function must call start on its
>> dependencies. This not only hardcodes the dependency, but also requires the
>> user to think about the startup order of components on every usage.
>>
>> This “every usage” is roughly every time a new component is added (in my
>> experience). Of the total number of components, around 80% is added at the
>> very beginning and a few more during the lifetime of the app. Last time I
>> had the ordering problem with one component I fixed it in the app start
>> function and never touched it again. So I’m not sure if the user is
>> required any special effort after the very first setup.
>>
>>
At my company we *do* have complicated dependency trees that you really
don't want to manage manually or even think about. We've build a layer on
top of Component actually. We use edn config files to declare what
components should be in the system. The dependencies are calculated
accordingly (I hope we can open source it some time)



> > In addition this approach doesn't support substituting alternate
>> implementations. During testing I often want to use a in-memory queue vs
>> RabbitMQ. Or perhaps I want to wire an entire system up with in-memory
>> queues to perform limited integration testing. Hardcoding dependencies
>> limits the flexibility of the app.
>>
>> Good point about stubbing out sometimes. But shouldn’t something like
>> (with-redefs [bootstrap/system {:rabbit “my stub”}] ) solve the
>> problem easily? As of running the app with a different configuration, you
>> could get away by “TESTING=true java -jar target/uberapp.jar” and put a
>> conditional in system.clj to wire-up the app with in-memory queues.
>>
>>
With the configuration files for instance, we substitute a Kafka component
with an in-memory logger component during testing and a file-based logger
in development. I have also been able to generate a full cluster of 10
nodes of the same server component in the same JVM running on 10 different
ports. This was possible because the configuration is just edn data and we
don't have any global state in our components [1]. This is also something
that wouldn't be possible with Mount as this library seems to promote
global state.

[1] except for the system var of course

-- 
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: component: dynamic configuration

[Jeroen van Dijk]

This could be a nice example of how to use component in practise:
https://github.com/bevuta/pepa

Internally we configure the system map differently. This is based on yet
another library https://github.com/RedBrainLabs/system-graph We have
extended the idea of this library and we now have a file based system
configuration where subsystems (graphs/maps) can be merged.

HTH

On Tue, Jul 7, 2015 at 7:07 PM, Stuart Sierra the.stuart.sie...@gmail.com
wrote:

 Not sure if this helps, but remember that components and systems are just
 records, and records behave like maps. You can construct an empty
 `system-map` and then `assoc` components or even `merge` other maps into it.

 –S



 On Tuesday, July 7, 2015 at 1:00:51 PM UTC-4, Pierre-Yves Ritschard wrote:

 Hi,

 I've been using an approximation of what component provides in my
 applications for quite a while, and I'm trying to see if it's feasible
 to move to component, in the sake of homogeneity with the rest of the
 clojure world and to see if there are things that make my life easier.

 I have a couple of apps which expose a somewhat generic way of
 manipulating data in a certain way. Most follow the pattern of having
 several possible inputs (which must all adhere to a protocol), an engine
 that does its work and several possible outputs (again, adhering to a
 protocol).

 While configuring each of these inputs or outputs as components is
 straightforward, I failed to find a good strategy for storing them and
 constructing the system-map correctly.

 Did anyone tackle this yet and if so are they willing to share their
 approach ?

 Cheers,
   - pyr

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


-- 
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: Weird behaviour in re-matches ?

[Jeroen van Dijk]

 Looks like something in re-matches is printing the second argument, but
 without a terminating newline. A subsequent print, such as of nil\n or
 (1 2)\n, by the REPL evaluator, with a newline, then completes the line
 and flushes the output buffer.

 There seem to be three separate errors here, two of them in re-matches:
 1. The one case where you slipped in an extra close parenthesis, which is
 what caused the exceptions.


Yeah I was quickly aware of this one


 2. The peculiar printing (without flushing) of the second argument by
 re-matches. (I don't know where it's going with some of the different REPLs
 but perhaps those ones maintain a different output stream for *out* and for
 REPL evaluation result printing.)


This caused all my confusion about the result. Not sure at what level this
happens.


 3. The regexp *should* match foo.gif\n from the looks of it, but seems
 not to be doing so.


Can be solved by using a multiline flag (?is) [1]:

user= (re-matches #(?is).*(foo\.gif).* foo.gif\n)
[foo.gif\n foo.gif]

[1] Found this here
http://stackoverflow.com/questions/15020669/clojure-multiline-regular-expression


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


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

Weird behaviour in re-matches ?

[Jeroen van Dijk]

I came accross this weird case below with re-matches (in clojure 1.6). For
some reason the pattern matches, once just once, only after a parse
exception. This pattern repeats with every follow up parse exception. Is
this a known bug? It seems to be related with the pending newline too.

user= (re-matches #.*(foo\.gif).* foo.gif\n)
nil
user= (re-matches #.*(foo\.gif).*) foo.gif\n)

PatternSyntaxException Unmatched closing ')' near index 13
.*(foo\.gif).*)
 ^  java.util.regex.Pattern.error (Pattern.java:1924)
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException
(Util.java:221)
user= (re-matches #.*(foo\.gif).* foo.gif\n)
foo.gif\nnil
user= (re-matches #.*(foo\.gif).* foo.gif\n)
nil
user=

-- 
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: Weird behaviour in re-matches ?

[Jeroen van Dijk]

Ah thanks James, I missed the pending nil. The actual value is still nil
indeed:

user= (def m (re-matches #.*(foo\.gif).* foo.gif\n))
foo.gif\n#'user/m
user= m
nil

Not sure what would be the cause here then, but the random printing of the
second argument of re-matches also happens when I evaluate an arbitrary
function after the exception

PatternSyntaxException Unmatched closing ')' near index 13
.*(foo\.gif).*)
 ^  java.util.regex.Pattern.error (Pattern.java:1924)
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException
(Util.java:221)
user= (list 1 2)
foo.gif\n(1 2)

cider doesn't have this problem either it seems



On Tue, Jun 16, 2015 at 12:56 PM, James Reeves ja...@booleanknot.com
wrote:

 On 16 June 2015 at 10:19, Jeroen van Dijk jeroentjevand...@gmail.com
 wrote:

 I came accross this weird case below with re-matches (in clojure 1.6).
 For some reason the pattern matches, once just once, only after a parse
 exception. This pattern repeats with every follow up parse exception. Is
 this a known bug? It seems to be related with the pending newline too.

 user= (re-matches #.*(foo\.gif).* foo.gif\n)
 nil
 user= (re-matches #.*(foo\.gif).*) foo.gif\n)

 PatternSyntaxException Unmatched closing ')' near index 13
 .*(foo\.gif).*)
  ^  java.util.regex.Pattern.error (Pattern.java:1924)
 RuntimeException Unmatched delimiter: )
  clojure.lang.Util.runtimeException (Util.java:221)
 user= (re-matches #.*(foo\.gif).* foo.gif\n)
 foo.gif\nnil


 This doesn't indicate a matching pattern. It still returns nil, but it
 also prints foo.gif\n. If you hit return instead of running the same
 command again, you'll see the same text printed.

 My guess is that this is an nrepl issue, as this problem doesn't occur
 when running the Clojure REPL directly from the Clojure jar.

 - James

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


-- 
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: Actually using component.

[Jeroen van Dijk]

I think the most important rule when using component is to only use local
state like Timothy stated, i.e. nothings gets def-ed. You could write an
application that a -main function that starts the system and you would
never need a global reference to the system.

In practise however, you do make references to the current system to
support working in the REPL (see README here
https://github.com/stuartsierra/component/#reloading) and I also use
references to the system to inspect db state etc in tests, but for that
`let` blocks also work well.

I would recommend to continue playing with the bare metal component for a
while to get an understanding of the concept, after a while I think you
will want something smarter. We're using system-graph
https://github.com/RedBrainLabs/system-graph that helps to stop thinking
and managing dependencies and recently we have a built a small layer on top
of that so we even have flexible graphs in a convenient way.

On Tue, Jun 9, 2015 at 8:33 AM, Atamert Ölçgen mu...@muhuk.com wrote:



 On Tue, Jun 9, 2015 at 6:12 AM, Timothy Baldridge tbaldri...@gmail.com
 wrote:

 Stuart addresses two anti-patterns in your PRs. Perhaps I can help
 explain them.

 Let's say we have a system that looks like this:

 (defrecord DBConnection [])

 (defrecord DBLayer [db-connection])

 (defrecord AppLayer [db-layer])

 We can construct a system thusly:

 {:db-connection (-DBConnection ...)
  :db-layer (-DBLayer ...)
  :app-layer (-AppLayer ...)}

 And start it up:

 (def my-system (start-system system-map))


 First of all, what you need to recognize is that every component now has
 it's dependencies assoc'ed into the component. So each component should
 only deal with it's local view of the system:

 (defrecord AppLayer [db-layer]
   IDoStuff
   (do-stuff [this]
 (print-data (get-data db-layer)
  (get-data2 (:db-layer this)))

 What should not happen is that the AppLayer should do this:

 (print-data (:db-layer my-system))

 If a component does this it now has access to the entire system, and that
 circumvents one of the reasons component was created, to help improve
 separation of concerns.

 In your other example you're doing something like this:

 (defrecord AppLayer [db-layer]
   IDoStuff
   (do-stuff [this]
  (run-query (:db-conn db-layer) select foo from bar)))

 The problem with this is that AppLayer is assuming that the db-layer has
 a connection to the db. This also violates the separation of concerns.
 Instead AppLayer should include a db-connection as a dependency if it is
 needed by the app layer code.


 This is also known as The Law of Demeter. (
 http://en.wikipedia.org/wiki/Law_of_Demeter)

 - Each unit should have only limited knowledge about other units: only
 units closely related to the current unit.
 - Each unit should only talk to its friends; don't talk to strangers.
 - Only talk to your immediate friends.



 So that sums up Stuart's two replies. a) don't touch the system from
 inside a component, the system map is only for starting and stopping the
 system, and to provide an entry point. b) don't reach into other components
 from a component


 Timothy

 On Mon, Jun 8, 2015 at 9:35 PM, James Reeves ja...@booleanknot.com
 wrote:

 My recommendation is to use a closure. So I'd write your example as:

 (defn username-endpoint [{:keys [db]}]
   (routes
(GET /:username [username]
  (let [user (users/get-user db username)]
(str h1Hello  (:name user) /h1)

 So you pass your configuration map into the endpoint function, which
 returns a handler.

 You can then wrap this in a component:

 (defrecord EndpointComponent [build-routes]
   component/Lifecycle
   (start [component]
 (if (:routes component)
   component
   (assoc component :routes (build-routes component
   (stop [component]
 (dissoc component :routes)))

 Incidentally, the above code is taken directly from Duct
 https://github.com/weavejester/duct, a template and small supporting
 library I've written for building component-based web apps.

 I've also written a blog article
 https://www.booleanknot.com/blog/2015/05/22/structuring-clojure-web-apps.html
  around
 general best practice for this type of style.

 - James


 On 8 June 2015 at 22:51, Dru Sellers d...@drusellers.com wrote:

 So, I guess I am a bit lost, how does someone actually use component? I
 have an application all set up with it and it seems to be working as I
 would expect but Stuart seems to be steering me in a different direction.

 https://github.com/stuartsierra/component/pull/35

 https://github.com/stuartsierra/component/issues/34

 So I'll try and paint a full picture.
 https://gist.github.com/drusellers/8109dce4b9fb19c14ebb

 I know compojure and component / reloaded may not play well, but I'm
 trying to figure out how to best use the system var. Am I close, I'd love
 to give back a decent PR to the README.md of the component repo to help
 others as they come along.

 -d

 --
 

Re: One more argument for cyclic dependencies

[Jeroen van Dijk]

Maybe I misunderstand the problem, but can't you have the Agents implement
protocols (in a different namespace) and refer to that?

On Tue, May 19, 2015 at 5:19 AM, Mars0i marsh...@logical.net wrote:

 Sorry, the reference to an 85X speed difference was a typo.  Should be 70X.

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


-- 
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: Minimum Viable Database Component

[Jeroen van Dijk]

Hi Andy,

I'm not aware of such a project, but I can confirm that it is an approach
that we apply internally at AdGoji and has been working well for us.  For
instance, we have (simple) components that mock Kafka and Redis in a way
that make them feature compatible to these services in the context of our
platform. For Kafka we have one mock component for testing (so you can can
test what has been pushed to Kafka) and we have one for development that
just logs to the file system (in a human-readable) form.

Although it doesn't replace real testing with these external services, it
does make the development flow a lot faster as boot-time is quicker, easier
cleanup etc.

Cheers,
Jeroen

On Thu, Apr 30, 2015 at 5:54 AM, Andy Chambers achambers.h...@gmail.com
wrote:

 Hi All,

 I'm trying to follow the component architecture for an app I'm working
 on and wondered if I was missing something. In the Just enough structure
 talk, one of the examples Stuart presents is a DB component that contains
 just a small selection of DB related functions (i.e. insert, and query
 IIRC) so that when you need to mock it out for your tests, you don't have
 to implement the entire JDBC interface.

 This makes sense but I'm wondering if anyone has released such a subset
 (possibly expanded to include things like transactions, and maybe a few
 utility query builders) as open source ideally with a corresponding mock
 implementation. With the popularity of the component library, I'm surprised
 not to find ready made components I can just plug into my app.

 If there's nothing like this already, then I guess I have an idea for a
 new project. Anyone think this is a good idea or would everyone's ideal DB
 component look a little different? Look forward to hearing your thoughts.

 Cheers,
 Andy

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


-- 
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] Phoenix 0.1.0 - help with structuring configuring Component-based systems

[Jeroen van Dijk]

Thanks for sharing James! I'll have a look.

As a side note, I see in the example code that you are dissoc-ing on the
component. This can lead to unexpected behaviour as I have
experienced (mostly in repl cases), as this will return a map instead of a
record when the field is not part of the record. This is also mentioned in
the readme of https://github.com/stuartsierra/component where `(assoc
component ::field nil)` is recommended

Jeroen

On Sun, Mar 29, 2015 at 9:44 PM, James Henderson ja...@jarohen.me.uk
wrote:

 A link would have been really helpful, I'm guessing! Here it is:

 https://github.com/james-henderson/phoenix

 James


 On Sunday, 29 March 2015 20:42:06 UTC+1, James Henderson wrote:

 Hi all,

 I've just released v0.1.0 of Phoenix - a 'batteries included, but
 removable' library to wire up and configure Component-based systems. If
 you've ever wondered whether you really have to copy and paste
 'system.clj', 'dev.clj' and 'user.clj' from one Component project to the
 next, it's well worth having a look at!

 Having used Phoenix in anger on a few projects for a couple of weeks,
 it's now had a fair bit of battle-testing, kinks ironed, and the like - so
 thought I'd make another post to the list :)

 Features added since I last posted:

- Many re-usable Components - CLJS compiler, Aleph, http-kit, JDBC
pool, CSS compiler (using Garden) - see https://github.com/james-
henderson/phoenix/tree/master/modules/
https://github.com/james-henderson/phoenix/tree/master/modules/ for
more details. These components can be used whether or not you choose to 
 use
Phoenix, and, likewise, non-Phoenix components can be used in
Phoenix-configured systems - hooray for composability :)
- Support for managing passwords/credentials - you can store these,
encrypted, in your configuration, and Phoenix will decrypt them for you.
- Pulling configuration variables from environment variables and JVM
properties, in addition to the Phoenix config files
- 'Batteries removable' API - if you need a little more flexibility,
or want to compose Phoenix with something else.
- A fair few bugfixes/API changes through usage

 There's also a couple of Lein templates to get up and running quickly:

-  `lein new phoenix-webapp my-project -- :reagent` will get you a
working webapp (other options are `:om`, `:om-sablono` or `:flow`).
- If you don't want the CLJS side, `lein new phoenix-api my-project`
just has an example server-side API.

 Would be great to get your thoughts and feedback on this - is this a good
 way to wire up such systems?

 Cheers,

 James

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


-- 
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: defmethod inside of a (stuart sierra) component?

[Jeroen van Dijk]

I would try to stay away from any nested def's in components (but also in
other functions). I'm using component a lot and I never had the need for
this.

Maybe you can elaborate on why you think you need a multimethod inside the
component? Maybe a full example?

Cheers,
Jeroen



On Wed, Feb 25, 2015 at 12:08 PM, Colin Yates colin.ya...@gmail.com wrote:

 Hi,

 I have a number of commands flying around which need to be handled.
 defmulti/defmethod seem a nice answer. The problem is that each command
 handler will need different collaborators (those with long memories will
 realise this isn't new ground here ;)).

 I want to do something like:

 (ns one)
 (defmulti handle first)

 (ns two)
 (defrecord CommandAHandler [collab-1 collab-2]
   component/Lifecycle
   (start [this]
 (defmethod handle :command-a 
   (collab-1 ...)))

 I realise that the lifecycle of defmethod doesn't match the component
 (i.e. stopping can't unregister the defmethod), but my main reservation is
 that a nested defmethod feels a bit weird. Has anyone done anything like
 this before?

 Thanks!

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


-- 
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: defmethod inside of a (stuart sierra) component?

[Jeroen van Dijk]

Sounds reasonable. Though destructuring a component (I was guessing db
etc were fields of this particular component) isn't the same as passing the
whole system. I'm guessing that you have a lot bigger system in mind than
these few commands. I don't have experience with that approach. I'm curious
to see what you'll end up with.

Cheers,
Jeroen

On Wed, Feb 25, 2015 at 2:01 PM, Colin Yates colin.ya...@gmail.com wrote:

 Yes, I did consider that but didn't like the idea of passing the
 system around. Also handle-command would need access to the system as
 well.

 I am wondering whether simply having a 'registry' component which
 handlers register themselves with (e.g. a map of {predicate handler})
 isn't a way forward and not using defmulti...

 On 25 February 2015 at 12:51, Jeroen van Dijk
 jeroentjevand...@gmail.com wrote:
  So I guess another question is where handle-command is being called.
 What
  about providing the component as argument to the multimethod (there are
  other approaches too depending on your need). So:
 
  (defmulti handle-command(fn [component command] (first command)))
 
  (defmethod handle-command :add-customer  [{:keys [db eventstore} [[_
  customer]]]
... )
 
  Isn't something like this enough?
 
  Jeroen
 
  On Wed, Feb 25, 2015 at 1:34 PM, Colin Yates colin.ya...@gmail.com
 wrote:
 
  Hi Jeroen - sure.
 
  I have a gateway which can handle a number of 'commands', let's say:
 
  AddCustomerCommand
  ExportQueryCommand
 
  to handle the AddCustomerCommand I need access to a database and an
  eventstore. To handle ExportQueryCommand I need access to the
  database, a PDF service and so on.
 
  One way of achieving this is (assuming commands are of the form
  [:command-discriminator payload]:
 
  (defmulti handle-command first)
 
  (defn add-customer [db eventstore customer]
   ...)
 
  (defrecord AddCustomerComponent [db eventstore]
...
(start [this] (defmethod handle-command :add-customer [[_ customer]]
  (add-customer db eventstore customer))..)
 
  (defn export-reports [db pdf-generator]
   ...)
 
  (defrecord ExportQueryCommand [db pdf-generator]
...
(start [this] (defmethod handle-command :export-query [[_]]
  (export-query db pdf-generator))..)
 
  and so on.
 
  Fundamentally my question is one of dispatching where the target of
  the dispatch requires collaborators that aren't part of the dispatch
  payload.
 
  Does that clarify?
 
  On 25 February 2015 at 12:11, Jeroen van Dijk
  jeroentjevand...@gmail.com wrote:
   I would try to stay away from any nested def's in components (but also
   in
   other functions). I'm using component a lot and I never had the need
 for
   this.
  
   Maybe you can elaborate on why you think you need a multimethod inside
   the
   component? Maybe a full example?
  
   Cheers,
   Jeroen
  
  
  
   On Wed, Feb 25, 2015 at 12:08 PM, Colin Yates colin.ya...@gmail.com
   wrote:
  
   Hi,
  
   I have a number of commands flying around which need to be handled.
   defmulti/defmethod seem a nice answer. The problem is that each
 command
   handler will need different collaborators (those with long memories
   will
   realise this isn't new ground here ;)).
  
   I want to do something like:
  
   (ns one)
   (defmulti handle first)
  
   (ns two)
   (defrecord CommandAHandler [collab-1 collab-2]
 component/Lifecycle
 (start [this]
   (defmethod handle :command-a 
 (collab-1 ...)))
  
   I realise that the lifecycle of defmethod doesn't match the component
   (i.e. stopping can't unregister the defmethod), but my main
 reservation
   is
   that a nested defmethod feels a bit weird. Has anyone done anything
   like
   this before?
  
   Thanks!
  
   --
   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.
  
  
   --
   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

Re: defmethod inside of a (stuart sierra) component?

[Jeroen van Dijk]

So I guess another question is where handle-command is being called. What
about providing the component as argument to the multimethod (there are
other approaches too depending on your need). So:

(defmulti handle-command(fn [component command] (first command)))

(defmethod handle-command :add-customer  [{:keys [db eventstore} [[_
customer]]]
  ... )

Isn't something like this enough?

Jeroen

On Wed, Feb 25, 2015 at 1:34 PM, Colin Yates colin.ya...@gmail.com wrote:

 Hi Jeroen - sure.

 I have a gateway which can handle a number of 'commands', let's say:

 AddCustomerCommand
 ExportQueryCommand

 to handle the AddCustomerCommand I need access to a database and an
 eventstore. To handle ExportQueryCommand I need access to the
 database, a PDF service and so on.

 One way of achieving this is (assuming commands are of the form
 [:command-discriminator payload]:

 (defmulti handle-command first)

 (defn add-customer [db eventstore customer]
  ...)

 (defrecord AddCustomerComponent [db eventstore]
   ...
   (start [this] (defmethod handle-command :add-customer [[_ customer]]
 (add-customer db eventstore customer))..)

 (defn export-reports [db pdf-generator]
  ...)

 (defrecord ExportQueryCommand [db pdf-generator]
   ...
   (start [this] (defmethod handle-command :export-query [[_]]
 (export-query db pdf-generator))..)

 and so on.

 Fundamentally my question is one of dispatching where the target of
 the dispatch requires collaborators that aren't part of the dispatch
 payload.

 Does that clarify?

 On 25 February 2015 at 12:11, Jeroen van Dijk
 jeroentjevand...@gmail.com wrote:
  I would try to stay away from any nested def's in components (but also in
  other functions). I'm using component a lot and I never had the need for
  this.
 
  Maybe you can elaborate on why you think you need a multimethod inside
 the
  component? Maybe a full example?
 
  Cheers,
  Jeroen
 
 
 
  On Wed, Feb 25, 2015 at 12:08 PM, Colin Yates colin.ya...@gmail.com
 wrote:
 
  Hi,
 
  I have a number of commands flying around which need to be handled.
  defmulti/defmethod seem a nice answer. The problem is that each command
  handler will need different collaborators (those with long memories will
  realise this isn't new ground here ;)).
 
  I want to do something like:
 
  (ns one)
  (defmulti handle first)
 
  (ns two)
  (defrecord CommandAHandler [collab-1 collab-2]
component/Lifecycle
(start [this]
  (defmethod handle :command-a 
(collab-1 ...)))
 
  I realise that the lifecycle of defmethod doesn't match the component
  (i.e. stopping can't unregister the defmethod), but my main reservation
 is
  that a nested defmethod feels a bit weird. Has anyone done anything like
  this before?
 
  Thanks!
 
  --
  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.
 
 
  --
  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.

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


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post

Re: Resources don't work in uberjar

[Jeroen van Dijk]

I'm not sure anymore what your goal is exactly, but here is what I meant to
be complete:

(defn -main I don't do a whole lot ... yet. [ args] (- hi.txt
io/resource slurp (spit out.txt)))

On Wed, Jan 28, 2015 at 4:57 PM, Dan Harbin dan.har...@gmail.com wrote:

 Marshall,

 If I remove io/file, I get:

 Exception in thread main java.lang.IllegalArgumentException: No method
 in multimethod 'do-copy' for dispatch value: [java.net.URL
 java.io.OutputStreamWriter]
 at clojure.lang.MultiFn.getFn(MultiFn.java:160)
 at clojure.lang.MultiFn.invoke(MultiFn.java:236)
 at clojure.java.io$copy.doInvoke(io.clj:396)
 at clojure.lang.RestFn.invoke(RestFn.java:425)
 at halp.core$_main.doInvoke(core.clj:10)
 at clojure.lang.RestFn.invoke(RestFn.java:397)
 at clojure.lang.AFn.applyToHelper(AFn.java:152)
 at clojure.lang.RestFn.applyTo(RestFn.java:132)
 at halp.core.main(Unknown Source)


 It doesn't look like io/copy works with a URL.

 On Tuesday, January 27, 2015 at 2:52:00 PM UTC-6, Marshall
 Bockrath-Vandegrift wrote:

 On Monday, January 26, 2015 at 9:24:28 PM UTC-5, Dan Harbin wrote:


   io/file


 Just delete that line.  The `io/resource` function returns a URL which
 all the Clojure IO functions can handle just fine-as is.  When running in
 development the URL happens to be a `file://` URL, and thus something
 `io/file` can handle.  Once the resource is in a JAR that is no longer the
 case, and hence exceptions.  Just don't require a file when any URL will do
 and you'll be fine.

 -Marshall

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


-- 
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: Resources don't work in uberjar

[Jeroen van Dijk]

Hi Dan,

Not sure if there are better options, but I know `slurp` does work on
resources in jars. You could (ab)use `spit` to do the copying.

HTH,
Jeroen

On Tue, Jan 27, 2015 at 3:24 AM, Dan Harbin dan.har...@gmail.com wrote:

 I've created a sample project at Github[1] to demonstrate the problem I'm 
 facing with accessing a resource file when using an uberjar.  Could someone 
 point out what I'm doing wrong here?  Thanks!


 [1]: https://github.com/RasterBurn/halp


 ### Given this code: ###

 ```clojure
 (ns halp.core
   (:require [clojure.java.io :as io])
   (:gen-class))

 (defn -main
   I don't do a whole lot ... yet.
   [ args]
   (- hi.txt
   io/resource
   io/file
   (io/copy *out*)))
 ```

 ### It runs well under leiningen ###

 ```
 ➜  halp  lein run
 .
 ─▄──▄
 ▌▒█───▄▀▒▌
 ▌▒▒▀▄───▄▀▒▒▒▐
 ───▐▄▀▒▒▄▄▄▀▒▐
 ─▄▄▀▒▒▒█▒▒▄█▒▐
 ───▄▀▒▒▒▀██▀▒▌
 ──▐▒▒▒▄▄▄▒▀▄▒▒▌
 ──▌▒▒▐▄█▀▄▀█▄▒▒▒█▒▐
 ─▐▒▒▒▌██▀▀▄▌
 ─▌▒▀▄██▄▒▒▒▌
 ─▌▀▐▄█▄█▌▄▒▀▒▒░░▒▒▒▐
 ▐▒▀▐▀▐▀▒▒▄▄▒▄▒░░▌
 ▐▒▒▒▀▀▄▄▒▒▒▄▒▒░░▒▒▒▐
 ─▌▒▒▀▀▀▌
 ─▐▐
 ──▀▄▒▄▌
 ▀▄▒▒▄▄▄▀▄▀
 ───▐▀▒▀▄▄▀▀▀▒▄▄▀
 ──▐▀▀
 ```

 ### But not so much as an uberjar #

 ```
 ➜  halp  java -jar target/uberjar/halp-0.1.0-SNAPSHOT-standalone.jar
 Exception in thread main java.lang.IllegalArgumentException: Not a file: 
 jar:file:/home/vagrant/code/halp/target/uberjar/halp-0.1.0-SNAPSHOT-standalone.jar!/hi.txt
 at clojure.java.io$fn__8588.invoke(io.clj:63)
 at clojure.java.io$fn__8572$G__8556__8577.invoke(io.clj:35)
 at clojure.java.io$file.invoke(io.clj:414)
 at halp.core$_main.doInvoke(core.clj:11)
 at clojure.lang.RestFn.invoke(RestFn.java:397)
 at clojure.lang.AFn.applyToHelper(AFn.java:152)
 at clojure.lang.RestFn.applyTo(RestFn.java:132)
 at halp.core.main(Unknown Source)
 ```

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


-- 
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: Datomic Pro Starter: limit per user or per app?

[Jeroen van Dijk]

Coincidentally,  I was wondering the same today and I asked the same
question in different wording on the Datomic mailinglist
https://groups.google.com/forum/#!topic/datomic/gvP0ecJghd8




On Thu, Apr 24, 2014 at 1:42 PM, Robin Heggelund Hansen 
skinney...@gmail.com wrote:

 Simple question, sorry if this is jotted down somewhere and I didn't read
 it :/

 Regarding Datomic Pro Starter, is the limitation of 1 transactor+two peers
 per registered user, or per app? I would love to use datomic in my
 projects, but when free is recommended for dev and not prod, and I can only
 use datomic pro starter for one project, it kinda looses it's appeal :(

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


-- 
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: Best way to loop a map of maps

[Jeroen van Dijk]

Don't forget about the option of walking over a map by using
clojure.walk/postwalk or clojure.walk/prewalk

I use these functions often lately. Especially useful if you have to update
values in your map and they could occur anywhere. It is a bit tricky to get
working at first, because the return value of each step needs to match the
structure that is currently walked. For that reason you sometimes need to
switch between a postwalk instead of a prewalk etc.

Try this for a demo

(def m
  {outerKeyA {:innerKeyA {string id {:foo 1 :bar 2}}}
   outerKeyB {:innerKeyB {string id {:bar 5 :baz 10)

(clojure.walk/postwalk-demo m)




On Thu, Dec 5, 2013 at 11:06 AM, Ryan arekand...@gmail.com wrote:

 Thanks guys for the useful answers :)

 Ryan


 On Wednesday, December 4, 2013 1:27:57 AM UTC+2, James Ferguson wrote:

 `update-in` could be helpful, depending on what exactly you're doing.

 (doseq [keyA keys, keyB otherkeys]
   (update-in m [keyA keyB] some-function))

 On Tuesday, December 3, 2013 6:05:14 PM UTC-5, Ryan wrote:

 Hi all,

 I am trying to figure out a better way to loop the following map than
 using nested doseq. The map has the following structure:

 (def m
   {outerKeyA {:innerKeyA {string id {:foo 1 :bar 2}}}
outerKeyB {:innerKeyB {string id {:bar 5 :baz 10)


 So, right now i am doing the following:

 (doseq [[outer-keys collections] m]
   (doseq [[collection-name collection] collections]
 (doseq [[string-id data] collection]
   ;; do stuff with all the above
 )))


 Is there a more idiomatic/better way to do deeply nested
 iterations/traversal of map of maps?

 Thank you for any replies!

 Ryan

  --
 --
 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/groups/opt_out.


-- 
-- 
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/groups/opt_out.

Re: CloudFormation template generation with Clojure

[Jeroen van Dijk]

Hi Kevin,

I've created some kind of wrapper around CF templates too. It is too
immature (and ugly) to open source it, but I think it has some nice
features, like Ref checking, templating for userdata and schema validation
of the CF resources via Prismatic Schema.

Can you elaborate on what kind of features you would like to support? Are
you just deciding on DSL syntax or do you have already some kind of Clojure
layer working?

About the DSL, in the end I decided to stick closer to the CF syntax to
avoid confusion and documentation mismatches. So for instance, all my
parameters for a CF resource are CamelCase. One of the most important
features for me is the validation on missing fields and Reference checking.

If you are interested in collaborating in this, please let me know.

Cheers,
Jeroen





On Tue, Nov 26, 2013 at 9:11 AM, Kevin Bell kevin.a.b...@gmail.com wrote:

 Hey Craig,

 Thanks for the input. Forgive my naiveté, but I gather you're implying
 that the DSL-ishness is desirable? That makes sense, and it seems to be
 inline with what I'm learning about the lisp mindset.

 You're suggestion is actually a lot more like an option that I was
 considering but didn't do because it seemed to depart from things like
 project.clj that I was emulating. But it might actually make sense to take
 it a step further to make the scoping within CloudFormation templates more
 explicit.

 I updated my gist with an even more DSL-like concept:
 https://gist.github.com/bellkev/7653342


 On Monday, November 25, 2013 11:49:20 PM UTC-8, Craig wrote:


 I don't know much about CF templates, but stripping some detail from your
 middle fragment moves further from data and to a DSL:

 (deftemplate my-template
   :aws-template-format-version 2010-09-09
   :description My description

   (param my-parameter :type :string :description My string parameter)

   (mapping my-mapping
:first-level-key-one {:second-level-key-one Value}
:first-level-key-two {:second-level-key-two Another Value})

   (condition my-condition (not my-parameter))
   (condition my-second-condition (= (- my-mapping :first-level-key-one
 :second-level-key-one) my-parameter))

   (resource my-instance aws.ec2/instance :image-id ami-79fd7eee)

   (output my-first-output (:instance-type my-instance))
   (output my-second-output my-parameter))

 Craig


 On Tuesday, November 26, 2013 3:41:29 PM UTC+11, Kevin Bell wrote:

 Hey folks, I'm working on a tool to enable the generation of AWS
 CloudFormation templates using a Clojure-based syntax kind of like
 leiningen's project.clj. I'm working on how the syntax should look to be
 most clojurey, and I wonder if anyone has some input:
 https://gist.github.com/bellkev/7653342https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Fbellkev%2F7653342sa=Dsntz=1usg=AFQjCNF5RUFgHxpojQ1x0EPxJFQ09ibA3A

 I should add that I'm very new to Clojure and using this project as an
 opportunity to learn more about the language internals. So please forgive
 any particularly non-idiomatic Clojure...

 Thanks!!

  --
 --
 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/groups/opt_out.


-- 
-- 
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/groups/opt_out.

Re: Quick question on protocols

[Jeroen van Dijk]

Hi David,

I've used protocols for the exact same purpose (Thrift unpacking, and like
you (?), for convenience in Cascalog). I think it works very well and is
speedier than other methods. It is also convenient when you have nested
data structures and you don't want to care how to go through this nesting
to get nested values. Protocols can make this work like magic. Your
question makes sense though and I wasn't sure if it will always works
(never had a counter example in practise though). I did the following
experiment and I think it shows that it works without exception:

user= (isa? String Object)
true

(defprotocol ITest
  (show-me [v]))

(extend-protocol ITest
  Object
  (show-me [v] (println got an object))
  String
  (show-me [v] (println got a string)))

user= (show-me (Object.))
got an object
nil
user= (show-me (String.))
got a string
nil
user= (show-me ^Object (String.))
got a string
nil
user= (show-me (Integer. 1))
got an object
nil
user= (show-me (cast Object 1))
got a string
nil

Not sure if there are other tests available, but this gives me some
confidence.

HTH,

Jeroen


On Thu, May 9, 2013 at 8:45 PM, Dave Kincaid kincaid.d...@gmail.com wrote:

 I've not worked with protocols much, but saw a good fit recently. However,
 I'm a little bit unsure about this situation. I have some Thrift objects
 that I'd like to be able to easily unpack into maps, so I created a protocol

 (defprotocol Unpackable
   (unpack [x]))

 Thrift has two main data types - structs and unions that need to be
 handled differently. Structs always implement the interface TBase. Unions
 extend the abstract class TUnion which in turn implements the interface
 TBase. So I'm extending my protocol to these types like this:

 (extend-protocol IUnpackable
   TUnion
   (unpack [x] (unpack-union x))

   TBase
   (unpack [x] (unpack-struct x (get-meta-data (class x)

 It all seems to work correctly, but I'm a little unsure that it is
 guaranteed to work especially in the case of a union. Since a union extends
 TUnion, but also implements TBase will a call to (unpack the-union) do the
 right thing (go to unpack-union instead of unpack-struct) every time?

 Thanks.

 --
 --
 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/groups/opt_out.




-- 
-- 
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/groups/opt_out.

Re: [ANN] stories - bdd lib for clojure

[Jeroen van Dijk]

Sounds interesting. The repo seems to be unavailable on Github, is that
correct?

Jeroen


On Sun, Apr 28, 2013 at 3:52 PM, Steven Degutis sbdegu...@gmail.com wrote:

 Great, thanks.

 Now it's at https://clojars.org/stories

 -Steven


 On Sun, Apr 28, 2013 at 1:25 AM, Michael Klishin 
 michael.s.klis...@gmail.com wrote:

 2013/4/28 Steven Degutis sbdegu...@gmail.com

 I'd put it on Clojars but I can't really figure out how to deal with
 this gpg stuff. Seems way more complicated. Wish clojure had something
 easier, like homebrew and melpa. But whatever.


 GPG signint is currently optional.

 lein do pom, jar
 scp pom.xml target/[library]-[version].jar cloj...@clojars.org:


 --
 MK

 http://github.com/michaelklishin
 http://twitter.com/michaelklishin

 --
 --
 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/groups/opt_out.




  --
 --
 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/groups/opt_out.




-- 
-- 
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/groups/opt_out.

Re: ANN Titanium, a Clojure library on top of Titan

[Jeroen van Dijk]

Looks interesting. I'm just wondering if you had a look at hermes [1], and
if so, how is it different?

[1] https://github.com/gameclosure/hermes


On Tue, Feb 12, 2013 at 6:39 PM, AtKaaZ atk...@gmail.com wrote:

 is there a way to use nested transactions, yet?
 I am looking at [1] and [2]

 [1]
 https://github.com/thinkaurelius/titan/wiki/Multi-Threaded-Transactions
 [2] https://github.com/tinkerpop/blueprints/wiki/Graph-Transactions



 On Mon, Feb 11, 2013 at 6:37 PM, Michael Klishin 
 michael.s.klis...@gmail.com wrote:

 Titanium [1] is a Clojure graph library that is built on top of  Titan
 [2].
 It combines a Clojure-friendly API and graph processing DSL with the
 power of Titan.

 Full announcement and more details:
 http://blog.clojurewerkz.org/blog/2013/02/11/introducing-titanium/

 1. http://titanium.clojurewerkz.org
 2. http://thinkaurelius.github.com/titan/
 --
 MK

 http://github.com/michaelklishin
 http://twitter.com/michaelklishin

 --
 --
 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/groups/opt_out.






 --
 Please correct me if I'm wrong or incomplete,
 even if you think I'll subconsciously hate it.

  --
 --
 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/groups/opt_out.




-- 
-- 
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/groups/opt_out.

Re: Heroku Boot Times

[Jeroen van Dijk]

Hi Scott,

We had some issues as well. SNAPSHOTS are likely to be an issue because
they are re-checked at least once a day. So if your app needs a restart
this will be re-checked and might slow down boot time. We also had problems
due to this in combination with failing maven mirrors. It is probably best
to just not use SNAPSHOT versions in production.

Another thing that can have impact on boot time is the reading of static
files on booting. We solved this by using '(def resource (delay
(expensive-task ))) and @resource to post-pone this execution for after
booting.

We also use this feature
https://devcenter.heroku.com/articles/labs-preboot/to minimize
possible downtime between deploys (not sure if this works for
restarts as well)

On top of that, we always have a minimum of two dynos for redundancy if one
is down.

HTH,
Jeroen



On Wed, Jan 23, 2013 at 5:00 PM, Scott Parker scott.p.par...@gmail.comwrote:

 Anyone else running a production website with Clojure in Heroku and
 struggling with boot time problems? After digging through our logs
 from the past month, I've noticed it's not uncommon to have a dyno
 crashed for awhile because of boot time problems. It seems especially
 likely when dynos are cycling once/day - I'm guessing because of
 additional delays in picking up latest snapshot dependencies.

 Has anyone else run into this problem and has a bright idea? I have
 already verified we're using lein compile :all at deploy (by virtue of
 being on lein2), running in the production profile, and I am working
 on removing those snapshot dependencies. I've checked the app for
 obvious bottlenecks like web/DB/IO requests during initialization with
 no luck. We don't have a ton of code or dependencies right now, so I'm
 a bit skeptical that we can remain on Heroku as we grow. As a last
 resort, I suppose we could try a proxy bound to a Unix socket as in
 https://github.com/dblock/heroku-forward but I'd rather avoid that if
 possible.

 If not advice specifically in the context of pleasing Heroku, advice
 on troubleshooting slow app init times generally would also be
 welcome. I've done some minimal code benchmarking in Clojure
 previously, but never specifically towards resolving time-to-init.

 Thanks,
 -SP

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

Re: [ANN] clj-squash 0.1.0

[Jeroen van Dijk]

Hi Ragnar,

This looks interesting. It looks like the url to the Squash app should be
http://www.squash.io instead.

I'm currenty (ab)using Airbrake as an exception notifier for my Clojure
apps (which is really unsatisfactory for many reasons). Since it seems
Squash has been built from a Ruby a background as well, could you say
something about how it works for a Clojure environment?

I hope to try it out soon.

Cheers,
Jeroen


On Sat, Jan 19, 2013 at 7:02 PM, Ragnar Dahlén r.dah...@gmail.com wrote:

 Hi,

 I did some work to enable Clojure applications to use Squash, an exception
 reporting and bug analysis tool recently released by Square (see
 http://www.square.io).

 This resulted in clj-squash (apologies for the lack of fantasy), which I
 think is now usable enough to warrant an offical 0.1.0 release in the hope
 that others might find it useful.

 A release has been pushed to Clojars, and the code is available at:
 https://github.com/ragnard/clj-squash

 Feedback and/or contributions are most welcome and appreciated.

 Best regards,

 Ragnar Dahlén

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

Application monitoring with Netty?

[Jeroen van Dijk]

Hi all,

I'm planning to deploy an app on Heroku that exploits some features of
Aleph (e.g. streaming responses). Coming from the Ruby world I've been
spoiled with all the application metrics that NewRelic provides. For
Clojure, however, they currently only support Jetty based apps. Does anyone
know similar solutions that work with Netty or has anyone got NewRelic
working with Netty? The option I am trying to avoid is writing a NewRelic
client myself.

Thanks,
Jeroen

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