merijn 2017-02-28 02:01:07
ertes: I actually realised I can simplify my life
ongy 2017-02-28 02:01:27
do we have a nice commandline parsing library that does mode/subcommands like the ip command?
merijn 2017-02-28 02:01:47
ongy: optparse-applicative has subcommands
tdammers 2017-02-28 02:02:52
so far, the most pleasant solution I've found was writing a custom parser with something like parsec
tdammers 2017-02-28 02:03:07
there's nothing stopping you from writing a parser over [String] rather than String
merijn 2017-02-28 02:03:16
tbh my experience with optparse-applicative was pretty good
merijn 2017-02-28 02:03:28
As long as you don't need anything to specifically custom
django_ 2017-02-28 02:05:14
whats a bold app
django_ 2017-02-28 02:05:16
a bold project
merijn 2017-02-28 02:05:45
tdammers: Have you used optparse-applicative? If so, what was insufficient about it?
tdammers 2017-02-28 02:06:21
I have, but I can't remember what I was missing specifically
ongy 2017-02-28 02:06:53
merijn: oh looks good. thx
merijn 2017-02-28 02:17:28
Anyone know what the fastest way to block a thread until some condition (a simple Int) is true?
merijn 2017-02-28 02:17:53
QSem(N)? Spin loop on IORef? Hand-written CAS loop using GHC primitives? Something else entirely?
hpc 2017-02-28 02:17:56
well, an int can never be true :P
hpc 2017-02-28 02:18:10
how does the condition change?
hpc 2017-02-28 02:18:29
if you can write it so the thread sleeps until notified, that'd likely be best
merijn 2017-02-28 02:18:34
hpc: Some threads increment a counter. Terminate when counter >N
merijn 2017-02-28 02:19:10
hpc: I want to benchmark concurrent operations, so I need to know when every thread is finished to end the benchmark
merijn 2017-02-28 02:19:16
hpc: Low latency > efficiency
hpc 2017-02-28 02:19:24
maybe a Chan?
merijn 2017-02-28 02:19:37
hpc: Chan is basically an MVar, but less efficient
hpc 2017-02-28 02:19:40
when a thread finishes, it sends () through the chan, and the waiting thread counts them
merijn 2017-02-28 02:19:55
hpc: Yeah...no, way too much overhead
merijn 2017-02-28 02:20:04
Since "sending to a Chan" is what I'm benchmarking
hpc 2017-02-28 02:20:11
oh lol
hpc 2017-02-28 02:24:07
maybe use MSem?
hpc 2017-02-28 02:24:34
initialize it to a negative number
hpc 2017-02-28 02:24:54
have the main thread wait (which waits to take until it's > 0)
hpc 2017-02-28 02:25:02
and the child threads signal (which adds 1)
hpc 2017-02-28 02:25:36
https://hackage.haskell.org/package/SafeSemaphore-0.10.1/docs/src/Control-Concurrent-MSem.html#MSem
hpc 2017-02-28 02:26:28
looks like QSem is deprecated
merijn 2017-02-28 02:28:08
hpc: Based on what? I don't see a deprecation ote
cocreature 2017-02-28 02:33:36
merijn: I would guess that a hand-written cas loop is best, but that's really just guessing :)
merijn 2017-02-28 02:34:05
cocreature: Yeah, leaves the question whether I should use GHC CAS primitives or unsafe FFI to C
merijn 2017-02-28 02:34:11
Guess that's another experiment xD
cocreature 2017-02-28 02:34:31
merijn: if the unsafe FFI stuff is faster, we need new primitives :)
merijn 2017-02-28 02:34:44
True :p
