Fork me on GitHub

anyone running clojure on 64bit arm cpus ? (something like the latest raspberry pi , enhanced beagleboard or olimex' olinuxino A64 ? ) . there supposedly is a java 8 out for these , but would like to hear if anyone has had success on these ?

Bobbi Towers10:09:50

Works great on my Pi 3 and Zero W, but they're both 32bit OS (even though the Pi 3 is 64bit CPU)


zero w having only 512mb of ram, doesn't that get a little restrictive ? and what java are you using there 🙂

Bobbi Towers10:09:30

Java 8, and yeah it struggles considerably if you ask it to do too much

Bobbi Towers10:09:06

I'd really like to use Planck on there, but couldn't get it working


is it a bug of Clojure 1.10.0-alpha8? (import 'java.sql.Date) (import 'java.util.Date) Exception in thread "main" Syntax error compiling at Cause: Date already refers to: class java.sql.Date (ns t (:import [java.sql JDBCType Types Date] [java.util.Date])) ;Caused by: clojure.lang.ExceptionInfo: ;Call to clojure.core/ns did not conform to spec.

Digital Baboon16:09:01

Can anyone recommend a style guide to writing Clojure? I'm having hard time keeping things consistent.

Digital Baboon16:09:03

Is that the "globally" recommended one?


it's the community driven one


you can also add to your editor cljfmt and don't worry about doing it manually

Digital Baboon16:09:45

Oh nice, there's a VSCode plugin. Thank you!


for VS i would recommend to use calva - the main package has this build in


and you can also install the formatter only


@im Just about any experienced Clojure programmer will disagree with one or more of the recommendations in that style guide, but likely they would agree with far more of them.

Digital Baboon17:09:34

Alright, as long as it's a good starting point I'm happy

Digital Baboon17:09:16

Hm. Using any of the formatting plugins and setting "format on save" to true, on saving a file I get ompilerException java.lang.IllegalAccessError: reader-error does not exist, compiling:(clojure/tools/reader/edn.clj:1:1).


Sounds like that "format on save" option is expecting the contents of the file to be correct EDN syntax (i.e. balanced parens, square brackets, curly braces, etc. strings end before the end of file), but your file violates what it expects.


or looking at the error message more carefully, the code for doing that has a version mismatch in Clojure or library versions


Does it give that error for any Clojure file you try to save, even a very short simple one that has no mention of a symbol called reader-error ?


what's up with these clauses

(defrecord A [])
(defrecord B [])
(def a (->A))
(case (type a)
  A "correct"
  B "false")

;; => IllegalArgumentException No matching clause: class ....


You’d probably have to use cond instead. In case those test constants are symbols.


yup, thought tough the symbols would be able to be compared, with = it's true.


a common idiom is condp =, or just a map


that's a hat trick condp =, case is strange sometimes.


nice thanks


(case 'A
 A "correct"
 B "false") 

👍 4

is the source code available somewhere for this @ericnormand test.check talk: ? if it's part of a course, i would be interested to get it too, because im curious about the async testing aspect. i found [test.carly]( which seems to carry the concept further, but i would like to see a simpler example, to understand it better/easier.


Love that John McAffee kind of look aha:gun:💊


I didn't keep the code for it, other than what is in the slides


and I don't have a course on it yet


but I'll mark you down as a vote for that one


I would love to do a course because I love generative testing


I'm not entirely sure I understand how setting vars work


I use set! to set a dynamic var


and I get exception Caused by: java.lang.IllegalStateException: Can't change/establish root binding of: *explain-out* with set


@roklenarcic See -- it's to do with threads. But for *explain-out* and other, similar dynamic vars, you should use binding instead.


But I want to set *explain-out* globally, not just for my thread and I don't want to wrap every line in REPL in binding.


In Clojure you pretty much never assign to a var (which is what set! is).


There are some situations where you might use alter-var-root (e.g., setting up Component in a way that's REPL-friendly), but set! is pretty rare (although you'll see (set! *warn-on-reflection* true) at the top-level in source code to turn on reflection-checking in the compiler).


does anybody know the reasoning for the following behaviour?

user> (:x {:x 1})
user> (:x (java.util.HashMap. {:x 1}))
user> (:x #{:x})
user> (:x (java.util.HashSet. #{:x}))


@beta1036 I'd have to go look at the source to be sure but I suspect (:x coll) expects coll to be associative and have a get method of some sort -- which java.util.HashSet does not. However, you can use contains? with both a Clojure set and a Java HashSet: (contains? #{:x} :x) => true and (contains? (java.util.HashSet. #{:x} :x) => true


@beta1036 Now I've looked at the code... (kw coll) ends up here if coll is not an instance of clojure.lang.ILookup (which would then call coll.valAt( kw ))


So it supports instances of java.util.Map, clojure.lang.iPersistentSet, and clojure.lang.ITransientSet (or if a string or array is indexed by a number). It doesn't support java.util.Set.


I've seen this in the code, and wanted to know the reasons for it being this way. I was surprised that keywords can take sets, and even more surprised that they can only take IPersistentSet or ITransientSet whereas java.util.Map is supported.


Is there an idiomatic use for applying a keyword to a set?


@beta1036 (Clojure) sets are associative on their keys -- like a map whose values are the same as their keys -- so you can call "get" on them. Java sets don't have that associative lookup -- only a "contains" operation. That would be my understanding of why you can lookup keywords in (Clojure) sets but not Java sets.


(and arrays are associative on their indices -- so, again, it makes sense to allow lookup "get" on those)


Does that make sense?


Having get on maps, sets and arrays makes sense to me.


It would make more sense to me if keyword application either supported java sets or not supported any sets at all. And of course supporting keyword application on vectors makes no sense at all.


The fact that java sets don't have a get operation seems like a weak excuse for not supporting them.


But I'm not complaining, since I don't have any use for applying keywords to sets at the moment. 🙂


Clojure is based on abstractions. map, set, and vector are associative in Clojure, hence should all support get. Java's Map is associative, Java's Set is not.


Re: keyword on vector -- vectors are associative on their index so, no, Clojure does not support keyword lookup on them. (kw coll) is "the same" as (coll kw) which is "the same" as (get coll kw) and for vectors (coll ix) is the shorthand.