Re: [Haskell-cafe] Is withAsync absolutely safe?
* Bertram Felgenhauer bertram.felgenha...@googlemail.com [2013-07-28 18:11:54+0200] Roman Cheplyaka wrote: Can withAsync guarantee that its child will be terminated if the thread executing withAsync gets an exception? To remind, here's an implementation of withAsync: withAsyncUsing :: (IO () - IO ThreadId) - IO a - (Async a - IO b) - IO b -- The bracket version works, but is slow. We can do better by -- hand-coding it: withAsyncUsing doFork = \action inner - do var - newEmptyTMVarIO mask $ \restore - do t - doFork $ try (restore action) = atomically . putTMVar var let a = Async t (readTMVar var) r - restore (inner a) `catchAll` \e - do cancel a; throwIO e cancel a return r I am interested in the case when an exception arrives which transfers control to 'cancel', and then another exception arrives to the same thread. Even though 'catchAll' (which is a type-restricted synonym for catch) masks the exception handler, 'throwTo' inside 'cancel' is interruptible (as stated by the documentation). Will this scenario lead to a thread leakage? Yes. I guess that 'cancel' should use 'uninterruptibleMask_', but it's a hard call to make (if an async action becomes unresponsive, do we want to risk not being able to deliver any exceptions to the controlling thread just because it wants to terminate the async action?) Fair point. What if we fork a new thread, shield it from exceptions using uninterruptibleMask_, and let it to kill every other thread (however long that may take)? It will change the semantics a bit (the cleanup will be asynchronous), but I'm not sure if it can be a problem. A hybrid (but complicated) approach should also be possible. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] using network+conduit+tls for a client application?
Dear Haskellers, I wanted to write a small TLS application (connecting to IMAP over TLS) and it seemed natural to use conduit for that. I found the network-conduit-tls package, but then I realized it's meant only for server applications. Is there something similar for client applications? Thank you, Petr Pudlak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using network+conduit+tls for a client application?
there's a similar one for client http://hackage.haskell.org/package/http-conduit-browser/ 2013/7/29 Petr Pudlák petr@gmail.com Dear Haskellers, I wanted to write a small TLS application (connecting to IMAP over TLS) and it seemed natural to use conduit for that. I found the network-conduit-tls package, but then I realized it's meant only for server applications. Is there something similar for client applications? Thank you, Petr Pudlak __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] using network+conduit+tls for a client application?
I've actually been intending to add the client side code to that package, but I simply haven't gotten around to it yet. It's actually not that complicated, but it does require some thought on the right interface for things like approving/rejecting server side certificates. If you open up an issue on Github for this, I'd be happy to continue the conversation there and we can try to get out a new version of the library. (I just don't want to spam the Cafe with an exploratory design discussion.) On Mon, Jul 29, 2013 at 11:08 AM, Petr Pudlák petr@gmail.com wrote: Dear Haskellers, I wanted to write a small TLS application (connecting to IMAP over TLS) and it seemed natural to use conduit for that. I found the network-conduit-tls package, but then I realized it's meant only for server applications. Is there something similar for client applications? Thank you, Petr Pudlak __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] using network+conduit+tls for a client application?
On 07/29/2013 09:08 AM, Petr Pudlák wrote: Dear Haskellers, I wanted to write a small TLS application (connecting to IMAP over TLS) and it seemed natural to use conduit for that. I found the network-conduit-tls package, but then I realized it's meant only for server applications. Is there something similar for client applications? Hi Petr, There's 2 packages that provide easy client TLS side API. I don't think it would be difficult to provide a conduit wrapper for both: http://hackage.haskell.org/package/network-simple-tls http://hackage.haskell.org/package/connection connection is a bit more low level for easily integration into something higher level. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using network+conduit+tls for a client application?
On 07/29/2013 10:43 AM, Michael Snoyman wrote: I've actually been intending to add the client side code to that package, but I simply haven't gotten around to it yet. It's actually not that complicated, but it does require some thought on the right interface for things like approving/rejecting server side certificates. If you open up an issue on Github for this, I'd be happy to continue the conversation there and we can try to get out a new version of the library. (I just don't want to spam the Cafe with an exploratory design discussion.) Michael, I've been meaning to add TOFU (Trust on first use) and certificate exceptions support (e.g. self signed) inside the TLS stack directly, maybe we should talk about this. Few design stuff that blocked me so far, one of them is how to store those things. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANN] thirdake-0.1 the Makefile-like DSL
Hi, cafe. Neil Mitchell mentioned more than ten build systems written in Haskell in his paper [1]. The list includes shake (of cause) Abba, Coadjuke, hake, hmk, and even two cakes. I'm glad to announce the thirdcake - a DSL for make language. Thirdcake allows user to produce clean and safe (I hope) Makefiles for the good old GNU make. The package is in it's early stages and is not on Hackage yet. Consider visiting https://github.com/grwlf/cake3 or just git clone https://github.com/grwlf/cake3 ./Example/Foo contains working toy-project demonstrating the approach. Regards, Sergey [1] - http://community.haskell.org/~ndm/downloads/paper-shake_before_building-10_sep_2012.pdf PS My English is still buggy, feel free to patch the grammar as well as the rest ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rank N Kinds
Hi, On Fri, Jul 26, 2013 at 10:42 PM, Wvv vite...@rambler.ru wrote: First useful use is in Typeable. In GHC 7.8 class Typeable (a::k) where ... == class Typeable (a ::**) where ... But we can't write data Foo (a::k)-(a::k)-* ... deriving Typeable Why not? This works fine in 7.7, as far as I know. Cheers, Pedro ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Getting the 'ThreadId' of the calling thread
(I'm trying to update a package that was written with GHC 6.10.4 in mind.) I feel that a 'myThreadId' action, which is defined in this module [1], is useless, but I'm not sure. I think it will always return the Map.find: element not in the map exception because a 'threadMap' contains an empty 'ThreadMap'. Is it right, or am I missing something? [1] https://gitweb.torproject.org/tordnsel.git/blob/HEAD:/src/TorDNSEL/Control/Concurrent/Link/Internals.hs pgpDV3Pyy5Laq.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CmdArgs non-flag arguments with newtypes
On 07/23/2013 11:48 PM, wren ng thornton wrote: On 7/23/13 9:01 PM, Michael Orlitzky wrote: Obviously not what I want! Has anyone else run into this? Figured out a workaround? I haven't run into this specific problem, but I do have a sort of workaround. Whenever dealing with CmdArgs (or any similar system) I typically define *two* record types. The first one just gets the raw input from CmdArgs; no more, no less. Thus, for your issue, this record would use String. For other issues mentioned recently about optionality, this record would use Maybe. The second one is the one actually used by the program as the configuration object. This one is generated from the first by performing various sanity checks, filling in defaults, converting types from their CmdArgs version to the version I actually want, etc. IME, regardless of language, trying to conflate these notions of an external-facing parser-state and an internal-facing configuration-record just causes problems and accidental complexity. It's best to keep them separate IMO. It's not the internal configuration and command-line arguments that I wanted to share, but rather the config /file/ and command-line arguments. Those two are then mashed together into the real configuration data structure at run time. The reason for the newtype is for the config file parsing -- without the newtype, I'm forced to create orphan instances like some kind of animal =) In any case, this turned out to be a real bug and not the usual user error. Neil was nice enough to fix it, and it looks like it already hit hackage, so I'm gonna go give it a shot! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskell.org down?
Dear list, I am not sure if this is the right place to post this, but I just went to haskell.org and got a Sorry! This site is experiencing technical difficulties. error message. cheers Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell.org down?
On 29/07/13 18:39, Paul Koerbitz wrote: Dear list, I am not sure if this is the right place to post this, but I just went to haskell.org and got a Sorry! This site is experiencing technical difficulties. error message. cheers Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Yep, it's down. Sit tight. I recommend using Google cached versions of the pages. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell.org down?
On Mon, Jul 29, 2013 at 7:45 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: Sit tight. I recommend using Google cached versions of the pages. Thanks. I hope this didn't come of as complaint. I am thankful for the work that goes into maintaining the site. Cheers Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
