If you're going to call that for multiple elements of the same vector, it's
worth thinking about doing some work upfront so that each look-up is faster:
(defn indices [vect]
(->> vect
(map-indexed vector)
(reduce (fn [acc [idx el]]
(update acc el (fnil conj []) idx
2017-11-14 4:03 GMT+01:00 Alan Thompson :
> I seem to still be getting the JDK 1.9 reflection warning:
>
>
> ~/tupelo > grep data.xml project.clj
> [org.clojure/data.xml "0.2.0-alpha5"]
>
> > lein test
> lein test tst.tupelo._bootstrap
>
> -
>
I can replicate that in the tupelo tests, but it's coming from enlive, not
data.xml. I think enlive needs a type hint on s in this function:
https://github.com/cgrand/enlive/blob/master/src/net/cgrand/xml.clj#L85
actual: java.lang.IllegalAccessException: class clojure.lang.Reflector
cannot a
Although it looks like that call is intentionally reflective to cover
several possible types. Probably need to solve that with a cond to check
for and hint the actual type at the point of the call.
On Tuesday, November 14, 2017 at 8:31:48 AM UTC-6, Alex Miller wrote:
>
> I can replicate that in
2017-11-14 15:33 GMT+01:00 Alex Miller :
> Although it looks like that call is intentionally reflective to cover
> several possible types. Probably need to solve that with a cond to check
> for and hint the actual type at the point of the call.
>
Yep, see the corresponding change in data.xml:
htt
Hey everybody!
I'm chiming in after seeing this linked to in The Repl
(https://therepl.net/).
On Alex's suggestion, I rewatched Spec-ulation last night. The parts about
negation and evolution are towards the end. I was struck (once again) by
how clearly he picked apart changes. Relaxing a requ
I took part of the goal to be that specs themselves would remain
compatible, so an old set of specs wouldn't start failing on data that
conforms to a new but compatible set of specs. That sort of compatibility
isn't possible when you go from disallowing something to allowing it.
On Tuesday, Nov
Oh, I see! That makes sense. Thanks!
On Tuesday, November 14, 2017 at 10:45:30 AM UTC-6, Seth Verrinder wrote:
>
> I took part of the goal to be that specs themselves would remain
> compatible, so an old set of specs wouldn't start failing on data that
> conforms to a new but compatible set of s
Eric does raise an interesting question tho’:
If you have an API that cares about ‘a’, ‘b’, and ‘c’ and you later specify
that ‘d’ is optional and should be an ‘int?’, does that qualify as breakage or
growth? If clients were sending ‘d’ as a string before but you ignored it, it
will break those
Yeah, it seems like if s/keys specs add any keys (required or not) that
have specs defined, you're breaking things. Removing the spec definition
and removing the key is growth. This explains why people would want things
to be stricter at first because it would allow them to relax later.
The idea t
Isn't this precisely why you should use namespaced keywords?
tirsdag 14. november 2017 19.43.55 UTC+1 skrev Sean Corfield følgende:
>
> Eric does raise an interesting question tho’:
>
>
>
> If you have an API that cares about ‘a’, ‘b’, and ‘c’ and you later
> specify that ‘d’ is optional and sh
>
> Eric does raise an interesting question tho
I think so too. I'm still finding it hard to come up with a single example
of why allowing extra keys to validate would ever be useful even for
non-breakage. I can't see how it would break anything.
I believe the only advantage of allowing extr
>
> I think so too. I'm still finding it hard to come up with a single example
> of why allowing extra keys to validate would ever be useful even for
> non-breakage. I can't see how it would break anything.
>
I think you're assuming you're validating API endpoints where client and
server are tight
Oh this looks cool!
On Tuesday, October 31, 2017 at 8:21:54 AM UTC-5, Alex Miller wrote:
>
> tools.deps.alpha 0.2.167 was released on Oct 26th. I have not announced
> all interim releases but some of the recent changes include:
>
>- Overhaul of the provider extension points
>- Initial sup
>
> If you have an API that cares about ‘a’, ‘b’, and ‘c’ and you later
> specify that ‘d’ is optional and should be an ‘int?’, does that qualify as
> breakage or growth? If clients were sending ‘d’ as a string before but you
> ignored it, it will break those clients. Clients that were not sending
> I think so too. I'm still finding it hard to come up with a single
example of why allowing extra keys to validate would ever be useful even
for non-breakage. I can't see how it would break anything.
>
> I believe the only advantage of allowing extra keys, is to allow partial
specs. So say you nev
(apologies for the resend; this didn't reach the web interface the first
time around)
When I have a function whose arguments I have spec'ed with an fdef, and
that function is used in the construction of a lazy seq, it's easy to
stumble into situations where the arguments are not actually checked e
| I think you're assuming you're validating API endpoints where client and
server are tightly coupled. I can imagine a microservices system where some
services put maps on a queue and others consume them. The consumers should
allow keys they don't understand. They and also need to validate that
That's weird, not sure why you get ClassCastException and not the spec error of
add1.
That said, you can not validate a lazy-seq without realizing it. You can use
s/every? on big collections, that will sample x element and validate only those.
So its normal for coll-of to realize the lazy-seq,
On Tuesday, November 14, 2017 at 4:16:00 PM UTC-6, Russell Mull wrote:
>
>
> This appears to be happening because the lazy sequence is actually
> realized *by* spec when instrumentation is on, but at that point checking
> is actually disabled with the st/with-instrument-disabled macro.
>
> A fe
| One option is to use the non-conforming s/every instead of the conforming
s/coll-of
Why isn't instrument just validating for all spec? Doesn't conform serve no
purpose here?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group,
On Tuesday, November 14, 2017 at 11:11:27 PM UTC-6, Didier wrote:
>
> | One option is to use the non-conforming s/every instead of the
> conforming s/coll-of
>
> Why isn't instrument just validating for all spec? Doesn't conform serve
> no purpose here?
>
Indeed, this could probably be changed
Logged this at https://dev.clojure.org/jira/browse/CLJ-2266 with a patch.
On Tuesday, November 14, 2017 at 11:26:45 PM UTC-6, Alex Miller wrote:
>
>
> On Tuesday, November 14, 2017 at 11:11:27 PM UTC-6, Didier wrote:
>>
>> | One option is to use the non-conforming s/every instead of the
>> confor
Saw this thread on the REPL, interesting discussion.
On Tuesday, October 3, 2017 at 10:57:34 AM UTC-7, Alex Miller wrote:
>
>
> It's not about easier, it's about possible. Open grows, closed breaks.
>
>
I agree with the broad brush, but it's important to listen to this
usability feedback befo
24 matches
Mail list logo
