Fork me on GitHub
#off-topic
<
2018-10-19
>
john00:10:07

This one is cool too, about hazard pointers you were talking about recently https://youtu.be/nvfzQAUpunI

valtteri13:10:23

Naming problem. What would be concise but informative word for status “temporarily out of service”?

polymeris13:10:49

abeyant

🔝 2
valtteri14:10:28

Kinda cool! But would everyone have to look it up in dictionary?

polymeris14:10:30

Yeah, was mostly kidding

pablore14:10:29

out for lunch

valtteri13:10:57

Is there even a single word for that. :thinking_face:

danm13:10:00

offline?

valtteri13:10:17

Hmmm it’s about physical places where people go to play sports

valtteri13:10:00

I need to distinguish if it’s temporarily or permanently closed

valtteri13:10:13

But closed is getting… closer to what I’m looking for 😉

valtteri13:10:40

:closed-temporarily and :closed-permanently sounds pretty good to me actually

danm13:10:26

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

polymeris13:10:29

:http-501 :http-503

sveri13:10:37

<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>

valtteri13:10:18

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.

sashton13:10:53

Unavailable?

👍 1
danm13:10:02

How are you intending this information to be consumed?

danm13:10:36

If you're wanting end-users to read these single word strings and believe them to be clear and unambiguous you're basically stuffed 😉

valtteri13:10:48

It’s for programmers.

danm13:10:05

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

valtteri13:10:22

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.

valtteri13:10:56

Thanks for the ideas! I’ll take a break and let my brain decide.

3Jane14:10:00

suspended

soulflyer14:10:05

would re-<something> give the right impression? Maybe re-starting....

emccue17:10:04

If you know it will reopen maybe "under-renovation"

emccue17:10:36

That's two words though

Denis G20:10:04

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?

markx16:10:55

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.

markx16:10:44

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.

Denis G21:10:59

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?

borkdude20:10:58

I don’t know about Go’s threading model though.

borkdude20:10:43

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?

borkdude20:10:59

In Haskell that is the case, they support async IO by default and use something like green threads.

borkdude20:10:51

Didn’t mean to interrupt you @tbaldridge 🙂

👍 1