This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-28
Channels
- # aleph (3)
- # babashka (66)
- # beginners (96)
- # calva (45)
- # clj-kondo (28)
- # clojure (30)
- # clojure-dev (2)
- # clojure-europe (20)
- # clojure-germany (22)
- # clojure-norway (4)
- # clojurescript (176)
- # clojutre (1)
- # cursive (23)
- # datalog (6)
- # datomic (7)
- # docker (3)
- # emacs (3)
- # exercism (4)
- # figwheel-main (5)
- # fulcro (8)
- # gratitude (9)
- # hyperfiddle (8)
- # introduce-yourself (2)
- # jobs (2)
- # malli (4)
- # membrane (3)
- # off-topic (17)
- # polylith (3)
- # portal (2)
- # re-frame (27)
- # reitit (3)
- # releases (1)
- # remote-jobs (1)
- # shadow-cljs (152)
- # spacemacs (8)
- # tools-deps (15)
- # vscode (1)
- # xtdb (24)
Anyone, Does aleph have any issues with :multi in malli schema? After schema validation the request body Inputstream is empty.
Thanks @U07FCNURX that helps but my query is that where the big lies either at malli’s end or aleph’s end
@U07FCNURX ' response gave you all the info you need if you actually take the time to understand it Surely Malli validation reads the InputStream once, that prevents further reads Whose bug is it? It doesn't matter, it's just how InputStream works, if you don't like it, wrap it in a custom type that is idempotent
This is not strictly correct. Many InputStreams support mark
and reset
, to enable rereading a stream, though Aleph’s underlying library byte-streams
doesn’t promise to return a markable stream in general.
Thanks for a detailed input guys that helps a lot @U45T93RA6 @U10EC98F5 :spock-hand:
@U030SSZRHGA Generally, if you don’t want to deal with an InputStream in your Aleph handler, you would use something like clj-commons.byte-streams/to-string
or clj-commons.byte-streams/to-byte-array
first. Check out the examples/
subdirectory in Aleph, or see https://aleph.io/aleph/literate.html#aleph.examples.http.
Awesome thanks @U10EC98F5 let me check with the suggestion you mentioned. Thanks man :spock-hand:
@U10EC98F5 the suggestion is for http-client but I am working on the server part with the ring-handler for routes. Your example seems to solve my web-app issue but not the server issue
@U030SSZRHGA I’m a little confused as to your situation. byte-streams
works on the server-side, too. The :body
of the req
is an InputStream (usually a ByteArrayInputStream). E.g. here’s a ring handler to upper-case the body:
(defn body-upper-case-handler
[req]
{:status 200
:body (-> req :body bs/to-string str/upper-case)})
I don’t know how Malli works, but if something is consuming the stream and not passing the contents along, you should extract it first and validate second.Let me check extracting the values @U10EC98F5
When I am the Code running in a future
/`future-call`, is there a possibility to react to being cancelled, e.g. by future-cancel
?
You can wrap the code in try-catch and handle https://docs.oracle.com/javase/7/docs/api/java/lang/InterruptedException.html
Hi! We have a code reloading process for our backend server that was recently ported from leiningen to tools-deps. We are using ns-tracker
and a loop that checks for changes every 500 ms. Reload code itself looks like this:
($/info "Reloading namespace:" ns-sym)
(require ns-sym :reload)
($/info "Done reloading namespace:" ns-sym)
Many namespaces take a long time from the first log statement to the last (couple of seconds or more). Before transitioning to tools-deps, there was no noticeable delay.
I know this isn’t a particularly solid reproducible report, and this probably isn’t the tool’s fault. I’m just posting this here in case anyone using tools-deps ran into this at some point and knows the reason for it.How is tools.deps involved?
Not much really. Only difference I could think of is some slight difference in dependency resolution, which i’m checking in depth now, or how the process is launched. But hardly any reason to think that either, started with lein run
before, starts with clojure -M:run
now
Well, not sure I see how that would be any different
When it's slow, try taking some thread dumps with ctrl-\
See what it's doing
Do you compare it on the same environment and for example not jar file vs REPL in editor?
@U064X3EF3 Thanks! I’m not good at interpreting those dumps, so I’ll show it to one of my colleagues tomorrow
@U0WL6FA77 Yes same environment, starting from source code, main fn. Could be that our java version went from 15 to 17 somewhere in this process, that’s also a good point to check out
Problem turned out (as always) to be something unrelated to the first hypothesis. It was indeed caused by switching to tools-deps, but not the way I thought. The old version had AOT, the new version did not. Old version was fast because of that… Thank you for taking the time to respond!
:thumbsup:
I have a deftype declared as follows:
(deftype DTSConnectionPool
[^:volatile-mutable availableConnections
^:volatile-mutable busyConnections
;; ... other non-mutable fields
]
IDTSConnectionPool
(initialize [this]
(locking this
(set! availableConnections [])
(set! busyConnections [])))
;; ... more methods
)
However, I am getting an error that says "Cannot assign to non-mutable: availableConnections" on the line that attempts to set availableConnections. What's wrong with the declaration that's causing the compiler to not recognize the attribute as mutable?