This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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)
- # crux (18)
- # 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)
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
(: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
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?
@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
(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'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
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/longs