> on any active window top bar What do you mean by that?

I think I need something more distributable. I need to implement this as part of colledge project. And prerequesite of using this is installing driver for specific web browser.

I don't know how would I submit project, when this assumes driver installed on host os.

actually this might work. @U050PJ2EU thanks for suggestion

😄 🍺

has really intuitive API, I think I might use this

In my view the etaoin/ webdriver approach is the most useful. It uses a "real" browser (headless), so at least you know that it does teh same as a browser, specially regarding javascript.

this is true in clojure as well. the reader enforces this in the reader literals.

{(random-uuid) nil
 (random-uuid) nil}
Syntax error reading source at (REPL:655:20).
Duplicate key: (random-uuid)

It surprised me.

understandable

And then it made me laugh.

it is a little surprising since there’s also a run-time check

(let [a :a b :a] {a 1 b 2})
Execution error (IllegalArgumentException) at metabase.prometheus-test/eval138632 (REPL:657).
Duplicate key: :a

Interesting!

You can't call the same function twice in a map literal? That’s wild

Oooh, I did not know this. Thanks for posting @UPD88PGNT, and for the explanation, @U11BV7MTK

It makes sense since read is a separate step from eval, especially when you consider macros. If you tried to read:

{(random-uuid) nil
 (random-uuid) nil}

i'm not sure, why is read concerned about duplicate keys? I thought the point of the separation is because we hadn't decided how to evaluate it yet.

as in, nothing about those characters can't be parsed, so i'm not sure why its necessary to throw at that point. the macro might check the map and do something with the duplicates for instance.

though i can't see why that would be useful, it would make more sense to pass a list then, which wouldn't have the issue in the first place.

> the macro might check the map and do something with the duplicates for instance. that's my point. maps can't have duplicate keys so you can't read that data structure without throwing away information, which would be wrong in this context.

;; make sense
> (read-string "{(random-uuid) nil}")
{(random-uuid) nil}

;; doesn't make sense
> (read-string "{(random-uuid) nil, (random-uuid) nil}")

I guess it's interesting because we're evaling/considering the structure even in "read". I'm used to thinking about lists where everything can pass through.

hopefully, it's not too pedantic, but there is no evaling happening during read. it's one of the key features and differentiators of lisp that it is defined in terms of data, rather than text. the data can be parsed from text (ie. read), but it can also be produced through normal usage (eg. (eval (list '+ 1 2)) ;; 3))

the problem with (read-string "{(random-uuid) nil, (random-uuid) nil}") is the same problem you would have if you tried to do JSON.parse('{"a":1, "a":2}') (although javascript doesn't complain and happily throws away data).

no, it's not to pedantic. Or at least i should say, i have come to enjoy being pedantic, if that just means being clear in my communication 🙂 I like to think about what words commonly mean, when considering what they mean in context. In this case, I guess the terminology conundrum is best exemplified by asking someone to "read a sentence, but don't evaluate it" How can one absorb information without having some idea of it's worth? In this case the parser does do some initial determination of the structure (that it's a map) to understand how to parse it. I don't see how it could be otherwise. That's part of what makes lists so useful, is they don't impose much structure beyond order which is very natural to humans in the first place. Hense why :

{(random-uuid) nil
 (random-uuid) nil}

(read-string "(1 2")

You may find this exchange between and alan kay on Hacker News interesting, https://news.ycombinator.com/item?id=11941656

> Data - something given, seems the raw material of pretty much everything else interesting, and interpreters are secondary, and perhaps essentially, varied. The exchange covers some of the topics you're expressing. I think the above quote gives a succinct case for lisp's separation of read and eval.

I suppose i find myself understanding Alan better this time around. i would argue a list or a hashmap is an "ambassador" across systems.

the real lesson is to not start a conversation with a "X is bad" statement unless that x=bad.

and if you say "bad is bad" you have to follow it up with an old timer western spit.