This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (19)
- # babashka (13)
- # beginners (7)
- # calva (8)
- # cider (25)
- # clj-kondo (12)
- # cljsrn (7)
- # clojure (60)
- # clojure-australia (5)
- # clojure-europe (59)
- # clojure-france (14)
- # clojure-gamedev (2)
- # clojure-nl (1)
- # clojure-uk (7)
- # clojurescript (43)
- # community-development (8)
- # core-async (2)
- # cursive (15)
- # datomic (75)
- # deps-new (31)
- # depstar (1)
- # fulcro (6)
- # graalvm (53)
- # holy-lambda (1)
- # juxt (3)
- # jvm (13)
- # kaocha (8)
- # lsp (109)
- # malli (14)
- # off-topic (62)
- # pathom (11)
- # pedestal (12)
- # polylith (12)
- # releases (5)
- # sci (5)
- # shadow-cljs (15)
- # sql (16)
- # tools-deps (27)
- # vim (1)
- # xtdb (14)
Hi everyone, I suddenly got this issue with leiningen on CircleCI, even old builds that previously work now fail when I run re-run build. Any clues on how to debug?
I couldn’t find the command to disable that, but it seems like it was caused by a new release of leiningen, I just downgraded it one version down and now it works.
https://github.com/technomancy/leiningen/issues/2763 is the issue the warning is intended to address
https://github.com/technomancy/leiningen/issues/2764 is an issue where someone appears to be having the problem as you
I'm learning Datomic and I started checking out below repos: https://github.com/Datomic/mbrainz-importer https://github.com/Datomic/mbrainz-sample https://github.com/cognitect-labs/day-of-datomic-cloud 1. What is the thing behind having repl.clj in the root directory? 2. I noticed that files I would categorise as resources (schemas, datasets, subsets, config) are kept outside of resources/ directory. What criteria do you use when deciding where to keep resource files?
I would think of it as resources is something special to the running program in java - ie on the path of the JVM. the resources in this repos are just "example" files to be read of the system, not a system-resource in itself. If that makes sense
That repl.clj file is loaded in all of the example files, it seems to be a convenient way to require a bunch of namespaces to run the examples.
You see in many projects a
dev/user.clj file with utility functions for exploring the project, with a corresponding
:dev alias in
deps.edn that puts the
dev folder on the classpath. If you then run
clj -A:dev, since the repl has the default namespace
user, it will load that file for you.
More anecdotal evidence: I’m currently working in an all-Clojure position, but my previous employer was an all-Java shop, and we used scrum and story points and all that good stuff. My current employer has been much less formal, but lately we’ve gotten in some new project managers and now we’re doing story points again. So fine, I know all about estimating using story points, no sweat. We had our sprint planning meeting, and went thru the tickets, and I assigned story points and we did our thumbs-up/thumbs-down until we had enough story points to last me for a two-week sprint. I finished all the tickets in like 3 days. Apparently, it’s a LOT more efficient to work in Clojure than in Java, and I’m going to have to seriously overhaul how I estimate story points.
So I'm using java.lang.invoke.MethodHandle#invoke in order to implement my wrapper of Panama, and I've run into a snag: invoke takes a varargs array of objects as its only parameter, but when I call it with an
(into-array Object args) as the only argument, but it says that MethodHandle#invoke cannot be called via reflection. Thing is, I'm tagging it with ^"[Ljava.lang.Object;".
Moreover, when I also tag the method handle with ^MethodHandle, then it says that it can't cast an object array to the type of the only argument, but if I raise that argument then it says it can't cast the argument to an object array.
Has anyone run into this kind of problem with MethodHandle#invoke before, and how did you resolve it?
I found this stack overflow answer https://stackoverflow.com/questions/52378078/using-java-lang-invoke-methodhandle-in-clojure
here's hoping it works for me, but I am concerned about the performance of using invokeWithArguments. I expect that I'll have to use the spreader if I can get that working.
Alright, well the spreader one doesn't appear to work, it has the same reflection problems, but invokeWithArguments works.
Yeah, jdk mailing list says that invokeWithArguments is about 15-30x slower than invoke and invokeExact
ideally I'd be able to use invokeExact because I know the exact types that will be called with, but I don't know if that's something I can do in Clojure without generating bytecode.
I resolved this by generating bytecode at macroexpansion time with https://github.com/jgpc42/insn
Thread has an example of the two kinds of invocations I did and the errors I got. I'll go check up on those javadocs to see if I missed anything.
Basically MethodHandle::invoke is very special, and the Clojure compiler doesn’t treat it specially
> In source code, a call to a signature polymorphic method will compile, regardless of the requested symbolic type descriptor. As usual, the Java compiler emits an
invokevirtual instruction with the given symbolic type descriptor against the named method. The unusual part is that the symbolic type descriptor is derived from the actual argument and return types, not from the method declaration.
Alright, that's interesting, but what does that actually mean for me? Is there a clojure workaround to this, or do I have to generate my own bytecode and load it into the class loader?
And as far as I know, that really would be the only option, since I have to be generating brand new invoke calls for every call to a particular macro, and it sounds like it wouldn't work to have a java class that calls invoke with an object varargs.
would someone be able to point me to where syntax-quote is implemented in clojure.core? I've looked around but haven't found it yet
Don't know if it is helpful, but
clojure.tools.reader is a Clojure implementation of the reader, and it has a
syntax-quote* function which should do the same thing as the Java counterpart.
I'm looking at the clojure CLI option to run a function (`clojure -X`), and it looks like it only works for functions that take a map as a single argument? Is that correct?
I'd be curious to know what the rationale for doing it that way as opposed to accepting a series of args like
-M does. The way it works is definitely handy for some use cases, but accepting a series of arguments is more general. Maybe I'll try to find the patch that added it.
There's not much that is more general in Clojure than passing all the arguments in a hash map 🙂
I should note in case some stumbles upon this via Google later that you can execute arbitrary functions from the commandline using
-e . For example,
clojure -e '(+ 2 2)'
Fair. 🙂 I guess my thinking is that accepting a series of args supports all the functions
-X does but not vice versa. (Although it doesn't enable the "set defaults in
:exec-opts and override them" workflow.)
> There's not much that is more general in Clojure than passing all the arguments in a hash map 🙂 Most clojure functions do not accept a single map, but would still be perfectly usable from the command line. I don't see much benefit in re-writing a perfectly good function just to invoke it from the command line
Most of my
-main functions parse
& args using
tools.cli which produces a hash map and
-main calls the implementation function with that hash map 🙂
The situation I'm thinking of is more little functions than major entry points. Although there's a good chance I'd just open a REPL for that.
I have a hacky way of getting -X like functionality in a single line of Clojure :P https://twitter.com/borkdude/status/1418976389609496580