This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-17
Channels
- # announcements (4)
- # babashka (22)
- # beginners (50)
- # biff (2)
- # calva (4)
- # cider (18)
- # clj-kondo (12)
- # cljs-dev (3)
- # clojars (2)
- # clojure (66)
- # clojure-austin (1)
- # clojure-belgium (11)
- # clojure-europe (90)
- # clojure-hungary (5)
- # clojure-norway (6)
- # clojure-switzerland (1)
- # clojure-uk (4)
- # clojurescript (19)
- # datascript (2)
- # datomic (41)
- # fulcro (4)
- # gratitude (2)
- # helix (20)
- # jackdaw (2)
- # jobs (9)
- # jobs-discuss (38)
- # kaocha (1)
- # minecraft (8)
- # off-topic (11)
- # polylith (21)
- # rdf (2)
- # remote-jobs (1)
- # sci (1)
- # shadow-cljs (12)
- # specter (7)
- # tools-deps (16)
is there a way to load a file from another jar's resources path?
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.
ok cool that's a good place to start from. thanks!
Could even just open it as a zipfile if you wanted to.
right, yeah, in this case I'm using babashka and it has some handy things for stepping into zip files and pulling things out
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.
f
will likely be a file url, but it could be any source in reality.
ooooh nice
thank you!
Pleasure.
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
which I'm guessing a loader would tell me
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
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
https://github.com/lambdaisland/kaocha integrates this and makes the reading/understanding of test output a great pleasure to do
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
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. https://github.com/nubank/matcher-combinators
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
The Portal tool has a https://github.com/djblue/portal/blob/master/doc/guides/test-runner.md. 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
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.
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
@johndoe postwalk is known to (accidentally?) drop metadata 😆 so maybe it kind of already works with walk/postwalk identity
;)
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.
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
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?
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.
https://docs.oracle.com/javase/7/docs/api/java/lang/Error.html
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.
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.
Think like an http client accept loop or an event dispatcher with core.async.
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.
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.
an example of which, using errors for control flow? That'd be https://github.com/IGJoshua/farolero, which absolutely can be used with other such systems as long as the other system makes a different subclass of Error