Fork me on GitHub
#off-topic
<
2020-09-11
>
idiomancy00:09:37

i need to go back to school.

chucklehead00:09:32

ah, that's where the message I was replying to went šŸ™‚

šŸ’Ø 3
chucklehead00:09:08

as someone going back to school, the number of arithmetic errors I've made doing linear algebra has been humbling

slipset12:09:13

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)?

šŸ‘ 3
ksd12:09:16

Consider applying for a job or consider starting a new job?

slipset12:09:47

I guess the combo.

slipset12:09:13

Or if you have different answers to the two options, both would be interesting.

ksd13:09:13

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.

šŸ‘ 9
ksd13:09:32

some of these will likely change as my life situation changes

ksd13:09:31

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.

Mattias14:09:29

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? šŸ˜„

šŸ‘ 6
lread15:09:17

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!

šŸ‘ 9
souenzzo20:09:13

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?

dominicm20:09:22

Yep, that is it.

kenny20:09:29

You'll probably want to merge data_readers.clj if you use that.

dominicm20:09:43

Uberjars squash all the files together

dominicm20:09:01

It's like copying them into a directory

dominicm20:09:22

Because they're all in a single directory, it's got to decide how to put them together

souenzzo20:09:45

uberjar can't store each project inside it's coordinate?

dominicm20:09:43

Well, presumably uberjar does that

3
souenzzo20:09:43

No. that uberjar utitlity should know nothing about clojure/javaĀ¹/ Ā¹ Maybe it handle some JVM stuff, like META_INF

dominicm20:09:57

Frankly, that sort of stuff is best avoided

dominicm20:09:17

Most tools don't merge data_readers properly afaik.

kenny20:09:25

Agree. Just remember that being a pre-req when I wrote an uberjar fn way back.

kenny20:09:53

"idiotic-log4j2-plugins-file" šŸ˜†

seancorfield21:09:35

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).

kenny21:09:27

Oh my... That sounds awful. It did give me a good chuckle though šŸ˜„

seancorfield21:09:07

There are lots of comments in the log4j2 bugbase complaining about it, going back years šŸ˜

šŸ¤Ŗ 3
dominicm20:09:14

Nope. It changes behavior from clojure. In clojure, if you get 2 conflicting keys you get an error. That tool just silently merges them.

āœ”ļø 3
seancorfield21:09:22

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.

seancorfield04:09:35

@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.

seancorfield04:09:30

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.

dominicm06:09:02

The .cljc file can't actually support that anyway.

dominicm06:09:15

It's not read in a way to support it

seancorfield17:09:11

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)

dominicm07:09:20

They're allowed, but no features are selected.

dominicm07:09:35

You always end up on :default

dominicm07:09:44

Maybe that's a bug though

dominicm20:09:24

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

dominicm20:09:57

Lein has a disgusting function which merges arbitrary xml

dominicm20:09:33

Oh, and lein violates the rules of apache license by not preserving each Copyright notice. Maven's uber does this.

dominicm20:09:51

Depstar ignores license files, so has the same problem.

seancorfield21:09:05

Maybe @ghadi can speak to why it does that, since that was how it behaved when I inherited it...?

dominicm22:09:33

Probably copied from lein

souenzzo20:09:43

No. that uberjar utitlity should know nothing about clojure/javaĀ¹/ Ā¹ Maybe it handle some JVM stuff, like META_INF

dominicm20:09:27

@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.

kenny20:09:44

I'm actually curious what you're doing to require the classpath be preserved?

kenny20:09:57

You mentioned tools that rely on scanning so you must be using one of those.

souenzzo20:09:25

I will take a look at pack

dominicm22:09:41

@U083D6HK9 honestly, I looked at the merging code in existing tools and decided there had to be a better way.

dominicm22:09:57

Lambda actually support this out of the box with zips

dominicm22:09:23

Docker support is something I also particularly love, as it avoids this problem.

kenny22:09:23

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?

dominicm22:09:39

Well, log4j2, clojure, webjars(maybe?) rely on this.

dominicm22:09:09

I was writing a tool at some point which relied on this too

dominicm22:09:24

There's a bunch of java libraries which rely on this behavior, hence the merging

dominicm22:09:51

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.

dominicm22:09:07

It handles licenses properly

kenny22:09:35

Huh. Sounds like depstar should, perhaps, include a warning that if you're using any of those tools you may get unexpected behavior.

dominicm22:09:28

Well, it tries to merge them for you. They're known.

dominicm22:09:50

Not sure if it handles components.xml, or the new java service loader stuff.

dominicm22:09:08

Frankly, the approach seems bankrupt to me. Too many edge cases.

dominicm22:09:24

I like my tools to be a reliable foundation that I trust to work 100% of the time.

kenny22:09:05

Fair enough. I have not hit a problematic case with depstar yet but I imagine it'd be a total nightmare to debug.

dominicm22:09:55

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.

dominicm22:09:26

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.

āœ”ļø 3
dominicm22:09:03

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.

dominicm22:09:43

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.

kenny22:09:14

Think of all those wasted hours that could've been used for betterment... šŸ™‚

seancorfield21:09:05

Maybe @ghadi can speak to why it does that, since that was how it behaved when I inherited it...?

seancorfield21:09:52

FYI #depstar has its own channel now, in case folks have questions about it.

seancorfield21:09:22

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.

sogaiu22:09:21

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).

seancorfield04:09:35

@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.