This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-12-20
Channels
- # adventofcode (140)
- # beginners (107)
- # boot (120)
- # boot-dev (1)
- # clara (13)
- # cljs-dev (9)
- # clojure (107)
- # clojure-argentina (5)
- # clojure-art (16)
- # clojure-dev (23)
- # clojure-greece (19)
- # clojure-italy (5)
- # clojure-russia (2)
- # clojure-serbia (3)
- # clojure-spec (27)
- # clojure-sweden (1)
- # clojure-uk (15)
- # clojurescript (134)
- # cursive (5)
- # data-science (10)
- # datomic (23)
- # duct (28)
- # fulcro (48)
- # garden (5)
- # hoplon (2)
- # instaparse (1)
- # klipse (7)
- # leiningen (8)
- # lumo (36)
- # off-topic (72)
- # om (4)
- # onyx (37)
- # perun (4)
- # re-frame (64)
- # reagent (86)
- # remote-jobs (1)
- # shadow-cljs (59)
- # spacemacs (16)
- # sql (1)
- # uncomplicate (6)
- # unrepl (90)
We put Clojure 1.9.0 into production today. We've been on RC builds in production for a while so it was uneventful (as all of our Clojure version upgrades are!).
Isn't it boring to be on an actual release though? :)
I'm already looking forward to 1.10-alpha1!!! š
https://clojuredocs.org/clojure.string/capitalize <-- I can't believe there is a builtin function for this.
@qqq Even after seven years of Clojure, I still find new-to-me functions in the core namespaces š
my jvm is crashing after some time developing. this is a mixed clojure+java projects and I'm using plugins like virgil (to reload java classes). I get the crash log but no core dump even though jvm said it wrote it (probably just need to change location). so.. first question, is this something that is more or less expected or a strong indication of a bug?
Sounds very unusual to me, but I don't use Virgil so it may be an issue with that.
I've been doing Clojure for over seven years and my experience -- both of the REPL when developing locally and of Clojure in heavy production use -- is that it's rock solid.
asking because to me this seems suspiciously like the classic PermGen OoM error with plain Java but could also be just my previous experiences. I'm on 1.8 java, the mem consumption doesn't look too bad to the OS but I haven't visualvm'd this yet. I'm new to Clojure but know my java, so I'm not sure whether I should stress out about it at this point or not. This is not in production yet but I really wouldn't like to find out at that time
clojure.string/capitalize is a very strange thing to have in Clojure, I agree. It also has a subtle bug. (Hint: Java strings, and thus Clojure strings, are represented in memory encoded as UTF-16)
but such corner cases of Unicode are best left for more comprehensive libraries like ICU4J
really hope that DL4Clj could be updated more efficiently.
is there something that makes the stack traces a bit more human readable? using vanilla lein run
at the moment
at least something that highlights the stack lines which are in my code, as opposed to clojure.lang...
Not sure if Ultra does exactly that, but you could give it a go: https://github.com/venantius/ultra
Also https://clojure-expectations.github.io could help with test stacktraces.
I'm translating this to Clojure. Is there a amore idiomatic way instead of converting the while loop into a loop-recur?
;; private static byte[] toByteArray(InputStream inputStream)
;; throws IOException
;; {
;; ByteArrayOutputStream baos = new ByteArrayOutputStream();
;; byte buffer[] = new byte[8192];
;; while (true)
;; {
;; int read = inputStream.read(buffer);
;; if (read == -1)
;; {
;; break;
;; }
;; baos.write(buffer, 0, read);
;; }
;; return baos.toByteArray();
;; }
It's fine to get either a byteArray or a string as output -- this data won't be too large -- it's the error msg (or stdout) of a very simple process).(do
(... read ...)
(while (not= read -1)
( ... write ...)
(... read ...))
(.toByteArray baos))
I don't think there's do-while
in Clojure.
(doseq [r (take-while #(not= -1 %) (repeatedly #(.read is buff)))] (.write baos buffer 0 r))
according to https://clojuredocs.org/clojure.core/slurp , slurp takes IhnputStream as an argument too
a quick question. This to me was perhaps not what I expected:
((every-pred =) 1 2)
=> true
I assume this is caused by the fact that (= 1) => true
and that every-pred
applies every predicate to one argument at a time, is there anything in clojure core that would do this but apply all arguments to the predicatesthe docs for every-pred
are not entirely conclusive here:
> Takes a set of predicates and returns a function f that returns true if all of its composing predicates return a logical true value against all of its arguments, else it returns false.
, but I guess I can see why it's implemented this way
@mbjarland probably youād need to use
(every? (every-pred pos? (partial > 0)) '(1 2 3 -1))
Hey, so I know the Clojure philosophy is, wrt errors and stack traces, barf everything and let the tools sort it out. Is there a REPL tool to sort it out? Something usable with lein repl
?
I have stack traces that contain prn-str data (from pedestal) that exceed my 5000 line scrollback.
(different question) do you know if Clojure support as many characters for keywords as for strings ?
I need to handle JSON documents, and the library is converting each JSON key to a keyword instead of a string
If you pr-str/read-string it, this will definitely cause problems. I'm pretty sure that keyword
does not validate the contents of the namespace or name, and they are stored as Java String
.
@fmind Hmm. It might not deal with the crazy amount of data in ex-info
but this seems nice. Also ultra
which uses it seems pretty useful.
Keywords are made of strings. If you are programatically creating and using them you should be fine
But donāt expect to be necessarily be able to print and read as data
Also keep in mind that keywords are interned so there are memory effects if using a large number of arbitrary keywords
itās entirely valid (IMHO preferable) to just tell the json library not to keywordize - both clojure.data.json and cheshire let you choose, and almost everything else is using one of those
our codebase has a bunch of nonsense for handling numbers that got turned to strings when they were keys in json, then turned into keywords when retrieved from the jsonā¦ huge headache
@scriptor yeah the problem was that the people integrating monger (the clojure mongodb wrapper) didnāt realize keywordizing was optional, and didnāt sanitize the data to make sense for mongo insertion (eg. avoiding numeric keys), and by the time it was pointed out that we had other options the inconsistency of number / string / keyword in the data keys was baked into all the code consuming the data
yeah, only way to avoid situations like that is mandating thorough code review from more experienced people
which can be hard to do if most people on the team are still somewhat unfamiliar with clojure and/or its libraries' conventions
right, a few iffy decisions made in the beginning (āmove fast and break things!ā) then years of pain
even experience people often get really annoyed when keys aren't keywords and write elaborate mapping layers
yeah - itās a weird thing that causes so much bs
it's probably because you can't use (keyname map)
syntax to get values when keyname
isn't keyword.
Clojure encourages keywording
Honestly, keywordizing user input is one of the biggest time sinks in the clojure community.
and the benefits of not having to convert from/to keywords are way more than saving 3 characters
@ghsgd2 I would be quite upset if I saw (:1234 foo)
in my codebase, those keywords existed because nobody realized how easy it would be to not create them
not a big fan of using maps as functions, personally, have to do a double-take to realize that it's a map and not a function defined elsewhere
The only thing I find a little confusing in this situation is that the external keys may come in via strings - and you leave them that way, but internally you probably have maps you make with keywords (in clj-land). so now you have both and that can get awkward or error prone
@scriptor but the nice thing is you can swap it out later for a function with no change to the code
@mikerod if the key comes in via user input, I prefer to make the key a string
and for reasons that should be obvious, I donāt use the same data structure to look up based on user input and compiled code
I mean, lisps are about arbitrary code at runtime and all but I like to pretend Iām not absolutely bonkers
is there a lot of expressive power gained from the whole IFn thing where keywords and collections can be in function position? as a newb I was totally surprised the first time I saw that, and Iām not 100% sold that the terseness is actually better for readability (echoing @bronsaās statement that get is only 3 chars). but maybe it is nice to have once you get used to it?
@justinlee itās often that I discover some function that I wrote can be replaced by a simple hash-map, and since hash maps are much less powerful than functions itās always a win to do that substitution
thatās a refactor that would be impossible if hash-maps didnāt implement IFn
@lee.justin.m it really is convenient, esp when you can use them HOF (e.g. (map :foo my-coll)
), but it's also really important to know when reaching for that conveniency causes unnecessary performance issues or having to handle conversions down the line
right -it can make chained data access in nested data much cleaner
@jstew but similarly to what I was saying about not using the same data for user input lookup and program lookup, I also donāt tend to write code such that user input comes in deeply nested, and yes I would absolutely use keywords for program created nested data structures
and this doesnāt run into the problems with keyword/ string cross conversion we were discussing
Ā„es indeed. When first starting with clojure I spent lots of time converting everything to keywords since it ālooks prettierā. Esp with JSON there are dark corners to get caught in like you mentioned.
also I canāt recommend transit enough if you need to write data to json (or external storage in general) in one place and then read it from another
if I was remaking our app all the mongo insertions would be small json maps, with the indexed keys at the top, then a larger transit encoded payload under one key with the actual original clojure data embedded
come to think of it I should make a small library that implements that pattern
@hiredman heh thereās some out of band / external stuff behind that but fair point
its been my experience that even with a "greenfield" project datastore choice is almost always dictated to you
glad to know itās not just me
in some ways it seems like validation of one of the core propositions of clojure, data is more important than programs
>wishes heād never gotten excited about MongoDB all those years ago... Me, 3 1/2 years ago: āAh weāll never get funding, Iāll make the app in Swift.ā (Narrator: they did)
I'm trying to rewrite:
Pointer kernelParameters = (
(new int[]{numElements}),
(deviceInputA),
(deviceInputB),
(deviceOutput)
);
as
kparam (Pointer/to
(Pointer/to (int-array [numE]))
(Pointer/to devA)
(Pointer/to devB)
(Pointer/to devOut))
but I'm getting a "no matching method: to" on the first "Pointer/to" line -- this is despite I already have an (:import [jcuda Pointer])
I need some way to make a call tothis function: http://www.jcuda.org/jcuda/doc/jcuda/Pointer.html#to(jcuda.NativePointerObject...)
is Pointer/to varargs? EDIT - yes, it is, and that means you need to put all the variable args into an array
wow, thatās a lot of calls to into-array, if I were doing this Iād make a function that constructs the varargs and calls the method (or maybe a macro)
@rauh: thanks! @noisesmith: yeah, agreed, this is "1. make it work; 2. make it pretty" ; I'm currently on step 1
I'm expecting:
devA (CUdeviceptr.)
_ (Pointer/to (to-array [devA]))
to work, but it's telling me "NO matching method Found to"right, you need into-array
as I understand it yes