This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-03
Channels
- # aleph (1)
- # announcements (9)
- # babashka (3)
- # beginners (200)
- # calva (22)
- # cider (74)
- # clojure (97)
- # clojure-dev (43)
- # clojure-europe (15)
- # clojure-italy (4)
- # clojure-nl (4)
- # clojure-sanfrancisco (2)
- # clojure-uk (103)
- # clojuredesign-podcast (2)
- # clojurescript (45)
- # core-async (5)
- # cursive (13)
- # datomic (42)
- # emacs (20)
- # fulcro (6)
- # graalvm (37)
- # jackdaw (10)
- # leiningen (7)
- # mid-cities-meetup (3)
- # off-topic (2)
- # pathom (1)
- # pedestal (3)
- # re-frame (6)
- # reagent (38)
- # reitit (5)
- # shadow-cljs (117)
- # spacemacs (1)
- # sql (1)
- # tools-deps (17)
- # vim (14)
- # xtdb (18)
As ring is heading towards using namespaced keys in request & response maps (https://github.com/ring-clojure/ring/issues/393), is there a plan to support namespaces keys with records?
I guess the lookups for unqualified & qualified keys from maps should have about the same performance?
a quick test for a field lookup for a ring-request map (14 keys) using: 1. qualfied key 24ns 2. unqualified key 20ns 3. record with unqualified key 4ns
Ran this test with a structmap for my own comparison.
Structmap with key: (:foo/bar x) 24ns
Structmap with accessor: (bar x) 11.65ns
Record: (:bar x) 15.83ns
if not record, maybe some new map-like type which would enable fast lookups with known qualified keys?
given how much things get added to request maps, I don't think records are necessarily a good choice anyways - changing a record means instantiating a new record
there are many ways request maps are used - focusing only on key lookup performance is missing other parts of the picture
it seems weird, but you may actually want to look at struct-maps
although I'm not sure struct-maps support ns'ed keys well either, I don't know if I've ever used them
They do not. clojure.java.jdbc used to use them years ago and switched to regular hash maps. Someone did some perf tests on next.jdbc early on and suggested I switch from regular hash maps to struct maps for improved performance but the lack of qualified keys was a blocker for that. Using a record for a result set row is a faster option (but also doesn't support qualified keys).
They seem to work for me, although they print wrong:
user=> (defstruct bar :bar/example)
#'user/bar
user=> (def example (accessor bar :bar/example))
#'user/example
user=> (struct bar "foobar")
#:bar{:bar/example nil, :example "foobar"}
user=> (keys (struct bar "foobar"))
(:bar/example)
user=> (example (struct bar "foobar"))
"foobar"The bug starts in lift-ns. It creates an empty of the struct, which still includes the key as nil, ofc. And also includes the ns-removed version of the key.
Simple answers are to convert structs to hashmap before printing, or to have lift-ns not use empty but instead an empty hashmap.
Interesting. I don't remember what tests I ran but I know I didn't get anything like the results I wanted so I came away thinking you couldn't use qualified keys at all in structs... Clearly, I didn't test extensively 🙂
That is actually already logged as it affects sorted maps
I’ve spent some time looking at it and it’s annoying
a customized map-like data structure optimized for known usage patterns may make sense here. I don't know that records are the right answer. getting a clearer picture for the operations and their frequency is the first step though
Started to investigate this. Never used struct-maps, but good time to understand how they work (even if not suitable for this). My interest is in optimizing the read part and now think the best way to do it is a mix of protocols, lazy evaluation and a map-like custom type to make it ring-compatible. Thanks for the pointers.
the current full-copy request with ring/takes 2.4µs on my MacBook. Goal is get into <200ns for apps that only need anything but the non-normalized info (like headers) and a <50ns for the benchmark case of just uri & request-method.
writing the whole request into log will be as slow as full-copy, can't help with that.
changing a record means instantiating a new record
how's that different from changing a map?
yeah, it's at least something that should be considered
@alexmiller dunno if you get notified about jira comments (I don't anymore), but resolve introduces a bug
if we don't want to open up the compiler, we could do it in a similar way as we do it for defn
(if (clojure.lang.Util/equals nil (clojure.lang.Compiler$HostExpr/maybeSpecialTag tag))
(let [c (clojure.lang.Compiler$HostExpr/maybeClass tag false)]you should get notified, but some of the "created by"/"updated by" metadata was broken in the migration - by default you should get notified if you created it, are watching, or voted for it
I may not receive the emails I care about anymore, but Atlassian makes sure I get those sweet sweet spam ones :)
is it possible to go back to receiving emails about issues created on my projects? I looked everywhere and couldn't find how to
I can probably fix that, will look at it later
I've updated the notification scheme both for your projects and many others to have project lead notification like we had on the old jira
I looked at your settings and some of the project settings. in general, you should receive updates if a) you reported the issue, b) you are the assignee, or c) you are "watching" the issue. Now, in the projects where you are a lead, you should also get updates on issues in your projects.
if you find a specific issue and a specific event that you don't get an email for, let me know and they have a tool that can use all that info and tell me what notifications you should get and why
what's the bug?
user=> (defprotocol p (^longs f [_]))
p
user=> (set! *warn-on-reflection* true)
true
user=> (defn foo [x] (aget (f x) 0))
Syntax error (IllegalArgumentException) compiling . at (REPL:1:15).
Unable to resolve classname: #'clojure.core/longssorry, you prob put it on the ticket
seems like there should be tests to expose this
They do not. clojure.java.jdbc used to use them years ago and switched to regular hash maps. Someone did some perf tests on next.jdbc early on and suggested I switch from regular hash maps to struct maps for improved performance but the lack of qualified keys was a blocker for that. Using a record for a result set row is a faster option (but also doesn't support qualified keys).
They seem to work for me, although they print wrong:
user=> (defstruct bar :bar/example)
#'user/bar
user=> (def example (accessor bar :bar/example))
#'user/example
user=> (struct bar "foobar")
#:bar{:bar/example nil, :example "foobar"}
user=> (keys (struct bar "foobar"))
(:bar/example)
user=> (example (struct bar "foobar"))
"foobar"