Clojurians Log v2

I asked @viebel if it was possible to have Klipse enable speculative: http://app.klipse.tech/?cljs_in=(require%20%27speculative.core)%0A(require%20%27%5Bclojure.spec.test.alpha%20%3Aas%20stest%5D)%0A(stest%2Finstrument%20%60map)%0A(map%20%27lol%20%27lol)&external-libs=%5B%22https%3A%2F%2Fraw.githubusercontent.com%2Fviebel%2Fspeculative%2Fmaster%2Fsrc%2F%22%2C%20%22https%3A%2F%2Fraw.githubusercontent.com%2Fmfikes%2Fworkarounds-1.10.439%2Fmaster%2Fsrc%2F%22%5D

@viebel has joined the channel

You might want to disable your ad-blocker

@bbrinck ^

https://gist.github.com/borkdude/8a977fa453c6ee26fefcecb4c88fe1f2 I want to include one more dimension: usefulness. So if a spec isn’t going to find bad input, it’s not useful to instrument.

Did you have any thoughts on disabling certain specs for people using 1.10.439? I just tried speculative in my project and immediately got “Maximum call stack size exceeded.”

apply may be fundamentally un-instrumentable in cljs. but I can live with that

Yeah. I’m just wondering if speculative is usable by anyone currently. I suppose it really depends on what your app does.

(For ClojureScript apps, at least.)

that’s what I’m trying to solve with the above penalty thing: to make it usable for developers by only enabling certain specs

I don’t mean usable in terms of perf. I mean show-stopper, I can’t even start my app, sort-of thing.

apply is the only show-stopper I think. comment out that one and try it again?

funny enough I can instrument apply in self-hosted cljs in Klipse (see earlier today)

calling (stest/instrument) in Klipse gives an analysis error

apply does work for clojure itself, not cljs

Yeah, you definitely want to enable speculative after your app is up and running

Especially on an iOS device

Our web app (client + server) becomes noticeably slower when instrumenting everything even after startup. That’s why I’m thinking of a “dev” profile using the above scores

@mfikes I notice our tests also pass without including the “workaround” in core, so I moved it to the test deps. Also I moved Clojure there, so users can decide what version of Clojure they want to bring. If you’re ok with this, I’ll merge.

https://github.com/slipset/speculative/pull/83

Users can opt-in in the “workarounds” lib if they want. And with that in place, our deploy is fixed as well.

Sounds good to me

@slipset what’s the current way of deploying: is every merge to master deployed, or only when you push to master?

every merge to master is (should be) pushed to clojars as a snapshot-release

ok thanks. I want to test if speculative is usable and I think so now.

when depending on it via a mvn/version

If we want to do a proper “release”, eg one without “-SNAPSHOT”, I might just have to do it manually from my computer.

hmm, maybe not.

maybe put a println in that script to check 😉

#!/bin/bash -eo pipefail
.circleci/maybe-deploy.sh
Skipped command Created /home/circleci/repo/target/speculative-0.0.2-SNAPSHOT.jar
Wrote /home/circleci/repo/pom.xml
Retrieving speculative/speculative/0.0.2-SNAPSHOT/maven-metadata.xml 
    from 
Sending speculative/speculative/0.0.2-SNAPSHOT/speculative-0.0.2-20181106.212336-164.jar (12k)
    to 
Sending speculative/speculative/0.0.2-SNAPSHOT/speculative-0.0.2-20181106.212336-164.pom (3k)
    to 
Retrieving speculative/speculative/maven-metadata.xml 
    from 
Sending speculative/speculative/0.0.2-SNAPSHOT/maven-metadata.xml (1k)
    to 
Sending speculative/speculative/maven-metadata.xml (1k)
    to 

ah, alrighty

so it seems like it sends it there…

good, thanks

yes, https://github.com/slipset/speculative/commit/8cf4f60cdf151a40f5c21ebf089bee17da38675f is the latest commit reported by clojars on 0.0.2-SNAPSHOT

yep, then it’s working as it should