monochrom 2017-01-28 07:45:23
And I have a Aesop tale to tell for that, too :)
dunx 2017-01-28 07:45:35
well, depends if you control the computers. so for instance i could offer a vm (hypothetically)
monochrom 2017-01-28 07:47:43
OK, you know whom to email to say you want donate your computing time, right?
reactormonk 2017-01-28 07:56:28
monochrom, so you didn't find anything either? :-(
monochrom 2017-01-28 08:00:59
I think urls are fairly implicit in http-types and not easy to single out.
reactormonk 2017-01-28 08:02:57
Yeah, having something explicit to build URLs would help out.
reactormonk 2017-01-28 08:03:39
Any you would know of?
monochrom 2017-01-28 08:05:39
No.
nitrix 2017-01-28 08:20:37
If there is only one reader and one writer to an IORef, but each have their independent threads, can I use readIORef and writeIORef respectively?
monochrom 2017-01-28 08:21:05
I think yes.
nitrix 2017-01-28 08:21:20
Or am I supposed to use atomicModifyIORef? This one seems like an issue with my current design because effects needs to be carried out only once between writes.
hpc 2017-01-28 08:23:39
in ghc, just about everything about acting on an IORef happens to be implemented with the same safeties as atomicModifyIORef
hpc 2017-01-28 08:24:18
which really just goes as far as to say you're never going to observe a "corrupted" value
glguy 2017-01-28 08:25:00
I think the concern is more about reordering of effects than corruption, isn't it?
nitrix 2017-01-28 08:25:18
hpc: That was my concern. Thanks.
hpc 2017-01-28 08:25:22
i would look more at something like TVar or MVar, which communicates more of a "this is being used concurrently by several things and here is how i keep it consistent"
nitrix 2017-01-28 08:25:47
Yeah. This would be an issue, excepted single writer and reader for this use case.
glguy 2017-01-28 08:26:19
so the issue would be that effects in the one thread could be reordered around the write to the ioref
glguy 2017-01-28 08:26:25
and observed in a different order in the other thread
ij 2017-01-28 08:26:34
How do I build an unpublished package's haddock docs?
nitrix 2017-01-28 08:26:41
I just want an effective communication between two threads that wont block on reads, so the reads can keep happening on the previous value until new writes happen.
ij 2017-01-28 08:26:43
haddock **/*.hs?
glguy 2017-01-28 08:26:50
ij : cabal haddock
ij 2017-01-28 08:28:12
or `stack haddock'?
monochrom 2017-01-28 08:29:49
@quote monochrom IORef.Int
lambdabot 2017-01-28 08:29:49
monochrom says: new catchy thing to say: an IORef Int contains an Int in the same sense as an IO Int contains an Int
ij 2017-01-28 08:30:36
Hmm, so are haddocks dependent on other packages?
nitrix 2017-01-28 08:30:39
hpc: Curiously, if an atomicallyModifyIORef fails, does the whole computation restarts or only the writing part?
ij 2017-01-28 08:30:45
And where will they be placed afterwards?
hpc 2017-01-28 08:31:44
nitrix: it never fails
nitrix 2017-01-28 08:31:47
hpc: (Failing as in, the compare-and-swap detects something touched it)
hpc 2017-01-28 08:31:58
nitrix: it waits for another atomic operation to complete, and then performs itself atomically
hpc 2017-01-28 08:32:01
blocking other operations
nitrix 2017-01-28 08:32:06
Ah interesting.
hpc 2017-01-28 08:32:20
what you describe is a transaction, which TVar does
hpc 2017-01-28 08:32:33
MVar is a more explicit form of blocking, where it can be either empty or full
nitrix 2017-01-28 08:32:36
So TVar is the one that does compare-and-swap and retries?
hpc 2017-01-28 08:32:41
empty vars block taking
hpc 2017-01-28 08:32:44
full vars block putting
hpc 2017-01-28 08:32:54
yes
nitrix 2017-01-28 08:33:01
Does TVar recomputes everything on every try or just the writing part?
hpc 2017-01-28 08:33:17
in fact, if you have a single consumer and producer, MVar might be what you want anyway
hpc 2017-01-28 08:33:30
the producer blocks if it gets ahead, until the consumer takes another item
hpc 2017-01-28 08:33:38
and the two threads proceed concurrently, but in relative lockstep
hpc 2017-01-28 08:33:56
or maybe you want them to not block each other, and you use a Chan perhaps
hpc 2017-01-28 08:34:30
if you use an IORef with atomic modifications, you're likely doing it in a way that the producer is able to overwrite the consumer's next step
hpc 2017-01-28 08:34:44
or the consumer doesn't need to wait for the producer and can perform multiple loops on the same input
nitrix 2017-01-28 08:35:00
hpc: That's indeed the goal.
nitrix 2017-01-28 08:35:27
hpc: I want my game engine to keep processing events and generate the next game state which the renderer will be able to pick up and render on the next frame.
nitrix 2017-01-28 08:36:49
I was concerned with potentially corrupted game state with IORef; the renderer blocking on reads for MVar; and the whole heavy logic being recomputed with a TVar.
nitrix 2017-01-28 08:36:54
But you dispelled some of my concerns :)
hpc 2017-01-28 08:36:58
:)
ij 2017-01-28 08:43:25
What does the LANGUAGE CPP do?
hpc 2017-01-28 08:43:46
it turns on the same CPP that preprocesses C files
ij 2017-01-28 08:44:04
But it is otherwise haskell?
ij 2017-01-28 08:44:20
Okay, cool, but very weird.
hpc 2017-01-28 08:44:37
quite
hpc 2017-01-28 08:44:47
it's useful for writing compiler-specific stuff
hpc 2017-01-28 08:44:52
and maybe occasionally FFI?
