This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-08
Channels
- # adventofcode (49)
- # babashka (21)
- # babashka-sci-dev (12)
- # beginners (250)
- # calva (23)
- # cider (6)
- # clj-kondo (11)
- # cljsrn (8)
- # clojure (129)
- # clojure-europe (50)
- # clojure-france (8)
- # clojure-italy (6)
- # clojure-nl (14)
- # clojure-romania (7)
- # clojure-spec (21)
- # clojure-uk (3)
- # clojurescript (17)
- # conjure (1)
- # core-async (40)
- # core-logic (24)
- # core-typed (7)
- # datavis (2)
- # datomic (2)
- # emacs (29)
- # fulcro (10)
- # graalvm (6)
- # graphql (24)
- # gratitude (6)
- # jobs (1)
- # lsp (9)
- # malli (6)
- # missionary (1)
- # nextjournal (46)
- # off-topic (2)
- # other-languages (3)
- # pathom (5)
- # portal (2)
- # re-frame (37)
- # remote-jobs (1)
- # shadow-cljs (15)
- # spacemacs (9)
- # testing (6)
- # tools-deps (13)
- # vim (32)
- # xtdb (16)
Good morning!
all stories
(that include gods)
Hm. I shouldn’t offend. But like the example you gave, I find that in most stories, gods have weird motivations and/or act weirdly. That’s a general thing when people are writing about sentient human-like entities that aren’t quite human, I find. Another example is ghosts. In most movies I’ve seen, ghosts are assholes or just random, for no apparent reason.
I guess, because in both fables and ghost stories, the human-like entities often serve as a plot device; generating a situation that the human protagonist(s) can react to (like divine intervention, or throwing around pots and pans)
(I’m conflating nonsensical and dumb here)
Thus concludes my TED talk 🙂
With gods, even if you conceded that they exist, it’s still difficult to understand what they want with us or how we are meant to respond to them
That’s the strangest part to me: there is no evidence of them expressing their Will and none of the holy books withstand any serious examination
Continuing on making clojure.spec.alpha compatible with bb by making minimal changes to the original repo, I've now got coax by exoscale working:
(require '[babashka.deps :as deps])
(deps/add-deps
'{:deps {babashka/spec.alpha {:git/url ""
:git/sha "4fb8ef0f8ca1700e7ff152b7691e5170eeb8690f"}
exoscale/coax {:mvn/version "1.0.0-alpha14"}}})
(require '[clojure.spec.alpha :as s])
(require '[exoscale.coax :as c])
(s/def ::foo keyword?)
(prn (c/coerce ::foo "bar")) ;; -> :bar
(s/def ::dude int?)
(s/def ::bar (s/keys :req-un [::dude]))
(prn (c/coerce ::bar {:dude "1"}))
$ time ./bb /tmp/hato.clj
:bar
{:dude 1}
./bb /tmp/hato.clj 0.08s user 0.03s system 95% cpu 0.111 total
user=> (require 'exoscale.coax-test)
nil
user=> (require '[clojure.test :as test])
nil
user=> (test/run-tests 'exoscale.coax-test)
Testing exoscale.coax-test
Ran 18 tests containing 145 assertions.
0 failures, 0 errors.
{:test 18, :pass 145, :fail 0, :error 0, :type :summary}
(in bb repl)We have another related lib that we might open source eventualy. Something that has to do with "humanized" error messages for spec. Nothing too exotic in its source either, pretty sure it would work with bb out of the box
It's similar, but slightly different. It actually started from frustrations with expound & others and the need to have more structured/data output to feed error messages for, say, forms (so "row" level messages/problems).
(oh the file is called hato.clj
because originally I tested that because it defines one spec somewhere in a util ns)
All clojure.spec tests pass, except those that were added last month because of the changes in clojure 1.11 with respect to kwargs... The changes to spec to support that look really complicated.
Ran 11 tests containing 115 assertions.
0 failures, 0 errors.
{:test 11, :pass 115, :fail 0, :error 0, :type :summary}
😎Having a weird css problem. Using the :read-only
selector, but hitting a bunch of input elements (like :select
) that don’t have readonly
set.
Anyone here have any experience with that?
argh css
makes me unhappy 😞
E.g. <body>
does not support it as well, of course, and document.querySelector('body:read-only')
returns the right element still.
sorry, I was imprecise. I’m talking about e.g. [:input {:type :checkbox}]
,
[:input {:type :select}]
The thing is, these elements do not have readonly
applied to them, but they are still hit with a .myClass:read-only
selector
and no docs are convincing me that this makes sense
And yeah, readonly
is applicable only to some types of <input>
: https://html.spec.whatwg.org/multipage/input.html#do-not-apply
And all other elements are considered "read only", at least for the purpose of that selector: https://html.spec.whatwg.org/multipage/semantics-other.html#selector-read-only
> The `:read-only` https://drafts.csswg.org/selectors/#pseudo-class must match all other https://html.spec.whatwg.org/multipage/infrastructure.html#html-elements.
ARgh. You’re right, it was [:select
and [:input {:type :checkbox