This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-29
Channels
- # announcements (2)
- # babashka (2)
- # beginners (76)
- # boot (6)
- # calva (7)
- # cider (12)
- # clara (4)
- # clj-kondo (11)
- # cljdoc (9)
- # cljs-dev (21)
- # cljsrn (7)
- # clojure (72)
- # clojure-dev (158)
- # clojure-europe (2)
- # clojure-italy (3)
- # clojure-losangeles (3)
- # clojure-nl (5)
- # clojure-spec (29)
- # clojure-uk (93)
- # clojurescript (40)
- # cursive (7)
- # data-science (1)
- # datomic (28)
- # defnpodcast (5)
- # duct (5)
- # emacs (7)
- # events (2)
- # figwheel-main (5)
- # fulcro (55)
- # graalvm (2)
- # instaparse (1)
- # jobs (5)
- # juxt (1)
- # luminus (3)
- # nyc (2)
- # pathom (3)
- # planck (25)
- # re-frame (2)
- # reagent (4)
- # reitit (23)
- # shadow-cljs (381)
- # spacemacs (6)
- # sql (19)
- # tools-deps (7)
- # xtdb (4)
Couldn't resist trying to create a more functional version of ->>
with no syntactic tricks.
(defn fn->> [init & fs]
(reduce (fn [x f] (f x)) init fs))
(fn->> 121
inc inc
(comp clojure.string/join reverse str))
=> "321"
I think you need a reverse in there as well
Yes, this works (anon fn syntax removed because it confuses me)
(defn fn->> [init & fs]
((apply comp (reverse fs)) init))
This command clj -Spom
adds extra blank lines to pom.xml file.
Also it adds "<sourceDirectory>src</sourceDirectory>" every time at the end when <build> tag is missing.
How can I submit this bug?
@maxp That sounds familiar. What version of Java are you using?
According to that ticket: Fixed in clj 1.10.1.478 -- are you using that latest version of the CLI @maxp?
I don't think I've heard about that other issue but you can ask a question about it in this category https://ask.clojure.org/index.php/activity/contrib-libs/tools-deps-alpha and the Clojure team will see it and either raise a new JIRA issue in response or answer with any known issues around it.
the extra blank lines should be fixed in the latest version
the sourceDirectory thing is intentional (but needs some attention still probably)
it has been brought up before but I don't know that it made it into a ticket
@seancorfield I use openjdk version "11.0.4" 2019-07-16, Clojure 1.10.1 release
sourceDirectory added at the end when there is no <build> tag. When <build> exists "sourceDirectory" appended once to it.
Could someone help me understand jdk? I had an Ubuntu Trusty running oraclejdk8. Then someone upgraded to Ubuntu Xenial, which no longer supports oraclejdk8. We switched back to Trusty for now, but it seems like we need to upgrade oraclejdk (or switch to openjdk) at some point. I'm looking for materials to understand how JDK versioning / Java versioning is related to Clojure and Lein versioning. That would tell me if I need to upgrade Clojure or Lein as well, which would give me a better estimate of how much of a hassle the upgrade would be.
@meepu probably you can use openjdk-8 instead of oracle-jdk-8. I used that for a long time after oracle-6.
I think you can use openjdk as a drop in replacement to Oracle
Yes, openjdk8 is one of our options. I'd like to understand if switching to it would be a long-term or short-term solutions - is 8 going to be outdated soon?
Clojure just recently stopped supporting JDK 1.6 and 1.7. So currently it requires JDK 8 or above
I can't predict the future, but I don't see why not. It supported JDK 1.6 for a really long time.
Is there a problem with the latest Lein and the default #inst
tag?
lein does bizarre things with bootclasspath on java 8 which causes issues with #inst @weavejester
Hello everyone
is parsing clojure functions via regexp possible ?
I don't know, but if so, it would probably be harder than it's worth
why not use a clojure parser/reader?
yeah maybe, but i was curious about regexp
a regex as in its formal definition, or the perl-derived regex eDSL that we have been using for ages now 😛
That's cheating 😛
I can’t actually find a conclusive source on what the expressive power of perl regex’es is… so sad
if you exclude ?{} and ??{} then the answer is "probably not": some context-free, some context-sensitive patterns definitely yes
yeah inlining perl code is usually not something that transfers to ‘non-perl languages’
while other constructs invented in perls regex can be used to match (some) non-regular languages are definitely being c/p’ed to other languages that embed the same ‘DSL’
If what you're thinking of is https://github.com/bhauman/rebel-readline/blob/1fc954215bc287ad590dac8e52c782d6077fee55/rebel-readline/src/rebel_readline/clojure/tokenizer.clj then it looks to me like a parser which internally uses regexes to match tokens, but isn't a regex itself
depends exactly what the question needs 🙂
thanks guys
which is exactly what the clojure reader does
regex for tokens is the standard way to parse things i suppose. I just remember seeing a bug that someone was hitting on a larger form throwing a regex error. I think @hiredman man diagnosed it was probably the repl and turned out to be a limitation in the size of forms that rebel could read
does anyone know how one can get relative times in juxt/tick
? I'm looking for something as simple as next monday
which should return the timestamp at midnight of the nearest monday closest to and excluding today (if today was monday)
well, here's a solution (some #(when (= (t/day-of-week %) t/MONDAY) %) (iterate t/inc (t/tomorrow)))
Hey, I was looking for libraries that derive customer facing error messages from clojure specs explain-data format. I found https://github.com/alexanderkiel/phrase but I was wondering whether there were other alternatives
I am specifically looking at error messages for users, so expound is too technical already
is this a bug? it seems kinda like one https://stackoverflow.com/questions/58614698/how-to-calculate-frequencies-for-sequences-containing-nans
This is to be expected. NaN is by design not equal to itself. As it describes something not being a number, not anything specific.
using NaN as a key in a map is asking for trouble, because by definition NaN is not equal to itself
user=> (assoc {} ##NaN :a ##NaN :b)
{##NaN :a, ##NaN :b}
user=> (get (assoc {} ##NaN :a ##NaN :b) ##NaN)
nil
user=>
it’s kinda interesting. in a maths context I totally accept NaN is not equal to itself. but from a programming point of view it also makes sense that it should be. unfortunately we only have one type of equality
This is an IEEE 754 standard-specified thing. https://github.com/jafingerhut/batman
There is also a section specifically on NaN in this article: https://clojure.org/guides/equality
We only have one clojure.core/=, but we also have clojure.core/==. Java has == and .equals. I don't have a reference or certainty on this, but have heard that Rust lets you have more fine control of double types with NaN vs. double types without NaN.