This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (5)
- # beginners (36)
- # boot (3)
- # cider (89)
- # clara (35)
- # cljsrn (6)
- # clojure (123)
- # clojure-dev (15)
- # clojure-italy (9)
- # clojure-nl (14)
- # clojure-spec (11)
- # clojure-uk (192)
- # clojurescript (27)
- # cursive (22)
- # data-science (1)
- # datascript (1)
- # datomic (31)
- # defnpodcast (1)
- # duct (1)
- # emacs (9)
- # fulcro (2)
- # graphql (16)
- # jobs-discuss (10)
- # juxt (1)
- # keechma (7)
- # mount (4)
- # off-topic (83)
- # onyx (8)
- # pedestal (5)
- # portkey (1)
- # re-frame (44)
- # reagent (29)
- # reitit (4)
- # remote-jobs (1)
- # ring-swagger (1)
- # rum (24)
- # shadow-cljs (1)
- # spacemacs (30)
- # tools-deps (6)
- # vim (23)
Hi, how does one deal with unsupported escape chars in strings?
this is response i get from one site which is location of a picture.
i just get erros what ever i do saying
\/ is unsupported which is ok but i can't even
replace them or do anything with that kind of string.
How do i deal with this?
@lepistane How are you trying to read the string? You should be able to read it as raw bytes, then replace
\/ then process it as strings.
@seancorfield this worked! thank you just as a reference for others i used https://clojuredocs.org/clojure.core/bytes, https://clojuredocs.org/clojure.core/byte-array and https://github.com/dakrone/clj-http/#output-coercion to accomplish this
luminus project, for a postgres connection, in
dev-config.edn, should it be with or without jdbc in
well test it 😄 try both see how it goes once you finish you will know it's without jdbc
So I'm trying write some unit tests where I need to mock some imported static java functions below
(ns app.foo (:import [com.auth0.jwt JWT JWTVerifier])) (defn decode-token [JWT token] (try (JWT/decode token) (catch Exception e (log/warn "Invalid Token: " e) e))) ;;;TEST FILE (ns app.foo-test (:import [com.auth0.jwt JWT JWTVerifier])) (def mock-jwt (proxy [JWT]  (decode [^String a] "decoded"))) (deftest decode-token-test (testing "should decode" (println (decode-token mock-jwt "foo"))))
it's a little confusing that you have imported JWT and also have a parameter called JWT. I'm honestly not sure which is resolved there. I'm also not convinced this test tests any actual code besides the try/catch and logging but that doesn't seem to be what you are testing. But I would do something like this:
also thought it would be better to pass in JWT to the function so that I can easily mock it and the function becomes pure.
if your param is x x/foo shouldn't work - you can't call static methods on classes passed as args like that
if x/foo is referring to the class x which was imported, your param is being ignored
@U6X9NEMP1 If interested in more details on that subject: Clojure has no secret power when it comes to doing something like a static method call on a class (this is just Java interop), it information needed at compile-time, otherwise you have to use reflection.
If you are familiar with Java, think of how you would try to do what you what you did there in Java and you’d run into the same problem
You might find
with-redefs useful. It lets you redefine a function for testing without having to pass it in as an argument.
replacing a parameter in order to use with-redefs is a bad idea - with-redefs is fragile, even for testing
and it only works on some functions - anything statically compiled or special cased in the clojure compiler won't be redeffed properly
in order to replace the class with something you with-redef, you need it to be a var, at that point you've already done the fix that allows you to use it as an arg
It only redefines things within the
with-redefs block though. We use it frequently for testing and it helps us write code that doesn’t care about the details of how it’s being tested.
Hm, interesting to know 🙂 That’s not something we’re doing so I never came across that.
i'm a big fan of the higher order type and make it easy to pass in a test param. and then def or defn a version in the code that correctly composes the actual implementation. I've found that writing code that cares about the details of how its being tested makes cleaner code often