This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-09-11
Channels
- # announcements (7)
- # aws (52)
- # babashka (16)
- # beginners (49)
- # bristol-clojurians (1)
- # calva (2)
- # chlorine-clover (26)
- # cider (6)
- # clara (1)
- # clj-kondo (79)
- # cljfx (15)
- # clojure (82)
- # clojure-berlin (2)
- # clojure-czech (1)
- # clojure-europe (26)
- # clojure-france (91)
- # clojure-germany (48)
- # clojure-nl (7)
- # clojure-norway (99)
- # clojure-uk (54)
- # clojurescript (18)
- # code-reviews (9)
- # data-science (2)
- # datalog (15)
- # datomic (15)
- # depstar (20)
- # emacs (4)
- # events (1)
- # fulcro (30)
- # funcool (1)
- # graphql (1)
- # helix (5)
- # jobs (6)
- # kaocha (12)
- # leiningen (8)
- # luminus (1)
- # malli (13)
- # off-topic (73)
- # pathom (12)
- # portal (11)
- # portland-or (1)
- # re-frame (10)
- # reagent (1)
- # reitit (44)
- # remote-jobs (1)
- # ring (19)
- # shadow-cljs (64)
- # tools-deps (32)
as someone going back to school, the number of arithmetic errors I've made doing linear algebra has been humbling
Just because itās Friday. What would it take for you to consider applying for a job (given that you had one youāre not totally miserable in)?
Iāll start with the latter: ā¢ Using good/interesting tech/not using bad/uninteresting tech ā¢ Good compensation (salary, possibility for company stocks after an initial āchecking Iām seriousā period) ā¢ Flexibility (not feeling like I have to work a certain number of hours, not being overly rigid about company policies in general) ā¢ Company mission: I would very much like to contribute to something good for humanity, like making efficient systems that help reduce waste ā¢ The rest of the staff: feeling like people who work there are generally happy, friendly, have good values, are interesting ā¢ Possibility for growth: feeling like in the long-term I will be able to learn, take on larger/more important tasks if I want to, feeling like there is a future for the company, etc.
To apply I think it doesnāt take much. Right now I want to start applying to jobs to see what kind of response I get and to be able to negotiate well with my current job. I am quite happy with my current job, but I definitely want to get an idea of what my options are. I will likely apply to jobs I am not all that interested in, just to see what kind of response I get, and I will be upfront about that with my interviewers. I will tell them that I am happy with my current job and will only consider changing if I get a very appealing offer, and that I am applying at several places to get an idea of the options I have.
Because itās Friday, Iāll repeat something Iāve said over the years only half joking - I want a job where I donāt have to report time. Projects/activities/time types/... argh. Just work, ok? š
Iām frugally āretiredā ala Mr. Money Moustacheā¦ which I seem to be liking. I loved my paid jobs, but I like this even better. So now taking on a job for me is working on open source projects. Iāve dipped my toe in one non-Clojure project where I personally found the lead a bit difficult, so I left before dipping my whole foot in. All my Clojure efforts have been both fun and warmly received by a great community, so Iāll stick around!
Is teorically possible to create a command-line tool that create uberjars like this:
echo "$(clj -Sdeps):bundle" | uberjar --path - --output app.jar --main-class clojure.main --main-opts -m --main-opts my-app.main
I'm missing some parameter/complexity?
Do we need to merge data readers? Looks like that clojure do that at runtime https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L7797
Because they're all in a single directory, it's got to decide how to put them together
No. that uberjar
utitlity should know nothing about clojure/javaĀ¹/
Ā¹ Maybe it handle some JVM stuff, like META_INF
depstar does I believe: https://github.com/seancorfield/depstar/blob/5e605b019d6641cca22f47502a82ccbf1e540f12/src/hf/depstar/uberjar.clj#L83-L84
Also interesting to look at the other "clashes": https://github.com/seancorfield/depstar/blob/5e605b019d6641cca22f47502a82ccbf1e540f12/src/hf/depstar/uberjar.clj#L80
Don't get me started on how bad that was to deal with at work... logging just randomly failed on some systems but not others (for JARs built on different systems -- the same JAR worked identically, or failed identically, on whichever system you deployed it).
There are lots of comments in the log4j2 bugbase complaining about it, going back years š
Nope. It changes behavior from clojure. In clojure, if you get 2 conflicting keys you get an error. That tool just silently merges them.
I didn't know about Clojure providing an error in that case. Makes sense. So far no one has complained about depstar
's behavior but I'll create a ticket for that.
@dominicm Since depstar
builds from the current classpath by default, the behavior from Clojure is actually preserved: Clojure itself loads and merges the data readers -- and it validates the keys and throws an exception if they conflict -- before depstar
actually runs. Only if you use the new -P
/ --classpath
option to build a JAR file from a classpath other than the default execution context is it possible for multiple conflicting data readers to be merged, so I've added some logic there to detect and warn about such conflicts.
Note that depstar
treats the data readers as EDN and merges them as such, so that doesn't work for .cljc
files that contain reader conditionals. Clojure reads them as code, with conditionals supported. I'll implement that if anyone actually trips over that in real life. I'm not convinced it's worth implementing "on spec" in advance.
The code in Clojure reads the .cljc
with reader conditionals allowed:
(let [read-opts (if (.endsWith (.getPath url) "cljc")
{:eof nil :read-cond :allow}
{:eof nil})
new-mappings (read read-opts rdr)]
(when (not (map? new-mappings))
(throw (ex-info (str "Not a valid data-reader map")
{:url url})))
(I thought it supported .cljs
as well, but it doesn't, although of course depstar
has to support it for building projects that support ClojureScript)The classpath isn't supposed to be flat. There's plenty of tools which rely on scanning to work, and hopefully your uberjar is kind enough to cover the tools you use
Oh, and lein violates the rules of apache license by not preserving each Copyright notice. Maven's uber does this.
Maybe @ghadi can speak to why it does that, since that was how it behaved when I inherited it...?
Do we need to merge data readers? Looks like that clojure do that at runtime https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L7797
No. that uberjar
utitlity should know nothing about clojure/javaĀ¹/
Ā¹ Maybe it handle some JVM stuff, like META_INF
@souenzzo I'm the author of pack, which is the only clojure uberjar tool (I know of) which preserves the classpath. It uses classloader tricks to achieve that.
@U083D6HK9 honestly, I looked at the merging code in existing tools and decided there had to be a better way.
Ohh. I assumed that given the plethora of tools you mentioned previously that it'd be highly likely to run into a scenario where the uberjar tool did not work as expected. It sounds like it may be more of an edge case?
Unfortunately my notes didn't start until after this project, but the maven shade plugin's source is very instructive wrt properly handling this. It's the closest tool to correct.
Huh. Sounds like depstar should, perhaps, include a warning that if you're using any of those tools you may get unexpected behavior.
Fair enough. I have not hit a problematic case with depstar yet but I imagine it'd be a total nightmare to debug.
Exactly. I've hit weird stuff one too many times in my career. I'd rather do things at that level "properly" - or at least according to original intent without stripping features.
I'm not too zealous with programming perfection or anything. But I feel like the tools we build on need to have our trust. Libraries, etc.
Perfection isn't the right word. I don't aim for correct programs. Bugs are ok. We're as inaccurate as the world lets us be. Embrace the chaos.
But wasting time on why logging doesn't work is a pointless use of human effort that derives from chasing a clever trick to gain a single deployable, at the expense of breaking the model of how the path works. Better to find an alternative.
Maybe @ghadi can speak to why it does that, since that was how it behaved when I inherited it...?
FYI #depstar has its own channel now, in case folks have questions about it.
I didn't know about Clojure providing an error in that case. Makes sense. So far no one has complained about depstar
's behavior but I'll create a ticket for that.
not sure what's a good place to (re-)mention this -- i have seen a few mentions of the http://clojurians.net site having difficulty. atm it's "Application error" for me. it seems that (used to be?) was the way to get invites(?) to get access to clojurians.slack and various resources link to it (e.g. http://calva.io). is this something that's worth trying to do something about? perhaps it is being attended to and i haven't missed such a message (though a quick search didn't seem to turn up anything relevant).
@dominicm Since depstar
builds from the current classpath by default, the behavior from Clojure is actually preserved: Clojure itself loads and merges the data readers -- and it validates the keys and throws an exception if they conflict -- before depstar
actually runs. Only if you use the new -P
/ --classpath
option to build a JAR file from a classpath other than the default execution context is it possible for multiple conflicting data readers to be merged, so I've added some logic there to detect and warn about such conflicts.