This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-03
Channels
- # announcements (5)
- # aws (3)
- # babashka (52)
- # babashka-sci-dev (23)
- # beginners (51)
- # calva (191)
- # clj-commons (18)
- # clj-kondo (11)
- # cljdoc (39)
- # cljsrn (3)
- # clojure (24)
- # clojure-czech (3)
- # clojure-dev (2)
- # clojure-europe (15)
- # clojuredesign-podcast (2)
- # clojurescript (8)
- # conjure (2)
- # core-typed (151)
- # cursive (15)
- # data-science (3)
- # datalevin (4)
- # datomic (8)
- # figwheel-main (21)
- # fulcro (37)
- # gratitude (3)
- # honeysql (1)
- # hyperfiddle (2)
- # introduce-yourself (1)
- # malli (3)
- # membrane (54)
- # off-topic (21)
- # other-languages (4)
- # portal (18)
- # re-frame (12)
- # reagent (7)
- # releases (2)
- # sci (64)
- # scittle (1)
- # spacemacs (14)
- # sql (2)
- # vim (4)
- # xtdb (6)
here is a list of the functions in core I have yet to implement… core is ENORMOUS. https://raw.githubusercontent.com/Zelex/jo_lisp/main/TODO.md
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? https://gist.github.com/v3gal0g/124b413fb306af50dd79794298906468
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
https://ring-clojure.github.io/ring/ring.middleware.multipart-params.html#var-wrap-multipart-params
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! http://mishadoff.com/blog/clojure-design-patterns/
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?
that's about as far as my understanding goes
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)
aren't there cases where there are deps provided by the server?
that's what my "most?" was about
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
I meant specifically the provided scope
drop
is lazy, while nthrest
evaluates more, see https://clojuredocs.org/clojure.core/nthrest
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
(:gen-class)
(: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.
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 -
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? 🙂
Esentially I know exception is thrown here: https://github.com/RutledgePaulV/clj-okhttp/blob/master/src/clj_okhttp/ssl.clj#L27 And I would like to know value of input string at that point.
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
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
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
the second one uses the installed tool definition (stored in ~/.clojure/tools/clj-new.edn in this case)
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)
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)
at the moment that usage data is primarily the default namespace and namespace aliases (may expand in the future)
I guess another difference is that the latter only works with git or local deps, not with maven-based tools
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.
Yep, that is another difference, but may be included eventually