This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-12-23
Channels
- # adventofcode (4)
- # beginners (25)
- # biff (11)
- # clojure (2)
- # clojure-bay-area (1)
- # clojure-europe (5)
- # clojure-norway (2)
- # clojuredesign-podcast (4)
- # datalevin (2)
- # dev-tooling (34)
- # hyperfiddle (2)
- # missionary (5)
- # off-topic (3)
- # polylith (4)
- # rewrite-clj (13)
- # shadow-cljs (11)
- # tools-deps (1)
- # vim (1)
- # xtdb (5)
I recently read both the Armstorng thesis and the CSP documentation for core.async. I'm trying to evaluate the differences between CSP and OTP/Actor concurrency. I broadly understand the what of the differences (CSP has identifiable channels that can be passed around and be taken of or put into; put can be blocking or non-blocking; in OTP the processes have an ID and communicate via unreliable message passing and mailboxes). What I am trying to learn more about is the why. What are the tradeoffs? What's better for distributed programming? What's easier to test/prove correct? Why did Clojure choose CSP over OTP? So far all the sources I have read were agenda driven (I wrote this OTP library, and here's why OTP is better...). I'd like to find something more balanced.d
It is also tough because both actors and csp have different implementations with different understanding of what it means (csp maybe comes closer to maybe having a "standard")
For OTP specifically, that is tied very closely to the execution model of erlang, and the jvm is just not that.
Scheme famously started as an experiment trying to understand the actor model better
I would say actor models tend to have very heavy runtimes, because the runtime is responsible for a lot of stuff like queue management, because those are implicit in the model
On the other hand it is much easier to add explicit queues to a language and say "hey, it's csp"
π calculus had channels and processes, but also types, so more interesting for doing proofs
I would be very shocked if doing proofs was a thing anyone cares about when creating core.async
There's some rationale for Clojure's choice here: https://clojure.org/about/state#actors
Rich Hickey also talks about it a bit in some of his talks about core.async, I don't have specific links though
Which is something to keep in mind, it isn't like clojure chose csp as the way to write concurrent programs. Clojure comes with some built in stuff for concurrent programs. core.async is a library (by some of the same people), an add on, that implements csp
People have also written other libraries, that are more promise like, or that do structured concurrency
I think core.async may have ended up more csp like than actor like because csp has sort of primitive flow control built in (processes synchronously meet at channels to exchange a message) actors have to build a gadget to do that (the actor model is formally strictly asynchronous so you either extend it with synchronous sends or add some kind of acknowledgement mechanism on top). And I think that kind of thing is important if you care about building open vs. closed systems, and I think rhickey is really into the idea of building open systems (spec, multi methods, stm, etc), but I don't think I've seen anything actually written about it by rhickey
https://github.com/halgari/clojure-conj-2013-core.async-examples/blob/master/src/clojure_conj_talk/core.clj#L496 halgari did a lot of early work on core.async and gave a talk on it early on, which included a mini actor implementation on top of core.async, and some comments about why he doesn't like actors
I use the next.jdbc
query data. the table's column manufacture_date
is DATE
dbtype with mysql .
(jdbc/execute! dbcon ["select * from car_info"])
return :manufacture_date "2023-12-05 00:00:00", It append time '00:00:00' why doesn't it only return the date?next.jdbc is a wrapper around jdbc, the java SQL database interface, that the driver for the particular database you are using implements. The driver is responsible for mapping jvm and SQL types. Most drivers where written or had development start on them well before java got a built in type that represented just dates without time
I would be more concerned about a string back than getting a date with all zero time
Hi all, this is my first time posting here. I am wondering how to you suppress info messages in the nREPL (cider/emacs)? I am currently parsing a large number of pdfs (c. 3000) using the pdfbox library (with the pdfboxing clojure wrapper https://github.com/dotemacs/pdfboxing). When calling pdfboxing.text/extract
is prints the following info message to the repl: "INFO: OpenType Layout tables used in font ABCDEE+Tahoma are not implemented in PDFBox and will be ignored" Is there a way to stop it printing this?
Hi vemv, thanks so much for the reply. It was a good tip to clone the projects and have a look at the logging. For context, the issue I was having was that when I ran a parsing function on all the pdfs using pmap
, emacs actually ended up completely crashing. I suspected maybe it was the repl having to print these warnings 3000+ times. When I ran the same function with map
it worked okay (albeit very slowly!) The workaround I've found for now is to just start cider without the 'middleware' (I edited the clj cider startup command and removed the ---middleware
parts from the :main-opts
), and everything is indeed working again now. Not the ideal solution, but I don't know enough about java and logging in general to find a more targeted solution. Anyway, thanks again for taking the time to reply.
As a quick fix, try set the repl buffer size to stop Emacs slowing down due to lots of messages in the repl buffer
(setq cider-repl-buffer-size-limit 100)