This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-19
Channels
- # 100-days-of-code (5)
- # announcements (1)
- # aws (1)
- # beginners (112)
- # cider (135)
- # cljdoc (6)
- # clojure (111)
- # clojure-dev (8)
- # clojure-italy (3)
- # clojure-nl (5)
- # clojure-sweden (3)
- # clojure-uk (152)
- # clojurescript (101)
- # datascript (14)
- # datomic (61)
- # editors (1)
- # emacs (29)
- # events (7)
- # figwheel (3)
- # figwheel-main (15)
- # fulcro (18)
- # funcool (2)
- # graphql (1)
- # juxt (2)
- # off-topic (51)
- # om (1)
- # overtone (28)
- # perun (2)
- # reagent (1)
- # reitit (6)
- # ring-swagger (5)
- # shadow-cljs (112)
- # spacemacs (49)
- # tools-deps (10)
- # unrepl (11)
- # yada (10)
This one is cool too, about hazard pointers you were talking about recently https://youtu.be/nvfzQAUpunI
Naming problem. What would be concise but informative word for status “temporarily out of service”?
Closed might imply permanently. Shut I would have though implies "for a limited time", but still doesn't differentiate between "Shut for the day" and "Shut for 2 months for refurbishments" or whatever
<rant>multiple projects with gradle and eclipse are a mess. Jeez. Eclipse just throws everything onto one classpath -.- leaving you with potentially different versions of the same lib one one classpath </rant>
Does closed sound too much like “This place is closed. We’re open back again 8:00 in the morning” when what I wish to communicate is more like an exception situation.
If you're wanting end-users to read these single word strings and believe them to be clear and unambiguous you're basically stuffed 😉
If you want some other API to consume them and provide a longer form output to actual users, then just define in your docs what each one means
Yes it’ll be part of a public API. But I want to choose wisely because I’ll most probably be maintaining this thing for a while and future-me will face all the bad naming decisions I make.
down.
What’s the name of that theme?
Btw you talk is brilliant. Love it so much. I definitely need to check duct 🙂
I think it was a theme I put together: https://github.com/weavejester/dotfiles/blob/master/emacs.d/themes/weft-theme.el
It's based off something else.
But I can't remember what.
Thank you @U0BKWMG5B ❤️ 🙂
Why there is so much hype about go-routines? Don’t know how go-routines in Clojure are similar to Go’s ones, but everybody is so excited of “cheap” threads. What are they? Just green threads (used from Thread Pool) that operate on cooperative scheduling? How can you make threads with smaller stack than the OS ones? They still need to use OS Threads right?
I think, they are called goroutines so you don’t think they are threads, you just use them to do stuff concurrently. The point is, you don’t need to care how it’s implemented, either a OS thread or a whatever. It creates a layer of abstract above all different stuff you need for concurrency, so to keep things simple. Under the hood though, it uses a mix of OS threads and async loop, and so it’s lightweight to create new goroutines and usually you can create as many as you want.
I think Go has the this CSP model in the beginning, so this goroutine is universal. While Clojure only added this via a lib, so you only have the “goroutine” from the lib, and the “native” thread is not like “goroutine”. That’s why in Clojure you need to do different things inside/outside of go blocks, while in Golang, even the main “thread” is just a goroutine.
Can you please elaborate more:
> That’s why in Clojure you need to do different things inside/outside of go blocks, while in Golang, even the main “thread” is just a goroutine.
What do you mean by that?
The thing is, when you do blocking IO in a clojure go block, it will hog the thread, so it can’t make the switch to another go block (if I’m right). I’m not sure if that is a problem in Go, because they support async IO maybe?