sternmull 2017-02-07 10:47:41
can i use hoogle to get a complete offline documentation? When i start the server locally then it searches the local index (i think) but all the links point to the public site. It would be nice to have the complete documentation offline.
mzabani 2017-02-07 10:48:08
Does anyone here know if http-client can be used on a different medium? My intention is to use it through a WebSocket tunnel on an already established connection..
EvanR_ 2017-02-07 10:51:13
nitrix: thread-local variables?
EvanR_ 2017-02-07 10:51:21
like, OpenGL
nitrix 2017-02-07 10:52:38
SDL
EvanR_ 2017-02-07 10:55:04
i mean, thread-local state, or just variables
nitrix 2017-02-07 10:56:32
EvanR_: https://wiki.libsdl.org/SDL_PumpEvents
nitrix 2017-02-07 10:56:35
EvanR_: "WARNING: This should only be run in the thread that initialized the video subsystem, and for extra safety, you should consider only doing those things on the main thread in any case."
nitrix 2017-02-07 10:57:08
EvanR_: It's not much to work with. Just a mere warning telling me the polling of events has to happen in the same thread as the one that initialized SDL.
nitrix 2017-02-07 11:03:57
Oh gosh, I think I found the problem.
nitrix 2017-02-07 11:04:18
EvanR_: Are multiple invocations of runInBoundThread going to use their own independent thread?
nitrix 2017-02-07 11:04:32
(As opposed to sharing a common one?)
kstuart 2017-02-07 11:05:36
sternmull: have you tried 'hoogle generate --local'
kstuart 2017-02-07 11:06:06
https://github.com/ndmitchell/hoogle/blob/master/docs/Install.md#index-all-ghc-pkg-installed-packages
nitrix 2017-02-07 11:06:22
EvanR_: e.g. do { a <- forkIO $ runInBoundThread $ foo; b <- forkIO $ runInBoundThread $ bar }
nitrix 2017-02-07 11:06:57
EvanR_: Are `a` and `b` going to share the same bound thread? How about forkOS ?
sternmull 2017-02-07 11:10:35
kstuart: i do not remember how i generated the index. Now i did it with --local. Search still works, but now the links to more documentation are dead... but at least they point to local URLs :)
kstuart 2017-02-07 11:12:43
ah, just getting started with haskell and happened to be reading that hoogle page ;)
exio4 2017-02-07 11:13:42
nitrix: I don't know there are guarantees about that, nor about the opposite
nitrix 2017-02-07 11:14:23
exio4: Can I have two forkIO threads pinned to the same forkOS thread easily?
exio4 2017-02-07 11:14:51
nitrix: no idea, I haven't played much with that stuff =)
dmwit 2017-02-07 11:15:06
forkIO threads can't be pinned at all.
nitrix 2017-02-07 11:15:13
exio4: It doesn't help that GHCi has a bug in it, where the main function isn't ran in a bound thread.
nitrix 2017-02-07 11:15:36
The documentation says main is always ran in a bound thread, but this is a lie for GHCi.
dmwit 2017-02-07 11:15:36
Also you cannot ask that two forkOS'd actions be run on the same OS thread.
dmwit 2017-02-07 11:15:58
What's the goal?
Tuplanolla 2017-02-07 11:16:03
You should probably rethink your architecture if you find yourself yearning for these guarantees, nitrix.
nitrix 2017-02-07 11:16:18
dmwit: Polling events from a window as well as rendering it.
nitrix 2017-02-07 11:16:32
dmwit: Both twos must happen in the OS thread that initialized SDL.
dmwit 2017-02-07 11:16:47
Usually GUI libraries have a way to send an action as an event.
dmwit 2017-02-07 11:16:53
Then the event loop will get the event and act on it.
nitrix 2017-02-07 11:17:01
dmwit: That's the precise problem.
nitrix 2017-02-07 11:17:20
I don't want the rendering to stop while waiting for events. And polling events is a naive approach.
Tuplanolla 2017-02-07 11:17:46
You can have the main thread read a channel, which other threads write into, to pass messages around, nitrix.
dmwit 2017-02-07 11:17:50
nitrix: Make another thread. It doesn't have to be bound to the same OS thread. Have it send an event to the event loop.
dmwit 2017-02-07 11:18:10
Tuplanolla: Not if the main thread is running the event loop...
nitrix 2017-02-07 11:18:12
Tuplanolla: I am doing exactly that and here we are :)
Tuplanolla 2017-02-07 11:18:25
Oh, right...
nitrix 2017-02-07 11:18:26
dmwit: I'm doing also exactly that :)
dmwit 2017-02-07 11:18:37
nitrix: Then I very much don't understand.
nitrix 2017-02-07 11:19:19
https://github.com/nitrix/lspace/blob/develop/src/Kawaii/Engine.hs#L52
nitrix 2017-02-07 11:19:41
This was one of the original implementation. Things have been thrown around a lot since then.
nitrix 2017-02-07 11:20:13
You can basically imagine all the combinations of asyncBound, async and runInBoundThread possible.
ph88 2017-02-07 11:20:36
if i have structures like Foo (Wrap T) (Bar (Wrap T)) (Wrap (Qux (Wrap T))) where all the structures contain a T eventually somewhere and i want to modify the last T .. is that a job for Lens or for generic programming ?
nitrix 2017-02-07 11:20:44
I do feel like I have a better understanding now so this definitely looks wrong. But even my current approach yields weird results.
dmwit 2017-02-07 11:21:15
nitrix: Have you looked through http://dmwit.com/gtk2hs, which discusses how to do threading the Right Way for gtk2hs? Probably the same commentary applies to SDL with some alpha varying of API call names.
ph88 2017-02-07 11:21:21
nitrix, you should put some screenshots in your readme :P
glguy 2017-02-07 11:21:30
ph88: That doesn't have anything in particular to do with a Lens
ph88 2017-02-07 11:21:41
k
dmwit 2017-02-07 11:21:46
nitrix: In short: almost nothing needs to run in a bound thread.
nitrix 2017-02-07 11:21:47
ph88: The master branch had somewhat of a working game with physics and all.
glguy 2017-02-07 11:21:57
You might make a lens that "refers" to the "last T" that's at a different layer
dmwit 2017-02-07 11:21:59
nitrix: Just the main event loop, usually; and on Linux, not even that. =P
nitrix 2017-02-07 11:22:15
ph88: https://github.com/nitrix/lspace/blob/master/assets/tileset.png Look at the cute little guy !
ezgoat 2017-02-07 11:22:21
.leave
ph88 2017-02-07 11:22:22
glguy, i don't want to write a function for each structure separately
ph88 2017-02-07 11:22:37
oh ye looks nice
dmwit 2017-02-07 11:22:51
nitrix: This code looks a bit bigger than I expect I can digest in one sitting.
nitrix 2017-02-07 11:23:48
dmwit: I think I was rubber ducking more than anything. Don't waste your time.
nitrix 2017-02-07 11:23:55
I'll eventually figure it out, as always :P
Tuplanolla 2017-02-07 11:24:44
I recently did something similar with Brick, but that thing gives you a `Chan` to send messages through.
dmwit 2017-02-07 11:24:50
nitrix: I'd like to help. But at the moment it's not clear to me what you're trying; what behavior you're exhibiting; and what behavior you're expecting instead.
nitrix 2017-02-07 11:25:33
dmwit: Give me a little time to experiment. I am trying to narrow it down for simplicity sake, and I'll actually have a test case to present if it doesn't lead anywhere.
dmwit 2017-02-07 11:25:41
cool
nitrix 2017-02-07 11:26:24
I realise not many people care about havin their events processed in parallel while the rendering is happening but I do :P
dmwit 2017-02-07 11:27:16
I think it's a perfectly reasonable goal.
nitrix 2017-02-07 11:27:36
And it's not realistic to ask library authors to design their library to be thread safe. That'd just be an overhead.
qmm 2017-02-07 11:27:54
data Foo :: !Foo
qmm 2017-02-07 11:28:11
does the bang represent strict evaluation?
davean 2017-02-07 11:28:27
qmm: yes
nitrix 2017-02-07 11:29:01
qmm: In this case I think it makes no difference.
dmwit 2017-02-07 11:29:02
qmm: Generally ! is about strictness. But that exact syntax doesn't look valid to me; are you sure you copied/pasted right?
nitrix 2017-02-07 11:29:21
qmm: I recall someone saying that the bang pattern makes the constructor strict and you have no constructor there.
davean 2017-02-07 11:29:56
qmm: https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.html#bang-patterns-and-strict-haskell
nitrix 2017-02-07 11:31:05
data Foo = MkFoo !Int; MkFoo's implementation basically becomes MkFoo x = x `seq` ...
qmm 2017-02-07 11:31:07
dmwit: not necessarily sure that it's correct, but i keep seeing bangs in value constructors and i wasn't entirely confident why
qmm 2017-02-07 11:31:22
nitrix: thanks
qmm 2017-02-07 11:31:26
davean: thank you as well
jle` 2017-02-07 11:44:42
qmm: the idea is that when you pattern match on the MkFoo constructor, it also forces evaluation of the :Int field inside
jle` 2017-02-07 11:45:01
when you pattern match on something, ghc has to evaluate it enough to figure out what the constructor is
