This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (91)
- # boot (5)
- # cider (30)
- # clara (16)
- # cljsjs (3)
- # cljsrn (6)
- # clojure (84)
- # clojure-dev (4)
- # clojure-dusseldorf (1)
- # clojure-italy (15)
- # clojure-nl (2)
- # clojure-spec (5)
- # clojure-uk (120)
- # clojurescript (54)
- # core-async (25)
- # core-matrix (1)
- # css (2)
- # cursive (20)
- # datomic (28)
- # editors (11)
- # emacs (6)
- # figwheel (4)
- # figwheel-main (28)
- # fulcro (36)
- # graphql (7)
- # hyperfiddle (2)
- # jobs (6)
- # jobs-discuss (10)
- # lambdaisland (1)
- # lumo (3)
- # nrepl (20)
- # off-topic (24)
- # pedestal (2)
- # protorepl (3)
- # reagent (3)
- # reitit (2)
- # remote-jobs (1)
- # ring-swagger (26)
- # rum (1)
- # shadow-cljs (247)
- # spacemacs (29)
- # tools-deps (12)
- # vim (15)
Can you override a defmethod only within a form? Similar to how with-redefs can redef a normal function only within its form?
is there a less-icky way to say “if this isn’t in a seq, put it in one” without flatten?
that just smells off to me
(flatten (conj  x))
the real fix is to never have something that sometimes returns a collection and sometimes doesn't; as a consumer of a bad api you don't always get to make that choice though
(I have a few of those at work, in code written years ago, and I shudder every time I have to interact with those functions)
Is there anything like
lein-ancient, compatible with
Any love here for AWS ElasticBeanStalk? I just managed to set a Java project up, and it seems to be working nicely (as in, I don’t have to worry about much, just upload a new uberjar and everything seems to be going well). Any horror stories I should know about?
Yeah that’s my worry, but I’m not sure how it differs from other clouds. Did you use CloudWatch or whatever that’s called?
So what are alternatives? It is kinda slow to deploy but if you use big instances it takes a minute or so and it does rolling deploys, health checks and so on.
I started testing it out with a t2.micro and that was painful, but with an m5.large deploys and conf. changes go fast.
I only spent one day trying to piece everything together using a toy app, so I’d have to do something bigger to see what it looks like.
I suppose with EBS rolling deploys aren't mutating in place, it's spinning up a new one and then async killing old ones.
I don’t think my workflow went through code deploy. I was manually uploading a prebuilt jar to the console.
Sure, but I think that's a general pattern. Terraform does the same for blue/green deploys.
So, I built an uberjar with lein, and I've stepped on a static initializer based problem
when i "lein run" the problematic static initializer is not run unless I execute the codepath that depends on it
when i "java -jar" the static initializer runs, and it's a problem for some codepaths that do not depend on it
CodeDeploy to EC2 instances in AutoScaling Groups behind a ALB. All created via terraform. Uberjar generated with pack.alpha
I’d love to have a sample terraform file. Any good resources out there?
Cloudposse have a lot of great modules, combined with our rock ami it's fairly distinct.
We can't do CD for compliance reasons - releases need sign off. But it's on my list for dev, just lower down because it's not so useful to us.
Generally CI/CD doesn't seem so important, you can run tests locally and shout if someone breaks them.
I’d love to have a sample terraform file. Any good resources out there?
Trying to remember a blog or Hickey talk/essay but my google skills are failing me. It basically describes clojure as a good language to use in long running systems with requirements that change over time and have to deal with messy human inputs as opposed to things like compilers that generally have a more fixed idea of the world and more slowly changing requirements etc. Does anyone know the post?
am i doing something wrong here reading in env vars at startup?
I keep getting a bad cast-
(def config (read-string (or (System/getenv "MY_ENV_FOO") "5"))) ... (with-redefs [some.ns/sym config] (run-app)))
java.lang.String cannot be cast to clojure.lang.IPersistentMap
@lwhorton First off, I'd advise against using
def for something that interacts with the environment since it will run whenever the namespace is loaded (e.g., at compile time). Second, that error sounds like something expects
some.ns/sym to resolve to a hash map?
(oh, and from a security standpoint, don't use
read-string on arbitrary external data -- it can be made to run arbitrary code and thus "hack" your application!)
Use something like
Long/parseLong if you just want to safely turn a string into an integer.
ah… i see the other problem now- i’m using with-redefs which is a macro. so i’m mixing my compile time + runtime. thanks for the info @seancorfield
Is it a known issue that the spec for valid Clojure symbols (https://clojure.org/reference/reader#_symbols) is wildly inaccurate? The EDN spec if correspondingly wrong (https://github.com/edn-format/edn#symbols), which is the context in which I encountered the issue. It seems essentially any Unicode character not otherwise reserved can be used, including some insane ones like
=> (type (clojure.edn/read-string "µ")) clojure.lang.Symbol => (type (clojure.edn/read-string "🔥")) clojure.lang.Symbol => (type (clojure.edn/read-string "\0")) clojure.lang.Symbol
> A symbol can contain one or more non-repeating ':'s. what does non-repeating mean? non-consecutive?
There's a lot in the specs that the implementations don't validate. But if you go outside the spec, don't be surprised if future validation tools throw errors at you.
So I guess if you're implementing an EDN parser in another language, you have two options: either follow the spec, and break on certain EDN that works with the official parser. Or try to match the official parser, but know you're "wrong" and it might break in the future.
I love EDN, think it's a great data format, but that makes it very hard to justify using for any serious cross-language project
If you're building inbound validation into your implementation, you should probably implement to the spec.
As a lib author, I wouldn't worry as much about breaking on certain EDN that happens to work with the official parser. The core stuff has to be a little more permissive for historical reasons. And perhaps some performance reasons. But a stricter implementation would probably be welcome by a lot of folks.
It isn't clear to me what might break in the future if you match the "official parser" behavior when reading. As far as I recall, at least, the English spec is strictly more constrained in what it allows as compared to the official parser.
Agreed that if you write code that generates EDN that is outside the constraints of a future more-strict-parser, that more-strict-parser will not accept such files.
My point is that a spec is only as useful as its most popular implementation. If
clojure.edn can generate, and parse, EDN data with symbols outside the defined spec, what is the purpose of the spec? A user could justifiably say "I made this EDN file using Clojure itself - why can't your tool read it?" and "the spec says so" wouldn't be a satisfying answer
Note that the Clojure reader docs don't even cover all the symbol characters used in
clojure.core (!!!) -
> are definitely missing, maybe more
I have discovered this issue working with syntax highlighters in the past too where allowable-but-non-spec-conformant symbol characters were syntax highlighted incorrectly or threw errors
You can vote on this issue if you are interested in maybe seeing tighter docs on this topic: https://dev.clojure.org/jira/browse/CLJ-1527 Some of the description and comments on that issue list some of the things you mention, and perhaps others you haven't seen yet.
If you want tight specs with sharp edges for "in" or "out" on every question, Clojure and EDN are not currently the kind of place where those abound.
Or I guess as you point out, there are multiple tight specs (English, spec, code implementations) that do not match each other exactly.
Given the Clojure core team's strong emphasis on backwards compatibility, Hyrum's Law comes into play: http://www.hyrumslaw.com
I think a "living spec" based on the Clojure implementation is a great approach - I just think it's misleading to have an "official" spec/documentation that doesn't line up with reality
Especially since the EDN spec claims a formal (i.e. BNF) specification is forthcoming (as of 4 years ago...): https://github.com/edn-format/edn#spec
My guess: If you implement something compatible with the current implementation, that is likely to change more slowly than the docs.
Does anyone ever switch out clojure.core for their own version eg.
(ns foo (:refer-clojure :only ) (:use my-stricter-clojure.core))?