Fork me on GitHub
Jon Olick03:04:04

here is a list of the functions in core I have yet to implement… core is ENORMOUS.

Jon Olick03:04:36

I’m thinking maybe another month if I have the time

Jon Olick03:04:47

so 2 month project for v0.5

Jon Olick04:04:18

then dynamic linked modules and stuffs

Jon Olick04:04:24

should be fun!

Jon Olick04:04:30

Then comes the other fun part, constant folding and lifting (simple optimizations)

Jon Olick04:04:15

Maybe a couple others too if they are fast


Sort of a web req question. I'm toying with multipart-params/uploading iles. I'm using insomnia to send my requests. Why is it putting the same data in :multipart-params and :params?


The ring middleware from the ring project tends to put decoded stuff under source specific key like multipart-params, and then merge it all together under :params


So if you only want to accept something passed via multipart-params you can look it up there, but if you don't care if it is multipart or a form or query string you can look it up under params

❤️ 1

The doc string mentions this


Looking at your gist, it looks like you may not be using the ring middleware, but some work alike


Gotcha. That makes sense. I'm using pedestal which seems to use the ring middleware for this but they modify it a little. I see now, also the pedestal docs mentioned :store but I couldn't find it in pedestals code. Now I see it directly in the rings docs. Cool.


Did you come to Clojure from an object-oriented programming background? Then I suspect you’ll find this article by @mishadoff very useful!

🙌 1
Vadim Zakovryashin14:04:10

Wow! Thanks a lot! Just yesterday I was thinking about it!

👍 1

What is the difference between jar and the uberjar ?

Cora (she/her)16:04:02

jar is a package format, basically a zip file with certain things included. an uberjar is a jar for a library or application that also contains all (or most?) of its dependencies


hi @U02N27RK69K Thanks for your response, When I want to build my clojure application, should I build it as uber jar?

Cora (she/her)17:04:25

yep, that'll make it so you only need java and the jar to run your app

🙌 1
Cora (she/her)16:04:13

that's about as far as my understanding goes

Alex Miller (Clojure team)17:04:44

That's right, typically an uberjar contains an application and all of the source or compiled classes for its deps (compilation is orthogonal but often it's all compiled)

Cora (she/her)17:04:28

aren't there cases where there are deps provided by the server?

Cora (she/her)17:04:56

that's what my "most?" was about

Alex Miller (Clojure team)20:04:12

not typically (although that is possible)


it would be possible to make a jlink image containing ALL-MODULE-PATH and distribute your clojure code alongside your dependencies without an uberjar and bundling the JRE


nobody really does that though

Cora (she/her)03:04:21

I meant specifically the provided scope

Jon Olick17:04:04

whats the difference between nthrest and drop?


drop is lazy, while nthrest evaluates more, see


how to build standalone uber jar for figwheel ?


An uberjar (or even a jar) is not necessary for a figwheel project A figwheel build will generate a JavaScript file which can be run on any web server (or on GitHub / GitLab pages or similar services) An uberjar is only required if the figwheel code is part of a back-end server project in Clojure that serves up the static content like htlm, CSS and JavaScript files.


I have a beginners question about adding dependencies. I added the following to deps.edn:

{:paths ["src" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.10.3"}
        instaparse/instaparse {:mvn/version "1.4.10"}}
and the following to my code
(ns odatasrv.parser
  (:require [instaparse.core :as insta]))
However, I get the following output in my REPL, even after restarting the REPL:
; Evaluating file: parser.clj
; Syntax error (FileNotFoundException) compiling at (/home/michael/Developments/Clojure/odata/parser/src/odatasrv/parser.clj:1:1).
; Could not locate instaparse/core__init.class, instaparse/core.clj or instaparse/core.cljc on classpath.
; Evaluation of file parser.clj failed: class clojure.lang.Compiler$CompilerException


We solved the issue in a thread in the #calva channel. Sharing the TL;DR here. The REPL was started with the :build alias, and that caused this error to be thrown. Starting the project without aliases seems to be the most REPL friendly option.


How did you start your repl?


In VSCode using Calva. I even exited VSCode and started again

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version,"0.9.0"},cider/cider-nrepl {:mvn/version,"0.27.4"}}}' -M:run-x:build:test -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
nREPL server started on port 44779 on host localhost - 

Paavo Pokkinen19:04:26

How does one debug or develop 3rd party library that is coming as dependency either via deps.edn or in project.clj? Let's say I clone git repo of that project somewhere, then what? 🙂

Paavo Pokkinen19:04:34

Esentially I know exception is thrown here: And I would like to know value of input string at that point.

Alex Miller (Clojure team)20:04:15

with deps.edn, you can replace your reference to that dep with a local dep (:local/root "../path/to/repo"} and then you'll be using your local version instead - modify live and reload in your editor

👍 1

With leiningen you can edit the version string, cache locally with lein install and restart your repl using that new (locally developed) version. it's a good idea to remove the version from your .m2 cache when done debugging.


What is the difference between these two things? Why would i prefer either one?

clojure -T:project/new :template app :name myname/myapp
clojure -Tclj-new app :name myname/myapp

Alex Miller (Clojure team)20:04:04

they are pretty close but differ in a couple respects - the first one takes the tool's definition from an alias, either in your project deps.edn or your shared ~/.clojure/deps.edn

Alex Miller (Clojure team)20:04:52

the second one uses the installed tool definition (stored in ~/.clojure/tools/clj-new.edn in this case)

Alex Miller (Clojure team)20:04:40

the alias one might have the benefit of allowing you to define a tool in the context of a specific project and share that config via your repo's deps.edn (but that's probably not useful for clj-new which you are presumably not running in existing projects)

Alex Miller (Clojure team)20:04:48

the latter one will pull the tool's default usage from the tool's git repo deps.edn so that you don't have to specify it in your own alias (or many aliases if copied across projects)

Alex Miller (Clojure team)20:04:21

at the moment that usage data is primarily the default namespace and namespace aliases (may expand in the future)

Alex Miller (Clojure team)20:04:05

I guess another difference is that the latter only works with git or local deps, not with maven-based tools

Alex Miller (Clojure team)20:04:29

for your specific use case of clj-new, I don't think any of these factors dominate and it really doesn't matter


A reason I still use -T:project/new is that I can define my own default options, using :exec-opts within the alias itself (and I have a bit of experience writing a few aliases now) With -Tclj-new then the defaults are what ever the tool developer defined as I dont believe I can set my own defaults in ~/.clojure/tools/clj-new.edn as of yet.

Alex Miller (Clojure team)23:04:18

Yep, that is another difference, but may be included eventually