On Wednesday, June 22, 2016 at 7:25:50 AM UTC-4, Bruno Bonacci wrote:
>
>
> To answer Brian on the "potential" problem of the clock drift I would
> recommend to have a look to
> https://aphyr.com/posts/299-the-trouble-with-timestamps. Beside the
> hardware problems you have to account for thin
Bruno,
I think the more you can reduce the chance of collision the better and the
thread-local capability is a good idea, but in the process you've almost
doubled the bits.
For me anyhow, an ID need to be produceable at a reasonable rate (1 million
a second per machine is good for me), have ne
On Friday, June 17, 2016 at 4:04:31 PM UTC-4, Alex Miller wrote:
>
>
>
> On Friday, June 17, 2016 at 2:46:37 PM UTC-5, Brian Platz wrote:
>>
>>
>> I'd like to be able to use clojure.spec for input validation where the
>> specs are stored in a database
I'd like to be able to use clojure.spec for input validation where the
specs are stored in a database using a data structure to represent them.
s/keys and its requirement to use the registry makes this challenging.
I'm able to generate specs dynamically using a workaround like:
(eval (cons 's/a
In a web-app you probably want the thread safety an atom provides, so it
would be a good choice.
You can include a reference to your atom in your system config if you want
to retain the reloaded-like / dependency injection pattern:
(def changing-config (atom {}))
;; system-map
(def sys-map
{:
start (connect config)
> :stop (disconnect mem-db))
>
> Do I misunderstand this or do we just disagree on what global state is? What
> if I want to have several (different) `mem-db` instances, how would that
> work?
>
>
>
> On Fri, Apr 8, 2016 at 4
>> This is also something that wouldn't be possible with Mount as this
library seems to promote global state.
As a recent switcher from Component to Mount, and without trying to change
the thread's topic into a this vs. that -- I'll simply say that I don't
believe any of these tools promote gl
=> ({:name "foo", :location 100} {:name "bar", :location 101})
On Sunday, September 13, 2015 at 10:56:14 AM UTC-4, Colin Yates wrote:
>
> I would transform the locations into {location id} and then use merge.
>
> On 13 Sep 2015, at 3:14 PM, Brian Platz >
&g
I have a pattern that comes up frequently, when I need to merge some value
into one map list from matching keys in a second map list.
I've developed a way to handle it, but I think it could be better. Here is
a simple example of it:
In the below case, we are looking to replace the :location in
