This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-23
Channels
- # announcements (10)
- # babashka (7)
- # beginners (31)
- # boot (4)
- # calva (8)
- # chlorine-clover (19)
- # cider (12)
- # clj-kondo (27)
- # cljsrn (7)
- # clojure (68)
- # clojure-colombia (2)
- # clojure-europe (47)
- # clojure-italy (16)
- # clojure-nl (4)
- # clojure-spec (13)
- # clojure-uk (39)
- # clojurescript (103)
- # code-reviews (8)
- # community-development (2)
- # conjure (38)
- # core-async (37)
- # cursive (2)
- # datascript (1)
- # datomic (31)
- # figwheel-main (22)
- # fulcro (18)
- # jobs (2)
- # jobs-discuss (6)
- # juxt (3)
- # keechma (1)
- # lambdaisland (6)
- # malli (30)
- # meander (20)
- # off-topic (29)
- # reagent (1)
- # reitit (16)
- # shadow-cljs (4)
- # tools-deps (70)
- # xtdb (19)
i'm getting a boxed math warning on an empty line. i can't find what it might be talking about... can someone point me to the right direction?
the warning: Boxed math warning, iny/http.clj:128:9 - call: public static java.lang.Number clojure.lang.Numbers.unchecked_add(java.lang.Object,long).
the code https://github.com/valerauko/iny/blob/d475e0c37ac2a489cae0b8445673c23b86407953/src/iny/http.clj#L128
Well, you could try bisecting it -- make a copy and keep removing parts of the code until the warning disappears...
is this well known behaviour?
❯ clojure
Clojure 1.10.1
user=> (range 3)
(0 1 2)
user=> (range 3.1)
(0 1 2 3)
user=> (range 1 3.1)
(1 2 3)
range increments by the step until it exceeds the end
takes all numeric types
user=> (range 1 10/3 0.5)
(1 1.5 2.0 2.5 3.0)
nice, thanks Alex ... was surprised when I saw it as the docs are a bit on the, ahem, sparse side
@raymcdermott I remember working on the spec of that function and initially I assumed integer steps which was also wrong. It's here now: https://github.com/borkdude/speculative/blob/4e773794a4065a84bdadd997516e52c76ab51b1f/src/speculative/core.cljc#L320 This is one of the PRs changing the spec https://github.com/borkdude/speculative/pull/38/files
the long/long/long cases of range are highly optimized given their prevalence
there are lots of super weird cases though
(range Long/MIN_VALUE Long/MAX_VALUE Long/MAX_VALUE)
but it gets weirder when you consider double range etc. much care was taken to avoid overflow/underflow scenarios
What's the best way to hack on a local copy of a Leiningen project form a clj deps.edn project?
My understanding is that if I'm working in a deps.edn project then I can include in my deps.edn {:local/root "/some/other/deps.edn/project"}
or I can {:git/url "
but I can't use either of those keys to point to a Leiningen project.
Right now, my plan is to clone the Leiningen dependency, change the version name in project.clj
, run lein pom
(or whatever lein commands build and place the uberjar in my local maven repo), and then add it to my deps.edn with {:mvn/version "my-modified-version"}
. And then it I'm hacking on the dependency, just re-run the commands to build the lein project every time I make a change that I want to test in my other project.
Ohh... Actually, I guess it would be faster (if I'm just making one-off hacks to test changes in a dependency) to just clone the repo, make the changes, then just evaluate the changes in my repl.
Clone the project, add deps.edn
to it, and then depend on it from your deps.edn
project 🙂
(and maybe submit a PR to the Leiningen project with deps.edn
so it becomes usable via git deps from Clojure CLI)
I started down this route but I'm struggling to understand the ecosystem of Lein, pom.xml, Maven, Clojars, Uberjars, Jars, etc...
The project currently has pom.xml
in it's .gitignore
. When I look at the jar in my ~/.m2
directory, I see that it has a pom.xml
file in their with a comment that it was auto-generated by Leiningen. My understanding is I can copy that pom.xml
, as it is needed by any build tool that doesn't auto-generate one?
So copy the pom.xml
from the latest jar, remove it from .gitignore
, and add something like the below to deps.edn
?
:build {:extra-deps
{seancorfield/depstar {:mvn/version "1.0.94"}}
:main-opts ["-m" "hf.depstar.jar" "migratus.jar"]}
In hindsight this all seems a bit heavy handed, switching build tools entirely. It just seemed wrongish to manually keep a deps.edn
file in parity with a project.clj
file.
Is it commonly accepted to use Lein and project.clj
for the builds, plugins, etc... and manually keep a deps.edn
in parity with it solely for usability as a git dependency from Clojure CLI?No, you only need a simple deps.edn
file that contains just the same :deps
as found in the :dependencies
vector of the project.clj
. No aliases. Nothing fancy. You just need the basic deps so the project is usable as a git dep from Clojure CLI.
In this case, all the PR needs to add is deps.edn
containing:
{:deps {org.clojure/clojure {:mvn/version "1.9.0"}
org.clojure/java.jdbc {:mvn/version "0.7.8"}
org.clojure/tools.logging {:mvn/version "0.4.1"}}}
If migratus had that deps.edn
, then you could depend on it as a git dep and as a local/root dep. @UJP37GW2K
@ggfpc12495 If you want to use only CLJS then maybe Reagent is a nice way to start. It does help to understand some of the React basics, so doing their official tutorial in plain JS will probably help