The short answer is string/replace takes three inputs, and therefore greetings takes three inputs. fnil wraps the function it is given (in your case string/replace), returning a new function. This new function will pass along its arguments to the wrapped function, except it will replace nils in the first three arguments by the values provided when calling fnil. The function returned by fnil can take 2 or more inputs, but in your case it will fail if you give it any number of inputs other than 3, because string/replace takes exactly three arguments.

user=> (greetings)
Execution error (ArityException) at user/eval9 (REPL:1).
Wrong number of args (0) passed to: clojure.core/fnil/fn--6902

user=> (greetings "a")
Execution error (ArityException) at user/eval11 (REPL:1).
Wrong number of args (1) passed to: clojure.core/fnil/fn--6902

user=> (greetings "a" "b")
Execution error (ArityException) at user/eval13 (REPL:1).
Wrong number of args (2) passed to: clojure.string/replace

user=> (greetings "Hello" "e" "u")
"Hullo"
user=> (greetings "a" "b" "c" "d")
Execution error (ArityException) at user/eval20 (REPL:1).
Wrong number of args (4) passed to: clojure.string/replace

notice Wrong number of args (…) passed to: clojure.core/fnil/fn--6902 (an anonymous function produced by fnil) vs. … passed to: clojure.string/replace

Hmmm... What are you trying to do? You may find it useful to use a templating thing like Selmer.

if you don't get a response, you might also try #shadow-cljs

What do you have in ~/.clojure/deps.edn ? 😮

;; The deps.edn file describes the information needed to build a classpath.
;;
;; When using the `clojure` or `clj` script, there are several deps.edn files
;; that are combined:
;; - install-level
;; - user level (this file)
;; - project level (current directory when invoked)
;;
;; For all attributes other than :paths, these config files are merged left to right.
;; Only the last :paths is kept and others are dropped.

{
  ;; Paths
  ;;   Directories in the current project to include in the classpath

  ;; :paths ["src"]

  ;; External dependencies
 
  ;; :deps {
  ;;   org.clojure/clojure {:mvn/version "1.10.1"}
  ;; }

  ;; Aliases
	;;   resolve-deps aliases (-R) affect dependency resolution, options:
	;;     :extra-deps - specifies extra deps to add to :deps
	;;     :override-deps - specifies a coordinate to use instead of that in :deps
	;;     :default-deps - specifies a coordinate to use for a lib if one isn't found
	;;   make-classpath aliases (-C) affect the classpath generation, options:
	;;     :extra-paths - vector of additional paths to add to the classpath
	;;     :classpath-overrides - map of lib to path that overrides the result of resolving deps

  ;; :aliases {
  ;;   :deps {:extra-deps {org.clojure/tools.deps.alpha {:mvn/version "0.8.677"}}}
  ;;   :test {:extra-paths ["test"]}
  ;; }

  ;; Provider attributes

  ;; :mvn/repos {
  ;;   "central" {:url ""}
  ;;   "clojars" {:url ""}
  ;; }
}

I'm not too sure about this exactly :x

What I see is that nrepl/nrepl 0.7.0 IS on clojars. So, not sure why lein is not able to pull it. FWIW, 0.8.0 seems to be the latest, but that does not appear to be your issue. Do you have a project.clj file? If so, can you share the contents? Is there a particular book or article you are trying to follow? It's Saturday morning in the US, there may be fewer folks around that can help.

And, clojure-complete version 0.2.5 is also on clojars. Oh, also do you have a ~/.lein/profiles.clj? If so, please share its contents as well.

@U0AT6MBUL No, I don't have ~/.lein/profiles.clj

@U0AT6MBUL I am following Getting Clojure, Russ Olsen book. P.S Also, I checked lein repl in created project (with lein app) and there are the same errors.

Looking at the errors messages a bit more closely, it says that it found nrepl, but could not transfer it from clojars. And same for clojure-complete.

So, maybe there is something preventing the transfer.

I don't know, it is useful info or not. OS: Ubuntu 20.04 Clojure: 1.10.1 Java: openjdk version "11.0.8" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8+10-post-Ubuntu-0ubuntu120.04) OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Ubuntu-0ubuntu120.04, mixed mode, sharing)

It's been a while since I used lein so trying to remember if there is a verbose mode that would provide some more debugging info as to why the transfer is failing.

Also, what does lein version show?

Thanks for the system info.

lein version: Leiningen 2.9.4 on Java 11.0.8 OpenJDK 64-Bit Server VM

That looks up-to-date.

Also I tried on Java 8 and the same errors

