This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-15
Channels
- # adventofcode (13)
- # aleph (5)
- # announcements (8)
- # beginners (87)
- # calva (9)
- # cider (102)
- # cljs-dev (71)
- # cljsrn (2)
- # clojure (198)
- # clojure-dev (28)
- # clojure-europe (3)
- # clojure-italy (27)
- # clojure-nl (3)
- # clojure-spec (1)
- # clojure-uk (43)
- # clojurescript (121)
- # component (11)
- # cursive (20)
- # data-science (13)
- # datascript (2)
- # datomic (102)
- # dirac (4)
- # duct (5)
- # emacs (14)
- # figwheel-main (7)
- # fulcro (37)
- # hoplon (11)
- # jackdaw (3)
- # jobs (2)
- # leiningen (16)
- # nrepl (2)
- # off-topic (51)
- # pathom (34)
- # pedestal (12)
- # perun (10)
- # portkey (1)
- # re-frame (6)
- # reitit (1)
- # shadow-cljs (21)
- # spacemacs (8)
- # tools-deps (2)
- # vim (2)
I somehow happened across the new programming language Pyret recently. It seems to have a fairly well thought out definition for 3 different equality operators, including identical, equal-always, and equal-now, where equal-always looks very close to Clojure =, but Clojure = also does double duty for equal-now, which is more like Java .equals: https://www.pyret.org/docs/latest/equality.html
Stuff I geek out on after writing the equality guide for Clojure: https://clojure.org/guides/equality
If you come here with info about performance degradation from latest java 8 or 11 upgrade, please provide me the following info: 1) java -version (when it is happening) 2) Clojure version 3) Leiningen version (if using lein) 4) a repo where you experienced the problem 5) the command you run in that repo to see it
@alexmiller You might want to look at this thread: https://groups.google.com/forum/?fromgroups#!topic/mechanical-sympathy/lflljWsKw0M - 8u201 received a zero-day fix that screwed up performance for static methods
This looks entirely relevant, thank you for the link. In particular this affects perf during static initialization and user.clj is loaded during RT static initializer, which matches several things about the repro
https://github.com/hiredman/weird-user-load-performance is a small reproducible case the user.clj performance issue I was helping someone with earlier. what I see is on some jdks loading core.async from user.clj takes about twice the time as loading it from a -i
script. this appears to be in some way general slowness loading code from user.clj, more apparent when it is macro heavy
yes, the macro heavy aspect seems to be common across multiple cases
I filed a Java bug report
@alexmiller can you put a link to the bug report?
I presume it is going through some triage machinery to measure its worth
and then, if we are very lucky, it will become a Bug
but more likely, they'll just ask for Java code
if you mean with native-image, then yes it's much faster to start, but it's precompiled so can't jit based on runtime data and is maybe slower after that
there are some significant limitations with dynamic loading so it depends a lot what your program is doing as to whether you can make a native image at all
Is this intentional?
(meta '^:x []) ;=> nil
while
(meta '^:x [:a]) ;=> {:x true}
(meta '^:x a) ;=> {:x true}
Looks like a bug@alexmiller FWIW Rich vetted the ticket a long time ago, before it was closed as duplicated and I reopened it, dunno if it should've been bumped back to pre-vetted
yeah, I know. It's fine. (needs screening of course)
it happens :)