ertes 2017-03-04 08:45:18
xubunto: where functors allow you to map over the (let's call it) point type of a single value, applicative functors let you combine two values into a single one while mapping over their point types
jle` 2017-03-04 08:45:33
gotta look into hs-boot files then
ertes 2017-03-04 08:45:58
fmap :: (a -> b) -> f a -> f b
ertes 2017-03-04 08:45:58
(<*>) :: f (a -> b) -> f a -> f b
ertes 2017-03-04 08:46:02
xubunto: ^
xubunto 2017-03-04 08:46:21
yea that f is confusing
ertes 2017-03-04 08:46:34
xubunto: look at a particular instance: Maybe
ertes 2017-03-04 08:48:12
xubunto: look also at [] and IO
ertes 2017-03-04 08:48:27
there is not only a list of values, but also a list of mapping functions
ertes 2017-03-04 08:48:41
[] does something along the lines of cartesian product
ertes 2017-03-04 08:49:01
IO: there is not only a program for the value, but also a program for the mapping function for the value
xubunto 2017-03-04 08:50:24
ertes: i found lyah article on it so reading through it
dbohdan 2017-03-04 08:58:12
Hey, everyone!
dbohdan 2017-03-04 08:58:29
I've run into an issue with a socket Handle that only manifests on Windows.
dbohdan 2017-03-04 08:59:13
When I do hReady on a socket Handle my program terminates with the message:
dbohdan 2017-03-04 08:59:16
>fdReady: fd is too big
dbohdan 2017-03-04 08:59:22
>This application has requested the Runtime to terminate it in an unusual way.
dbohdan 2017-03-04 08:59:27
>Please contact the application's support team for more information.
dbohdan 2017-03-04 09:01:00
The code to reproduce the issue + log: http://lpaste.net/917655724551569408
dbohdan 2017-03-04 09:01:29
Does anyone here know what this is?
dbohdan 2017-03-04 09:02:02
The example (and the larger socket program from which it derives) works normally on Linux and FreeBSD.
geekosaur 2017-03-04 09:02:34
dbohdan, that means the ghc runtime is using select() with a (virtual, for Windows) file descriptor number that exceeds FD_SETSIZE
dbohdan 2017-03-04 09:03:16
I would the underlying C code that prints the message, but I'm not sure what it means.
geekosaur 2017-03-04 09:03:27
(well, slightly more complex than that)
dbohdan 2017-03-04 09:03:35
*found
dbohdan 2017-03-04 09:03:47
Should I be using hReady differently?
dbohdan 2017-03-04 09:04:02
(on Windows)
geekosaur 2017-03-04 09:04:27
I don't think so. but I also didn't think the ghc runtime used select(), precisely because of issues like this... but winsock is seriously weird and select() might be the only API available
geekosaur 2017-03-04 09:04:54
and in that case you may need to rethink things, because the error translates to "winsock can;t cope with the number of sockets you have open"
geekosaur 2017-03-04 09:05:27
oh, hm. you probably don;t want hReady there anyway
geekosaur 2017-03-04 09:05:42
it doesn't do what you think
geekosaur 2017-03-04 09:05:58
why did you use it?
geekosaur 2017-03-04 09:06:54
(and given how winsock works, I would not want to bet on things actually being set up fully enough for it to work there)
dbohdan 2017-03-04 09:07:13
Originally I was writing a function that pipes data from one handle to another.
dbohdan 2017-03-04 09:07:27
I'll paste it.
dbohdan 2017-03-04 09:08:43
It's for a little program that I like to write in every new language I learn.
dbohdan 2017-03-04 09:08:47
http://lpaste.net/2334901538167717888
geekosaur 2017-03-04 09:10:38
mm. at this point you probably need to talk to someone who knows what the network library is doing on Windows
dbohdan 2017-03-04 09:11:01
I use `forkIO $ relay a b` and `forkIO $ relay b a`. The hReady check is to handle the other green thread closing the socket underneath you.
geekosaur 2017-03-04 09:11:12
last time I looked at the details, it still required you to wrap stuff in withSocketsDo (this is unneessary in current versions)
geekosaur 2017-03-04 09:12:41
yes, the problem is that something may be deferring actually creating the full socket <-> fd hack that winsock uses (socketToHandle doesn't do that part, Handle-s for sockets on Windows are not fd based)
dbohdan 2017-03-04 09:14:11
Could I force the socket creation?
geekosaur 2017-03-04 09:15:00
... that's kinda the wrong question. the socket exists
geekosaur 2017-03-04 09:15:09
Windows sockets *are not file descriptors*
geekosaur 2017-03-04 09:16:04
what doesn;t necessarily exist yet is an evil hack somewhere in the depths of winsock that creates a fake fd so you can use normal I/O functions and Windows CRT will detect it and use the appropriate winsock functions instead
geekosaur 2017-03-04 09:16:18
and I don;t know the guts of the network library on Windows well enough to know what controls that part
dbohdan 2017-03-04 09:17:32
I guess it's time to learn Winsock properly.
geekosaur 2017-03-04 09:17:40
it's weird and ghc's runtime for some reason tries to avoid conflating sockets and their fake file descriptors as much as possible even though most socket APIs require you to use the fd interface :/
geekosaur 2017-03-04 09:18:15
(so, some of this may be on ghc's runtime. Handle is moderately evil when it comes to winsock)
dbohdan 2017-03-04 09:19:29
Is there a list of known Windows gotchas? The docs for Network.Socket have some notes on Windows but not about this.
geekosaur 2017-03-04 09:19:43
not that I know of
geekosaur 2017-03-04 09:20:33
ghc generally treats windows as a second class citizen :( (despite having been funded by microsoft research!)
Tuplanolla 2017-03-04 09:21:56
If the funds aren't working, you aren't using enough.
thoughtpolice 2017-03-04 09:22:12
Well, this particular problem is tricky because the way Windows async I/O works is really, fundamentally different from Linux/BSD (honestly, I like Windows' approach more, tbh). There have been attempts to fix the feature parity problems, and it fixed certain issues like asynchronous interrupts and FD limits. Making it all scalable is still even more
thoughtpolice 2017-03-04 09:22:12
difficult.
geekosaur 2017-03-04 09:22:12
also I'm not 100% on that explanation of what's going wrong here. I can see it happening that way but I cn also see other things (that would imply ghc's runtime is just broken for some reason. what ghc version?)
geekosaur 2017-03-04 09:22:30
yes, windows async I/O is much saner
geekosaur 2017-03-04 09:22:47
but this particular problem *is* an fd limit
thoughtpolice 2017-03-04 09:22:53
(IIRC, it probably requires scheduler integration to actually be fast, otherwise you die from the context switching).
thoughtpolice 2017-03-04 09:23:27
Right, I'm just saying the reason it uses select() (and thus why the limit exists at all) is partially a design thing, to be figured out
thoughtpolice 2017-03-04 09:23:56
Well, mostly the performance part. I think Joey's port of the I/O manager to Windows actually did fix a lot of the egregious feature-parity problems, but it wasn't very fast. That's probably OK.
thoughtpolice 2017-03-04 09:24:11
e.g. things like socket functions not being interruptible on Windows via async exceptions
thoughtpolice 2017-03-04 09:24:26
Which means things like 'timeout' on a forkIO'd thread waiting on a foreign call can work, etc.
thoughtpolice 2017-03-04 09:25:09
The scheduler thing is kind of shitty if you want to get the performance back, though. It's conceptually nice having the I/O manager almost entirely separated from the runtime, and written in Haskell, I think. It's a challenge for sure.
geekosaur 2017-03-04 09:25:53
btw if anyone knows a Windows programmer with a fair amount of internals knowlege who is willing to learn hacking on a haskell compiler, ghc needs them badly
geekosaur 2017-03-04 09:26:04
there's *one* person who actually groks windows
geekosaur 2017-03-04 09:27:02
(that person would not be me. I know a little but get lost quickly when it starts getting into details)
dbohdan 2017-03-04 09:27:42
geekosaur: Maybe not making Haskell's Windows support better is part of Microsoft's F# strategy? (j/k, F# fans tell me MS doesn't have one.) Still, it seems like Haskell on Windows works way better than it used to even 5-7 years ago, if you go by the blog posts.
dbohdan 2017-03-04 09:28:24
stack is very consistent across different platforms.
thoughtpolice 2017-03-04 09:29:00
GHC-on-Windows improvement in the past few years, IMO, is largely attributable to Tamar more than anyone.
thoughtpolice 2017-03-04 09:29:47
It's not just obvious things like async I/O parity... hundreds of bugs, toolchain issues, minor wrinkles. Many of those are collectively, together, far more than the sum of their parts, so to speak.
geekosaur 2017-03-04 09:30:17
dbohdan, they were funding it for OS hardening / security research. they've moved that project on to other things at this point though
geekosaur 2017-03-04 09:30:49
and yes, Tamar's done a lot of good work to fix up what used to be a much more terrible Windows story
dbohdan 2017-03-04 09:31:04
Would you say that Haskell is or isn't production ready on Windows?
dbohdan 2017-03-04 09:31:14
(For network-y applications.)
dbohdan 2017-03-04 09:31:26
Command line tools seem to works great.
geekosaur 2017-03-04 09:31:37
there are people who use it. most of them have figured out the pain points, but I don;t know of any writeups
thoughtpolice 2017-03-04 09:32:05
Depends. Are you writing a server that gets called twice a day to do reporting? That's easy. Do you want 500,000 concurrent connections? That's... not going to be easy I'm afraid.
geekosaur 2017-03-04 09:32:22
but, I'm mostly a unix person, so.
dbohdan 2017-03-04 09:32:36
geekosaur: Me too...
dbohdan 2017-03-04 09:33:16
thoughtpolice: Closer to the former than the latter, I guess.
xubunto 2017-03-04 09:36:01
ertes: fun thing those applicative functors
dbohdan 2017-03-04 09:37:12
All right, you've given me some tips (thanks!) and I'll try to investigate the problem some more, maybe with a debugger. I'll get back to you if I find anything interesting.
Tuplanolla 2017-03-04 09:38:02
Threads seem to install their own exception handlers that print out the exceptions when they arrive and exit. Is there a way to completely replace this mechanism?
Zemyla 2017-03-04 09:39:37
Bit janitoring is just as annoying with Haskell as it is with any other language, it seems.
xubunto 2017-03-04 09:39:48
so what is the symbol <* for?
Tuplanolla 2017-03-04 09:40:18
It's `<*>`, but ignores the result on the right, xubunto.
Rembane 2017-03-04 09:40:19
xubunto: It's like >> but in the other direction and or applicative functors.
Rembane 2017-03-04 09:40:27
+f
Zemyla 2017-03-04 09:40:28
xubunto: a <* b = const <$> a <*> b.
Zemyla 2017-03-04 09:40:42
Except potentially more optimized.
Tuplanolla 2017-03-04 09:41:27
It comes up often with parsers etc.
Theophane 2017-03-04 09:41:48
hi folks!
geekosaur 2017-03-04 09:41:54
Tuplanolla, fafik it's just a catch (\(e :: SomeException) -> ...) wrapped around the whole thing. what are you trying to do?
Tuplanolla 2017-03-04 09:42:06
Just exploring, geekosaur.
Theophane 2017-03-04 09:42:49
I'm trying to create a shell application (a REPL, basically), and I would need to hold the network socket as a global state, and I have a few questions about it:
Theophane 2017-03-04 09:43:03
Is it the good way to do it?
Theophane 2017-03-04 09:43:26
and should I investigate about the State monad?
geekosaur 2017-03-04 09:43:43
hm, actually that cant be right. I think they actually don;t trap excedptions at all, and they propagate up to top level and abort the program
Zemyla 2017-03-04 09:43:44
Theophane: You can probably get away with the ReaderT monad.
Theophane 2017-03-04 09:44:02
okay cool, thanks Zemyla :)
geekosaur 2017-03-04 09:44:19
and you will need to understand how exceptions work if you want to change this, although the wrapper I suggested is a good start
Zemyla 2017-03-04 09:44:20
If you need to change the socket, use the ReaderT monad holding an MVar with the socket in it, so you always have the most updated state of the socket.
geekosaur 2017-03-04 09:44:30
*** but remember that Haskell is lazy ***
geekosaur 2017-03-04 09:45:07
threads can and will produce unevaluated thunks that get evaluated sometime afterward and throw then, and no exception handler in the thread will help you
