Re: [Haskell-cafe] Rebox Package or To Hackage or not to Hackage
Hi John, I don't know if this is useful for you, but these are instances of Cofunctor's comap. For example if we use TypeCompose package we have: rebox f = unFlip . cofmap f . Flip The rest are also Cofunctors. There are a few options. You can either specify instances or use type combinators from category-extras or TypeCompose packages. Basically (a - a - b) is curried composition of diagonal Functor from Bifunctor (,) and Cofunctor (Flip (-) a) etc. It's interesting to know more about usage of the pattern for AST reduction. Vitaliy On Tue, Dec 8, 2009 at 9:37 PM, John Van Enk vane...@gmail.com wrote: Hi List, I've recently had a situation where I used the same pattern quite a bit while reducing and evaluating an AST. I quickly wrapped the operation in a package and stuck it on github. http://github.com/sw17ch/rebox/blob/master/src/Data/Rebox.hs I'm wondering two things: 1) Does any one recognize the pattern I'm using here as something with a different name? 2) Is this worth sticking on Hackage? It's trivial, but we have plenty of trivial concepts on Hackage (and it's not a bad thing). Any feedback would be great. /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
2008/3/17, Adam Langley [EMAIL PROTECTED]: On Mon, Mar 17, 2008 at 2:29 AM, Vitaliy Akimov The important point here is that the recvFrom calls in Network.Socket[1] don't block. Yes, this is the answer. Network.Socket.socket calls System.Posix.Internals.setNonBlockingFD to set socket non-blocking. I'm on Windows, and this function is simply return () for this platform. So that's why it doesn't work on Windows, I think I should find some way to make a socket unblocking after its creation. Thank you. Vitaliy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
So that's why it doesn't work on Windows, I think I should find some way to make a socket unblocking after its creation. Unfortunally this way seems to be wrong. Error codes for winsockets and BSD-sockets are different. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
It's not an issue of error codes. Though error code of WSAEWOULDBLOCK and EAGAIN is different this is not the problem. You've posted a link to preprocessed source code. And there is no implementation of throwErrnoIfMinus1Retry_repeatOnBlock for Windows. This function for Windows treat WSAEWOULDBLOCK as error, and it doesn't have loop for its correct processing. It's not a surprise since the socket isn't supposed to be blocked on windows. Here is source code with setting socket to non-blocking mode [1]. It terminates with error: UdpEcho.exe: recvFrom: failed (Resource temporarily unavailable (WSAEWOULDBLOCK)) [1] http://hpaste.org/6476 Vitaliy. 2008/3/18, Adam Langley [EMAIL PROTECTED]: On Tue, Mar 18, 2008 at 3:41 AM, Vitaliy Akimov [EMAIL PROTECTED] wrote: Unfortunally this way seems to be wrong. Error codes for winsockets and BSD-sockets are different. Hmm, Networking broken on Windows would seem to be a pretty big issue. One of the Windows peeps like to speak up here? AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
Hi Adam, sorry for late answer. Here is my example [1], but yours doesn't work on my PC too. And it's strange it works on yours. According to documentation for Control.Concurrent module [2] every other thread should be blocked. With the -threaded option, only foreign calls with the unsafe attribute will block all other threads. And after changing in the network package FFI declaration for c_recvfrom from unsafe to safe both examples start working. There are two solutions I see now. The first is to copy-paste definitions from the network package to mine with changing unsafe to safe for FFI declaration. The second is to use unblocking sockets. This by the way will help to get rid of hack-like solution of stopping server by closing listening socket, but it will get more effort. [1] http://hpaste.org/6426 [2] http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#4 2008/3/14, Adam Langley [EMAIL PROTECTED]: On Fri, Mar 14, 2008 at 8:51 AM, Vitaliy Akimov [EMAIL PROTECTED] wrote: I assume that you're binding the libc function directly here: I'm using Network.Socket. Sory if it's not clear from my previous posts. Then everything should Just Work(tm). You might need to paste in code in order to figure out why this wouldn't be so. See [1] for an example which works for me. It starts a thread which prints working... once a second and, in another thread, listens for UDP packets on port 4112. I can use `nc -u 127.0.0.1 4112` to get this: working... working... (testing\n,8,127.0.0.1:36179) working... working... (testing two\n,12,127.0.0.1:36179) working... [1] http://hpaste.org/6362 -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] all threads are blocked by recvFrom
Hello, I have a problem with building multithreaded UDP server. If main thread is waiting for new request in recvFrom all other threads are blocked too. I've checked every variant with forkIO,forkOS,-threaded etc, nothing's helped. After reading GHC docs I've understood this is happened becouse foreign function call from recvFrom (network library) is marked to be unsefe, so it's execution blocks every other thread. How can I resolve it? Thank you. Vitaliy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: all threads are blocked by recvFrom
Rebuilding of the network package with changed safety helped but I don't think this is the solution. BTW accept is declared as safe. What is the reason of declaring recvFrom as unsafe? I think this breaks highly required feature. Apparently it's impossible to make concurrent server for non connection based protocols. 2008/3/14, Vitaliy Akimov [EMAIL PROTECTED]: Hello, I have a problem with building multithreaded UDP server. If main thread is waiting for new request in recvFrom all other threads are blocked too. I've checked every variant with forkIO,forkOS,-threaded etc, nothing's helped. After reading GHC docs I've understood this is happened becouse foreign function call from recvFrom (network library) is marked to be unsefe, so it's execution blocks every other thread. How can I resolve it? Thank you. Vitaliy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
I assume that you're binding the libc function directly here: I'm using Network.Socket. Sory if it's not clear from my previous posts. In that case, you need to have the RTS manage sleeping your thread for you. You should make the socket non-blocking and handle the EAGAIN and EWOULDBLOCK cases by calling threadWaitRead[1] to block the current Haskell thread only, until the fd is readable. Note that threadWaitRead is GHC only. If you download the source to network-bytestring[2], you can see a very similar pattern in the code for send and recv in there. Thanks, but I haven't managed to find a way of setting a socket into non blocking mode without using FFI directly (and I haven't found solution in network-bytestring too). How can I make this? The only way I've found is making handle by socketToHandle then reading by hGetBufNonBlocking. But this way seems not suited for non-connection based sockets. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial: Curry-Howard Correspondence
Very clear tutorial indeed. But why isn't propCC shown as Pierce's Law? And Excluded middle is proven on such basis. Vitaliy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PROPOSAL: New efficient Unicode string library.
Hi, thanks for proposal, Why questions connected with converting are considered only? The library i18n should give a number of other services such as normalization, comparison, sorting, etc. Furthermore it's not so easy to keep such library up to date. Why simply do not make a bindings to IBM ICU (http://www-306.ibm.com/software/globalization/icu/index.jsp) library which is up to date unicode implementation? Vitaliy. 2007/9/25, Johan Tibell [EMAIL PROTECTED]: Dear haskell-cafe, I would like to propose a new, ByteString like, Unicode string library which can be used where both efficiency (currently offered by ByteString) and i18n support (currently offered by vanilla Strings) are needed. I wrote a skeleton draft today but I'm a bit tired so I didn't get all the details. Nevertheless I think it fleshed out enough for some initial feedback. If I can get the important parts nailed down before Hackathon I could hack on it there. Apologies for not getting everything we discussed on #haskell down in the first draft. It'll get in there eventually. Bring out your Unicode kung-fu! http://haskell.org/haskellwiki/UnicodeByteString Cheers, Johan Tibell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad for Set?
If you also read the rest of that thread, you'll see that with a recent GHC HEAD, you should be able to avoid the need for the Teq witness. http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps here is solution which doesn't require GADT and HEAD, but it does require changing of monad interface. This trick is used in SYB3. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