I am guessing you have some permissions or connectivity issue.

Is there any way to give permits for lein?

Not sure what you mean. lein, by itself, does not need permissions.

Just trying some experiments myself here (on ubuntu 19.10)

What happens if you try clj? Or clj -Sverbose at the Ubuntu prompt?

This is just using the installed Clojure CLI, not lein, but just wanted to see if we can get that to work.

I got this message Please install rlwrap for command editing or use "clojure" instead. But, clojure works well.

Try sudo apt install rlwrap

Good that clojure works.

I did, clj works as clojure .

Okay. Now try the following

clj -Sdeps '{:deps {nrepl {:mvn/version "0.70"}}}'

At the ubuntu prompt.

Sorry. That was wrong.

clj -Sdeps '{:deps {nrepl {:mvn/version "0.7.0"}}}'

Does that download the nrepl library?

No, got errors.

Please share.

Error building classpath. Failed to read artifact descriptor for nrepl:nrepl:jar:0.7.0
org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for nrepl:nrepl:jar:0.7.0
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:255)
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:171)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:255)
	at clojure.tools.deps.alpha.extensions.maven$eval813$fn__815.invoke(maven.clj:99)
	at clojure.lang.MultiFn.invoke(MultiFn.java:244)
	at clojure.tools.deps.alpha$expand_deps$fn__1230$fn__1231.invoke(alpha.clj:214)
	at clojure.tools.deps.alpha.util.concurrent$submit_task$task__500.invoke(concurrent.clj:33)
	at clojure.lang.AFn.call(AFn.java:18)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact nrepl:nrepl:pom:0.7.0 from/to clojars (): : Temporary failure in name resolution
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:424)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:229)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:207)
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:240)
	... 11 more
Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not transfer artifact nrepl:nrepl:pom:0.7.0 from/to clojars (): : Temporary failure in name resolution
	at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:52)
	at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:369)
	at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
	at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:644)
	at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:262)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:499)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:401)
	... 14 more
Caused by: java.net.UnknownHostException: : Temporary failure in name resolution
	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
	at java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:929)
	at java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1515)
	at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:848)
	at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1505)
	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1364)
	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1298)
	at org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)
	at org.apache.http.impl.conn.DefaultClientConnectionOperator.resolveHostname(DefaultClientConnectionOperator.java:263)
	at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:162)
	at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:326)
	at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:610)
	at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:445)
	at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:835)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:72)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
	at org.apache.http.impl.client.DecompressingHttpClient.execute(DecompressingHttpClient.java:164)
	at org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:290)
	at org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:246)
	at org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:67)
	at org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:457)
	at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:364)
	... 19 more

Okay. That is a bit more infor : Temporary failure in name resolution

Can you get to via a web browser from that Ubuntu machine?

seems like your machine cannot resolve the name .

Yeah, exactly. I can't get to .

Can you get to some other well-known host (say ).

Yes I can. I did try use VPN in browser to get and now I can get it.

You seem to have a networking issue then.

Hmm... My internet provider blocks

That would explain things.

I am a bit surprised that the ISP is blocking clojars. Perhaps it is blocking http or https?

You said you used an VPN. Is that VPN on the browser or the Ubuntu host?

VPN on the browser

If you can set up a VPN on the Ubuntu host to get around the ISP block, you might be able to get it to work. Unfortunately, VPN on the browser will not help.

I guess, the only solution is use VPN on terminal.

Do you have access to an external http/https proxy that your ISP does not block?

No, I don't have access

Anyway, @U0AT6MBUL thanks a lot for helping me. Now, I see issue clearly.

Welcome. I will have to leave soon.

Hope you can get the VPN working.

Or convince your ISP to remove the clojars block.

Out of curiosity, how did you install clojure and lein? Via apt?

via apt

no, sorry

not via apt

via curl

Can you get to github? If so, an option might be to download the nrepl (and clojure-complete) repos and then install locally into your ~/.m2/repository.

Sorry, I have to go now. Hope you can get the connection working.

SOLVED: It was internet issue, my Internet Provider blocks , so I used OpenVPN on Ubuntu and solved this issue. @U0AT6MBUL thanks a lot again.

Now I can start a journey in clojure world!

So weird that clojars is being blocked by your ISP. Sorry I wasn't much help. But glad you got it working!

What's the scale of your application, and have you confirmed that a thread pool based solution (e.g. jetty) really won't make it?

Is it really depends on a scale? I cant predict a scale upfront for this app, but I thought it is better to pick the right tool from the start, and to not rewrite after