Logs: liberachat/#haskell
| 2021-06-13 19:45:18 | <davean> | I think of fusion as a way of talking about code optimization by replacement |
| 2021-06-13 19:45:19 | <shapr> | P1RATEZ: are you using ghcup to install the latest version of the compiler and the lsp plugin? |
| 2021-06-13 19:45:31 | × | dunkeln quits (~dunkeln@94.129.65.28) (Ping timeout: 272 seconds) |
| 2021-06-13 19:45:48 | <P1RATEZ> | i don't have it installed at the moment but i could give it a shot |
| 2021-06-13 19:45:56 | <P1RATEZ> | having troubles? |
| 2021-06-13 19:46:16 | <shapr> | P1RATEZ: no, just wanting to help someone who's jumping into the lambda lifestyle again |
| 2021-06-13 19:46:17 | × | teddyc quits (theodorc@cassarossa.samfundet.no) (Quit: WeeChat 2.3) |
| 2021-06-13 19:46:20 | <davean> | maerwald: the problem with fusion is it implicitly runs functions on your code, but thats true of strict *or* lazy |
| 2021-06-13 19:46:22 | <maerwald> | davean: well... "purity" was also defined in terms of evaluation strategy equivalence... so I think defining laziness semantics in terms of fusion could be a reasonable attempt |
| 2021-06-13 19:46:28 | → | teddyc joins (theodorc@cassarossa.samfundet.no) |
| 2021-06-13 19:46:30 | <davean> | maerwald: the fusion issue is entirely independent |
| 2021-06-13 19:46:40 | <maerwald> | not independent |
| 2021-06-13 19:46:48 | <maerwald> | but there are more problems to fusion than laziness |
| 2021-06-13 19:47:34 | <maerwald> | I'm not writing a paper about it :) |
| 2021-06-13 19:47:44 | <shapr> | maerwald, davean : perhaps we can make up "Big L notation" that describes the space usage per number of inputs? |
| 2021-06-13 19:47:52 | <shapr> | L for laziness? :-) |
| 2021-06-13 19:48:31 | <davean> | shapr: so in the worst case you're talking about something the size of computability - but few sane functions will hit that really. |
| 2021-06-13 19:49:10 | <davean> | maerwald: So fusion can cause you to force *less* stuff than the non-fused code, but shouldn't allow you to force more for correctly implimented fusion |
| 2021-06-13 19:49:54 | <maerwald> | My point is that rules for maintaining laziness are similarly obscure as rules for triggering fusion |
| 2021-06-13 19:50:07 | <davean> | But not in terms of bounds |
| 2021-06-13 19:50:34 | × | yoctocell quits (~yoctocell@h87-96-130-155.cust.a3fiber.se) (Quit: C-x C-c, Shutting down OS...) |
| 2021-06-13 19:50:46 | <maerwald> | Most ppl, I'm certain, have no intuition about which of their functions are really properly lazy... and the only time you really develop this intuition is... when you deal with fusion |
| 2021-06-13 19:50:59 | <davean> | I do not deal with fusion and I do |
| 2021-06-13 19:51:08 | <davean> | so you're very much clearly showing some bias I'm unfamiliar with |
| 2021-06-13 19:51:18 | <shapr> | davean: we could run a poll |
| 2021-06-13 19:51:31 | × | Xnuk quits (~xnuk@45.76.202.58) (Quit: ZNC - https://znc.in) |
| 2021-06-13 19:51:42 | <shapr> | or we could put up a quiz where people see the source code and then say which variables are strict or lazy or whatnot. |
| 2021-06-13 19:51:48 | → | Xnuk joins (~xnuk@vultr.xnu.kr) |
| 2021-06-13 19:51:49 | <davean> | mmm |
| 2021-06-13 19:51:52 | <maerwald> | "understanding laziness" is an effort of fixing memory leaks in your haskell code :p |
| 2021-06-13 19:51:56 | → | remedan joins (~remedan@balak.me) |
| 2021-06-13 19:51:59 | <davean> | maerwald: no it isn't |
| 2021-06-13 19:52:06 | <davean> | maerwald: its an effort to extract performance |
| 2021-06-13 19:52:09 | <maerwald> | well, I have very different experience |
| 2021-06-13 19:52:10 | <dmwit> | One thing to keep in mind is that if you are using Haskell professionally, there may well be people on the project who are not as intimately familiar with Haskell as we are. |
| 2021-06-13 19:52:30 | <shapr> | true that |
| 2021-06-13 19:52:41 | <dmwit> | So I agree that there is something to be said for programming in a way that leaves things robust, even if that means you don't use cool language features. |
| 2021-06-13 19:52:42 | <davean> | maerwald: laziness lets us do better than the general performance bounds. |
| 2021-06-13 19:52:55 | <maerwald> | when you've been paying for 64GB ram amazon instances, because you didn't use StrictData in the right places... then you start to have a somewhat different opinion |
| 2021-06-13 19:53:31 | → | kayprish joins (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) |
| 2021-06-13 19:53:31 | <maerwald> | (and that after you hired expensive haskell consultants, who couldn't find it either) |
| 2021-06-13 19:53:38 | <shapr> | I bought a laptop with 128GB ram, so much easier! |
| 2021-06-13 19:53:38 | <davean> | I think the largest Haskell programs I have are ~12GiB and thats because I load the entire dataset into memory of a few million node graph for performance. |
| 2021-06-13 19:53:45 | × | wonko quits (~wjc@62.115.229.50) (Ping timeout: 272 seconds) |
| 2021-06-13 19:54:03 | → | allbery_b joins (~geekosaur@069-135-003-034.biz.spectrum.com) |
| 2021-06-13 19:54:31 | <davean> | and even then about 2GiB of it is a cache |
| 2021-06-13 19:54:36 | → | kayprish_ joins (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) |
| 2021-06-13 19:54:42 | <shapr> | I've still eaten far more than 128gb when I wrote a space leak. It took twenty seconds to eat my ram, and ten seconds to wait for the kill command to stop the problem. |
| 2021-06-13 19:54:45 | × | geekosaur quits (~geekosaur@069-135-003-034.biz.spectrum.com) (Ping timeout: 252 seconds) |
| 2021-06-13 19:54:48 | → | kayprish1 joins (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) |
| 2021-06-13 19:55:07 | allbery_b | is now known as geekosaur |
| 2021-06-13 19:55:26 | <maerwald> | however... I can't say if that platform would have been truly better with "strict by default"... but I can say that debugging laziness issues is very non-trivial in haskell, and I'm wondering if the Idris approach would have helped |
| 2021-06-13 19:55:30 | <maerwald> | I'm not sure |
| 2021-06-13 19:55:54 | <davean> | maerwald: your experience doesn't at all match mine |
| 2021-06-13 19:56:43 | <davean> | But your perspective and take on the problem doesn't either |
| 2021-06-13 19:56:50 | <davean> | we clearly come at this from very different directions |
| 2021-06-13 19:57:24 | <maerwald> | davean: https://github.com/yesodweb/wai/pull/752#issuecomment-501531386 |
| 2021-06-13 19:57:28 | <maerwald> | I agree with Kazu |
| 2021-06-13 19:57:47 | <shapr> | I really enjoy laziness for many solutions |
| 2021-06-13 19:57:55 | <shapr> | I just wish it were somehow more compositional |
| 2021-06-13 19:57:57 | <davean> | maerwald: yah well, lets talk about warp ... |
| 2021-06-13 19:58:01 | × | kayprish quits (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) (Client Quit) |
| 2021-06-13 19:58:01 | × | kayprish_ quits (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) (Client Quit) |
| 2021-06-13 19:58:01 | × | kayprish1 quits (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) (Client Quit) |
| 2021-06-13 19:58:06 | <davean> | maerwald: that code base is a mess and I had to fork it |
| 2021-06-13 19:58:12 | <maerwald> | :p |
| 2021-06-13 19:58:20 | <davean> | It doesn't even manage exceptions! |
| 2021-06-13 19:58:27 | <davean> | It doesn't work in production IME |
| 2021-06-13 19:58:32 | <maerwald> | davean: guess what... I had to fork `tar`, because it's a broken mess and even after forking doesn't work correctly |
| 2021-06-13 19:58:33 | <davean> | but it didn't take long to fix |
| 2021-06-13 19:58:41 | <maerwald> | part of it being over-use of "lazy patterns" |
| 2021-06-13 19:58:44 | <davean> | maerwald: right, its a mostly-rewrite |
| 2021-06-13 19:58:50 | <davean> | maerwald: yes, that is a problem in tar |
| 2021-06-13 19:59:00 | <maerwald> | while it should use a proper streaming library |
| 2021-06-13 19:59:01 | <davean> | maerwald: thats actually ... yah, tar is a fuckfest |
| 2021-06-13 19:59:08 | <davean> | yes, I have a version thatstarts to |
| 2021-06-13 19:59:10 | <maerwald> | see, we finally agree :D |
| 2021-06-13 19:59:14 | <davean> | this is actually a security bug |
| 2021-06-13 19:59:24 | <davean> | tar uses laziness for a dumb reason |
| 2021-06-13 19:59:27 | <davean> | and they wouldn't fix it |
| 2021-06-13 19:59:30 | <davean> | so now I get to |
| 2021-06-13 19:59:39 | <davean> | its better than maintaining my own warp! |
| 2021-06-13 19:59:44 | <maerwald> | yes... if you have a 200mb file in the tar archive, you'll get that 200mb file loaded into memory |
| 2021-06-13 19:59:50 | <davean> | no, no |
| 2021-06-13 19:59:58 | <davean> | you can use tar in constant space for arbitrary files |
| 2021-06-13 19:59:58 | <maerwald> | yes |
| 2021-06-13 20:00:01 | <davean> | I've done that a lot |
| 2021-06-13 20:00:01 | <maerwald> | no |
| 2021-06-13 20:00:05 | <davean> | No, I have |
| 2021-06-13 20:00:09 | <maerwald> | I don't believe you! |
| 2021-06-13 20:00:14 | <davean> | I've streameed tape through it |
| 2021-06-13 20:00:24 | <maerwald> | (I'm talking about unpack) |
| 2021-06-13 20:00:25 | <davean> | but you can force it to load all the data |
| 2021-06-13 20:00:50 | <davean> | Oh unpack? |
| 2021-06-13 20:00:51 | <maerwald> | https://github.com/haskell/tar/issues/57 |
| 2021-06-13 20:00:55 | <davean> | No you have to use the base combinators |
| 2021-06-13 20:00:56 | <maerwald> | yes, it leaks file size |
| 2021-06-13 20:01:05 | <davean> | Right |
| 2021-06-13 20:01:07 | <davean> | unpack is broken |
| 2021-06-13 20:01:14 | <maerwald> | yeah... I fixed it with streamly |
All times are in UTC.