This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (28)
- # beginners (169)
- # cider (3)
- # clara (2)
- # clojars (1)
- # clojure (198)
- # clojure-europe (2)
- # clojure-nl (6)
- # clojure-spec (29)
- # clojure-uk (21)
- # clojurescript (21)
- # clojurewerkz (1)
- # core-async (6)
- # cryogen (2)
- # datomic (4)
- # duct (1)
- # fulcro (26)
- # graalvm (1)
- # malli (1)
- # reitit (5)
- # spacemacs (21)
with clj / deps.edn is the only way to add default jvm opts to use a profile explicitly?
@noisesmith I believe that is correct. I think there is a JIRA ticket to consider allowing
:jvm-opts at the top-level.
@seancorfield so there's no implicit base alias, or repl alias that gets merged onto?
yeah, I'm setting up project tooling for a new app, I dont' want to force my team to all use the same shell aliases or custom config
what I want is to make this lib work by providing the right system properties at vm startup, for now I guess my best option is to make everyone switch to a custom shell script instead of using clj/clojure directly
Those seem pretty volatile to me since anyone can override them at startup, in their own environment.
I guess I could set
outpace.config.bootstrap/explicit-config-source but that still needs to be done in a way that all tasks end up invoking the code
If your library code has control before
outpace runs, you can set a default value for the JVM property if none is present.
looks like just moving the file to the expected place would solve it (but then I need some other incompatible setup for running from a jar...)
At some point we will refactor it out of our code and open source it... but I've been saying that for a couple of years already so...
do you guys use cheshire for strucutred logging, as in logging JSON to the stdout to capturing it using another tool to send it to a logs aggregator?
thanks, i will look into this cambium, i'm currently trying to combine timbre and cheshire
jackson is the biggest source of painful / breaking dep tree problems in my entire software career
but, imo, for well-defined, not-likely-to-change things, there’s a fair argument for “go with the faster thing”
there's one problem i'm facing with both org.clojure/data.json and cheshire, maybe you guys could help, i'm kinda new to clojure. timbre has an option that allows you to provide a function that will be responsible for generating the output based on the data sent to it to log, i provided a function like this one:
; for cheshire (s/defn timbre-output [data] (-> data (json/generate-string data) (println)))
; for clojure json.data (s/defn timbre-output [data] (-> data (json/write-str) (println)))
hmmm, this combination lets you send whatever object comes to you to your logging function and it manages to serialize it without exceptions?
I forget what its generate-string does with a second arg, but that's clearly not what you want
also, if that function is returning the thing you want to log, take out the println call
if it is meant to do the output, println is a weird choice but I guess it could work
you can use doto if printing for debugging purposes
(-> data json/write-str (doto println))
oh, i didn't know about doto :thinking_face: gonna check it out, thanks for mentioning!
the problem i'm facing is that both clojure/json.data and cheshire throws exceptions when they encounter an object they can't seem to convert to json, currently an instance of clojure.lang.Delay, i'd like to knows if there's any option to call .toString for objects in this condition, but couldn't find anything on the docs. although there's an option in both libraries that allows you to check the object's type and manually serialized them
this is how you add rules to cheshire https://github.com/dakrone/cheshire#custom-encoders
with clojure.data.json you extend the JSONWriter protocol for each type - it has one method
nice! now i do have a few things to look into, thank you @noisesmith and @potetm. cambium seems to be a better option in order to not reinvent the wheel, at least from what i could quickly read on their web site, in case it don't i will try the clojure.data.json approach maybe checking for the protocol implementation with
satisfies? and calling
.toString when it doesn't :thinking_face:
Is there a good reason why
println isn't concatenating on single-arity before it writes the newline to out ?
The current behavior means that newline could be out of order in a multi-thread scenario
yeah, println simply isn't thread safe, I wouldn't be surprised if that was intentional
Once in a while, I get burned trying to debug a concurrent algorithm at the repl, and realize the println isn't thread safe
Generally my fix has been to concatenate before I call println, but I realized today even the newline is not thread safe
My only small guess is maybe it is assumed that .write on a stream is itself not thread safe, so they figured no guarantees exists and so didn't bother
Anyone know of a good algorithm to group programmatically created string together? For example, "gke-qa-stable-06e4523d-grp" and "gke-qa-stable-06e4525d-grp" would belong together. "cachefiler01" and "l2cachefiler01" would not belong together. I've tried using levenshtein distance under some threshold to group strings together, but it gets several strings wrong. Ideally the algorithm would weight earlier letters more than later letters when computing the distance.
https://en.wikipedia.org/wiki/Jaccard_index have a look at this one. I found it more accurate for purpose of calculating weights of “autocomplete suggestions” that looks close to what you describe in example
If the strings all have a regular structure, it seems like parsing them and grouping them based on their parsed attributes would be more reliable than trying to use a string similarity algorithm.
For address matching (street, city, …) we used quite successful the n-gram matching. (Similar to levenshtein). If you then add additional information about your strings, like grouping the sections separated by a ‘-’ you could get good predictions. Or have the first n-grams higher weighted than the last n-grams. In clojure it will be pretty easy to be implmented with the partition function.
Interesting. About 50% of my sample of names have a hyphen and the other 50% do not. For example "devices01" and "devices02".
This might give you an idea about an unweighted n-gram match. Good luck. But really interesting task you have. 😉
This won't really work because I have a giant list of strings that needs to be grouped. I'd need to know where in that sorted list to break apart into groups.
There may be something here though. Sort, partition into groups of 2, find groups where the levenshtein is less than some threshold or percentage of word size. May work well if the groups are often pretty dissimilar.
We have customers running VMs in the cloud. They have hundreds to thousands of instances running which are not grouped in any way besides name similarity. The goal is to help them understand what they are running by grouping things together.
Which, if that’s accurate, is much easier (or only, really possible?) if you have a proper grammar
Definitely. It’s hard to enforce that at large enterprises though. These VMs cross several teams. They are interested in fixing what they have now and then work on the cultural problem.
At any rate, curious to see what you come up with. What you said about sort + levenshtein might just work gud enuf.
@kenny Look up Chris Oakman's talk on probabilistic record linkage on youtube from the last conj. It seems highly relevant to your situation except for domain differences. He even has source code in a repo on his github account.
Oh cool! I've done some work in the healthcare realm and know the data can be quite nasty. I'll be he's got some good ideas.
The sort + levenshtein only gets about 2% wrong. I’m going to watch that talk for fun but I’m guessing that error rate is acceptable.
is there a cider+company operation/function to list parameters of the function at the cursor?
oh, it is even already enabled by default, it was displaying the doc at the bottom of the window and i didn't notice. sorry and thanks at the same time @U0CJ19XAM hahahah
FYI: http://clojars.org is currently down. I'm working on fixing it now. The repo is readable, but search, uploads, and the API are unavailable.
Ok, it's back up. I was iterating on the ansible config and make a mistake there.
Are there any thoughts about upgrading the Clojure license to EPL 2.0 from 1.0? I have been nudged to do that in one of my own Clojure projects to continue benefiting from the free open-source project tier at Netlify.
i saw something about netlify changing how they offer free tier. i think i remember they will require a code of conduct in the future as well?
By the way, EPL 1.0/is an approved OSI license. So it seems it would fit the Netlify qualification
> Includes a license listed on the Open Source Initiative approved license list or a Creative Commons license that includes “attribution” or places the work in the public domain.
This is for the Open Source Plan which gives pro plan benefits for free. I did need to add my code of conduct to the project, and EPL 1.0 is not one of the available licenses because it’s deprecated to reduce license proliferation.
I don’t need Clojure to change, I was just curious about the thinking because of that license proliferation question. It’s probably inevitable because I’m sure Rich isn’t the only person to prefer 1.0.
The Program (including Contributions) may always be distributed subject to the version of the Agreement under which it was received. In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version.
Because of that, EPL 1.0 allows anyone to redistribute an EPL 1.0 program as an EPL 2.0 program.
EPL 2.0 clarifies that source distributed code as part of a program making use of an EPL 2.0 dependency can have its own code be distributed under a different license
This answers most questions https://www.eclipse.org/legal/epl-2.0/faq.php#h.hz76esowpykz
The part I'm not sure is why EPL 1.0 isn't suitable for scripting languages. I believe it is related to the wording using "module" instead of "file"
It makes it sound like by bundling your own files with EPL 1.0 files together in one module this would be considered a modified work of the original and therefore your new files should also be EPL 1.0
In Java, you could argue module means a given JAR, but even there it isn't super clear. Could it be the package? Or what is it in Clojure? Is it the namespace?
For example, if I take Clojure core and add 5 new functions to closure.core namespace? Is that derivative or modified?
In EPL 2.0 the language is very clear, if I modified an existing file, even if by only adding to it, it is modified and my additions fall under EPL as well
In EPL 1.0, if I just add functions to the clojure.core namespace at runtime, even if I do this in my own file bundled in a seperate jar, someone could claim it is a modification of the closure.core module and thus needs to be licensed as EPL as well