Re: Clojure 1.9.0-alpha10: Semantic mismatch: any? vs not-any?
Thanks Sean, Alex. I understand the rationale now. On Sat, Jul 16, 2016 at 12:38 AM, Alex Miller <a...@puredanger.com> wrote: > > On Friday, July 15, 2016 at 2:27:56 PM UTC-5, Atamert Ölçgen wrote: >> >> >> I can't think of a single use case where this function would be useful. I >> would either inline true instead of a function call, or I would supply >> (constantly true) if a function is expected. >> >> I am sure it wouldn't be included in core if there wasn't a valid reason. >> Could you tell me what is this function good for? >> > > It's useful for defining specs. > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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 1.9.0-alpha10: Semantic mismatch: any? vs not-any?
On Mon, Jul 11, 2016 at 9:01 PM, Alan Thompson <clooj...@gmail.com> wrote: > In clojure we are used to shortcuts involving not: > > (when-not x ...) => (when (not x) ...) > (if-not x ...) => (if (not x) ...) > (not-every? pred coll) => (not (every? pred coll)) > (not-any? pred coll) => (not (some pred coll)) > > However, the new function clojure.core/any? breaks this semantic pattern: > > > > (doc clojure.core/any?) > - > clojure.core/any? > ([x]) > Returns true given any argument. > > > > (doc clojure.core/not-any?) > - > clojure.core/not-any? > ([pred coll]) > Returns false if (pred x) is logical true for any x in coll, > else true. > > These two functions are not only unrelated to each other, but they don't > even accept the same number or type of arguments. Moreover, there is an > even more surprising property: > > > (clojure.core/any? nil) > true > > I would have bet money that, at least for nil, the result would not have > been true. > > Given the significant prior conventions in Clojure for functions like > some, every?, *-not, not-*, and also the general handling of nil, it seems > that the new any? function is bound to cause much confusion & > consternation, especially among people learning Clojure. > > Given the degenerate definition: > > > (source clojure.core/any?) > (defn any? > [x] true) > > I can't think of a single use case where this function would be useful. I would either inline true instead of a function call, or I would supply (constantly true) if a function is expected. I am sure it wouldn't be included in core if there wasn't a valid reason. Could you tell me what is this function good for? > would it not be simpler and more instinctive to rename the function > clojure.core/true: > > (defn clojure.core/true > [x] true) > > We could then have code with the obvious result: > > (true 1) => true > (true "hi") => true > (true [])=> true > (true nil) => true > > I believe that such a change would help to keep Clojure in line with users > instincts and assumptions, as well as past Clojure practices. I have often > felt that one of the most important principles in any sort of software > development is adherence to the Principle of Least Astonishment > <https://en.wikipedia.org/wiki/Principle_of_least_astonishment>. > > Alan > > > > On Mon, Jul 11, 2016 at 7:28 AM, Alex Miller <a...@puredanger.com> wrote: > >> >> 1.9.0-alpha10 includes the following changes since 1.9.0-alpha9: >> >> - NEW clojure.core/any? - a predicate that matches anything. any? has >> built-in gen support. The :clojure.spec/any spec has been removed. >> Additionally, gen support has been added for some?. >> >> >> >> > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.
Added truss to validation-benchmark
Hi, Peter Taoussanis was kind enough to contribute truss implementation to validation-benchmark. I have run it (with a few <https://github.com/muhuk/validation-benchmark/commit/7f501a5af769baca4c2fefe5733222a02ff77d7c> upgrades <https://github.com/muhuk/validation-benchmark/commit/68a75036efd28b5eb665406dd99690241eae48d3> to <https://github.com/muhuk/validation-benchmark/commit/edda54ed567c22aadd54d5b0e58b697b8be4c432> other <https://github.com/muhuk/validation-benchmark/commit/1f3b9c5034e5c654414b0d24ac5a60de9e3d4d30> dependencies) and updated the report page. - Personal note: truss is faster than anything else. Much faster. How can this be? It can't be an issue of no-op. Because the wrapper (validation-benchmark.lib.truss/wrapper) is calling the given function. And validation-benchmark.core/prepare-benchmark-for-lib wraps the benchmark function with an assertion on the result (true for valid, false for invalid). Either we have a bug or I am justified to be in awe. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: spec performance comparison
Hi, I have updated the benchmark results. Thanks to Alex Miller's contributions the results should be a bit more accurate now. http://muhuk.github.io/validation-benchmark/ On Tue, Jun 7, 2016 at 3:16 AM, Daniel <doubleagen...@gmail.com> wrote: > Awesome! Would be interesting to see other metrics charted eg loc, memory. > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.
spec performance comparison
Hi, I have added spec to validation-benchmark[1]. The results are here: http://muhuk.github.io/validation-benchmark/ Could you please take check if the implementation is correct and reasonable? Also, I am trying to keep all benchmarks self-contained (in one def/defn). It there a way to perform map validation without spec/def'ing ::name, ::age & ::saiyan? 1: https://github.com/muhuk/validation-benchmark -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.9.0-alpha4
Hi Alex,
On Sat, Jun 4, 2016 at 3:22 PM, Alex Miller <a...@puredanger.com> wrote:
> Why?
>
Because unordered collections shouldn't have heads defined.
Is (first #{3 1 2}) => 3? or 2? or 1?
(I just tried it in a REPL and it is apparently 1.)
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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.9.0-alpha4
On Sat, Jun 4, 2016 at 9:28 AM, <676c7...@gmail.com> wrote:
> This isn’t only an optimisation but also a change in behaviour, isn’t
> it?
>
> Clojure 1.9.0-alpha3:
>
> user=> (let [[x & xs] #{1 2 3}] x)
> UnsupportedOperationException nth not supported on this type:
> PersistentHashSet clojure.lang.RT.nthFrom (RT.java:948)
>
> Clojure 1.9.0-alpha4:
>
> user=> (let [[x & xs] #{1 2 3}] x)
> 1
>
I hope this will be considered a regression and the old behavior will be
restored.
>
> Perhaps the documentation needs to be updated?
> http://clojure.org/reference/special_forms#_vector_binding_destructuring
>
>
> --
> David
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: Get the name of parameters in a function
On Sat, Jun 4, 2016 at 1:45 AM, James Reeves <ja...@booleanknot.com> wrote:
> You can do it with a macro.
>
> - James
>
> On 3 June 2016 at 22:22, Steven Zhou <zzuoh...@gmail.com> wrote:
>
>> Is it possible to write down a function do the following?
>>
>> (defn foo
>> [input]
>>
>> )
>>
>> (def x "Hello")
>> (def y "Clojure")
>>
>> (foo [x y])
>> => {:x "Hello" :y "Clojure"}
>>
>
This seems to do what you want:
(defmacro foo [vars]
(let [keys_ (mapv keyword vars)]
`(zipmap ~keys_ ~vars)))
Note the difference between ~(mapv keyword vars) & ~vars. The former maps
(keyword) over a vector of symbols, then resolves their value (which is
themselves). The latter resolves the vector of symbols directly, each
element in turn gets resolved to their respective definitions.
If you rewrite this to use a (foo [& vars] ...) and be called as (foo x y),
I think it would be easier to see what's happening.
>
>>
>> Regards,
>> -Steven
>>
>> --
>> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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
Thanks Alex! I didn't know this.
On Tue, May 24, 2016 at 3:10 PM, Alex Miller <a...@puredanger.com> wrote:
> The first use is a namespace alias and the second is a var - they don't
> overlap in usage.
>
>
> On Tuesday, May 24, 2016 at 2:28:11 AM UTC-5, Atamert Ölçgen wrote:
>>
>> Isn't s redefined in this example:
>>
>> user=> (require '[clojure.spec :as s])
>> (s/def ::even? (s/and integer? even?))
>> (s/def ::odd? (s/and integer? odd?))
>> (s/def ::a integer?)
>> (s/def ::b integer?)
>> (s/def ::c integer?)
>> (def s (s/cat :forty-two #{42}
>> :odds (s/+ ::odd?)
>> :m (s/keys :req-un [::a ::b ::c])
>> :oes (s/* (s/cat :o ::odd? :e ::even?))
>> :ex (s/alt :odd ::odd? :even ::even?)))
>> user=> (s/conform s [42 11 13 15 {:a 1 :b 2 :c 3} 1 2 3 42 43 44 11])
>> {:forty-two 42,
>> :odds [11 13 15],
>> :m {:a 1, :b 2, :c 3},
>> :oes [{:o 1, :e 2} {:o 3, :e 42} {:o 43, :e 44}],
>> :ex {:odd 11}}
>>
>>
>> in http://clojure.org/about/spec
>>
>>
>> On Mon, May 23, 2016 at 5:12 PM, Rich Hickey <richhic...@gmail.com>
>> wrote:
>>
>>> Introducing clojure.spec
>>>
>>> I'm happy to introduce today clojure.spec, a new core library and
>>> support for data and function specifications in Clojure.
>>>
>>> Better communication
>>>
>>> Clojure is a dynamic language, and thus far we have relied on
>>> documentation or external libraries to explain the use and behavior of
>>> functions and libraries. But documentation is difficult to produce, is
>>> frequently not maintained, cannot be automatically checked and varies
>>> greatly in quality. Specs are expressive and precise. Including spec in
>>> Clojure creates a lingua franca with which we can state how our programs
>>> work and how to use them.
>>>
>>> More leverage and power
>>>
>>> A key advantage of specifications over documentation is the leverage
>>> they provide. In particular, specs can be utilized by programs in ways that
>>> docs cannot. Defining specs takes effort, and spec aims to maximize the
>>> return you get from making that effort. spec gives you tools for leveraging
>>> specs in documentation, validation, error reporting, destructuring,
>>> instrumentation, test-data generation and generative testing.
>>>
>>> Improved developer experience
>>>
>>> Error messages from macros are a perennial challenge for new (and
>>> experienced) users of Clojure. specs can be used to conform data in macros
>>> instead of using a custom parser. And Clojure's macro expansion will
>>> automatically use specs, when present, to explain errors to users. This
>>> should result in a greatly improved experience for users when errors occur.
>>>
>>> More robust software
>>>
>>> Clojure has always been about simplifying the development of robust
>>> software. In all languages, dynamic or not, tests are essential to quality
>>> - too many critical properties are not captured by common type systems.
>>> spec has been designed from the ground up to directly support generative
>>> testing via test.check https://github.com/clojure/test.check. When you
>>> use spec you get generative tests for free.
>>>
>>> Taken together, I think the features of spec demonstrate the ongoing
>>> advantages of a powerful dynamic language like Clojure for building robust
>>> software - superior expressivity, instrumentation-enhanced REPL-driven
>>> development, sophisticated testing and more flexible systems. I encourage
>>> you to read the spec rationale and overview
>>> http://clojure.org/about/spec. Look for spec's inclusion in the next
>>> alpha release of Clojure, within a day or so.
>>>
>>> Note that spec is still alpha, and some details are likely to change.
>>> Feedback welcome.
>>>
>>> I hope you find spec useful and powerful!
>>>
>>> Rich
>>>
>>> --
>>> 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
>>> htt
Re: clojure.spec
Isn't s redefined in this example:
user=> (require '[clojure.spec :as s])
(s/def ::even? (s/and integer? even?))
(s/def ::odd? (s/and integer? odd?))
(s/def ::a integer?)
(s/def ::b integer?)
(s/def ::c integer?)
(def s (s/cat :forty-two #{42}
:odds (s/+ ::odd?)
:m (s/keys :req-un [::a ::b ::c])
:oes (s/* (s/cat :o ::odd? :e ::even?))
:ex (s/alt :odd ::odd? :even ::even?)))
user=> (s/conform s [42 11 13 15 {:a 1 :b 2 :c 3} 1 2 3 42 43 44 11])
{:forty-two 42,
:odds [11 13 15],
:m {:a 1, :b 2, :c 3},
:oes [{:o 1, :e 2} {:o 3, :e 42} {:o 43, :e 44}],
:ex {:odd 11}}
in http://clojure.org/about/spec
On Mon, May 23, 2016 at 5:12 PM, Rich Hickey <richhic...@gmail.com> wrote:
> Introducing clojure.spec
>
> I'm happy to introduce today clojure.spec, a new core library and support
> for data and function specifications in Clojure.
>
> Better communication
>
> Clojure is a dynamic language, and thus far we have relied on
> documentation or external libraries to explain the use and behavior of
> functions and libraries. But documentation is difficult to produce, is
> frequently not maintained, cannot be automatically checked and varies
> greatly in quality. Specs are expressive and precise. Including spec in
> Clojure creates a lingua franca with which we can state how our programs
> work and how to use them.
>
> More leverage and power
>
> A key advantage of specifications over documentation is the leverage they
> provide. In particular, specs can be utilized by programs in ways that docs
> cannot. Defining specs takes effort, and spec aims to maximize the return
> you get from making that effort. spec gives you tools for leveraging specs
> in documentation, validation, error reporting, destructuring,
> instrumentation, test-data generation and generative testing.
>
> Improved developer experience
>
> Error messages from macros are a perennial challenge for new (and
> experienced) users of Clojure. specs can be used to conform data in macros
> instead of using a custom parser. And Clojure's macro expansion will
> automatically use specs, when present, to explain errors to users. This
> should result in a greatly improved experience for users when errors occur.
>
> More robust software
>
> Clojure has always been about simplifying the development of robust
> software. In all languages, dynamic or not, tests are essential to quality
> - too many critical properties are not captured by common type systems.
> spec has been designed from the ground up to directly support generative
> testing via test.check https://github.com/clojure/test.check. When you
> use spec you get generative tests for free.
>
> Taken together, I think the features of spec demonstrate the ongoing
> advantages of a powerful dynamic language like Clojure for building robust
> software - superior expressivity, instrumentation-enhanced REPL-driven
> development, sophisticated testing and more flexible systems. I encourage
> you to read the spec rationale and overview http://clojure.org/about/spec.
> Look for spec's inclusion in the next alpha release of Clojure, within a
> day or so.
>
> Note that spec is still alpha, and some details are likely to change.
> Feedback welcome.
>
> I hope you find spec useful and powerful!
>
> Rich
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: Validation Benchmark
Hi Jason, Thank you for the PR. I've just merged it. For now I have added this to the blog post: Results below and the comments about Schema being slow is no longer true. See this pull request <https://github.com/muhuk/validation-benchmark/pull/6> for the results Jason got with quick mode benchmark. I am thinking about generating a stand alone page (GH pages) so that I don't have to update or create a new post everytime the results are updated. The README for Schema doesn't mention checker function, FYI. On Tue, Apr 19, 2016 at 7:30 AM, Jason Wolfe <ja...@w01fe.com> wrote: > Thanks for putting this together! > > For schema, I think using `s/validate` is not a fair comparison with the > other libraries -- as you mention, it throws an exception on error, and it > also has to parse the schema each time. > > I think `s/checker` is the correct construct to use here -- it returns an > error or nil for success (no exceptions), and only parses the schema once. > (This is what's used by `s/defn`, for example). > > Here's a pull request that implements this change: > > https://github.com/muhuk/validation-benchmark/pull/6 > > I posted the updated results in the PR comments as well, which are > qualitatively quite different from the ones currently reported in your blog > post (with this change, schema is fastest on all but one benchmark, often > by a factor of 3 or more). > > Please let me know if you have any questions. > > Thanks, > Jason > > > On Tuesday, April 19, 2016 at 2:47:33 AM UTC+7, Atamert Ölçgen wrote: >> >> Hi All, >> >> I have been working a benchmark for (runtime) validation libraries. I >> think it is mature enough to share the results with the group. >> >> The repo is here: https://github.com/muhuk/validation-benchmark >> >> Raw benchmark output as EDN is here: >> https://gist.github.com/muhuk/93d7d9e46bf5191310aaa4557379d10e >> >> More human readable results are in my blog: >> http://blog.muhuk.com/2016/04/18/performance_comparison_of_annotate_herbert_schema.html >> >> If you are familiar with Annotate, Herbert or Schema, please take a quick >> look at their implementations: >> https://github.com/muhuk/validation-benchmark/tree/master/src/validation_benchmark/lib >> >> Also contributions of other validation libraries are most welcome! >> >> - >> >> As an aside: what is the group policy for attachments? Would it be ok if >> I attached images of benchmark results? >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> ◻◼◻ >> ◻◻◼ >> ◼◼◼ >> >> www.muhuk.com >> > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.
Validation Benchmark
Hi All, I have been working a benchmark for (runtime) validation libraries. I think it is mature enough to share the results with the group. The repo is here: https://github.com/muhuk/validation-benchmark Raw benchmark output as EDN is here: https://gist.github.com/muhuk/93d7d9e46bf5191310aaa4557379d10e More human readable results are in my blog: http://blog.muhuk.com/2016/04/18/performance_comparison_of_annotate_herbert_schema.html If you are familiar with Annotate, Herbert or Schema, please take a quick look at their implementations: https://github.com/muhuk/validation-benchmark/tree/master/src/validation_benchmark/lib Also contributions of other validation libraries are most welcome! - As an aside: what is the group policy for attachments? Would it be ok if I attached images of benchmark results? -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] rete4frames, v. 5.2.4 - CLIPS-like expert system shell
Hi, It seems this library has really good documentation, but the link is at the very end of readme. I think it would be great if "I see you are not familiar with rule engines, here's a real quick summary of what rete4frames is" comes before "and here is the detailed docs" which comes before "look, we're not faster than this Java thing, but we beat it in a few benchmarks". On Thu, Feb 4, 2016 at 4:19 PM, ru <soro...@oogis.ru> wrote: > Hi, > > New version 5.2.4 of rete4frames CLIPS-like expert system shell is > published on https://github.com/rururu/rete4frames. > > News: > > 1. Refactored functions "dissoc-in" and "remove-fmem" for better > performance and reliability. > 2. New compound example of expert system: "Real" air traffic control > system - client-server ClojureScript-Clojure application based on > Flightradar24 web service (http://www.flightradar24.com/), Leaflet > JavaScript libraty (http://leafletjs.com/), httpkit, compojure, > core.async and others Clojure libraries. This example is in a separate > repository https://github.com/rururu/rete4flights. > > Enjoy! > > Sincerely, > Ru > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Check if value is a ring handler
You can check for a valid response using ring.util.response/response? (obviously requires calling the function in question) On Wed, Jan 27, 2016 at 7:42 AM, JvJ <kfjwhee...@gmail.com> wrote: > Is there a way to dynamically check whether or not a given function > qualifies as a ring handler? > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Ultralight Components
Hi Colin, > in this industry there are hardly any unambiguous and objective statements Either you contradict yourself or the following is ambiguous and/or subjective: > pragmatism throws it all out of the window - > One man’s complexity is another man’s simplicity and so on. Can you please give an example? - Are you suggesting we don't discuss merits and shortcomings of different approaches to design software? On Tue, Nov 24, 2015 at 10:11 AM, Colin Yates <colin.ya...@gmail.com> wrote: > I think this discussion has run into the age-old problem of ‘subjective > interpretation’, namely, multiple people all agreeing with a principle > (i.e. complexity sucks) but then having _different_ interpretations of > where that principle is challenged/upheld. Unfortunately in this industry > there are hardly any unambiguous and objective statements because most of > what we do is more artistic than engineering (zips up the flame suit now). > > And, as ever, pragmatism throws it all out of the window :-) > > One man’s complexity is another man’s simplicity and so on. > > > > On 24 Nov 2015, at 06:34, Atamert Ölçgen <mu...@muhuk.com> wrote: > > Hi William, > > How is this different than Yo-yo? ( > https://groups.google.com/forum/#!topic/clojure/PvCc5sSeSRY) > > > Justifying things is generally impossible. > > Actually, no. It is possible, at least when you are dealing with > reasonable people. And when you make claims like "lightweight" or > "ultralight", people will naturally ask "oh, interesting, how so?" > > - > > Some functional programming folks are allergic to exceptions. They go out > of their ways to prevent any and all exceptions and they end up > unnecessarily complicating their types for little or no gain. > > It seems to me, you are trying to avoid using protocols like it's a plague. > > > I am tired of doing ongoing refactorings interrupted periodically by > complete rewrites. Class hierarchies are the worst... > > When your ultralight function based components get out of hand, you will > have a worse time refactoring. With component you only have two functions, > your lightweight design will end up having (* n 2) functions. > > Also, looking at a component's code (it's defrecord form I mean) I can see > what other components it depends on. Your design would bury them inside > functions making it harder to read. > > > On Tue, Nov 24, 2015 at 6:57 AM, James Reeves <ja...@booleanknot.com> > wrote: > >> Have you watched Simple Made Easy >> <http://www.infoq.com/presentations/Simple-Made-Easy>? >> >> I mention it because you remark about being tired of refactoring. It's my >> opinion that's a symptom of complexity, in the Hickey definition of the >> term. >> >> - James >> >> On 24 November 2015 at 03:31, William la Forge <laforg...@gmail.com> >> wrote: >> >>> James, >>> >>> Being fun is important but not a justification. We should strive to keep >>> things fun, but there are plenty of thing worth doing and our resources are >>> always limited. And if it is not fun, you are not going to do your best >>> work. >>> >>> Justifying things is generally impossible. If vanilla clojure meets your >>> needs, then vanilla clojure it is. If macros solve the problems you have >>> been dealt in the past, then three cheers for macros. If unifying client >>> and server addresses your needs, then Om Next may well be a major blessing >>> for you. >>> >>> For me, the winner is avoiding static structures. I am tired of doing >>> ongoing refactorings interrupted periodically by complete rewrites. Class >>> hierarchies are the worst--being the largest, they are the least stable. I >>> like small files that I can put to bed as finished. And self-defining >>> aggregation. Because these meet my very real needs. I constantly >>> reconceptualize what I am working on while bringing projects to completion. >>> So having a programming style which keeps code relevant in the face of such >>> an onslaught is very helpful and also a genuine delight. >>> >>> --b >>> >>> On Mon, Nov 23, 2015 at 10:08 PM, James Reeves <ja...@booleanknot.com> >>> wrote: >>> >>>> I feel you might be barking up the wrong tree with this approach, as it >>>> seems to complicate things without providing any compelling advantages. >>>> >>>> That said, if it's fun then by all means continue to experiment. Maybe >>>> I'm wrong :) >>>> >>
Re: Ultralight Components
mings, > too frequently we don’t, we only discuss the merits. > > The reason I posted initially is because I have wasted so many months > arguing details with other developers and having a black and white view of > things and it almost always turned out that we were agreeing with the > general principle but the application of that principle meant different > things in each of our different contexts. We were ‘violently agreeing’ :-). > > TLDR(2): there is no ‘better’ only ‘better in this context' > > I hope that clarified my view point. > > > > > On Tue, Nov 24, 2015 at 10:11 AM, Colin Yates <colin.ya...@gmail.com> > wrote: > >> I think this discussion has run into the age-old problem of ‘subjective >> interpretation’, namely, multiple people all agreeing with a principle >> (i.e. complexity sucks) but then having _different_ interpretations of >> where that principle is challenged/upheld. Unfortunately in this industry >> there are hardly any unambiguous and objective statements because most of >> what we do is more artistic than engineering (zips up the flame suit now). >> >> And, as ever, pragmatism throws it all out of the window :-) >> >> One man’s complexity is another man’s simplicity and so on. >> >> >> >> On 24 Nov 2015, at 06:34, Atamert Ölçgen <mu...@muhuk.com> wrote: >> >> Hi William, >> >> How is this different than Yo-yo? ( >> https://groups.google.com/forum/#!topic/clojure/PvCc5sSeSRY) >> >> > Justifying things is generally impossible. >> >> Actually, no. It is possible, at least when you are dealing with >> reasonable people. And when you make claims like "lightweight" or >> "ultralight", people will naturally ask "oh, interesting, how so?" >> >> - >> >> Some functional programming folks are allergic to exceptions. They go out >> of their ways to prevent any and all exceptions and they end up >> unnecessarily complicating their types for little or no gain. >> >> It seems to me, you are trying to avoid using protocols like it's a >> plague. >> >> > I am tired of doing ongoing refactorings interrupted periodically by >> complete rewrites. Class hierarchies are the worst... >> >> When your ultralight function based components get out of hand, you will >> have a worse time refactoring. With component you only have two functions, >> your lightweight design will end up having (* n 2) functions. >> >> Also, looking at a component's code (it's defrecord form I mean) I can >> see what other components it depends on. Your design would bury them inside >> functions making it harder to read. >> >> >> On Tue, Nov 24, 2015 at 6:57 AM, James Reeves <ja...@booleanknot.com> >> wrote: >> >>> Have you watched Simple Made Easy >>> <http://www.infoq.com/presentations/Simple-Made-Easy>? >>> >>> I mention it because you remark about being tired of refactoring. It's >>> my opinion that's a symptom of complexity, in the Hickey definition of the >>> term. >>> >>> - James >>> >>> On 24 November 2015 at 03:31, William la Forge <laforg...@gmail.com> >>> wrote: >>> >>>> James, >>>> >>>> Being fun is important but not a justification. We should strive to >>>> keep things fun, but there are plenty of thing worth doing and our >>>> resources are always limited. And if it is not fun, you are not going to do >>>> your best work. >>>> >>>> Justifying things is generally impossible. If vanilla clojure meets >>>> your needs, then vanilla clojure it is. If macros solve the problems you >>>> have been dealt in the past, then three cheers for macros. If unifying >>>> client and server addresses your needs, then Om Next may well be a major >>>> blessing for you. >>>> >>>> For me, the winner is avoiding static structures. I am tired of doing >>>> ongoing refactorings interrupted periodically by complete rewrites. Class >>>> hierarchies are the worst--being the largest, they are the least stable. I >>>> like small files that I can put to bed as finished. And self-defining >>>> aggregation. Because these meet my very real needs. I constantly >>>> reconceptualize what I am working on while bringing projects to completion. >>>> So having a programming style which keeps code relevant in the face of such >>>> an onslaught is very helpful and also a genuine delight. >
Re: Ultralight Components
nd 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 a topic in the >>>>> Google Groups "Clojure" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/clojure/7Q7QvlSUGL4/unsubscribe. >>>>> To unsubscribe from this group and all its topics, 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 a topic in the >>> Google Groups "Clojure" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/clojure/7Q7QvlSUGL4/unsubscribe. >>> To unsubscribe from this group and all its topics, 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: A call for an idiomatic rendering of Clojure EDN in info/error messages
+1 for no special markup, +1 for backquotes, -1 for underscore, -1 for pipe
char.
On Fri, Nov 13, 2015 at 7:18 PM, Colin Yates <colin.ya...@gmail.com> wrote:
> This. Confusing for the rubyists but hey :-).
>
> On 13 Nov 2015, at 17:13, Yuri Govorushchenko <yuri.go...@gmail.com>
> wrote:
>
> I recall Google uses vertical bars in ObjC comments for similar purposes,
> as stated in their style guide:
>
> Use vertical bars to quote variable names and symbols in comments rather
> than quotes or naming the symbol inline.
>
> This helps eliminate ambiguity, especially when the symbol is a common
> word that might make the sentence read like it was poorly constructed. E.g.
> for a symbol "count":
>
> // Sometimes we need |count| to be less than zero.
>
> or when quoting something which already contains quotes
>
> // Remember to call |StringWithoutSpaces("foo bar baz")|
>
>
> --
> https://google.github.io/styleguide/objcguide.xml?showone=Implementation_Comments#Implementation_Comments
>
> пятница, 13 ноября 2015 г., 13:55:40 UTC+2 пользователь Colin Yates
> написал:
>>
>> Hi all,
>>
>> Can we, the community agree a consistent way of rendering Clojure EDN
>> when we report it in info or error. For example, given the EDN "2" (i.e. a
>> string containing a single character 2) I have seen various libraries
>> render it as:
>>
>> - 2
>> - "2"
>> - ["2"]
>> - [2]
>> - (2)
>> - '"2"'
>>
>> I would like to propose that we standardise around "_" as the boundary
>> character as that isn't likely to be used in (except for some markup I
>> guess but that is pretty unlikely), so a test framework might render as
>> such:
>>
>> - expected _2_ but was _"2"_
>>
>> Please? :-)
>>
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: A call for an idiomatic rendering of Clojure EDN in info/error messages
Hi Colin, Why not just "2"? On Fri, Nov 13, 2015 at 1:55 PM, Colin Yates <colin.ya...@gmail.com> wrote: > Hi all, > > Can we, the community agree a consistent way of rendering Clojure EDN when > we report it in info or error. For example, given the EDN "2" (i.e. a > string containing a single character 2) I have seen various libraries > render it as: > > - 2 > - "2" > - ["2"] > - [2] > - (2) > - '"2"' > > I would like to propose that we standardise around "_" as the boundary > character as that isn't likely to be used in (except for some markup I > guess but that is pretty unlikely), so a test framework might render as > such: > > - expected _2_ but was _"2"_ > > Please? :-) > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Style, Efficiency, and updating nested structure
f new vector on project_roles, so they aren't
> included in allocations
> ;; below since both routines have to do it.
> ;;
> ;; Note that x-element map allocates storage for map and map-entries or
> clojure equivalent.
> ;; (and more expensive than an x-element vector, of course).
> ;;
> ;; n == length of input project list.
> ;; m == average length of input project list role vectors.
> ;;
> ;; Object Allocations
> ;; Function call:
> ;; update-roles:
> ;; 1 atom
> ;; 1 O(n) vector for mapv
> ;; update-or-insert-project-role:
> ;; 1 3-entry map + 1 single-element vector for prj-role argument
> input.
> ;; 1 n-element map for group-by
> ;; n vectors for group-by map values
> ;; 1 n-element map for update-in
> ;; 1 list/sequence for mapcat (+ n concat intermediaries?)
> ;; 1 vector for into
> ;;
> ;; If we discard the second 'into' and first 'mapv' allocations the
> update-or-insert-project-role routine allocates
> ;; 3 additional maps (two of which are O(n)), n additional vectors, and 1
> additional list/sequence.
> ;;
> ;; Searches/traversals/copies
> ;; update-roles:
> ;; O(n) - mapv
> ;; update-or-insert-project-role:
> ;; O(n) - group-by
> ;; O(n) - update-in
> ;; O(n) - mapcat
> ;; O(n) - into
> ;;
> ;; Here's what update-or-insert-project-role allocates (by way of
> assistance in assessing the above)
> ;;{1 [{:project_id 1, :project_name "One", :project_roles [:own]}], 3
> [{:project_id 3, :project_name "Three", :project_roles [:edit]}]}
> -- group-by
> ;;{1 [{:project_id 1, :project_name "One", :project_roles [:own :edit]}],
> 3 [{:project_id 3, :project_name "Three", :project_roles [:edit]}]}
> -- update-in
> ;;({:project_id 1, :project_name "One", :project_roles [:own :edit]}
> {:project_id 3, :project_name "Three", :project_roles [:edit]})
>-- mapcat
> ;;[{:project_id 1, :project_name "One", :project_roles [:own :edit]}
> {:project_id 3, :project_name "Three", :project_roles [:edit]}]
>-- into
>
> Thanks for your thoughts and suggestions.
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: Help with decisions in threading macros
Perhaps you can replace (reduce ...) with (every? true?), which works with empty collections. On Tue, Nov 3, 2015 at 6:05 PM, Timur <timurha...@gmail.com> wrote: > Hi all, > > Often I need to make decisions in simple threading macros, for instance > consider the following code > > (->> m >:vector >(filterv #(= (:id %) (:id m))) >(reduce #(and %1 %2))) > > In this case, if the result of filter is empty reduce throws an exception > as it expects some values. Therefore, I want to include a decision between > filter and reduce for instance if empty then add false into the resulting > vector. What would be the best way to achieve this? I could add a function > that checks if empty then add sth into the vector but wanted to ask your > opinions if there is a better way to do this. > > Regards, > > Timur > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] ring-transit-middleware 0.1.1
Hi Sven, What is the difference to ring-transit ring-transit-middleware doesn't silence exceptions. Also the three points I listed in my original message. But _essentially_ they both do the same thing. On Sat, Oct 31, 2015 at 11:41 PM, Sven Richter <sver...@googlemail.com> wrote: > Hi Atamert, > > Thanks for your work. I am curious. What is the difference to ring-transit > (https://github.com/jalehman/ring-transit). Both libraries seem to have > the same goal. > > Best Regards, > Sven > > > Am Samstag, 31. Oktober 2015 14:30:21 UTC+1 schrieb Atamert Ölçgen: >> >> Hi, >> >> I've just released ring-transit-middleware 0.1.1 to clojars. >> >> - It has sane defaults, most of the time you just need to wrap with >> ring.middleware.transit/wrap-transit >> - Allows customisation (see API docs) >> - Is Aleph-aware (handles deferred responses) >> >> https://github.com/muhuk/ring-transit-middleware >> >> Your feedback & contributions are welcome. >> >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> ◻◼◻ >> ◻◻◼ >> ◼◼◼ >> >> www.muhuk.com >> > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] ring-transit-middleware 0.1.1
Hi, I've just released ring-transit-middleware 0.1.1 to clojars. - It has sane defaults, most of the time you just need to wrap with ring.middleware.transit/wrap-transit - Allows customisation (see API docs) - Is Aleph-aware (handles deferred responses) https://github.com/muhuk/ring-transit-middleware Your feedback & contributions are welcome. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Timbre corrupting EDN via prn-str
Hi Ken, Have you tried with-out-str? On Wed, Oct 7, 2015 at 11:18 AM, Ken Restivo <k...@restivo.org> wrote: > I was trying to save a data structure using prn-str. > > However, I'm also using Timbre for logging. > > My nice data structure is getting corrupted by INFO and DEBUG and other > log messages from Timbre. > > Is there any way to turn a Clojure data structure into EDN without mucking > around with things like pr-str that use *out*, which apparently is used for > logging, among other things? > > -ken > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Timbre corrupting EDN via prn-str
So you actually want to print your data. I don't think it can be helped then, two threads writing to the same buffer. I would have one of them use a different buffer, write the logs to a file and tail it for instance. On Wed, Oct 7, 2015 at 11:36 AM, Ken Restivo <k...@restivo.org> wrote: > Yep. It doesn't help. > > I also tried (.flush *out*) before... no dice. > > -ken > -- > - > On Wed, Oct 07, 2015 at 11:31:12AM +0300, Atamert Ölçgen wrote: > > Hi Ken, > > > > Have you tried with-out-str? > > > > On Wed, Oct 7, 2015 at 11:18 AM, Ken Restivo <k...@restivo.org> wrote: > > > > > I was trying to save a data structure using prn-str. > > > > > > However, I'm also using Timbre for logging. > > > > > > My nice data structure is getting corrupted by INFO and DEBUG and other > > > log messages from Timbre. > > > > > > Is there any way to turn a Clojure data structure into EDN without > mucking > > > around with things like pr-str that use *out*, which apparently is > used for > > > logging, among other things? > > > > > > -ken > > > > > > -- > > > 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. > > > > > > > > > > > -- > > Kind Regards, > > Atamert Ölçgen > > > > ◻◼◻ > > ◻◻◼ > > ◼◼◼ > > > > www.muhuk.com > > > > -- > > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] Shrubbery 0.3.0, a stubbing, spying, and mocking library for Clojure protocols
This is awesome! I might have more useful feedback (and PRs) in the future, because I can see myself using this extensively. It would be great if multiple return values for multiple calls were supported. First use case it something like an iteration, calling some protocol method repeatedly (possibly with different inputs). Another use case is just calling it with different inputs, expecting different outputs. Something like (add (square x) (square y)). Thanks for sharing Brian. On Tue, Oct 6, 2015 at 5:29 AM, Brian Guthrie <btguth...@gmail.com> wrote: > Great to hear! Let me know if there are any questions I can answer. > Feedback gratefully accepted. > > Cheers, > > Brian > > > On Mon, Oct 5, 2015 at 11:56 AM, James Reeves <ja...@booleanknot.com> > wrote: > >> Very nice. I was looking for something like this. >> >> - James >> >> On 5 October 2015 at 15:14, Brian Guthrie <btguth...@gmail.com> wrote: >> >>> Clojure protocols are a great way to encapsulate operations with side >>> effects, but suffer from a lack of general test tooling. Shrubbery provides >>> a small set of basic building blocks for working with them: >>> >>> * stub, which accepts a variable list of protocols and a optional >>> hashmap of simple value implementations and returns an object that reifies >>> all given protocols; >>> * spy, which accepts an object with at least one protocol >>> implementation and returns a new implementation that tracks the number of >>> times each of its members were called; >>> * mock, which wraps a stub in a spy, allowing callers to supply basic >>> function implementations and assert against those calls; and >>> * calls/received?, which in conjunction with the Matcher protocol >>> provide a way to query spies and assert against their state. >>> >>> Shrubbery is test-framework-agnostic, avoids altering runtime state to >>> the degree possible, and uses no macros. It should work nicely with >>> refactorings like rename-function. >>> >>> https://github.com/bguthrie/shrubbery >>> >>> [com.gearswithingears/shrubbery "0.3.0"] >>> >>> >>> New in this release: >>> >>> – Support for multiple protocols in both spies and stubs. >>> – Spies attempt to automatically derive the given implementation's >>> protocols, and tracks calls to all of them. (This behavior can be >>> overridden.) >>> – Replaced all macros with plain functions. (Unfortunately, this means >>> leaning on eval in some cases.) >>> >>> Cheers, >>> >>> 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. >> > > -- > 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 unsu
Re: midje only 1 test
Hi Brian,
On Sun, Sep 6, 2015 at 1:19 AM, Brian Marick <mar...@exampler.com> wrote:
> I *strongly* recommend doing all your testing in a repl buffer. That
> given, there are two ways to solve your problem. The first, which I prefer,
> is to start by testing everything:
>
> (use 'midje.repl)
> (autotest)
>
Other than having a REPL, is this different than doing `lein midje
:autotest`?
>
> Then, when you change any text and save the namespace it's in, all tests
> that depend on that namespace will be rerun, including the one you're
> specifically working on.
>
> The other alternative is to rerun your specific test with something like:
>
> (check-facts #"fact description")
>
> ... or, once you've run a specific fact:
>
> (recheck-fact)
>
>
>
> r/ Wobben wrote:
>
>> hello,
>>
>> Suppose I have this test
>>
>> (facts "do-a-thing" {:exercise 1:points 1} (do-a-thing 3) =>
>> 46656.0 (do-a-thing 1) => 4.0 (do-a-thing 0) => 1.0)
>>
>>
>> Is there a way I can only run this test
>> I tried lein midje :filter exercise 1
>> but that one fails.
>>
>> Roelof
>>
>> --
>> 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
>> <mailto: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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: Live rendering of AsciiDoc files in Chrome browser
I am using AsciiLight plugin for LightTable and very happy with it: https://github.com/rundis/AsciiLight On Wed, Sep 2, 2015 at 10:06 PM, Alan Thompson <clooj...@gmail.com> wrote: > Hey, > > As you all know, the README files on Github, etc can be formatted using > the either AsciiDoc (my favorite) or the older MarkDown format. However, > it is a pain to edit these files in just a plain text editor without a good > way of seeing the final, rendered format until you commit and push your > latest changes up to GH. > > If you haven't seen it yet, there is a Chrome extension named > "Asciidoctor.js" that will render both AsciiDoc *and* MarkDown files into > HTML right in your browser. It even features automatic reloading of > changes (~2 sec delay) whenever you make a change to the source file. > > If you are not already using this or a similar tool, you should give it a > try. Enjoy! > > Alan > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Generalizing - and - forms
Hi, threading doesn't need to be a macro. In fact it would be easier to test if it's just a function. Also, you know about as-, don't you? On Fri, Aug 28, 2015 at 2:37 PM, Akhil Wali green.transis...@gmail.com wrote: I've been trying to refactor the - and - forms to use a common macro form. Ended up with this. (defmacro threading [a b x forms] (loop [x x forms forms] (if forms (let [form (first forms) f (first form) r (rest form) threaded (if (seq? form) (with-meta `(~f ~`(~a ~`(list ~x ~@r)) ~`(~b ~`(list ~x ~@r))) (meta form)) (list form x))] (recur threaded (next forms))) x))) (defmacro - [x forms] `(threading ~'first ~'second ~x ~forms)) (defmacro - [x forms] `(threading ~'second ~'first ~x ~forms)) This does work, but it's a bit of whammy. Anyone with suggestions for improvement? -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] io.aviso/rook 0.1.36
Got it, thanks. I think you still need to prepend ^'s to the metadata. On Thu, Aug 27, 2015 at 8:40 PM, Howard Lewis Ship hls...@gmail.com wrote: That's misleading. In the case of convention function names, (index, show, create), there's default :route metadata that is used automatically ... the docstrings are merely supplying a reminder. This is described in the Getting Started page: https://portal.aviso.io/#/document/open-source/rook/Current/getting-started.html If you look at the increment endpoint function, which is not a convention name, it has explicit :route metadata. I'll update the example to make this much more clear. On Tue, Aug 25, 2015 at 7:43 AM, Atamert Ölçgen mu...@muhuk.com wrote: Hi Howard, In the example application it seems the routing information is encoded in the beginning of the docstring and not the actual metadata. Is there an option to put this info in the metadata of the var? On Mon, Aug 24, 2015 at 6:31 PM, Howard Lewis Ship hls...@gmail.com wrote: Rook is a set of middleware and handlers to enable metadata-based routing for Ring web applications. The intention is to expose a Clojure namespace as a web service resource; there’s a default mapping of HTTP verbs and paths to function names; these can be extended or overridden by metadata on the functions in the namespace. The end result is that a compliant web service resource can be created in very little code. Rook also supports Swagger 2.0: a detailed JSON description of your web service is generated directly from the functions and metadata. Recent changes: * Described more of the APIs using Prismatic Schema * Added ability to reuse the argument resolution logic outside of endpoint functions * Many improvements to the Swagger 2.0 description support https://github.com/AvisoNovate/rook -- Howard M. Lewis Ship Looking for Clojure engagements: coding, architecture, mentoring more! Creator of Apache Tapestry (971) 678-5210 http://howardlewisship.com @hlship -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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. -- Howard M. Lewis Ship Starting with WalMart Labs on Sep 28th! Creator of Apache Tapestry (971) 678-5210 http://howardlewisship.com @hlship -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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
Re: Manifold questions: Creating sinks/sources
On Thu, Aug 27, 2015 at 10:51 PM, Zach Tellman ztell...@gmail.com wrote: Hi Atamert, Hi Zach, For future reference, posting these questions to https://groups.google.com/forum/#!forum/aleph-lib will ensure I'll see them sooner. I've subscribed. Thanks. The `source-only` method is just a way to make sure that the chance for confusion is minimized, it doesn't prevent the underlying object from being used normally. As for your scenario, I'm not sure I completely understand. In a standard stream, the flow of data is: [ sink - source ] So if you `put!` something into the sink, you can `take!` it from the source. If you use `source-only` and connect that to some other sink, then the flow of data will be [ sink - source ] - sink So the source is only connected to one sink, not two. Maybe I'm misunderstanding you, though. I have initially written it right. I was looking through the docs and the source at the same time and I got confused. Then I replaced source with sink and vice versa. So if you are misunderstanding, you are understanding. :) Let me try again. If we have: (def my-sink (s/sink-only (s/stream ...))) (def my-source (s/source-only (s/stream ...))) (s/connect my-source my-sink) ;; BTW this got me confused, I thought flow was like my-source - my-sink After I have written the comment above, and playing with this code in the REPL, I have realized the flow IS from source to sink. I think I am un-confused now, and it all makes sense. I have a producer side and a consumer side. Instead of repeating a function call, I want to connect these two components using a stream. I thought I'd need half a stream here and half a stream there. But now I realize I need two whole streams, connect them, put! on one side, take! on the other. I hope it makes sense. Sorry for the noise. Zach On Thursday, August 27, 2015 at 4:13:35 AM UTC-7, Atamert Ölçgen wrote: Hi, AFAIK the only way to create (just) a source (or sink) is: (def my-source (s/source-only (s/stream ...))) This results in creating a stream and then wrapping it with a SourceProxy. We don't keep a reference to the stream and the SourceProxy doesn't allow taking. But if I'm not missing something since SourceProxy keeps a reference of the original stream, there is a sink nobody is using there. If I create a sink separately and connect my-source to it, now my-source would be connected to two sinks. My questions are: 1. Is there another method for creating only sinks or sources? 2. Should the extra/unused source/sink I mentioned above cause concern? PS: I'm not talking about a scenario where we're creating thousands streams and connecting them all like there's no tomorrow. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.
Manifold questions: Creating sinks/sources
Hi, AFAIK the only way to create (just) a source (or sink) is: (def my-source (s/source-only (s/stream ...))) This results in creating a stream and then wrapping it with a SourceProxy. We don't keep a reference to the stream and the SourceProxy doesn't allow taking. But if I'm not missing something since SourceProxy keeps a reference of the original stream, there is a sink nobody is using there. If I create a sink separately and connect my-source to it, now my-source would be connected to two sinks. My questions are: 1. Is there another method for creating only sinks or sources? 2. Should the extra/unused source/sink I mentioned above cause concern? PS: I'm not talking about a scenario where we're creating thousands streams and connecting them all like there's no tomorrow. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: I am looking for xml parsing lib
Just a general note: if a library is not updated for X months/years, it doesn't necessarily mean it's obsolete/totally useless. I sometimes do this myself too, but I've recently found a library that hasn't been updated for a looong time and it works perfectly fine. On Tue, Aug 25, 2015 at 11:31 AM, Josh Kamau joshnet2...@gmail.com wrote: Thanks all. clojure.xml/parse worked for me. On Tue, Aug 25, 2015 at 1:52 AM, Jordan Schatz jor...@noionlabs.com wrote: Which is the recommended xml parsing lib for clojure? I think you are after clojure.xml/parse http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.xml/parse/ and friends: http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.core/xml-seq/ http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.zip/xml-zip/ - Jordan On Mon, Aug 24, 2015 at 12:50 PM, blake watson dsblakewat...@gmail.com wrote: I believe that's it, though. On Mon, Aug 24, 2015 at 10:48 AM, Josh Kamau joshnet2...@gmail.com wrote: Hello; Which is the recommended xml parsing lib for clojure? clojure.data.xml was last updated 10months ago and is still on version 0.0.8 Thanks Josh -- 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 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] io.aviso/rook 0.1.36
Hi Howard, In the example application it seems the routing information is encoded in the beginning of the docstring and not the actual metadata. Is there an option to put this info in the metadata of the var? On Mon, Aug 24, 2015 at 6:31 PM, Howard Lewis Ship hls...@gmail.com wrote: Rook is a set of middleware and handlers to enable metadata-based routing for Ring web applications. The intention is to expose a Clojure namespace as a web service resource; there’s a default mapping of HTTP verbs and paths to function names; these can be extended or overridden by metadata on the functions in the namespace. The end result is that a compliant web service resource can be created in very little code. Rook also supports Swagger 2.0: a detailed JSON description of your web service is generated directly from the functions and metadata. Recent changes: * Described more of the APIs using Prismatic Schema * Added ability to reuse the argument resolution logic outside of endpoint functions * Many improvements to the Swagger 2.0 description support https://github.com/AvisoNovate/rook -- Howard M. Lewis Ship Looking for Clojure engagements: coding, architecture, mentoring more! Creator of Apache Tapestry (971) 678-5210 http://howardlewisship.com @hlship -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Unable to write GPL software with clojure?
Hi Sean, On Thu, Aug 20, 2015 at 8:20 PM, Sean Corfield s...@corfield.org wrote: Atamert Ölçgen said on August 20, 2015 at 8:51 AM: If you modify this Program, or any covered work, by linking or combining it with clojure (or a modified version of that library), containing parts covered by the terms of EPL, the licensors of this Program grant you additional permission to convey the resulting work. Would you expect that to be read as just the Clojure JAR (which contains the Clojure compiler itself as well as a number of standard namespaces), or would you expect that to include the Contrib JAR libraries as well? Or, further, any other Clojure libraries released under the EPL? If you are saying what clojure there means is unclear, I agree with that. And I would like to work towards fixing it. I think, at the time I created this, my intent was just Clojure distribution (sans contrib) since clecs only depends on that. But now I realize a game made with clecs can depend on other libraries as well and this clause perhaps also need to cover them. I think the is the core issue of the confusion: what is Clojure for the purpose of any such license exclusions? Corresponding source for a non-source form of such a combination shall include the source code for the parts of clojure used as well as that of the covered work. Are you saying that the whole of the EPL-licensed Clojure source, for a specific version of Clojure used in the combined work, should be physically included into the source overall for the combined work? I.e., that any game built with clecs and distributed in source form would have to include the GitHub repos of any/all Clojure libraries used? *[I believe it’s reasonable to say this — I just wanted to check this was your intent]* If it included clecs' source and the game's source it would be enough for me. I wouldn't want to dictate terms for other people's code. If another library the game depends on is also GPL, it's source should be included as well. But that's because of the other author's licensing. If that library has a license that doesn't require source distribution, who am I to ask for that. Not directly related to licensing but my main intent is to get people to write games and share them. Not necessarily as a commercial activity but game development for game development's sake. Commercial side is IMO already covered well. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Unable to write GPL software with clojure?
On Wed, Aug 19, 2015 at 1:05 AM, Sean Corfield s...@corfield.org wrote: On 8/18/15, 2:24 PM, Kyle Sexton clojure@googlegroups.com on behalf of k...@mocker.org wrote: Can anyone weigh in on whether it is possible to write GPL code with clojure? Seen some recent[1] tweets saying that the EPL on clojure core prevents writing GPL code with clojure. You cannot write an application that is GPL and released as a standalone program with EPL libraries embedded: https://eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE Based upon the position http://www.fsf.org/licensing/licenses/ of the Free Software Foundation, you may not combine EPL and GPL code in any scenario where linking exists between code made available under those licenses. The above applies to both GPL version 2 and GPL version 3. https://www.fsf.org/blogs/licensing/using-the-gpl-for-eclipse-plug-ins However, developers who want to release GPL-covered plug-ins for Eclipse can address this issue by providing an additional permission with their license http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs that grants users permission to combine their work with Eclipse in this way. In other words, while you can’t write standalone GPL software using EPL libraries, you could provide just your (Clojure) software under a modified GPL that would allow end users to then combine it with the (EPL) libraries it needs to make a complete piece of software — but that wouldn’t be very convenient for your users. I have added this extra clause to clecs' LICENSE https://github.com/muhuk/clecs/blob/master/LICENSE: If you modify this Program, or any covered work, by linking or combining it with clojure (or a modified version of that library), containing parts covered by the terms of EPL, the licensors of this Program grant you additional permission to convey the resulting work. Corresponding source for a non-source form of such a combination shall include the source code for the parts of clojure used as well as that of the covered work. To my understanding a game can be written with clecs Clojure provided that it's distributed with GPL. Any other non-GPL clojure library cannot be included in the distribution though, as far as I can understand. It would be cool it would automatically work. This is part of why some people consider GPL to be a viral license and why many companies will not use GPL software: it taints everything it touches and requires the whole thing to be GPL. Proponents of GPL will argue a different position (so, be careful, this is almost a religious issue on both sides). Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Hashing With Consistent Results
Hi Christian,
hasch looks nice, I might end up just using it. I will be hashing smaller
collections
(maps where keys are keywords and values are atomic data like integers).
Collisions BTW are not such a big deal for my use case. I will have a
limited number
of fragments (buckets, index pages, etc.) anyway. 65536 of them perhaps.
The more
I think about the problem the more I realize I am implementing some sort of
hash map.
On Mon, Aug 10, 2015 at 3:49 PM, Christian Weilbach
whitesp...@polyc0l0r.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I am the author of https://github.com/whilo/hasch
Would calling hasch.core/edn-hash satisfy your performance
requirements? I tried hard to make the recursion of the protocol
performant, but hashing a value is slower than the time needed to
write the data to disk for big collections. You should pick a faster
message-digest like you suggested, e.g. MD5:
(defn ^MessageDigest md5-message-digest []
(MessageDigest/getInstance md5))
(edn-hash {:foo Bar :baz 5} md5-message-digest)
You can use the criterium benchmarking snippets in platform.clj to do
benchmarks. Object.hashCode() is a lot faster still and caches the
result, I am not sure how much overhead the protocol dispatch causes.
Note that if some collisions are ok for you, you might find a better
tradeoff, since atm. commutative collections like maps and sets are
hashed key-value wise and then XOR'd for safety. I am interested in
your findings and decision, especially if you pick something else.
Christian
On 10.08.2015 09:00, Atamert Ölçgen wrote:
Hi,
I need a way to reduce a compound value, say {:foo bar}, into a
number (like 693d9a0698aff95c in hex). I don't necessarily need a
very large hash space, 7 hex digits is good enough for my purposes.
But I need this hash to be consistent between runs and JVM versions
etc. So I guess that rules out standard object hashes.
I would like to find a sufficiently fast way to do this. I can live
with MD5, but are there faster alternatives (but produce smaller
hashes)? ( clj-digest https://github.com/tebeka/clj-digest
provides a nice interface to what Java provides but there are only
usual suspects AFAICS
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#MessageDigest
)
I will be dealing with unordered collections, but it seems hashing
is consistent when the input order is changed:
user= (.hashCode {:foo Bar :baz 5}) 2040536238 user= (.hashCode
{:baz 5 :foo Bar}) 2040536238
(It even gave the same hash code in different runs.)
I will use these hashes to build index tables. My data, that
contains these things I hash is a set. I will store this as an
ordered set and keep an index pointing to where records from this
hash to that hash lives. This is all Clojure, but I can't keep all
my data in memory. (So Clojure's persistent data structures is out
of the picture. life would've been much simpler if I could.)
Thanks for reading. Any insight is appreciated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJVyJ3vAAoJEKel+aujRZMkbhMIAJ61DGUWM9JoN/JcIxvh2Jph
VohlWbr1yw69D+x4guGOk5AXUh7HMAkmlbuc+YRRnYqGhZtc3r/6C/d/aa5faBAh
NdIeDa8yNHTAuYERDktfviy+q5a/blJRdvIIe7ntyjpDZyd2gD1AwUGYOKctXipS
wMPan7v7yPfPlFfnl+VVXfP8yx/LWyZbwfu0Ugv2B2NhvqPMu8joyondOz7GPcLd
P7EgpIrvfQAElA4c4+UB0BEeJkn+fnpYF3QLJIy5oQny5QwbVtxgVuUNES8EolYl
HkpFY1ECV/M65fvP6wrcYPihuphSYQoPkfY4ZQfzWCq9mo+3Aj1Jq2u7QfG9HxM=
=1UE6
-END PGP SIGNATURE-
--
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.
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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
Hashing With Consistent Results
Hi,
I need a way to reduce a compound value, say {:foo bar}, into a number
(like 693d9a0698aff95c in hex). I don't necessarily need a very large hash
space, 7 hex digits is good enough for my purposes. But I need
this hash to be consistent between runs and JVM versions etc. So I guess
that rules out standard object hashes.
I would like to find a sufficiently fast way to do this. I can live with
MD5, but are there faster alternatives (but produce smaller hashes)? (
clj-digest https://github.com/tebeka/clj-digest provides a nice interface
to what Java provides but there are only usual suspects AFAICS
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#MessageDigest
)
I will be dealing with unordered collections, but it seems hashing is
consistent when the input order is changed:
user= (.hashCode {:foo Bar :baz 5})
2040536238
user= (.hashCode {:baz 5 :foo Bar})
2040536238
(It even gave the same hash code in different runs.)
I will use these hashes to build index tables. My data, that contains these
things I hash is a set. I will store this as an ordered set and keep an
index pointing to where records from this hash to that hash lives. This is
all Clojure, but I can't keep all my data in memory. (So Clojure's
persistent data structures is out of the picture. life would've been much
simpler if I could.)
Thanks for reading. Any insight is appreciated.
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: Manifold streams/deferreds raising errors downstream of a sink
Hi Andy, I would provide a function that wraps put!. It would still return a deferred, but not the result of put!. It would create a deferred, representing the result of the computation and pass it down the stream together with the input. Consumers would set its value once the computation is done. I am actually using this technique in a couple of projects and very happy with it. On Mon, Aug 10, 2015 at 7:13 AM, Andy Chambers achambers.h...@gmail.com wrote: Hey All, I'm trying to build a library that exposes manifold streams for data producing applications. The intention would be for these apps to s/put! to a sink stream returned by the producer function. However, I need to take the value that is put in and pipe it into some other function before I know whether there is an error and if there is an error, I'd like to propagate it back to the caller. I understand that the value returned by put! is a deferred, and how to set the error state of a deferred but I don't understand how I can arrange for the deferred to be manipulated downstream of where it has been taken off the stream. (defn producer [] (let [in (s/stream)] (s/consume (fn [msg] (d/future (prn oops, going to error now) (throw (Exception. (str msg) in) in)) @(s/put! (producer) 42) As written, you get a success response even though an exception was triggered by the function that consumes the in stream. Is it possible to re-write this so that the exception bubbles up to where the put! is deref'd? 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: (fail promise exception)
Hi William, Manifold deferreds can capture exceptions like future does. http://aleph.io/manifold/deferreds.html On Sat, Aug 8, 2015 at 12:44 AM, William la Forge laforg...@gmail.com wrote: Still a newbie here, about to release my first Clojure project. But that clojure blob will take some digging on my part. I use a gummed up dereference function that checks for Throwable in the meantime. My goal right now is to become a Dtomic freelancer. So much to learn! Which is why I'm doing projects. Only way I know to become proficient! So yeah, I need to get to the point where I can roll my own. Similarly, my first project builds on the send method, but I really need to get to the point where I can roll my own agent. In any case, thanks Francis. I can only promise more dumb questions in the future. ;-) On Friday, August 7, 2015 at 5:24:24 PM UTC-4, Francis Avila wrote: Huh, I was sure I had done this before, but I misremembered, I was using my own promise that rethrew Throwable instances on deref (and it was in clojurescript!) Clojure promises have no notion of failure, only realized/not-realized. You need to deliver a sentinel type or value and check for it on deref, or implement your own promise type which does it for you. (It's not that hard: https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L6803 ) On Friday, August 7, 2015 at 4:09:39 PM UTC-5, William la Forge wrote: Sorry, I meant to ask how to fail with a promise? It seems that there is no fail method. On Friday, August 7, 2015 at 4:52:47 PM UTC-4, Francis Avila wrote: Futures automatically capture exceptions raised in their bodies and reraise them when the future is derefed. Promises also throw exceptions when derefed. Unlike promises, futures are created with the code that delivers their value, so calling fail and deliver explicitly on a future makes no sense. Think of futures as a thin wrapper around a promise which spawns a thread, runs the code, and to the wrapped promise either delivers the result of the code or calls (fail private-promise raised-exception) for you. On Friday, August 7, 2015 at 2:14:30 PM UTC-5, William la Forge wrote: A future fails when it throws an exception. How to do that with a future? It looks like (fail future exception) does not do the trick: http://dev.clojure.org/display/design/Promises -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] stateful-check 0.3.0 - test stateful systems with test.check
Hi Carlo,
This is an awesome lib. Thanks for sharing.
README mentions the queue example and goes directly into details. I would
inline the queue example and maybe move the Specifications section into a
different file.
On Fri, Jul 31, 2015 at 7:05 AM, Carlo Zancanaro carlozancan...@gmail.com
wrote:
Hey everyone!
I've just released a new version of my library for testing stateful
systems with test.check!
[org.clojars.czan/stateful-check 0.3.0]
https://github.com/czan/stateful-check
https://clojars.org/org.clojars.czan/stateful-check
Important changes in this version:
+ Updated to test.check 0.7.0
+ *Breaking: *Postconditions now take two states: the prior and the
next states. This means that any postconditions being used with 0.2.0 need
to be changed:
(fn [state args result]
arbitrary-logic-for-postcondition)
;; needs to change to
(fn [prev-state next-state args result]
arbitrary-logic-for-postcondition)
+ *Breaking: *The old `reality-matches-model?` function has been both
renamed (to remove the '?', which implied it was a predicate when it's not)
and deprecated. The `specification-correct?` form below is the preferred
form now.
+ Add a new function, `specification-correct?`, which runs a
stateful-test specification using test.check. If used within a clojure.test
`is` assertion it will also print helpful output:
(is (specification-correct? queue-spec {:seed 1417059242645}))
;;
;; FAIL in clojure.lang.PersistentList$EmptyList@1
(form-init1067629020891437332.clj:1)
;;#0 = (:new) = #Atom@53df198e: #PersistentQueue
clojure.lang.PersistentQueue@1
;;#2 = (:push #0 0) = nil
;;#3 = (:pop #0)= #PersistentQueue
clojure.lang.PersistentQueue@1
;; Error while checking postcondition
;; Seed: 1417059242645
;;
;; expected: :pass
;; actual: :fail
I hope somebody finds this useful!
Carlo
--
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.
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
On Tue, Jun 23, 2015 at 11:47 PM, James Henderson ja...@jarohen.me.uk
wrote:
Hi Atamert - thanks :)
I thought it might be preferable to keep the call to (latch)explicit - it
means that ylet can be used in nested calls, too - for example, to set up
and compose groups of components/sub-systems: (contrived example, though!)
;; (docs for ylet at https://github.com/james-henderson/yoyo#introducing-ylet
)
(require '[yoyo :refer [ylet]])
(defn with-connections [config f]
(ylet [db-pool (with-db-pool (:db config))
es-conn (with-es-connection (:elasticsearch config))]
(f {:db-pool db-pool
:es-conn es-conn})))
(defn make-system [latch]
(let [config ...]
(ylet [connections (with-connections system)
_ (with-webserver {:handler (make-handler (merge connections
{:config config}))
:port 3000})]
(latch
How would you see the with-* functions working, btw?
I think the general idea should be to provide a clean API to the consumer
(of your lib). Perhaps something that accepts a start function, a stop
function and some sort of main loop (f in your example).
Cheers,
James
On Tuesday, 23 June 2015 09:57:16 UTC+1, Atamert Ölçgen wrote:
Hi James,
Interesting idea. Thanks for sharing.
I think you can simplify this:
(yoyo/run-system!
(fn [latch]
(ylet [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server (with-web-server server-opts)]
(do-this web-server)
(do-that db-pool web-server)
(latch
to:
(yoyo/foo! [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server (with-web-server server-opts)]
(do-this web-server)
(do-that db-pool web-server))
I believe with-* function can also be simplified further.
On Tue, Jun 23, 2015 at 1:18 AM, James Henderson ja...@jarohen.me.uk
wrote:
Hi all,
I've just released an early version of 'Yo-yo', a protocol-less,
function composition-based alternative to Component. It's still in its
early stages, so feedback would be very much appreciated!
https://github.com/james-henderson/yoyo
Yo-yo was also an experiment to see what could be de-coupled from the
concept of 'reloadable systems', so you won't find any configuration,
dependency injection, etc - just a way to write a system that can be easily
started, stopped, and reloaded.
Fundamentally, we start by assuming there's a function available that
only returns 'when the system stops' - a 'latch', say. If we had such a
function, we could start our system, call that function, then stop the
system (closing any necessary resources). A database pool, for example,
might look like this:
(defn with-db-pool [db-config f]
(let [db-pool (start-pool! db-config)]
(try
(f db-pool)
(finally
(stop-pool! db-pool)
Here, we're assuming that we'll be passed 'f', the 'latch' function. A
web server would be similar, and, because they're both functions, they're
very simple to compose:
(with-db-pool {...}
(fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool})
:port ...}
(fn [web-server]
;; TODO: Ah. We've run out of turtles. :(
This is where Yo-yo comes in - there’s a function called run-system!,
which takes a function that accepts a latch:
(:require [yoyo])
(yoyo/run-system!
(fn [latch]
(with-db-pool {...}
(fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool}) ; n.b.
we have access to the db-pool here - no need for global state!
:port ...}
(fn [web-server]
(latch))) ; Aha!
run-system! then returns a promise - deliver any value to it, and it'll
stop the system.
And that's pretty much it! There are a few more functions - mostly to do
with easily starting/stopping/reloading a system through the REPL, and a
macro to simplify the 'function staircase' - these are covered in more
detail in the README. There are some also common components - a database
pool, a web server, and a simple integration for existing Component systems.
It'd be great to hear your thoughts/ideas, whatever they may be - either
through here, e-mail, Github, or Twitter - thanks!
James
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You
[ANN] aleph-middleware: Ring middleware that support deferred responses.
Hi, https://github.com/muhuk/aleph-middleware This is library that provides deferred-friendly versions of some of the middleware that's shipped with ring-core. Specifically ones that modify responses. They were choking on deferred's so I had to modify them a bit. Let me know if it's useful. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Writing REST api the right way
On Tue, Jun 23, 2015 at 11:19 AM, Mike Grabowski grab...@gmail.com wrote: Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) It would be really cool if documentation could be generated from Liberator resource defs (http://clojure-liberator.github.io/). Maybe it's possible right now and I don't know about it. 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
Hi James,
Interesting idea. Thanks for sharing.
I think you can simplify this:
(yoyo/run-system!
(fn [latch]
(ylet [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server (with-web-server server-opts)]
(do-this web-server)
(do-that db-pool web-server)
(latch
to:
(yoyo/foo! [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server (with-web-server server-opts)]
(do-this web-server)
(do-that db-pool web-server))
I believe with-* function can also be simplified further.
On Tue, Jun 23, 2015 at 1:18 AM, James Henderson ja...@jarohen.me.uk
wrote:
Hi all,
I've just released an early version of 'Yo-yo', a protocol-less, function
composition-based alternative to Component. It's still in its early stages,
so feedback would be very much appreciated!
https://github.com/james-henderson/yoyo
Yo-yo was also an experiment to see what could be de-coupled from the
concept of 'reloadable systems', so you won't find any configuration,
dependency injection, etc - just a way to write a system that can be easily
started, stopped, and reloaded.
Fundamentally, we start by assuming there's a function available that only
returns 'when the system stops' - a 'latch', say. If we had such a
function, we could start our system, call that function, then stop the
system (closing any necessary resources). A database pool, for example,
might look like this:
(defn with-db-pool [db-config f]
(let [db-pool (start-pool! db-config)]
(try
(f db-pool)
(finally
(stop-pool! db-pool)
Here, we're assuming that we'll be passed 'f', the 'latch' function. A
web server would be similar, and, because they're both functions, they're
very simple to compose:
(with-db-pool {...}
(fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool})
:port ...}
(fn [web-server]
;; TODO: Ah. We've run out of turtles. :(
This is where Yo-yo comes in - there’s a function called run-system!,
which takes a function that accepts a latch:
(:require [yoyo])
(yoyo/run-system!
(fn [latch]
(with-db-pool {...}
(fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool}) ; n.b.
we have access to the db-pool here - no need for global state!
:port ...}
(fn [web-server]
(latch))) ; Aha!
run-system! then returns a promise - deliver any value to it, and it'll
stop the system.
And that's pretty much it! There are a few more functions - mostly to do
with easily starting/stopping/reloading a system through the REPL, and a
macro to simplify the 'function staircase' - these are covered in more
detail in the README. There are some also common components - a database
pool, a web server, and a simple integration for existing Component systems.
It'd be great to hear your thoughts/ideas, whatever they may be - either
through here, e-mail, Github, or Twitter - thanks!
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.
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
How is stuartsierra/component OOP when it is building an immutable object graph? (Contrast that to Guava etc.) On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou tao...@gmail.com wrote: hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? You can do that. But it's not a really good idea to have top-level side-effectful code within namespaces. How are you going to test that ns? How will you do (stop)? Namespaces should only define things. because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.
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. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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: Single-atom update ordering guarantees
On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner gardne...@gmail.com wrote: This might be blindingly obvious to some, but I can't find any discussion about it. Let's say I have code like the following: (def a (atom 1)) ... (swap! a inc) (swap! a dec) Is there any possibility of another thread seeing a=0? If not, what provides this guarantee? No. Not if those two swap! calls are made from different threads. -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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] - example : Stop writing unit tests and generate them instead (details inside)
Hi David, How does this integrate prerequisites? Even if my fn is pure, I still mock calls made within. On Mon, Jun 8, 2015 at 5:33 PM, David Sargeant da...@dsargeant.com wrote: Speed up your development cycle using example. Here's the process: 1. Write your test code inline with your functions. 2. Test the output of your functions in the REPL as you code. 3. Generate unit tests when you're satisfied with the behavior of your functions. See https://github.com/dubiousdavid/example for more information. -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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] - example : Stop writing unit tests and generate them instead (details inside)
Got it. Thanks! On Mon, Jun 8, 2015 at 6:14 PM, David Sargeant da...@dsargeant.com wrote: I'm not totally sure why you would need to use `provided` with pure functions, but that is definitely not in scope for this project. example isn't meant to replace all cases where you would write tests. It's designed to streamline the creation of a certain class of tests that come with a lot of unnecessary manual work. -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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] - example : Stop writing unit tests and generate them instead (details inside)
I meant (provided), (against-background), etc. On Mon, Jun 8, 2015 at 6:02 PM, David Sargeant da...@dsargeant.com wrote: If I need something more complicated in terms of testing my functions I usually create a file dev/examples.clj and add dev to the source-paths in my project's dev profile. I would require the namespace with my functions and put the examples in dev/examples.clj. The rest of the process is the same after that. In addition, I might create dev/generate.clj if I need to pass lot's of arguments to gen-facts/gen-facts-file and wrap calls to those functions in a function (e.g., gen-tests/gen-tests-file). I hope to have examples of these more complicated scenarios in the near future. Suffice to say, this ends up being much faster than any other workflow I've tried. David -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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: Looking for a clojure expert to help fill in a language feature reference
Hi Dan, Who are the people you help understand the tradeoffs and features of technologies? Is this a public project with a public website? On Mon, May 18, 2015 at 11:51 AM, Dan Cancro dan.can...@gmail.com wrote: Hi, I'm not a Clojure user but I maintain a reference to help people understand the tradeoffs and features of technologies. I was hoping someone among you would be interested in helping to contribute some knowledge about it to the project. Click here to see the reference https://docs.google.com/spreadsheets/d/1r8rJy2Q5p5QORYKcye93UECwOlSgFL24c5fyF7dqhaM/edit#gid=1534967054 . It should not take more than a few minutes for someone who knows Clojure well and will really help people understand quickly what it's about and how it's different. If you would like to help out, I've made a questionnaire that should make it a little easier: Click here to complete a short questionnaire about Clojure https://docs.google.com/forms/d/1uq2aavM2JfKkN5Exh15x8WejXoJQNf1rI8MTF62hPQs/viewform I'm sure I've left out a lot of benefits that Clojure delivers. Please let me know about the big things I've missed and I'll add them to the list. Thanks, Dan -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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: Help with async operations
Hi Oleg, On Sun, May 17, 2015 at 6:48 AM, Oleg Dashevskii olegdashevs...@gmail.com wrote: Hi, I’m new to Clojure async operations (while have a good understanding of other things) and want to get a bit of advice. Atoms agents still confuse me. What I’m implementing is a small REST webservice with custom in-memory database. Database is indexed by unique key, basically it’s a map (I’ll denote it as MAP). There are two basic operations: *PUT /api/…/KEY.* Initiate an update for given KEY. The HTTP response should be returned immediately, and the processing should be done asynchronously. The processing consists of downloading a data file from web and doing some data crunching, the result should go into MAP. *GET /api/…/KEY.* Use (get MAP KEY) and request params to generate response synchronously. The tricky part (well, for me :) is that parallel PUT requests should be possible. The downloading and processing can and should go in parallel, independently, whereas updating the MAP should come synchronized, one-after-the-other. How would you implement this? While this can be done with atoms agents, perhaps you should check out core.async or Lamina first. Neither atoms nor agents can be updated in a parallel manner. Only one update runs on a single atom/agent at a given time. If you really need parallelism and the updates affect small parts of MAP, perhaps you can model it using refs, but then it's not one big map anymore. (Still you can't update a single ref in more than one thread at the same time.) You probably also want to control how the files are downloaded and processed, so that there's not duplication of effort. So an event driven solution seems to fit this problem. -- Oleg. -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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: Crazy Need: Embed JavaScript Structure in Clojure
On Tue, Apr 28, 2015 at 10:44 AM, Gary Verhaegen gary.verhae...@gmail.com
wrote:
On 28 April 2015 at 07:39, Atamert Ölçgen mu...@muhuk.com wrote:
Perhaps you can write a function that builds a function somewhere and
then
outputs a string containing JavaScript code that invokes it.
(defn js [ body]
(eval `(defn fn-name# [] ~@body))
(str function() { your.ns. fn-name# (); }))
If the goal is to send this code to a database to be evaluated there,
I do not think this would work, as the function is only defined within
Clojure.
You are right. Now that I've read OP more carefully; I think exploring your
idea is really worth it, since it would allow the consumers of this library
to
write their transactions in ClojureScript instead of JavaScript.
@OP: as you admit that this is a crazy need, here is a crazy solution:
use the ClojureScript compiler directly within your Clojure code. I'm
not familiar with it at all; after a quick glance at the Himera source
code, here is a proof of concept:
--
$ lein try org.clojure/clojurescript 0.0-3211
nREPL server started on port 52299 on host 127.0.0.1 - nrepl://
127.0.0.1:52299
REPL-y 0.3.5, nREPL 0.2.6
Clojure 1.6.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_25-b17
Docs: (doc function-name-here)
(find-doc part-of-name-here)
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
user= (require '[cljs.compiler :as comp])
nil
user= (require '[cljs.analyzer :as ana])
nil
user= (comp/emit-str (ana/analyze {:uses #{'cljs.core}} '(fn []
(js/alert hello
(function (){\nreturn alert(\hello\);\n});\n
user=
--
The first argument to analyze is the environment; you'll probably have
to dig a little deeper into the ClojureScript compiler to decide what
to pass there. This should allow you to create a macro that let you
write ClojureScript code directly:
{:some-key :some-value,
:action (js-macro (fn []
(js/console.log pretty crappy transaction)
(js/console.log another line)))}
--
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.
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
www.olcgen.com
--
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: Crazy Need: Embed JavaScript Structure in Clojure
Hi JPatrick,
On Mon, Apr 27, 2015 at 11:50 PM, JPatrick Davenport virmu...@gmail.com
wrote:
Hello,
So just to get it out: I do not want to evaluate the JavaScript, simply
preserve it.
I'm working on an ArangoDB driver. Part of the wonder that is ArangoDB is
its ability to support transactions. This is done using JSON. Part of the
REST object for a transaction is what I want to do in the transaction. This
is encapsulated in the action attribute of the posted JSON object.
Here's an example
{...JSON configuration
action: function (){many lines of stuff here,
More JSON configuration}
Now the way that this works in node is by converting the function into a
String. I didn't know that String(function () {..valid JavaScript...})
would kick out a string version of the function. Pretty neat.
I want to do the same thing with Clojure. I presently take a map with one
of the attributes of :action. I want something like this.
{:some-key :some-value,
:action (js-macro function(){
console.log(pretty crappy transaction);
console.log(another line);
})}
On the other side of the macro I want to get function() {\t\t\t\n
console.log(\pretty crappy transaction\;\n\t\t\tconsole.log(\another
line\);\n} or there about.
I've got
(defmacro js [ js-fun]
(let [body (str js-fun)]
(subs body 1 (- (count body) 1
That gets the idea. Unfortunately, I loose the ; as well as the new
lines.
Your macro thinks it receives the code as a string, but Clojure macros
receive their parameters as s-expressions. Just like functions, with the
only difference functions' params are evaluated.
I'm pretty sure I don't *need* this macro. I can probably get away with
function () {
console.log('println');
}, but I feel like this would make the code nicer.
Perhaps you can write a function that builds a function somewhere and then
outputs a string containing JavaScript code that invokes it.
(defn js [ body]
(eval `(defn fn-name# [] ~@body))
(str function() { your.ns. fn-name# (); }))
(I didn't test the code, it's just to give you an idea.)
Thanks,
JPD
--
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.
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
www.olcgen.com
--
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: Meaning of part of the doc string for `ns-resolve`
This fails: (ns-resolve 'sumtin 'clecs.world/remove-entity) Exception No namespace: sumtin found clojure.core/the-ns (core.clj:3830) But this succeeds: (ns-resolve 'seesaw.core 'clecs.world/remove-entity) #'clecs.world/remove-entity It seems when the 2nd argument is fully qualified, first argument is not important but it still needs to be a valid namespace. On Fri, Apr 24, 2015 at 1:43 AM, Brian Marick mar...@exampler.com wrote: The last sentence of the `ns-resolve` documentation reads: Note that if the symbol is fully qualified, the var/Class to which it resolves need not be present in the namespace. What does that mean? I would expect something like the following to produce a non-nil value: user= (ns-resolve 'clojure.core 'fofofof) user= (ns-resolve 'clojure.core 'clojure.core/fofofof) user= (ns-resolve *ns* 'clojure.core/fofofof) ... to produce a non-nil value, but they're all nil. (Note: in the 1.6 API, it looks to me like the only other uses of fully qualified refer to classes.) -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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] ednsl-0.2.0: a super-simple DSL for building DSLs
Hi James,
Interesting library. I have a few comments on the readme.
The simple example is not so simple:
(ns my.app
(:use [ednsl]))
(defn main [ args]
(let [r (- config-file.edn read-file ctx-form
(= emap (eithery (etuple ekey (eor (- esym eload-sym)
eany)
{:keys [main args]} r]
(apply main args)))
(defn real-main [ args]
;; Do something useful!
(prn args))
The calculation of r is supposed to demonstrate what this library does, but
a potential user will have no idea what any of those supposed to do.
Perhaps loosening the code and adding some comments that explain what's
going on there can help adoption.
I think main should do (apply real-main args), otherwise infinite recursion.
Codox docs are in the 'doc' directory or can be read on github. They
contain a good walkthrough.
github link here goes to your user page.
On Fri, Apr 3, 2015 at 5:43 PM, James Laver james.la...@gmail.com wrote:
It’s not quite as stupid as it sounds and it’s mostly the result of
factoring out the config handling code from oolong[1]
https://github.com/jjl/ednsl/
https://clojars.org/ednsl
Happy hacking!
James
[1] https://github.com/jjl/oolong/
--
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.
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
www.olcgen.com
--
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 test multiple implementations of a protocol?
Hi Leif, What does this answer fail to address? http://stackoverflow.com/a/16579272/42188 On Wed, Mar 25, 2015 at 3:40 AM, Leif leif.poor...@gmail.com wrote: If I have a protocol that supposedly satisfies some constraints, and multiple implementations that supposedly implement the protocol, what is the best way to test them all? A minimal example is here: https://gist.github.com/leifp/bf5c74eea98026329a76 This question on SO is basically the same as mine, but the answer seems less than ideal to me: http://stackoverflow.com/questions/16578882/testing-to-the-interface-in-clojure In my mind, the ideal solution lets you: * See the failing implementation in the test output * Don't repeat yourself I'm surprised that this isn't well-trodden ground, given the amount of people using Components to organize their apps, but I can't find any examples. Perhaps I am just failing to use the internet properly. Thanks, Leif -- 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. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] clecs 2.0.0
clecs is an entity component system library. Repo is here: https://github.com/muhuk/clecs API documentation is here: http://clecs.muhuk.com/2.0.x/api/ Changelog is here: http://clecs.muhuk.com/2.0.x/user_guide/#_changelog This version comes with some major changes which will hopefully make working with clecs easier. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Is this the good way to write get-percentage
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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: OO Programmer trying to move to Clojure: Namespace Organization
Hi Dru, I find it easier to organize things when I follow TDD. It's easier for me to spot something is in the wrong place (module or maybe as a responsibility of a function) by looking at the tests. (This is true for any language I work with.) http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd On Sat, Feb 7, 2015 at 6:23 PM, Dru Sellers d...@drusellers.com wrote: Greetings, I am trying to convert my mind from OO (C#) to one more functionally friendly. I am increasingly comfortable with simple applications in clojure, but as I start to build more complex applications, I start to fall down about how to structure my application. I don't want to just shove OO ideas into the functional nature of Clojure. I'm looking for any help someone can provide to help shimmy my brain into the right mental patterns. Background: Long time C# developer who leans heavily on IoC / DI / Interfaces / Testing / Object Encapsulation. Specific Questions: Namespace Organization Now I know this is almost entirely personal preference, but I'm playing with a namespace model that looks like this and I'd love some feed back. Tear it about, bust that red pen out and help me to better think of things in clojure way. I only have my C# / OO background to lean on and need some fresh brain juice. :) I currently organize my projects like this. a spin off of 'duct' https://github.com/weavejester/duct but i'm looking for a bit more detail. Context: Project name is going to be ford, feature is going to be a simple log of text ~/ src/ ford/ - the project log/ - the feature name http.clj - contains clojure routes at 'http/routes' - orchestrate the business calls model.clj - contains my 'defrecords' / yesql / db calls core.clj - the business calls I def have a preference for shorter files rather than longer files I also tend to have a heavy use of 'ceremony' - right now I need a lot of structure because I'm still learning to think in terms of clojure. and I spend a lot of time still reading it rather than thinking about it. Again, thank you. -d -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: micrologic - A tiny, literate implementation of miniKanren/core.logic
This is fantastic! Thanks a lot. On Thu, Jan 8, 2015 at 9:26 PM, David Nolen dnolen.li...@gmail.com wrote: Nothing to add other than this is really cool. David On Thu, Jan 8, 2015 at 1:56 PM, Russell Mull russell.m...@gmail.com wrote: Hi fellow Clojurists, I've been working on a small miniKanren in Clojure. It started as a port of https://github.com/jasonhemann/microKanren. But this one is interesting because: - It's a literate program, with far more description and examples than actual code. - Many names have been changed to be more descriptive than that which is found in the literature, at least to my eye. - It's written in idiomatic Clojure. It should be a good introduction to the way miniKanren and core.logic work, especially if you're more software engineer than computer scientist. Is this useful, confusing? Wrong in places? please let me know if you have any feedback! http://mullr.github.io/micrologic/literate.html Cheers, Russell -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] co-dependency in stuartsierra/component
Hi Juan, I thought co-dependencies ought to be designed out. Could you give a use case for co-dependency? On Tue, Dec 2, 2014 at 7:16 PM, JUAN ANTONIO Ruz juanantonio...@gmail.com wrote: *co-dependency* is a library that lets you use *cyclic* dependencies in stuartsierra/component systems In other words, :a depends-on :b, :b (co-)depends-on :a Although I used cyclic word, this co-dependency library is designed on the idea that components don't need co-dependencies to start as normal dependencies. co-dependency follows the pattern described in stuartsierra/component#customization https://github.com/stuartsierra/component#customization to accomplish this cyclic feature You can find all the details about this lib on https://github.com/tangrammer/co-dependency -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] co-dependency in stuartsierra/component
Thanks for the explanation. Yes, it makes sense. Without this library I would do something similar myself. You are using deref (pragmatic clojure) and the relationship is explicit (in system map), both are advantages. It is possible to design around it though; separate the common parts, say the container of webservices in your first example (as :c) and then make both :a and :b depend on :c, and :b to depend on :a too for instance. A component doesn't have to be immutable, or has to be initialized all at once (during start). I imagine it can have other life-cycle event and change its state. Anyways I see myself as a potential user of your library. I'm just sharing my thoughts. On Tue, Dec 2, 2014 at 8:33 PM, JUAN ANTONIO Ruz juanantonio...@gmail.com wrote: Hi Atamert, I realised too the discouraged note https://github.com/stuartsierra/component#disadvantages-of-the-component-model about cyclic dependencies but although your closed parent-child component relations is logically perfect on start your system, when system is ready to work it's very useful to open the door to child-parent relation too, so the child component can communicate with parent component. Here a couple of examples that you could find this reverse relation: * routing (router and webservices). webservice could need to know which other webservices are connected to its parent router to construct urls ( modular/bidi https://github.com/juxt/modular/tree/master/modules/bidi) * templating (menu and menu-items). Menu-items could need to know which others menu-items are used/displayed on the menu component to adapt their renderer Does this explanation make sense to you? Thanks for reviewing Juan El martes, 2 de diciembre de 2014 12:55:42 UTC+1, Atamert Ölçgen escribió: Hi Juan, I thought co-dependencies ought to be designed out. Could you give a use case for co-dependency? On Tue, Dec 2, 2014 at 7:16 PM, JUAN ANTONIO Ruz juanant...@gmail.com wrote: *co-dependency* is a library that lets you use *cyclic* dependencies in stuartsierra/component systems In other words, :a depends-on :b, :b (co-)depends-on :a Although I used cyclic word, this co-dependency library is designed on the idea that components don't need co-dependencies to start as normal dependencies. co-dependency follows the pattern described in stuartsierra/component# customization https://github.com/stuartsierra/component#customization to accomplish this cyclic feature You can find all the details about this lib on https://github.com/ tangrammer/co-dependency -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Richelieu: a library for advising functions
Just a small suggestion; I would make :unadvisable namespaced since it's richelieu specific. On Wed, Dec 3, 2014 at 6:01 AM, Gary Verhaegen gary.verhae...@gmail.com wrote: At a very superficial glance, it looks like dire also sort of fits into the same space: https://github.com/MichaelDrogalis/dire On Tuesday, 2 December 2014, Edwin Watkeys e...@poseur.com wrote: Phillip, Of Robert Hooke's features, I think the ability to suppress advice temporarily (its `with-hooks-disabled`) as well to advise a function within a particular dynamic scope (`with-scope`) are most relevant to Richelieu. Since one of the major goals of Richelieu is to serve as a generic basis for advising, I'll probably implement a `with-advice-disabled` form that takes a sequence of advisedf-and-advicef-set values to temporarily suppress. R.H. and Richelieu, while they do much the same thing, seem to be orthogonal to each other in terms of intent: Richelieu exists to allow folks to write arbitrary advice-based facilities that are oblivious to each others' existences, decorating functions that weren't written with being advised in mind—think tracing and profiling. Phil, on the other hand, focused on providing a facility for developers who anticipate that their code might be advised à la the Emacs hooks mechanism. Or not. I'm totally speculating. As for the name, I guess I'm willing to overlook some semantic quibbles—especially since something very similar to Emacs's normal hooks could easily built atop R.H.—in pursuit of a charming allusion. Edwin On Tuesday, December 2, 2014 8:39:37 AM UTC-5, Phillip Lord wrote: I think yours might be nicer, to be honest, though, although Robert Hooke has some features yours doesn't. Advising entire namespaces is an interesting addition for sure. I still don't understand why Robert Hooke has this name though. I can't have been the only person expecting it to implements hooks. Phil Edwin Watkeys e...@poseur.com writes: Phillip, I’d cry if it weren’t so funny; I’ve just begun to make my way through the lastest Read Eval Print λove and the first page or two dwells on reinvention. At least mine wasn’t intentional. Edwin -- Phillip Lord, Phone: +44 (0) 191 208 7827 Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk School of Computing Science,http://homepages.cs.ncl.ac. uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] silc - a tiny entity database for clojure (games)
This is a very nice example of abstraction. Using a hash-map is just an implementation detail. However I'd be very interested to hear if there are any other compelling use cases for this. Sparsely populated tables, unstructured anything... We used an EAV abstraction (over SQL) to build a product database. Different product types have very different fields, even same types of product might have different fields sometimes. In hindsight normalized relational tables would have been a better fit (the decision was made before I joined). In your README, the change and delete examples give the impression that they're mutating the db, but they actually return an updated db if I'm not mistaken. On Wed, Dec 3, 2014 at 6:37 AM, dan.stone16...@gmail.com wrote: I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] silc - a tiny entity database for clojure (games)
Why are you using BigDecimal's for indices? If you want to go big, isn't BigInt a better choice? Actually, I would just use Long's. (MAX_VALUE = 9223372036854775807) On Wed, Dec 3, 2014 at 10:04 AM, Atamert Ölçgen mu...@muhuk.com wrote: This is a very nice example of abstraction. Using a hash-map is just an implementation detail. However I'd be very interested to hear if there are any other compelling use cases for this. Sparsely populated tables, unstructured anything... We used an EAV abstraction (over SQL) to build a product database. Different product types have very different fields, even same types of product might have different fields sometimes. In hindsight normalized relational tables would have been a better fit (the decision was made before I joined). In your README, the change and delete examples give the impression that they're mutating the db, but they actually return an updated db if I'm not mistaken. On Wed, Dec 3, 2014 at 6:37 AM, dan.stone16...@gmail.com wrote: I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] silc - a tiny entity database for clojure (games)
I don't feed trolls. On Wed, Dec 3, 2014 at 10:10 AM, Atamert Ölçgen mu...@muhuk.com wrote: Why are you using BigDecimal's for indices? If you want to go big, isn't BigInt a better choice? Actually, I would just use Long's. (MAX_VALUE = 9223372036854775807) On Wed, Dec 3, 2014 at 10:04 AM, Atamert Ölçgen mu...@muhuk.com wrote: This is a very nice example of abstraction. Using a hash-map is just an implementation detail. However I'd be very interested to hear if there are any other compelling use cases for this. Sparsely populated tables, unstructured anything... We used an EAV abstraction (over SQL) to build a product database. Different product types have very different fields, even same types of product might have different fields sometimes. In hindsight normalized relational tables would have been a better fit (the decision was made before I joined). In your README, the change and delete examples give the impression that they're mutating the db, but they actually return an updated db if I'm not mistaken. On Wed, Dec 3, 2014 at 6:37 AM, dan.stone16...@gmail.com wrote: I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] differ v0.1.0, a tool for creating, and applying, diffs on clojure(script) datastructures
Hi Robin,
Thanks for adding a README. It might contain a couple of errors though.
I can't make sense of this for example:
(def person-map {:name Robin
:age 25
:sex :male})
(def person-diff (differ/diff test-map {:name Robin Heggelund Hansen
:age 26})
;; person-diff will now be [{:name Robin Heggelund Hansen, :age
26};; {:sex 0}]
Where did test-map come from? I'm assuming it's person-map. Why is :sex 0?
Is he fat and bald? If that's a list of keys that's removed, I suggest
using a set there.
(differ/patch {:specie :dog
:sex :female}
person-diff)
;; Will return {:name Robin Heggelund Hansen;; :age
26;; :specie :dog}
Shouldn't the result contain [:sex :female] as well?
On Tue, Nov 18, 2014 at 3:51 AM, Robin Heggelund Hansen
skinney...@gmail.com wrote:
https://github.com/Skinney/differ
I needed a way to send diffs of data from a cljs web-app to a clj backend,
and I found clojure.data/diff to be a pain to work with, so i created my
own solution. It currently only supports maps (and nested maps...), but
support for lists, vectors and sets is on the roadmap for the next version.
This version is mostly for me to test with my own app, which currently only
uses maps.
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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] Counterclockwise User Plugins reloaded
FWIW this sparked my interest to give CCW another try. I suggest everyone to at least take a look at the source of hello world plugin: https://github.com/laurentpetit/ccw-plugin-hello-world/blob/master/hello-world.clj I wanted to see what features of eclipse is exposed, but I couldn't find CCW's API docs hosted anywhere. Instead I've found this: https://github.com/laurentpetit/ccw/blob/ea26df9ff64464c6ed796cc12d60a41be0cd2b6f/ccw.core/src/clj/ccw/eclipse.clj On Fri, Nov 14, 2014 at 5:21 AM, Laurent PETIT laurent.pe...@gmail.com wrote: Hi again, I've published the 'Hello World' of User Plugins project: https://github.com/laurentpetit/ccw-plugin-hello-world The README describes how to install it, and how to live code it. Cheers, -- Laurent 2014-11-13 17:34 GMT+01:00 Laurent PETIT laurent.pe...@gmail.com: Since there has been interest in writing User Plugins this last month, I've decided to be more serious about it. *Counterclockwise User Plugins allow you to customize Counterclockwise / Eclipse with Clojure!!* *User Plugins are...* - *Safe*: plug / unplug user plugins by adding / deleting repos clones from ~/.ccw/ - *Dynamic*: with the help of ccw-plugin-manager, you can open your user plugins as regular Eclipse projects, use the Eclipse embedded REPL to interact with your current environment *live*, as usual with Clojure! - *Powerful*: user plugins are added to Counterclockwise's classpath and can access the same Eclipse services Counterclockwise has access to. - *Agile*: updating a user plugin is as simple as 1. git checkout 2. Alt+U S (re[S]tart plugins) *[ANN] ccw-plugin-manager Plugin* I've created a Github repository for the mother of all CCW User plugins: ccw-plugin-manager. The intent of this plugin is to provide tooling for developing User Plugins ! The plugin is available at Github, with Installation and Usage in the README: https://github.com/laurentpetit/ccw-plugin-manager *Documentation:* User Plugins documentation: http://doc.ccw-ide.org/documentation.html#_user_plugins *More to come:* - ccw-plugin-hello-world: a project for helping get started with User Plugins, showing the basics and explaining the expected workflow. - ccw-plugin-async: a project for connecting to save actions, launch actions, repl interactions, etc. Enjoy! -- Laurent Petit -- Laurent Petit -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Get the value of the persistentArrayMap from the exception which was thrown
It wouldn't matter which map is throwing the exception in this case. It's
an arity issue and maps accept 1 or 2 parameters.
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/APersistentMap.java
If this wasn't REPL, it would result in a larger stacktrace and sufficient
squinting would reveal the line of originating call.
On Thu, Nov 6, 2014 at 3:19 PM, Michael Blume blume.m...@gmail.com wrote:
Well, from the print of the exception, it looks unlikely, but let's look
at the code. This stacktrace says the exception was thrown in line 429 of
clojure.lang.AFn, and I'm going to assume you're using Clojure 1.6.0, so we
want
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/AFn.java#L429
Looking at that line of code, it's creating the exception object using
only the arity (a number) and the name of the class of the object, a
string. So no, the map is not recoverable from the exception.
On Wednesday, November 5, 2014 10:15:50 PM UTC-8, Sunil Nandihalli wrote:
Hi Everybody,
user= ({:a 1})
ArityException Wrong number of args (0) passed to: PersistentArrayMap
clojure.lang.AFn.throwArity (AFn.java:429)
user= *e
#ArityException clojure.lang.ArityException: Wrong number of args (0)
passed to: PersistentArrayMap
From *e is it possible to infer that the object which threw it was {:a 1}?
Thanks,
Sunil.
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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: Deterministic Randomness in Functional Clojure
clojure-lanterna is pretty cool. https://github.com/sjl/clojure-lanterna I'm interested in hearing about alternatives as well. On Wed, Nov 5, 2014 at 4:09 AM, blake dsblakewat...@gmail.com wrote: Pardon my interruption: What are you using for screen output for your roguelike? On Tue, Oct 28, 2014 at 12:08 PM, Isaac Karth isaacka...@gmail.com wrote: I've been working on some projects (roguelikes, story-generators) that often have a reason to have a random outcome for things like procedurally generating a map. Ideally, they would be deterministically psuduorandom, so that I can generate the same results from the same seed. The part I'm having trouble with is figuring out what method to use to implement this in a functional way. The naive approach that first occurred to me was to pass a PRNG and seed value into each function. That would certainly keep the functions referentially transparent. But it would also require either rewriting a bunch of functions that don't directly use the randomness themselves or adding the RNG as part of the map that's already being passed. Plus, the seed should probably vary (deterministically) between calls to the subfunctions. It's not too useful if all the rooms on a map have the same type because they all pulled their die roll from the same-nth result of the exact same seed. Maybe the seed could be created from the contents of the vector or a UUID of a map object or something? The other suggestion I've run across is to rebind something like clojure.data.generators/*rnd* for each high-level procedural generation call. I think this requires the generation to be single threaded and otherwise deterministic. At the moment I don't feel like I know enough about how things work under the hood to say if this a good idea or not. I've poked around at the bigml.sampling and clojure.data.generators libraries, which look useful for dealing with some of this, but I haven't come across anything that directly addresses what kind of architecture to use for deterministic randomness. This may be my inexperience. I feel like I may be a bit too close to the problem, and I can't quite see what the idiomatic answer is. Re-read SICP? Implement some kind of monad? Just bite the bullet and pass the RNG+seed? Find the secret pure functional library everyone is using for repeatable stochastic simulations? Does anyone have any advice on this? Or prior experience with approaches that work? What are some best practices for approaching deterministic simulations in an idiomatic, functional way? -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: About transients no longer being safe in 1.7-alpha2
Hi Daniel, On Wed, Nov 5, 2014 at 3:06 PM, Daniel Marjenburgh dmarjenbu...@gmail.com wrote: My concern is purely about the safety that is taken away when transients 'are' used wrongly. All the examples would've throw exceptions before 1.7-alpha2, and they don't do so anymore. But they would run fine, if you used delay's instead of future's. Same wrong usage, single threaded. So the issue is not really this new change. (See my code with delay's earlier) -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: About transients no longer being safe in 1.7-alpha2
On Mon, Nov 3, 2014 at 5:57 PM, Daniel Marjenburgh dmarjenbu...@gmail.com
wrote:
Hi,
I just want to address this issue (CLJ-1498
http://dev.clojure.org/jira/browse/CLJ-1498). It was accepted in
1.7-alpha2 and I haven't seen a lot of discussion around it, even though
it's quite a big change.
With this change the following code is possible:
With persistents the result would be the same, every time. If this is now
valid Clojure, I didn't run it myself, we are sacrificing consistency. I
don't understand what we're getting in return.
Even the simple example in the ticket (with one future) doesn't make a lot
of sense to me.
Am I missing something obvious?
(let [m (transient {:a 0})
futs (for [n (range 100)]
(future (assoc! m :a (inc (:a m)]
(mapv deref futs) ; wait until futures are done
(persistent! m))
The results will vary per run, where it used to throw
an IllegalAccessError: Transient used by non-owner thread.
I understand the problems of not being able to have 1 go routine access a
transient, even though it would be safe, but this solution feels like it's
throwing out the baby with the bathwater. Basically, it's doing away with
what the following block on clojure.org http://clojure.org/transients
says:
*Transients enforce thread isolation**.* Because each result of a
transient operation shares (mutable) structure with the previous, it would
be very dangerous if more than one thread were to manipulate a transient at
once. In order to prevent this, transients will detect any (read or write)
use from a thread other than the one that created them and throw an
exception.
This may not sound like a concurrency story, but single-thread isolation
is actually a very useful concurrency semantic. The whole point of using
transients is that doing so is safe, because their use is an isolated
implementation detail of otherwise functional code. Having that be enforced
means that some things that would normally be very hard to make safe with
ordinary mutable data structures become easy.
I don't have a good solution for dealing with transients and logical
threads, but I would much prefer keeping the semantics of transients as
they are and maybe pass an option to transient to disable owner checking.
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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: About transients no longer being safe in 1.7-alpha2
Thanks Alex!
Now that I took a second look at Daniel's code, it seems assoc! is used
like swap!, as if it would modify m in place. So I would expect, if it runs
without errors, result to be {:a 0}.
Given that transients are values (not reference types like ref or atom) I
can't think of a case where they can be modified concurrently.
On Tue, Nov 4, 2014 at 11:19 AM, Alex Miller a...@puredanger.com wrote:
On Monday, November 3, 2014 9:00:10 PM UTC-6, Atamert Ölçgen wrote:
On Mon, Nov 3, 2014 at 5:57 PM, Daniel Marjenburgh dmarje...@gmail.com
wrote:
Hi,
I just want to address this issue (CLJ-1498
http://dev.clojure.org/jira/browse/CLJ-1498). It was accepted in
1.7-alpha2 and I haven't seen a lot of discussion around it, even though
it's quite a big change.
With this change the following code is possible:
With persistents the result would be the same, every time. If this is now
valid Clojure, I didn't run it myself, we are sacrificing consistency. I
don't understand what we're getting in return.
Even the simple example in the ticket (with one future) doesn't make a
lot of sense to me.
Am I missing something obvious?
Transients always expect thread isolation. In the past this was locked to
a single thread (the one that made the transient). That restriction now
extends to being used by multiple threads, but isolation should still be
maintained for proper use.
What we are gaining is the ability to use transient collections in go
blocks with core.async, where the thread being used is just one pool out of
a thread. For example (just typing this not running it, so excuse any
typos):
(defn drain [ch coll]
(let [t (transient []]
(go-loop
(if-some [v (! ch)]
(do (conj! t v) (recur))
(persistent! t)
This doesn't necessarily work in core.async because each time the !
parks, it may be woken up with a different thread from the pool. The
transient change allows this kind of code to succeed.
(let [m (transient {:a 0})
futs (for [n (range 100)]
(future (assoc! m :a (inc (:a m)]
(mapv deref futs) ; wait until futures are done
(persistent! m))
The results will vary per run, where it used to throw
an IllegalAccessError: Transient used by non-owner thread.
I understand the problems of not being able to have 1 go routine access
a transient, even though it would be safe, but this solution feels like
it's throwing out the baby with the bathwater. Basically, it's doing away
with what the following block on clojure.org
http://clojure.org/transients says:
*Transients enforce thread isolation**.* Because each result of a
transient operation shares (mutable) structure with the previous, it would
be very dangerous if more than one thread were to manipulate a transient at
once. In order to prevent this, transients will detect any (read or write)
use from a thread other than the one that created them and throw an
exception.
This may not sound like a concurrency story, but single-thread
isolation is actually a very useful concurrency semantic. The whole point
of using transients is that doing so is safe, because their use is an
isolated implementation detail of otherwise functional code. Having that be
enforced means that some things that would normally be very hard to make
safe with ordinary mutable data structures become easy.
I don't have a good solution for dealing with transients and logical
threads, but I would much prefer keeping the semantics of transients as
they are and maybe pass an option to transient to disable owner checking.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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
Re: About transients no longer being safe in 1.7-alpha2
FWIW I can confirm the following code produces {:a 90} consistently:
(let [v (transient {:a 0})
f1 (delay (reduce #(assoc! % :a (+ (:a %) %2)) v (range 10)))
f2 (delay (reduce #(assoc! % :a (+ (:a %) %2)) v (range 10)))]
@f1 @f2 ; wait for futures
(persistent! @f1))
Note that there are no future calls here. Clojure 1.5.1
Part of me wants the result to be {:a 45}
On Tue, Nov 4, 2014 at 3:13 PM, Daniel Marjenburgh dmarjenbu...@gmail.com
wrote:
I was a bit too quick there and posted some errors int he code:
(let [v (transient {:a 0})
f1 (future (reduce #(assoc! % (+ (:a %) %2)) v (range 10)))
f2 (future (reduce #(assoc! % (+ (:a %) %2)) v (range 10)))]
@f1 @f2 ; wait for futures
(persistent! @f1))
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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] outfn - A macro for clearer, more declarative functions (that are actually macros).
I think this is pretty cool. Instead of thinking it as functions on
steroids, I'd prefer looking at it as a powerful callable abstraction.
How does macroexpand-time validation play with apply (the function)? What
happens if I do (map some-outfn coll) ?
Also implicits confused me a bit. At first I thought they were parameter
defaults. But it seems they're some sort of inheriance mechanism for
callables.
BTW, thanks for taking the time to write a detailed readme. I know this is
a young project and it's probably in heavy development. It shows
professionalism (yes, professionalism in an open source context is a thing)
on your part.
On Thu, Oct 30, 2014 at 3:08 AM, Diogo Almeida diogo...@gmail.com wrote:
Hi everyone,
A couple of coworkers and I were chatting about what some of our biggest
problems with (our) Clojure code was, and came up with this:
https://github.com/diogo149/outfn ! We just finished making it, so we
haven't really battle-tested it, but we would love to hear feedback and
general thoughts about the approach, and possibly have it evolve with the
community.
The readme has a bunch examples, so I won't copy-paste it all here, but
here is a list of things that we are hoping to acheive:
- bad/inconsistent variable naming
- function call clarity
- function dispatch based on inputs instead of arity and allowing the
usage of a threading macro no matter the order of arguments with 0 overhead
- static DRY verification
- decomposing big let blocks easily
- dependency passing without coupling (and anything that makes us want to
use a :dynamic var)
- automatic creation of glue code
Some of our favorite examples:
- keyword arguments for function call clarity
(do-something :user-map x :password-list y)
- decomplecting order from function arguments:
(defoutfn map-v2.0
Like map, but better
[f coll]
(map f coll))
;; threading in a collection
(- 5
range
(map-v2.0 :f inc :coll)) ;; (1 2 3 4 5)
;; threading in a function
(- 5
(partial +)
(map-v2.0 :coll (range 5) :f)) ;; (5 6 7 8 9)
- macroexpand-time validation
(defoutfn outfn
what's up doc
[foo]
:foo)
(when nil
;; this doesn't get run
(outfn :fo 2))
;; Error! Invalid set of keys #{:fo} for #'outfn.core/outfn
- declarative function calls without glue code
(defoutfn foo-fn {:output :foo}
Docstring
([a] 3)
([b] 4)
([c d] 5))
(defoutfn bar-fn {:implicits #{#'foo-fn}}
what's up doc
[foo] foo)
;; Look ma, no glue code
(bar-fn :foo 2) ;; 2
(bar-fn :a nil) ;; 3
(bar-fn :b 42) ;; 4
(bar-fn :c 11 :d 22) ;; 5
;; I don't need to know what bar-fn needs - decoupling
(bar-fn :foo 2 :a 3 :b 4 :c 5 :d 6 :q 72) ;; 2
;; Laziness is a virtue
(bar-fn :foo 42 :a (throw Exception.)) ;; 42
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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: Transducers: Why left to right rather than right to left?
We had this exact discussion just yesterday. I'd suggest forgetting about the technical details, how comp works etc. for a minute. And think about what we're dealing with. 1. If we are dealing with functions, function composition makes sense to be written left to right and applied right to left. If you were working on paper this would feel natural to you. And that's exactly how comp works. 2. When we're dealing with transducers, they are functions under the hood but you know they're not functions that take a value and return another value[1]. Anyway that's an implementation detail. Rich describes transducers as processes, or steps of instructions. Natural way to deal with these things is to write them top to bottom or left to right and then assume they'll be applied in that same order[2]. 1: A transducer is a function that takes another transducer or a step function and returns a function that wraps it. If I'm not mistaken second application takes a collection and returns a reducing function on that collection. But I'm probably wrong. 2: How does the order change? I hope this incomplete example helps: ;; applied in reverse order (defn f [g] (fn [coll] (g (do-something coll ;; f is applied before g, like transducer composition (comp f g) ;; applied in given order (defn k [j] (fn [coll] (do-something (j coll ;; j is applied before k, like function composition (comp k j) On Thu, Oct 30, 2014 at 11:44 PM, Mars0i marsh...@logical.net wrote: Caveat: I am still feeling around in the dark in my understanding of transducers. What I write below may just convey how clueless I am. (Meta-caveat: I'm probably spitting into the wind. I should no doubt use my time more wisely.) Normal function composition is done starting from the right. This is familiar from mathematics, other Lisps, most languages, and it's how Clojure's function application and 'comp' work. Sometimes it's easier to understand composition going from left to right, as in many natural languages and as in unix pipes, and Clojure provides '-' and '-' to do that. That's good. Best of both worlds. One thing I like about these operators is that their name clearly indicates the direction of function application. Transducers allow function composition with potential efficiency gains, but apply functions starting from left to right. But *it does this using the name 'comp'*, which otherwise applies functions from right to left. What?? Doesn't that seem like a Bad Thing? Why not use a different name? (It's like overloading the minus sign so that in some contexts, it subtracts the first argument from the second.) (Is Clojure is getting too popular? Its essential features--prefix notation, parentheses, purely functional operations, and laziness--aren't doing enough to scare away Java programmers? :-) -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Modelling in Clojure
Every programming language is a (somewhat) unique approach to programming. So they all have their ways. Java is best expressed using Java best practices. Python is best expressed using Python best practices. Of course Clojure too is best expressed using Clojure best practices. Having said that; I don't think object oriented paradigm makes a lot sense in a dynamic environment. Clojure is a dynamic language. Data can be the API without major issues because we can handle all kinds of data with ease. (= (seq []) nil), select-keys, fnil etc... Encapsulation is a valuable property when we're in a statically typed environment. We want to hide more because it's a more rigid environment. On Fri, Oct 17, 2014 at 12:23 PM, Armando Blancas abm221...@gmail.com wrote: Sure, that's the theory behind encapsulation, but I'm not convinced there are many cases in practice where the API can remain consistent while the data changes. I'm not, either. Models that have little or no abstraction --basically aggregates of related items-- end up having APIs that just reflect their contents. For years, my tools were the Eclipse refactoring features and the code (re)generation of the Eclipse Modeling Framework, not encapsulation. I started using Clojure practices, though not totally convinced until a while ago Stuart Sierra wrote: The data *is* the API, which helped me understand what I was really doing. Whereas I never faced the proverbial computed-field change, I've now taken good advantage of generic functions over maps and records. -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Modelling in Clojure
On Fri, Oct 17, 2014 at 12:47 PM, Rui Yang ryang@gmail.com wrote: I am new to clojure. My question how to handle version if we expose data directly as api, any schema change will break the api which may impact third party users. You can't protect the consumers of your API. You publish your new API and pray. As a consumer I do TDD. So my code is fully tested. Of course most of the 3rd party code is mocked in my tests. When I upgrade a dependency I read the changelog and run my code to see if anything breaks. Clojure is a dynamic language, so there's actually no schema. I suppose I can write integration tests and such... But I doubt they'll be able to catch everything. My point is; as a producer (of libraries) there's little you can do within your code. As a consumer you can do a bit more. On Friday, 17 October 2014 15:23:10 UTC+11, Armando Blancas wrote: Sure, that's the theory behind encapsulation, but I'm not convinced there are many cases in practice where the API can remain consistent while the data changes. I'm not, either. Models that have little or no abstraction --basically aggregates of related items-- end up having APIs that just reflect their contents. For years, my tools were the Eclipse refactoring features and the code (re)generation of the Eclipse Modeling Framework, not encapsulation. I started using Clojure practices, though not totally convinced until a while ago Stuart Sierra wrote: The data *is* the API, which helped me understand what I was really doing. Whereas I never faced the proverbial computed-field change, I've now taken good advantage of generic functions over maps and records. -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: State of Clojure 2014 Survey - please contribute!!
Dear Clojurians, Inclusion of such questions on the survey would be another opportunity for Clojure to be more than just not unwelcoming to atypical folks and allow us to purposefully invite more people to this relative paradise we inhabit. I would simply not fill the survey. Because what does my age or gender or race have to do with a programming language. There is nothing stopping the atypical folks from grabbing a REPL and typing away some code. On Wed, Oct 15, 2014 at 3:33 PM, Bruce Durling b...@otfrom.com wrote: Jony, It is being introduced into what was the intro to OO course. cheers, Bruce On Fri, Oct 10, 2014 at 11:27 PM, Jony Hudson jonyepsi...@gmail.com wrote: If this is the unofficial survey post of academics using Clojure then I'd better add myself to the list :-) @Bruce do you know what course they're going to be teaching Clojure on at Birkbeck? Jony On Friday, 10 October 2014 08:08:28 UTC+1, Bruce Durling wrote: I also know that Birkbeck College University of London is going to be teaching Clojure this year. On Oct 10, 2014 12:01 AM, Lee Spector lspe...@hampshire.edu wrote: FWIW I'm another person using Clojure mostly for academic research. And for computer science education, e.g. I'm currently teaching a Clojure-based AI course. I'd be curious to know how many others of us are out there. And BTW I think that attention to users in these categories could help to grow the community. -Lee On Oct 9, 2014, at 12:32 AM, Mars0i mars...@logical.net wrote: Thanks for the survey! I have a couple of suggestions/questions: For domains, there are no categories for scientific or other research applications. For example, I mainly use Clojure for writing agent-based models for academic research. Would a set of categories in this area be usedful? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: State of Clojure 2014 Survey - please contribute!!
On Thu, Oct 16, 2014 at 8:30 AM, Ashton Kemerling ashtonkemerl...@gmail.com wrote: I'm curious if there's any empirical evidence that significant numbers of people will do that. Suppose I have provided reliable data that shows only 0.1% would refuse to answer such a Survey. A programming related survey with questions about demographics and a stated mission of being inclusive. What would be your moral reasoning for not being inclusive for this group of people? On Wed, Oct 15, 2014 at 6:23 PM, Mars0i marsh...@logical.net wrote: I don't really get it. I don't see a legitimate reason why anyone would refuse to participate in the survey because it included demographic questions. The survey is anonymous. The combination of questions is not such that it would be at all plausible that anyone could be identified by their responses. At worst, answering a few additional questions--or simply skipping those questions--would be a very minor annoyance. Is it that some people object to the idea that there are disparities due to systemic factors in our society? If someone wants to disagree about that, OK, but I still don't see how boycotting a survey because it offers respondents the opportunity to provide demographic information is reasonable. On Wednesday, October 15, 2014 2:06:29 PM UTC-5, Sean Corfield wrote: On Oct 15, 2014, at 11:29 AM, Ashton Kemerling ashtonk...@gmail.com wrote: I would rather not say is a common and valid response in these scenarios. Yes, although that doesn't address that there are people who will not complete a survey that even asks such questions (on a philosophical objection to collecting such demographic information). As I said, it's a sensitive issue. As Bridget noted, they'll consider the approach for 2015. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] Example project to illustrate usage of system library
On Fri, Oct 10, 2014 at 2:06 PM, Daniel Szmulewicz daniel.szmulew...@gmail.com wrote: Yes, because locally you are in the repl already. The repl in production is brought in explicitly to be able to login/debug remotely into the application where it’s hosted. Does that make sense? Makes sense. Thanks. On Friday, October 10, 2014 7:13:39 AM UTC+3, Atamert Ölçgen wrote: prod-system has a REPL but dev-system doesn't. Is this intentional? https://github.com/danielsz/system/blob/master/example/ src/example/systems.clj On Wed, Oct 8, 2014 at 7:57 PM, Daniel Szmulewicz daniel.s...@gmail.com wrote: Hello everybody, I noticed a demand for examples in how to put together a web app with the reloaded approach (Stuart Sierra's components). For this reason, I've published an example project in the system library. https://github.com/danielsz/system/tree/master/example Enjoy. Please let me know if you have comments/suggestions/etc. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] Example project to illustrate usage of system library
prod-system has a REPL but dev-system doesn't. Is this intentional? https://github.com/danielsz/system/blob/master/example/src/example/systems.clj On Wed, Oct 8, 2014 at 7:57 PM, Daniel Szmulewicz daniel.szmulew...@gmail.com wrote: Hello everybody, I noticed a demand for examples in how to put together a web app with the reloaded approach (Stuart Sierra's components). For this reason, I've published an example project in the system library. https://github.com/danielsz/system/tree/master/example Enjoy. Please let me know if you have comments/suggestions/etc. -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: What is the best setup to program Clojurescript IF...
LightTable is awesome. On Thu, Oct 2, 2014 at 11:43 PM, Tony Tam ttasteri...@gmail.com wrote: I use Sublime and Terminator (terminal) on Ubuntu (btw, there's a Clojurescript google group :)) On Thursday, October 2, 2014 8:13:14 PM UTC+1, Peter Mancini wrote: What is the best setup to program Clojurescript IF: - you hate EMACS - use linux or windows Any suggestions? -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] clecs 1.0.1
clecs is an entity-component-system framework for Clojure. The repo is here: https://github.com/muhuk/clecs Changes Since Version 0.2.x * Replaced function based queries with data driven queries. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: How can I add meta to an object that doesn't implement IObj?
Hi Francis,
On Sat, Aug 30, 2014 at 1:34 PM, Francis Avila franci...@gmail.com wrote:
It would probably help if you said more about the source of this
atom-holding object. Is it a plain Java class? A deftype/defrecord? Is it
final?
It's not an atom-holding object. The only guarantee is that this object
extends one (or two) of these protocols:
http://clecs.muhuk.com/api/0.2.1/clecs.world.html
Other than that, it can be anything. A Java class, or a type or a record...
If you can control the construction of this object and its class is not
final, you can subclass it and add an IObj implementation. (Note that most,
maybe all clojure ways of creating classes create final classes, so this
technique won't work.) The easiest way to subclass is with `proxy`:
(defn meta-AtomHolder [atom-value metadata]
(proxy [AtomHolderClass clojure.lang.IObj] ;; [superclass, new
interfaces]
[atom-value] ;; constructor args
(meta [] metadata) ;; subclass method
(withMeta [newmeta] (meta-AtomHolder newmeta
= (var user/meta-AtomHolder)
(meta-AtomHolder (atom x) {})
= #AtomHolderClass$IObj$40298964
user.proxy$AtomHolderClass$IObj$40298964@302c28cc
(meta (meta-AtomHolder (atom x) {}))
= {}
(meta (with-meta (meta-AtomHolder (atom x) {}) {:a 1}))
= {:a 1}
This is really cool. So I can do (deref (meta-AtomHolder (atom x) {}))
and it would return x, right?
I have actually managed to solve it using vars, had to move things around a
bit:
https://github.com/muhuk/clecs/blob/master/src/clecs/world/check.clj#L73
If the parent class is final or you can't construct the object yourself,
you need to delegate method calls from one instance to this object
instance. I think this is hard-but-not-impossible in java, but I'm not sure.
(Clojurescript has `specify`, which does exactly what you want, but only
exists because delegation between instances in javascript is trivial.)
On Friday, August 29, 2014 10:16:05 PM UTC-5, Atamert Ölçgen wrote:
Obviously I can't.
But I need to add this capability to an object. During testing I attach
meta to this object that contains an atom. Then I pass this object to other
functions, known in runtime. I can't use a dynamic var because all this
happens within a mock function that may be retried and run in different
threads.
I have seen this: http://stackoverflow.com/questions/20724219/
simplest-possible-clojure-object-that-can-accept-a-primitive-and-metadata
but can't deref it since I can't change the functions that will use it
later. If I wrap this object I need to be able to delegate all of its
functionality to the original object.
I hope this all is not too vague. The code I'm working on is not online
yet. But it's for clecs (https://github.com/muhuk/clecs/), I'm adding
quickcheck to compare different world implementations.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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: How can I add meta to an object that doesn't implement IObj?
On Mon, Sep 1, 2014 at 1:52 AM, adrian.med...@mail.yu.edu wrote:
If you don't want to wrap the object in an atom, you can also reify an
object that supports IDeref which returns your object. All reified objects
support IObj out of the box.
As I said earlier:
... can't deref it since I can't change the functions that will use it
later.
And again, later:
I can't really pass a list since the first function is expecting the object
I am passing,
That was why I was asking how to attach metadata.
On Sunday, August 31, 2014 4:55:58 AM UTC-4, Atamert Ölçgen wrote:
Hi Francis,
On Sat, Aug 30, 2014 at 1:34 PM, Francis Avila fran...@gmail.com wrote:
It would probably help if you said more about the source of this
atom-holding object. Is it a plain Java class? A deftype/defrecord? Is it
final?
It's not an atom-holding object. The only guarantee is that this object
extends one (or two) of these protocols: http://clecs.muhuk.
com/api/0.2.1/clecs.world.html
Other than that, it can be anything. A Java class, or a type or a
record...
If you can control the construction of this object and its class is not
final, you can subclass it and add an IObj implementation. (Note that most,
maybe all clojure ways of creating classes create final classes, so this
technique won't work.) The easiest way to subclass is with `proxy`:
(defn meta-AtomHolder [atom-value metadata]
(proxy [AtomHolderClass clojure.lang.IObj] ;; [superclass, new
interfaces]
[atom-value] ;; constructor args
(meta [] metadata) ;; subclass method
(withMeta [newmeta] (meta-AtomHolder newmeta
= (var user/meta-AtomHolder)
(meta-AtomHolder (atom x) {})
= #AtomHolderClass$IObj$40298964 user.proxy$AtomHolderClass$
IObj$40298964@302c28cc
(meta (meta-AtomHolder (atom x) {}))
= {}
(meta (with-meta (meta-AtomHolder (atom x) {}) {:a 1}))
= {:a 1}
This is really cool. So I can do (deref (meta-AtomHolder (atom x) {}))
and it would return x, right?
I have actually managed to solve it using vars, had to move things around
a bit: https://github.com/muhuk/clecs/blob/master/src/clecs/
world/check.clj#L73
If the parent class is final or you can't construct the object yourself,
you need to delegate method calls from one instance to this object
instance. I think this is hard-but-not-impossible in java, but I'm not sure.
(Clojurescript has `specify`, which does exactly what you want, but only
exists because delegation between instances in javascript is trivial.)
On Friday, August 29, 2014 10:16:05 PM UTC-5, Atamert Ölçgen wrote:
Obviously I can't.
But I need to add this capability to an object. During testing I attach
meta to this object that contains an atom. Then I pass this object to other
functions, known in runtime. I can't use a dynamic var because all this
happens within a mock function that may be retried and run in different
threads.
I have seen this: http://stackoverflow.com/questions/20724219/simplest-
possible-clojure-object-that-can-accept-a-primitive-and-metadata but
can't deref it since I can't change the functions that will use it later.
If I wrap this object I need to be able to delegate all of its
functionality to the original object.
I hope this all is not too vague. The code I'm working on is not online
yet. But it's for clecs (https://github.com/muhuk/clecs/), I'm adding
quickcheck to compare different world implementations.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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.
--
Kind Regards
Re: How can I add meta to an object that doesn't implement IObj?
Hi François, Thanks for the links. I can't really pass a list since the first function is expecting the object I am passing, then it calls some other functions that were supposed to extract the meta. The problem is, functions that are called later can be executed in a different thread. On Sat, Aug 30, 2014 at 4:29 PM, François Rey fmj...@gmail.com wrote: On 30/08/14 05:15, Atamert Ölçgen wrote: Obviously I can't. But I need to add this capability to an object. During testing I attach meta to this object that contains an atom. Then I pass this object to other functions, known in runtime. I can't use a dynamic var because all this happens within a mock function that may be retried and run in different threads. In my case I used a list, e.g. (list obj), and used destructuring on the other side when needed, e.g. [obj :as wobj]. I have seen this: http://stackoverflow.com/questions/20724219/simplest-possible-clojure-object-that-can-accept-a-primitive-and-metadata but can't deref it since I can't change the functions that will use it later. If I wrap this object I need to be able to delegate all of its functionality to the original object. I don't think there's a quick solution without changing the contract. Whatever solution is chosen you need to keep in mind how this will affect things like equality, hashing, and instanceof? Perhaps these links could be a start: https://groups.google.com/forum/#!topic/clojure/9zCGdW_Q7o8 http://stackoverflow.com/questions/9086926/create-a-proxy-for-an-specific-instance-of-an-object-in-clojure Also, if the meta data is just for you own use, then you might want to store it yourself in a map with weak references, or just use WeakHashMap http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html directly. But then you'll be stateful... -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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.
How can I add meta to an object that doesn't implement IObj?
Obviously I can't. But I need to add this capability to an object. During testing I attach meta to this object that contains an atom. Then I pass this object to other functions, known in runtime. I can't use a dynamic var because all this happens within a mock function that may be retried and run in different threads. I have seen this: http://stackoverflow.com/questions/20724219/simplest-possible-clojure-object-that-can-accept-a-primitive-and-metadata but can't deref it since I can't change the functions that will use it later. If I wrap this object I need to be able to delegate all of its functionality to the original object. I hope this all is not too vague. The code I'm working on is not online yet. But it's for clecs (https://github.com/muhuk/clecs/), I'm adding quickcheck to compare different world implementations. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] Debug: clojure port of node debug
Awesome! Thanks for sharing. For those who are wondering what debug does exactly, I suggest checking out the screenshots in the node port's GitHub page. (Any chance you can borrowsteal them?) There's also flatland.useful.debug/? for inspecting forms. ( https://github.com/amalloy/useful/blob/develop/src/flatland/useful/debug.clj ) On Sat, Jul 5, 2014 at 7:10 AM, Sun Ning classicn...@gmail.com wrote: Hi all, I just ported node debug[1] library to clojure, hoping it could be helpful in clojure world. The debug library is widely used in node projects. The usage is very simple: print debug message when certain namespace is enabled via environment variable DEBUG. https://github.com/sunng87/debug The Clojure version of debug has almost all features of node one. And there are some advantages: * No need to configure module name since we have *ns* in clojure * Zero overhead in runtime if debug is disabled: the debug macro won't produce anything Compared with logging tools of clojure, the debug library is: * Much simpler, no xml or properties at all * Light weight, no additional dependencies [1] https://github.com/visionmedia/debug -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Why does unquote clone values?
On Thu, Jul 3, 2014 at 11:55 PM, Pascal Germroth funkyco...@gmail.com wrote: Hi Atamert, Here's a gist with the example code: https://gist.github.com/neapel/4e502a14e3738b709672 I tried replacing a closure with a dynamically built and evaluated metafunction but discovered that it was actually slower. If evaluating code during run is slower than AOT compiling it, it wouldn't surprise me. I didn't actually try AOT compiling it, just using the REPL. As far as I understand there shouldn't be a difference in speed, since (eval) runs the same compiler as AOT does, and even writes out a .class file. OK, perhaps I could have phrased it better. I'm not an expert but I believe REPL does compile the forms you enter to bytecode. It compiles an fn form into a JVM class that implements IFn. It also compiles a quoted form (such as `(fn ...) ) but this time it takes the form of a list (as in (list ...) ), IOW it's still data after it is compiled. The latter is executed directly and the former is evaluated (turned into bytecode and then executed perhaps). If I'm wrong on any of these, I'd like to be corrected. I also realize AOT means something slightly different. Something compiled before REPL is started, right? -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: guide on how to plug eastwood into clojure.test unittests?
On Wed, Jul 2, 2014 at 3:01 PM, Andy Fingerhut andy.finger...@gmail.com wrote: Hopefully someone else can describe their preferred method for adding a command line invocation like 'lein eastwood' to their checkin/CI/release process. @Chris Have you tried adding `lein eastwood` to your build process? If you did, and it didn't work perhaps you can provide more details. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Why does unquote clone values?
Hi Pascal, On Wed, Jul 2, 2014 at 10:19 PM, Pascal Germroth funkyco...@gmail.com wrote: I tried replacing a closure with a dynamically built and evaluated metafunction but discovered that it was actually slower. If evaluating code during run is slower than AOT compiling it, it wouldn't surprise me. I guess f2 runs this much slower than f1 because it doesn't actually pass a reference to x when unquoting, but clones the value, which means it needs to compare the lists element-wise. This is interesting. Were you able to confirm it or are you just guessing? (I'm just curious.) -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Code health metrics
My toolbox is: lein-cloverage (mostly vanity), Midje (TDD), Eastwood (to decrease wtf/minute) + lein check (once in a while). No fancy cyclomatic coupling hyperdrives. Metrics become more important in larger teams, say 3+ people. They don't add much value for small teams as everyone can follow up with everybody else and provide direct feedback. What's the size of your team? It's harder to (programmatically and statically) analyze dynamic languages. On Wed, Jul 2, 2014 at 4:53 AM, Chris Ford christophertf...@gmail.com wrote: Hi all, Are there any good tools for measuring the health of a Clojure codebase? What is even useful to measure for Clojure? Afferent/efferent coupling, cyclomatic complexity and unit test coverage are metrics I would use for Java, but do they apply equally to Clojure? I'm aware of Clique https://github.com/Hendekagon/lein-clique and Vanity https://github.com/dgtized/lein-vanity, which look nice, but they don't seem to perform any analysis. Cheers, Chris -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Game logic with Clojure
+1 for Caves of Clojure. I would also take a look at these blog posts: http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ Not Clojure specific, but I think they're good for getting the general concepts. On Mon, Jun 23, 2014 at 11:37 PM, Mark Mandel mark.man...@gmail.com wrote: If you are looking for another example, here is my pong clone with play-clj, and my own Entity Component system, brute. https://github.com/markmandel/brute-play-pong I also use an atom that I reset! on each game loop. Because it's integrated with play-clj (and therefore libgdx) there is a bit more mutable state in there than normal. Mark On Tue, Jun 24, 2014 at 7:45 AM, James Reeves ja...@booleanknot.com wrote: I typically keep my state in an atom, and use swap! to update it. This means I can decouple rendering and other things from the actual game logic. However, depending on how your application functions, you might just be able to keep the state in a loop. - James On 23 June 2014 21:53, Majen Ful majen...@gmail.com wrote: Thank you all ! @James, I confirm it is like Bang! (same editor), but I prefer this ;-) So in fact I don't have to have a state to update, instead, I just pass my init state to functions/loops to get a new one. Le lundi 23 juin 2014 21:54:56 UTC+2, Majen Ful a écrit : Hello all, First, thank you all for your contribution and your help. I just follow Clojure's news and groups, and I'm really impressed by how this community is pleasant and helpful. Well, I am new to Clojure world, I do programming as a hobby (I'm not pro) and I don't have advanced knowledges. However I really enjoy programming and I like games. In a classic language, as Ruby or Java, I can use mutable states and objects so it is easy to reason. In Clojure, I understand how immutability works, but I still miss some reflexes. My goal is to build a little card game like http://boardgamegeek.com/ boardgame/128667/samurai-sword A lot of things to do, but I have some difficulties at beginning. For example, I can define cards, I can define some function (isdead, attack)... But how can I save the state of the game ? When a player attacks another player, the second player must have its life reduced. At this point, my OO reflexes are went back and don't find a solution. Could you give me some tips and lead me to the right things to do. Thanks by advance :-) -- 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. -- E: mark.man...@gmail.com T: http://www.twitter.com/neurotic W: www.compoundtheory.com 2 Devs from Down Under Podcast http://www.2ddu.com/ -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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
Re: RFC: dynamic-object, a library for working with Clojure data in Java
Absolutely. I don't believe consumers (of open source projects) are
entitled to anything anyway. I think it's a cool project and I hope it gets
the attention.
On Tue, Jun 17, 2014 at 1:02 AM, Ryan Schmitt rschm...@u.rochester.edu
wrote:
I'll look into it, I'm just sort of reluctant because I don't think people
take beta warnings seriously. In the meantime, if all you want is a .jar
file, you can just clone the git repo and run the Gradle build. You should
also be able to open up the repo as an IntelliJ project. (Let me know if
you can't, by the way--I've tested both approaches on multiple operating
systems with the intention that they should *just work*.)
On Sunday, June 15, 2014 8:38:25 PM UTC-7, Atamert Ölçgen wrote:
Perhaps if you make it easily available (making an early release) more
people would use it and you might get more feedback then. You can always
change interfaces, conventions etc.
On Mon, Jun 16, 2014 at 3:09 AM, Ryan Schmitt rsch...@u.rochester.edu
wrote:
Set, Util, and List are actually just interfaces, and Clojure's
collections implement them. The destructive operations throw
UnsupportedOperationException of course, which is actually explicitly
allowed by the spec:
* pThe destructive methods contained in this interface, that is, the
* methods that modify the map on which they operate, are specified to
throw
* ttUnsupportedOperationException/tt if this map does not support
the
* operation. If this is the case, these methods may, but are not
required
* to, throw an ttUnsupportedOperationException/tt if the
invocation would
* have no effect on the map. For example, invoking the {@link
#putAll(Map)}
* method on an unmodifiable map may, but is not required to, throw the
* exception if the map whose mappings are to be superimposed is empty.
This conversion is recursive; for instance, a ListListInteger will
be internally stored as an immutable persistent ListListLong. However,
this behavior is not documented, partially because it hasn't been tested to
my satisfaction yet and partially because validation does not currently
work with nested collections.
The library isn't available on Maven yet; I want more feedback on the
design before I make a commitment to the current interfaces, conventions,
and behaviors.
On Sunday, June 15, 2014 7:56:30 PM UTC-7, Atamert Ölçgen wrote:
Really cool library, thanks for sharing. I was initially irked by the
use of (mutable) Java collection interfaces, but then I read that they're
made immutable when passed to the builder. I assume they're recursively
converted to persistent representations.
It reminded me of Guava's immutable classes a little. (Not persistent,
no serialization)
Is it available via maven?
On Mon, Jun 16, 2014 at 1:18 AM, Ryan Schmitt rsch...@u.rochester.edu
wrote:
I've been developing a library to bring Clojure data to Java
developers. By Clojure data I mean both Clojure's persistent immutable
data structures *and* serialized Edn data. I wanted access to
Clojure's capabilities without having to use Clojure-Java interop
directly or make use of downcasting. Obviously it would be preferable to
just use Clojure, but this is intended as the next best thing for
developers who for whatever reason are currently stuck with Java.
https://github.com/rschmitt/dynamic-object
I'm looking for feedback on the design and implementation. The README
is reasonably thorough, and the tests
https://github.com/rschmitt/dynamic-object/tree/master/src/test/java/com/github/rschmitt/dynamicobject
contain hundreds of usage examples. If anyone has any questions, I'll be
glad to field them here.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop
Re: RFC: dynamic-object, a library for working with Clojure data in Java
Really cool library, thanks for sharing. I was initially irked by the use of (mutable) Java collection interfaces, but then I read that they're made immutable when passed to the builder. I assume they're recursively converted to persistent representations. It reminded me of Guava's immutable classes a little. (Not persistent, no serialization) Is it available via maven? On Mon, Jun 16, 2014 at 1:18 AM, Ryan Schmitt rschm...@u.rochester.edu wrote: I've been developing a library to bring Clojure data to Java developers. By Clojure data I mean both Clojure's persistent immutable data structures *and* serialized Edn data. I wanted access to Clojure's capabilities without having to use Clojure-Java interop directly or make use of downcasting. Obviously it would be preferable to just use Clojure, but this is intended as the next best thing for developers who for whatever reason are currently stuck with Java. https://github.com/rschmitt/dynamic-object I'm looking for feedback on the design and implementation. The README is reasonably thorough, and the tests https://github.com/rschmitt/dynamic-object/tree/master/src/test/java/com/github/rschmitt/dynamicobject contain hundreds of usage examples. If anyone has any questions, I'll be glad to field them here. -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: RFC: dynamic-object, a library for working with Clojure data in Java
Perhaps if you make it easily available (making an early release) more
people would use it and you might get more feedback then. You can always
change interfaces, conventions etc.
On Mon, Jun 16, 2014 at 3:09 AM, Ryan Schmitt rschm...@u.rochester.edu
wrote:
Set, Util, and List are actually just interfaces, and Clojure's
collections implement them. The destructive operations throw
UnsupportedOperationException of course, which is actually explicitly
allowed by the spec:
* pThe destructive methods contained in this interface, that is, the
* methods that modify the map on which they operate, are specified to
throw
* ttUnsupportedOperationException/tt if this map does not support the
* operation. If this is the case, these methods may, but are not required
* to, throw an ttUnsupportedOperationException/tt if the invocation
would
* have no effect on the map. For example, invoking the {@link
#putAll(Map)}
* method on an unmodifiable map may, but is not required to, throw the
* exception if the map whose mappings are to be superimposed is empty.
This conversion is recursive; for instance, a ListListInteger will be
internally stored as an immutable persistent ListListLong. However,
this behavior is not documented, partially because it hasn't been tested to
my satisfaction yet and partially because validation does not currently
work with nested collections.
The library isn't available on Maven yet; I want more feedback on the
design before I make a commitment to the current interfaces, conventions,
and behaviors.
On Sunday, June 15, 2014 7:56:30 PM UTC-7, Atamert Ölçgen wrote:
Really cool library, thanks for sharing. I was initially irked by the use
of (mutable) Java collection interfaces, but then I read that they're made
immutable when passed to the builder. I assume they're recursively
converted to persistent representations.
It reminded me of Guava's immutable classes a little. (Not persistent, no
serialization)
Is it available via maven?
On Mon, Jun 16, 2014 at 1:18 AM, Ryan Schmitt rsch...@u.rochester.edu
wrote:
I've been developing a library to bring Clojure data to Java
developers. By Clojure data I mean both Clojure's persistent immutable
data structures *and* serialized Edn data. I wanted access to Clojure's
capabilities without having to use Clojure-Java interop directly or make
use of downcasting. Obviously it would be preferable to just use Clojure,
but this is intended as the next best thing for developers who for whatever
reason are currently stuck with Java.
https://github.com/rschmitt/dynamic-object
I'm looking for feedback on the design and implementation. The README is
reasonably thorough, and the tests
https://github.com/rschmitt/dynamic-object/tree/master/src/test/java/com/github/rschmitt/dynamicobject
contain hundreds of usage examples. If anyone has any questions, I'll be
glad to field them here.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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
Re: Clojure:Lisp :: LSD:Meditation
On Fri, Jun 13, 2014 at 9:34 AM, Dave Della Costa ddellaco...@gmail.com wrote: So it seems to me that some folks simply don't like the content; It's not because we don't like the content. I didn't even read the content. You haven't made a post and linked to your blog since February, right? (I just searched my local archives) Divyansh has posted 3 links in the last 3 months. I have seen another post by Gijs. He links to his blog. But he's also announcing an open source project. I see no problems with that. I even posted it to hacker news. I'm not a moderator or anything, just simply explaining my point of view - as a member of the group. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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.
