Re: clojure.edn/read isn't spec compliant
Sean Corfield writes: > If you find valid EDN that a particular EDN reader fails to process > correctly, that's a bug. If you feed it invalid EDN, well, you may or may > not get an error or a value or... This is a good guideline. A valid edn reader should read valid edn, and the behaviour for "illegal" edn is unspecified. In fact, it is helping me to think about my own implementation. Good tip. Other than a few more "illegal" things that clojure.edn accepts, I have found a valid edn value that it doesn't: user=> (edn/read-string ":a:") Execution error at user/eval33 (REPL:1). Invalid token: :a: As per the spec, a keyword: "Keywords follow the rules of symbols, except they can (and must) begin with `:`" And for symbols: "`: #` are allowed as constituent characters in symbols other than as the first character." It follows that ":a:" is a valid keyword, as ":a#" is. The first produces an error, while the second is a valid keyword. >From what we've discussed on this thread, this is a bug. Did I miss anything? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/87mu02607y.fsf%40euandre.org.
Integrating `core.async` with `httpcore5-h2`
Hi folks, For some reason, the server component of the apache http-components [1] library doesn't get any love from the Clojure community. This is particularly strange to me, given the early/broad adoption of the client component (i.e. clj-http). In any case, I took version 5 for a spin, and in particular the async-server aspect of it, as I wanted to see whether it would integrate cleanly/nicely with core.async channels. The ring model of async handlers taking 3 arguments, albeit necessary, is hard to work with. Not only does it feel kind of magic - it is actually non-trivial to (correctly) propagate the `respond` and `raise` callbacks across the middleware stack (which can lead to bugs). The way I see it, it would be much nicer if the response's body was enough to distinguish whether this is a sync or async response. In other words, returning a core.async channel as the body should suffice to treat this as an async response. I spent a few hours today, and came up with this server wrapper [2]. If you need convincing that this works, evaluate the two expressions at the bottom of the file (inside a `comment` expression), and cURL into it from your terminal (per the comments). The actual construct which enables a channel to act as body can be seen here (`ChannelContentProducer`) [3]. The convention (for handlers) is simple. Use `promise-chan` for single response, but regular `chan` for streaming responses. That is it! No respond/raise indirection - just putting into the channel (and closing it when streaming). Other than that, honors the ring-spec (wrt requests). So there you have it - async from the ground-up, HTTP2 supporting, ring-friendly web-server prototype (in less than 250 lines). Kind regards, Dimitrios [1]: https://hc.apache.org/httpcomponents-core-5.0.x/index.html [2]: https://github.com/jimpil/asynctopia/blob/master/src/asynctopia/server/embedded.clj [3]: https://github.com/jimpil/asynctopia/blob/master/src/asynctopia/server/channel_body.clj -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/0dfa9260-9d8b-fbeb-d9ca-f29e01b1a04a%40gmail.com.
Re: clojure.edn/read isn't spec compliant
Here is some possibly relevant information. I suspect the reason that `(clojure.edn/read-string ":a:")` gives an error is that Clojure's EDN reader implementation was originally developed as an adaptation from Clojure's reader, and `(read-string ":a:")` also gives an error. The reference documentation for Clojure's reader here https://clojure.org/reference/reader#_symbols says "Symbols beginning or ending with ':' are reserved by Clojure. A symbol can contain one or more non-repeating ':'s". That is likely why Clojure's reader gives an error attempting to read ":a:". Perhaps it was intended that the last sentence should be included in the EDN specification, too. I do not know. My personal guess: the authors of the EDN specification and implementation are content with their level of detail, and might not be interested in making them 100% equivalent in all ways. (This is only my personal guess. Realize that making specifications and implementations match can be an exhausting and unrewarding process.) Andy On Sat, Oct 31, 2020 at 5:38 AM 'EuAndreh' via Clojure < clojure@googlegroups.com> wrote: > Sean Corfield writes: > > > If you find valid EDN that a particular EDN reader fails to process > > correctly, that's a bug. If you feed it invalid EDN, well, you may or may > > not get an error or a value or... > > This is a good guideline. A valid edn reader should read valid edn, and > the behaviour for "illegal" edn is unspecified. In fact, it is helping > me to think about my own implementation. Good tip. > > Other than a few more "illegal" things that clojure.edn accepts, I have > found a valid edn value that it doesn't: > > user=> (edn/read-string ":a:") > Execution error at user/eval33 (REPL:1). > Invalid token: :a: > > As per the spec, a keyword: > "Keywords follow the rules of symbols, except they can (and must) > begin with `:`" > > And for symbols: > "`: #` are allowed as constituent characters in symbols other than > as the first character." > > It follows that ":a:" is a valid keyword, as ":a#" is. The first > produces an error, while the second is a valid keyword. > > From what we've discussed on this thread, this is a bug. > > Did I miss anything? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/87mu02607y.fsf%40euandre.org. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CAKvLtDbrr%2B-ZQwLi6vYEUiMePdUExh589ZPjCHV3MHxTkRt9eg%40mail.gmail.com.
