Fork me on GitHub
Cora (she/her)01:06:42

is there a way to load a file from another jar's resources path?

R.A. Porter02:06:11

In raw Java, you could load the jar into a new classloader and pull the resource from that loader. Might need to do a bit of ugly interop in Clojure to make it work, but probably not too much.

Cora (she/her)02:06:52

ok cool that's a good place to start from. thanks!

R.A. Porter02:06:13

Could even just open it as a zipfile if you wanted to.

Cora (she/her)02:06:42

right, yeah, in this case I'm using babashka and it has some handy things for stepping into zip files and pulling things out

R.A. Porter02:06:12

This should work. It’s possible you might hit security policy issues, but unlikely. And if you do, then falling back to zip file processing will work fine.

R.A. Porter02:06:37

f will likely be a file url, but it could be any source in reality.

Cora (she/her)02:06:37

I suppose I'll need to somehow get java to give me where the jar file is even if I wanted to use zip to access the files within it

Cora (she/her)02:06:45

which I'm guessing a loader would tell me

R.A. Porter02:06:43

Oh yeah. That assumes you already know the path.


under normal circumstances the libs resources path was just one root. so all the files in it should have ended up in the jar


so resources/whatever/foo.txt would just be accessible via ( "whatever/foo.txt")


no need to locate the actual jar or mess with classloaders?


didn't babashka support some kind of classpath management? I'm not sure


if so it should just work

Cora (she/her)01:06:32

I'd like to be able to read a config file within a jar


I have a question around clojure tests - I’ve been trying to use the more lately, and often find myself comparing the results of a couple maps. However, even when the maps are small, for failures I just get a massive line of text implying ‘these two maps are not equal’ and I’m left to sort through these unformatted unstyled uncolored maps to find the difference myself. How do clojurians deal with this/solve this problem? I always see map comparisons in tests so I’m assuming that there is a solution

robert-stuttaford09:06:50 integrates this and makes the reading/understanding of test output a great pleasure to do

👀 1

i also use CIDER's built-in test uis and those work great for most things


Unfortunately all my projects are made with shadow-cljs and that doesn’t seem to be supported 😢 I’ll look into manually using deep-diff2 though


shadow-cljs can be used with kaocha through kaocha-cljs2.


but there are probably easier ways to get deep-diff2 support into your existing workflow


If you can supply a custom reporter then it should be quite doable to hook those things up


This isn’t exactly what you are asking for but I find Nubank’s matcher-combinators library has made my life a lot easier.


It allows you to make structural assertions about data structures without needing exact equality. And it also does a pretty good job of reporting mismatches clearly.


I have not tested it with CLJS so not 100% it works for you, but its a good tool regardless


second nubank/matcher-combinators

Luke Johnson01:06:34

The Portal tool has a When you send the test result to Portal, it pulls out the data for easier visibility. And you can always multi select both the expect and actual maps and deep-diff them directly in Portal! It's pretty handy! Learn more on #portal.


for a lower tech suggestion, I usually replace (is (= map-wanted map-found)) with (is (= map-wanted (select-keys map-found (keys map-wanted))))


also, if you are testing for 80 keys, as above but make 10 tests, each one with 8 keys selected (adjust the numbers as you like)


Does anyone know of a way to configure hato to not include headers in the exception info? We don't want to accidentally log secrets

Linus Ericsson18:06:45

I cannot find such an option. I suggest you wrap all calls to hato with wrappers that (try (catch )) and then remove headers if present, then rethrow the exceptions with the updated data.



Linus Ericsson18:06:29

I guess you could make a wrapper namespace. It could have the exact same fn names as hato client. If it is about code you control, it is quite a mechanical operation to replace the refers to hato client to your new wrapper namespace.


well we already have wrappers for the service to inject the tokens and such into the headers, doing it for this case isn't that bad


but I got a pretty huge codebase sittin here


i wonder if clj-http handles it/how


Is there straightforward method to recursively remove meta of nested objects?


@johndoe postwalk is known to (accidentally?) drop metadata 😆 so maybe it kind of already works with walk/postwalk identity ;)


and else postwalk + with-meta nil (+ check if something is an IObj)


wow. Thank you!


@johndoe why though? Metadata should be invisible. Secrets?


I have a complex macro which works similar to let-form but in reactive way. It supposed to work in clojure and clojurescripts and it works perfectly, just clojurescript complaining with warnings about undefined vars. So I just investigate it and try to erase metadata in generated code which partially source of problem.


Are there and significant performance issues with var quoting function names where they are used? I know this is common for web handlers so it makes it easier to develop them interactively. Just wondering if the resolution has any nontrivial impact on performance.


hard to say, the cost is in theory low, reading a volatile field


definitely something that would be dwarfed by any other work a webserver is doing


but that is not nothing, and I have heard that hotspot won't inline across the volatile field, so maybe something to avoid in hot loops

👍 2

Catching Exception VS catching Throwable : My understand is that generally you should catch Exceptions rather than Throwables, as Throwable tends to be errors you cannot recover from (like OOM for example), but my knowledge of Java is certainly lacking so maybe my understanding is wrong. What do people here tend to do?

Drew Verlee03:06:58

In terms of word choice, it would be unfortunate if you weren't supposed to catch something called a throwable.


Depends on how you are trying to handle the exception. Generally Exception is recommended. If it's you're eg logging the error and rethrowing it then catching throwable could make sense. Throwable has two descendants, Exception and Error. You could catch both separately and handle them differently. Also something to keep in mind: assertions throw RuntimeErrors, so these are not handled if you catch only Exception.


@U0DJ4T5U1 hah, yeah agree! Unfortunate, it doesn't seem like Java gets naming right in all the cases so wouldn't surprise me a lot


@U07FP7QJ0 thanks! Yeah, I understand there are exceptions (no pun intended) to that rule, like within testing or maybe within specific infrastructure dealings. Seems unfortunate that assertions throw Error instead of Exception , since the Javadocs for Error says "probably shouldn't catch it" > An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions.

Joshua Suskalo13:06:42

I mean if you fail to meet an assertion in some code that's probably a developer error, which means crashing is a viable strategy.

Joshua Suskalo13:06:07

I would advise to never catch throwable unless you are making a job harness. That is, some clde which must execute other code in isolated environments where one does not affect the next, and where a previous one failing does't affect if the next should be run.

Joshua Suskalo13:06:49

Think like an http client accept loop or an event dispatcher with core.async.

Joshua Suskalo13:06:00

Error is specifically designed to not be caught, and so there are libraries that rely on that in order to provide high level flow control constructs, and catching throwable disables the ability to use those to cross the boundary of your code. In the case of some kind of job harness this isn't a problem, it makes no sense to unwind from inside a job to outside that job's harness, but in nearly every other context catching throwable just to catch assertions should not interfere with other errors.

Drew Verlee13:06:37

What's a good example of doing that? Two such systems couldn't be nested, so the catcher would have to be sure they were always going to control the context.

Joshua Suskalo14:06:59

an example of which, using errors for control flow? That'd be, which absolutely can be used with other such systems as long as the other system makes a different subclass of Error