Logs: freenode/#haskell
| 2020-11-21 13:30:03 | → | perohig joins (~user@dsl-212-23-31-113.zen.co.uk) |
| 2020-11-21 13:30:04 | × | perry69420 quits (6ee39737@110.227.151.55) (Ping timeout: 245 seconds) |
| 2020-11-21 13:30:47 | → | jonatanb joins (jonatanb@gateway/vpn/protonvpn/jonatanb) |
| 2020-11-21 13:31:22 | × | _mecairS` quits (~st_ars@110.54.187.248) (Quit: Hi. If i ever be an Angel of Light to guide you, to lead you in every way, will you also think of me at night and day.. https://bit.ly/36blphN) |
| 2020-11-21 13:32:10 | → | Boomerang joins (~Boomerang@xd520f68c.cust.hiper.dk) |
| 2020-11-21 13:32:53 | → | perry69420 joins (6ee39737@110.227.151.55) |
| 2020-11-21 13:32:56 | ← | perohig parts (~user@dsl-212-23-31-113.zen.co.uk) () |
| 2020-11-21 13:34:14 | × | bgamari quits (~bgamari@72.65.101.76) (Ping timeout: 256 seconds) |
| 2020-11-21 13:34:28 | → | cyphase joins (~cyphase@unaffiliated/cyphase) |
| 2020-11-21 13:35:42 | → | bgamari joins (~bgamari@2001:470:e438::1) |
| 2020-11-21 13:37:23 | <jophish> | maralorn: I made a test for HLS (in vim, but doesn't have to be). It works quite reliably now I've worked the kinks out. Do you think that this would make a reasonable addition to the nixos tests in nixpkgs: https://github.com/expipiplus1/dotfiles/blob/f41836bb61d98502236a7ea6522dbc24830af439/tests/vim-diagnostic-list.nix |
| 2020-11-21 13:37:26 | <jophish> | it's quite niche |
| 2020-11-21 13:37:32 | <jophish> | but it would be good to get HLS tested there |
| 2020-11-21 13:37:53 | × | SanchayanM quits (~Sanchayan@223.226.47.98) (Quit: SanchayanM) |
| 2020-11-21 13:39:06 | → | acarrico joins (~acarrico@dhcp-68-142-39-249.greenmountainaccess.net) |
| 2020-11-21 13:39:31 | → | gproto023 joins (~gproto23@unaffiliated/gproto23) |
| 2020-11-21 13:41:45 | → | cosimone joins (~cosimone@2001:b07:ae5:db26:1fb3:ef3f:ece2:c6f8) |
| 2020-11-21 13:42:30 | × | gproto0023 quits (~gproto23@unaffiliated/gproto23) (Ping timeout: 272 seconds) |
| 2020-11-21 13:50:01 | → | jedws joins (~jedws@101.184.150.93) |
| 2020-11-21 13:50:51 | → | wygulmage joins (d4662d5d@212.102.45.93) |
| 2020-11-21 13:51:38 | <wygulmage> | Question about Async: When would I want to use `cancel` rather than `uninterruptibleCancel`? |
| 2020-11-21 13:52:57 | <merijn> | "It Depends" |
| 2020-11-21 13:53:05 | → | sand_dull joins (~theuser@c-73-149-95-105.hsd1.ct.comcast.net) |
| 2020-11-21 13:53:32 | × | robbiet480 quits (~robbiet48@178.162.212.214) (Remote host closed the connection) |
| 2020-11-21 13:54:16 | → | aj2 joins (~aj@193.56.252.12) |
| 2020-11-21 13:54:32 | <wygulmage> | I was trying to think of a use case for `cancel` and I couldn't think of one, but I'm not very good at thinking in terms of concurrency. |
| 2020-11-21 13:55:00 | <merijn> | wygulmage: Well, when waiting for succesful cancellation isn't important |
| 2020-11-21 13:55:35 | <merijn> | wygulmage: The cancellation always happens (since async exceptions are blocked during "throwTo") |
| 2020-11-21 13:56:03 | <wygulmage> | Doesn't `cancel` also wait? |
| 2020-11-21 13:56:54 | <merijn> | wygulmage: cancel waits without exceptions masked, so with cancel the final "waitCatch" (which confirms the termination of the cancelled thread) can itself be interrupted by a cancel of the thread |
| 2020-11-21 13:57:09 | <merijn> | Suppose thread A spawns async B, which spawn async C |
| 2020-11-21 13:57:14 | <merijn> | B cancels C |
| 2020-11-21 13:57:29 | <merijn> | "cancel" waits to receive the exception C got (via waitCatch) |
| 2020-11-21 13:57:30 | hackage | heap-console 0.1.0.1 - interactively inspect Haskell values at runtime https://hackage.haskell.org/package/heap-console-0.1.0.1 (TheMatten) |
| 2020-11-21 13:57:51 | <merijn> | wygulmage: The difference between cancel and uninterruptibleCancel is that the latter masks async exceptions during the wait |
| 2020-11-21 13:58:14 | <merijn> | so with uninterruptibleCancel, A can't cancel B while B waits for the final exception from C |
| 2020-11-21 13:58:30 | <wygulmage> | Oh, I see. That makes sense. So if you want to immediately kill the thread waiting for the other to cancel, you you plain `cancel`. Thanks! |
| 2020-11-21 13:58:32 | <merijn> | With cancel, A can cancel B while before it receives the final exception of C |
| 2020-11-21 13:59:17 | <merijn> | wygulmage: The reason for uninterruptibleCancel might be if you care about races with cancellation of C |
| 2020-11-21 13:59:22 | × | knupfer quits (~Thunderbi@200116b82ce1e10080928bee7ad1b338.dip.versatel-1u1.de) (Ping timeout: 260 seconds) |
| 2020-11-21 13:59:33 | <merijn> | i.e. imagine I cancel C, but C gets killed by another exception before it receives the cancel |
| 2020-11-21 13:59:51 | <merijn> | If it's important that I check that final exception, then you need uninterruptibleCancel to guarantee you will see it |
| 2020-11-21 14:00:00 | <merijn> | If you just need C dead and don't care, cancel should be fine |
| 2020-11-21 14:00:11 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-11-21 14:02:39 | <wygulmage> | Thanks, merijn; that's much more straightforward than I expected. |
| 2020-11-21 14:04:54 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2020-11-21 14:05:09 | <merijn> | wygulmage: Basically, there's two levels of masking interrupts. "mask" which blocks async exceptions but unblocks them while blocking on (say) MVars, etc. (to help make it easier to avoid deadlocks) |
| 2020-11-21 14:05:34 | <merijn> | And then there's uninterruptibleMask which will blocks them, even when the code blocks on stuff like MVars |
| 2020-11-21 14:08:05 | <wygulmage> | Right. I got the use of 'uninterruptibleMask' for cleanup/finalizers, but I wasn't thinking of the return from the child thread in those terms. |
| 2020-11-21 14:08:05 | × | carlomagno1 quits (~cararell@148.87.23.6) (Remote host closed the connection) |
| 2020-11-21 14:09:42 | → | machinedgod joins (~machinedg@24.105.81.50) |
| 2020-11-21 14:12:01 | → | HugoDan joins (~semba@a109-49-47-155.cpe.netcabo.pt) |
| 2020-11-21 14:12:47 | ← | HugoDan parts (~semba@a109-49-47-155.cpe.netcabo.pt) () |
| 2020-11-21 14:13:56 | <merijn> | iirc, async just has an outer handler that writes any exceptions to a TVar/MVar that the parent thread can access |
| 2020-11-21 14:14:16 | <Uniaika> | I should use 'ki' one day |
| 2020-11-21 14:15:18 | <Feuermagier> | how can i check if number is contained at most once in a list? |
| 2020-11-21 14:15:43 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2020-11-21 14:15:54 | × | wygulmage quits (d4662d5d@212.102.45.93) (Ping timeout: 245 seconds) |
| 2020-11-21 14:16:43 | <merijn> | Turn it into a map with numbers as keys and counts as values? |
| 2020-11-21 14:16:49 | <merijn> | :t M.fromListWith |
| 2020-11-21 14:16:50 | <lambdabot> | Ord k => (a -> a -> a) -> [(k, a)] -> M.Map k a |
| 2020-11-21 14:17:32 | <merijn> | > M.fromListWith (+) . map (,1) $ "Hello World!" |
| 2020-11-21 14:17:34 | <lambdabot> | fromList [(' ',1),('!',1),('H',1),('W',1),('d',1),('e',1),('l',3),('o',2),('... |
| 2020-11-21 14:17:38 | <Feuermagier> | merijn, intersting idea! - that should even allow me to check multiple numbers for occurance without additional cost |
| 2020-11-21 14:17:39 | <fendor_> | > ((< 2) . length . filter (== 1)) [1,2,3,4,1] |
| 2020-11-21 14:17:41 | <lambdabot> | False |
| 2020-11-21 14:18:04 | <fendor_> | > (\x -> (< 2) . length . filter (== x)) [1,2,3,4,1] 4 |
| 2020-11-21 14:18:06 | <lambdabot> | error: |
| 2020-11-21 14:18:06 | <lambdabot> | • No instance for (Num [[Integer]]) arising from the literal ‘4’ |
| 2020-11-21 14:18:06 | <lambdabot> | • In the second argument of ‘\ x |
| 2020-11-21 14:18:18 | <fendor_> | > (\x -> (< 2) . length . filter (== x)) 4 [1,2,3,4,1] |
| 2020-11-21 14:18:20 | <lambdabot> | True |
| 2020-11-21 14:18:23 | <merijn> | fendor_: Mine is more robust and cheaper for repeated queries ;) |
| 2020-11-21 14:18:29 | <fendor_> | absolutely |
| 2020-11-21 14:18:40 | fendor_ | is now known as fendor |
| 2020-11-21 14:18:52 | <merijn> | It could've been even easier if we didn't have a bad Monoid instance for Map >.< |
| 2020-11-21 14:19:03 | merijn | hisses at containers |
| 2020-11-21 14:19:30 | <merijn> | No clue which monkey decided on that nonsense |
| 2020-11-21 14:19:36 | × | sand_dull quits (~theuser@c-73-149-95-105.hsd1.ct.comcast.net) (Ping timeout: 240 seconds) |
| 2020-11-21 14:19:51 | <merijn> | But I have no hopes if it ever getting fixed :\ |
| 2020-11-21 14:20:35 | → | sand_dull joins (~theuser@c-73-149-95-105.hsd1.ct.comcast.net) |
| 2020-11-21 14:20:50 | → | polyphem joins (~p0lyph3m@2a02:810d:640:776c:76d7:55f6:f85b:c889) |
| 2020-11-21 14:21:49 | <Feuermagier> | where in my dependencies do i have to add map to use it? (the import says "could not load map; is member f hidden package") |
| 2020-11-21 14:21:50 | × | cosimone quits (~cosimone@2001:b07:ae5:db26:1fb3:ef3f:ece2:c6f8) (Read error: Connection reset by peer) |
| 2020-11-21 14:22:41 | <merijn> | Feuermagier: Add "containers" to build-depends in your cabal file |
| 2020-11-21 14:23:19 | × | larou quits (5eae2591@gateway/web/cgi-irc/kiwiirc.com/ip.94.174.37.145) (Quit: Connection closed) |
| 2020-11-21 14:24:53 | → | sondre joins (~sondre@cm-84.211.56.132.getinternet.no) |
| 2020-11-21 14:25:19 | <Feuermagier> | tgrl wsgi• build-depends: |
| 2020-11-21 14:25:19 | <Feuermagier> | base == 4.* |
| 2020-11-21 14:25:19 | <Feuermagier> | containers |
| 2020-11-21 14:25:22 | → | mputz joins (~Thunderbi@dslb-084-058-211-084.084.058.pools.vodafone-ip.de) |
| 2020-11-21 14:25:36 | <Feuermagier> | like this? build-depends: |
| 2020-11-21 14:25:36 | <Feuermagier> | base == 4.* |
| 2020-11-21 14:25:36 | <Feuermagier> | containers: |
| 2020-11-21 14:25:48 | <merijn> | you need a comma between them, iirc |
| 2020-11-21 14:26:01 | → | SanchayanMaity joins (~Sanchayan@223.226.47.98) |
| 2020-11-21 14:30:29 | × | SanchayanMaity quits (~Sanchayan@223.226.47.98) (Client Quit) |
| 2020-11-21 14:31:10 | × | sondre quits (~sondre@cm-84.211.56.132.getinternet.no) (Quit: sondre) |
| 2020-11-21 14:31:57 | <Feuermagier> | ah, that was it |
| 2020-11-21 14:31:59 | <Feuermagier> | thx |
All times are in UTC.