Logs: freenode/#haskell
| 2021-05-04 12:28:23 | <merijn> | I really don't wanna implement ARP myself using raw sockets :( |
| 2021-05-04 12:28:29 | <edmundnoble> | cub3s_: that article came out after nix-style builds became the default in cabal, it's still current as far as I know |
| 2021-05-04 12:28:53 | × | benkolera quits (uid285671@gateway/web/irccloud.com/x-etixrpfkvxahekhz) (Quit: Connection closed for inactivity) |
| 2021-05-04 12:29:44 | <tdammers> | personally, I think that if you want to get rid of manual diligence being a factor in versioning, then there are two realistic strategies: A) just pin everything down to exact matches (either by vendoring in your dependencies verbatim, or using freeze files, or via content-addressable code), and B) develop a language that has such fine-grained dependency inference that you can resolve dependencies on a |
| 2021-05-04 12:29:46 | <tdammers> | per-identifier basis |
| 2021-05-04 12:30:33 | <maerwald> | what if API doesn't break, but behavior changes? |
| 2021-05-04 12:30:43 | × | nineonine quits (~nineonine@2604:3d08:7783:f200:10b9:8c10:5b66:dc51) (Ping timeout: 276 seconds) |
| 2021-05-04 12:30:49 | <maerwald> | wrt B) |
| 2021-05-04 12:31:04 | <tdammers> | pin it down with types, I guess |
| 2021-05-04 12:31:34 | <maerwald> | I mean the big seller of semver, PVP etc were: you can break behavior without renaming your function |
| 2021-05-04 12:32:07 | × | todda7 quits (~torstein@2a02:587:3724:f30b:d88b:b67e:116b:c170) (Remote host closed the connection) |
| 2021-05-04 12:32:07 | <tdammers> | except that you really are renaming your function |
| 2021-05-04 12:32:15 | <tdammers> | it's just indirect |
| 2021-05-04 12:32:37 | <maerwald> | so we can have versions per identifier? :) |
| 2021-05-04 12:32:41 | <tdammers> | pmuch |
| 2021-05-04 12:33:08 | <maerwald> | so solving will take more time than compiling, I guess |
| 2021-05-04 12:33:16 | <tdammers> | it depends though |
| 2021-05-04 12:33:30 | → | OldMiner joins (~OldMiner@185.169.233.12) |
| 2021-05-04 12:33:35 | <tdammers> | if you combine it with content-addressable identifiers and freezing, then you won't need to do a full solver run very often |
| 2021-05-04 12:33:35 | <yushyin> | cargo does this btw. |
| 2021-05-04 12:34:44 | → | kuribas joins (~user@ptr-25vy0i74839npjhgcue.18120a2.ip6.access.telenet.be) |
| 2021-05-04 12:34:44 | <tdammers> | also: when the behavior of a function changes, then as a consumer of the API, you 1) want to know, and 2) likely want to keep using the old version until you decide that the new version has advantages that are worth changing your code for |
| 2021-05-04 12:35:37 | <tdammers> | in this context, I also think that there is no such thing as a "compatible bugfix". if you don't change the behavior, then it's not a bugfix; but if you do change the behavior, then it's no longer the same thing, and thus not compatible |
| 2021-05-04 12:36:00 | <merijn> | carter: You're not in numerical-haskell! :O |
| 2021-05-04 12:36:24 | <carter> | Watt |
| 2021-05-04 12:36:33 | → | todda7 joins (~torstein@2a02:587:3724:f30b:d88b:b67e:116b:c170) |
| 2021-05-04 12:38:50 | → | royal_screwup213 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-05-04 12:40:55 | → | ddellacosta joins (~ddellacos@86.106.143.239) |
| 2021-05-04 12:41:54 | → | totte joins (~totte@chakra/totte) |
| 2021-05-04 12:41:54 | × | cheater quits (~user@unaffiliated/cheater) (Ping timeout: 260 seconds) |
| 2021-05-04 12:42:37 | × | star_cloud quits (~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com) (Ping timeout: 252 seconds) |
| 2021-05-04 12:42:52 | × | frozenErebus quits (~frozenEre@37.231.244.249) (Ping timeout: 240 seconds) |
| 2021-05-04 12:43:15 | × | todda7 quits (~torstein@2a02:587:3724:f30b:d88b:b67e:116b:c170) (Ping timeout: 260 seconds) |
| 2021-05-04 12:45:12 | × | ddellacosta quits (~ddellacos@86.106.143.239) (Ping timeout: 240 seconds) |
| 2021-05-04 12:45:20 | → | star_cloud joins (~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com) |
| 2021-05-04 12:45:42 | → | ddellacosta joins (~ddellacos@ool-44c73afa.dyn.optonline.net) |
| 2021-05-04 12:46:16 | × | stree quits (~stree@68.36.8.116) (Ping timeout: 260 seconds) |
| 2021-05-04 12:46:26 | → | nicholasbulka joins (~nicholasb@2601:900:4301:da0:4851:1ff9:a46:9389) |
| 2021-05-04 12:49:27 | × | dinciorip quits (~dincio@5.171.9.137) (Quit: WeeChat 3.1) |
| 2021-05-04 12:50:17 | → | geekosaur joins (930099da@rrcs-147-0-153-218.central.biz.rr.com) |
| 2021-05-04 12:53:59 | → | bitmagie joins (~Thunderbi@200116b8061c5600286b98b995fbce0a.dip.versatel-1u1.de) |
| 2021-05-04 12:55:08 | × | star_cloud quits (~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com) (Excess Flood) |
| 2021-05-04 12:55:14 | × | bitmagie quits (~Thunderbi@200116b8061c5600286b98b995fbce0a.dip.versatel-1u1.de) (Client Quit) |
| 2021-05-04 12:56:21 | → | star_cloud joins (~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com) |
| 2021-05-04 12:57:11 | → | cheater joins (~user@unaffiliated/cheater) |
| 2021-05-04 12:58:26 | × | philderbeast quits (~textual@bras-base-vldvpq5901w-grc-06-184-144-244-252.dsl.bell.ca) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-05-04 12:58:38 | → | ddellac__ joins (~ddellacos@86.106.143.18) |
| 2021-05-04 12:58:40 | × | EvilMagix quits (~aVikingTr@2001:8003:340d:d00:b2de:b98:7a93:b0ea) (Ping timeout: 276 seconds) |
| 2021-05-04 12:59:32 | → | stree joins (~stree@68.36.8.116) |
| 2021-05-04 13:00:07 | → | nineonine joins (~nineonine@2604:3d08:7783:f200:10b9:8c10:5b66:dc51) |
| 2021-05-04 13:01:36 | × | nicholasbulka quits (~nicholasb@2601:900:4301:da0:4851:1ff9:a46:9389) (Remote host closed the connection) |
| 2021-05-04 13:01:52 | → | nicholasbulka joins (~nicholasb@2601:900:4301:da0:4851:1ff9:a46:9389) |
| 2021-05-04 13:02:26 | × | kaletaa quits (~kaletaa@188.34.177.83) (Quit: ZNC 1.8.1 - https://znc.in) |
| 2021-05-04 13:02:48 | <edmundnoble> | Are there any semantic gotchas involved in using `par` with side effects? |
| 2021-05-04 13:03:17 | → | kaletaa joins (~kaletaa@188.34.177.83) |
| 2021-05-04 13:03:36 | × | ddellac__ quits (~ddellacos@86.106.143.18) (Ping timeout: 268 seconds) |
| 2021-05-04 13:03:42 | <edmundnoble> | I have heard that `par` creates "sparks" which are essentially items to be put on a work queue and "sparked" (executed on a new Haskell thread) only when a processor is idle, whereas `forkIO` unconditionally forks a new Haskell thread |
| 2021-05-04 13:04:12 | × | kuribas quits (~user@ptr-25vy0i74839npjhgcue.18120a2.ip6.access.telenet.be) (Read error: Connection reset by peer) |
| 2021-05-04 13:04:18 | × | ddellacosta quits (~ddellacos@ool-44c73afa.dyn.optonline.net) (Ping timeout: 260 seconds) |
| 2021-05-04 13:05:09 | <edmundnoble> | In the case that my side effects do not interfere with each other, is there any way to use `par`'s sparks and scheduler to parallelize them? |
| 2021-05-04 13:05:19 | × | nineonine quits (~nineonine@2604:3d08:7783:f200:10b9:8c10:5b66:dc51) (Ping timeout: 250 seconds) |
| 2021-05-04 13:05:46 | → | kuribas joins (~user@ptr-25vy0i74839npjhgcue.18120a2.ip6.access.telenet.be) |
| 2021-05-04 13:05:55 | → | hyperisco joins (~hyperisco@d192-186-117-226.static.comm.cgocable.net) |
| 2021-05-04 13:07:11 | × | p8m_ quits (p8m@gateway/vpn/protonvpn/p8m) (Ping timeout: 240 seconds) |
| 2021-05-04 13:08:11 | <edmundnoble> | I guess there is an obvious way using `unsafeInterleaveIO`, but is it going to do anything crazy like leave resources allocated by those sparks open if the sparks are GC'd |
| 2021-05-04 13:09:01 | → | p8m joins (p8m@gateway/vpn/protonvpn/p8m) |
| 2021-05-04 13:09:17 | <merijn> | edmundnoble: Why do you not wanna create threads? |
| 2021-05-04 13:09:50 | <merijn> | Or: why do you imagine sparks would be better? |
| 2021-05-04 13:10:14 | <edmundnoble> | Sparks are executed only when a processor is idle, and scheduled by the GHC runtime |
| 2021-05-04 13:10:31 | <edmundnoble> | Writing or using another scheduler, and having the two interact, doesn't sound nearly as clean to me |
| 2021-05-04 13:11:06 | <edmundnoble> | All I am interested in is knowledge of the safety of using `par` with side effects |
| 2021-05-04 13:11:18 | <merijn> | why would you need to write another scheduler? |
| 2021-05-04 13:11:37 | → | v01d4lph4 joins (~v01d4lph4@182.68.187.197) |
| 2021-05-04 13:11:38 | <edmundnoble> | Because I want my computations to be scheduled, rather than all run concurrently |
| 2021-05-04 13:11:57 | × | Pickchea quits (~private@unaffiliated/pickchea) (Ping timeout: 260 seconds) |
| 2021-05-04 13:11:57 | <edmundnoble> | Similar to the thing async-pool does |
| 2021-05-04 13:11:59 | <merijn> | par assumes you don't do side-effects, so if you do, well, sucks to be you, then |
| 2021-05-04 13:12:15 | <merijn> | Pretty sure async-pool just uses forkIO |
| 2021-05-04 13:12:18 | <edmundnoble> | Okay, but what are the actual semantic issues |
| 2021-05-04 13:12:21 | <edmundnoble> | Yes, exactly |
| 2021-05-04 13:12:23 | <edmundnoble> | That is what I'm asking about |
| 2021-05-04 13:12:38 | <edmundnoble> | How can I do this in a way which is program-global, using the scheduler that sparks use |
| 2021-05-04 13:12:50 | <edmundnoble> | Rather than delimiting these work groups in which the concurrency is limited |
| 2021-05-04 13:12:51 | <merijn> | There's a whole lotta unstated context here |
| 2021-05-04 13:13:06 | <edmundnoble> | I would just like an answer to my question |
| 2021-05-04 13:13:32 | <edmundnoble> | What kind of craziness can I expect if I should spark a computation in IO? |
| 2021-05-04 13:14:00 | <merijn> | any arbitrary interleaving |
| 2021-05-04 13:15:11 | <merijn> | If you sneak IO into sparks, then you get the same craziness as sneaking IO into any context where things are expected to be pure. That is, arbitrary unpredictable interleaving and breaking purity |
| 2021-05-04 13:15:21 | <edmundnoble> | Arbitrary unpredictable interleaving makes sense to me |
| 2021-05-04 13:15:31 | <edmundnoble> | Breaking purity? |
| 2021-05-04 13:15:56 | <edmundnoble> | Let's say I have encapsulated this into a function `sched :: IO a -> IO (IO a)` |
| 2021-05-04 13:16:22 | × | v01d4lph4 quits (~v01d4lph4@182.68.187.197) (Ping timeout: 252 seconds) |
| 2021-05-04 13:16:27 | <edmundnoble> | The real scary shit I'm thinking of by analogy here is what happens when you `unsafePerformIO` inside of `STM` |
| 2021-05-04 13:16:40 | <edmundnoble> | Because no exception handlers are run |
| 2021-05-04 13:16:42 | <merijn> | I just don't see how "par" is remotely relevant when you already have IO anyway |
| 2021-05-04 13:17:08 | <edmundnoble> | I already told you, I want to use the spark scheduler. I don't want to limit concurrency by hand when there is a scheduler already there and capable of doing it for me |
| 2021-05-04 13:17:24 | <merijn> | edmundnoble: How is that different from threads? |
| 2021-05-04 13:18:05 | <hyperisco> | if I just want to parse cli options (not also have a dispatch framework) what can I use? |
| 2021-05-04 13:18:10 | <tdammers> | Possibly relevant and not entirely obvious: a Haskell thread is not an OS thread (a.k.a. "capability"); spawning a Haskell thread is MUCH cheaper than spawning an OS thread with, say pthread |
| 2021-05-04 13:18:15 | <carbolymer> | Can I trigger GC from outside of Haskell process? |
All times are in UTC.