| 2024-11-12 00:03:26 +0100 | califax | (~califax@user/califx) (Ping timeout: 260 seconds) |
| 2024-11-12 00:04:05 +0100 | califax | (~califax@user/califx) califx |
| 2024-11-12 00:05:11 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 260 seconds) |
| 2024-11-12 00:05:15 +0100 | biberu | (~biberu@user/biberu) (Ping timeout: 246 seconds) |
| 2024-11-12 00:05:42 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2024-11-12 00:08:51 +0100 | falafel | (~falafel@2600:1700:99f4:2050:c99f:7c1:9343:9cff) falafel |
| 2024-11-12 00:19:33 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-11-12 00:24:18 +0100 | fp | (~Thunderbi@87-92-78-48.bb.dnainternet.fi) fp |
| 2024-11-12 00:25:54 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f73010f78d8062037d2.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2024-11-12 00:30:26 +0100 | <fp> | Hey I'm trying to parse numbers with Parsec, and I'm a bit stuck (this is for the 48h scheme tutorial). I'm trying to parse numbers of various radix and I need to avoid accepting numbers where the first digits are valid in the radix, but later digits aren't, e.g. #b010001a. The regex for what I want is /#b[01]+\b/, but I'm struggling to work out how to implement the \b. =endBy1 binDigit (choice [removeChar <$> space, removeChar <$> symbol, |
| 2024-11-12 00:31:29 +0100 | <Axman6> | I think your message got cut off, last I see is "<$> symbol," |
| 2024-11-12 00:31:44 +0100 | <fp> | =endBy1 binDigit (choice [removeChar <$> space, removeChar <$> symbol, eof])= is almost what I want (where removeChar :: Char -> ()), but it demands the latter expression be a separator |
| 2024-11-12 00:32:07 +0100 | <fp> | also this removeChar thing is super hacky and feels wrong |
| 2024-11-12 00:32:25 +0100 | <Axman6> | so what is the a in that example string? |
| 2024-11-12 00:32:43 +0100 | <fp> | not =binDigit= |
| 2024-11-12 00:32:47 +0100 | <Axman6> | do you want #b10101foo to be valid, and parse 42 and foo? |
| 2024-11-12 00:32:54 +0100 | <glguy> | fp: are you sure you need to worry about it? Haskell doesn't |
| 2024-11-12 00:33:00 +0100 | <glguy> | > (+) 1x :: Expr |
| 2024-11-12 00:33:01 +0100 | <lambdabot> | 1 + x |
| 2024-11-12 00:33:13 +0100 | <Axman6> | D: |
| 2024-11-12 00:33:37 +0100 | <probie> | You probably want to reject it for a lisp |
| 2024-11-12 00:33:42 +0100 | <fp> | yeah |
| 2024-11-12 00:34:33 +0100 | <probie> | Since something like `1+` or `a+b` are normally valid identifier names |
| 2024-11-12 00:35:02 +0100 | <fp> | And the point here is just to learn haskell, and I think there's probably some knowledge I'm missing that would allow me to reason about this problem better |
| 2024-11-12 00:37:04 +0100 | <glguy> | Maybe you want https://hackage.haskell.org/package/parsec-3.1.17.0/docs/Text-Parsec-Combinator.html#v:notFollowedBy |
| 2024-11-12 00:37:25 +0100 | <c_wraith> | have a separate parser for each radix. Only accept characters that radix uses |
| 2024-11-12 00:37:29 +0100 | <glguy> | Parsec doesn't make it particularly easy to handle these cases, but it's possible |
| 2024-11-12 00:37:53 +0100 | falafel | (~falafel@2600:1700:99f4:2050:c99f:7c1:9343:9cff) (Quit: Leaving) |
| 2024-11-12 00:37:56 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 244 seconds) |
| 2024-11-12 00:38:19 +0100 | falafel | (~falafel@2600:1700:99f4:2050:c99f:7c1:9343:9cff) falafel |
| 2024-11-12 00:38:36 +0100 | <glguy> | Ideally you'd process your input string into lexical tokens first and then use parsec over those instead of characters |
| 2024-11-12 00:38:53 +0100 | <fp> | > have a separate parser for each radix. Only accept characters that radix uses |
| 2024-11-12 00:38:53 +0100 | <fp> | The issue is that if I have #b01234, it will parse #b01 as a valid number, and then it'll parse 1234 as a valid number |
| 2024-11-12 00:38:54 +0100 | <lambdabot> | error: |
| 2024-11-12 00:38:54 +0100 | <lambdabot> | Variable not in scope: |
| 2024-11-12 00:38:54 +0100 | <lambdabot> | have |
| 2024-11-12 00:38:59 +0100 | <glguy> | Parsec is parameterized to work over an arbitrary stream of arbitrary tokens |
| 2024-11-12 00:39:53 +0100 | <fp> | or 234 |
| 2024-11-12 00:40:23 +0100 | <c_wraith> | oh, then yeah. tokenize and parse separately |
| 2024-11-12 00:40:36 +0100 | <glguy> | If you're doing a lisp your tokens might be something like, '(' ')' and sequences of stuff that's delimited by whitespace |
| 2024-11-12 00:42:25 +0100 | <fp> | But right now I'm really just trying to get this to work against single tokens. My test string is '#b0110a', which tokenization won't help |
| 2024-11-12 00:43:02 +0100 | <fp> | Or will it? |
| 2024-11-12 00:43:12 +0100 | <glguy> | it would because you'd get "#b0110a" as a token that you'd try to process and you'd decide it needs to be a binary number literal because of the first two characters |
| 2024-11-12 00:43:14 +0100 | jinsun | (~jinsun@user/jinsun) (Ping timeout: 248 seconds) |
| 2024-11-12 00:43:22 +0100 | <glguy> | and then you'd try to turn it into one and find it had invalid characters |
| 2024-11-12 00:43:24 +0100 | <c_wraith> | you're fundamentally asking about a tokenizing issue |
| 2024-11-12 00:43:48 +0100 | <c_wraith> | You need to identify a sequence of characters as a single token, and then check that the token is valid *as a token* |
| 2024-11-12 00:44:08 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Ping timeout: 244 seconds) |
| 2024-11-12 00:44:17 +0100 | <glguy> | but if you don't want to completely rethink your design maybe spend some time looking at "notFollowedBy" and hack it together |
| 2024-11-12 00:48:24 +0100 | Everything | (~Everythin@46.211.220.37) (Quit: leaving) |
| 2024-11-12 00:48:46 +0100 | <fp> | I guess the question become, if I have it set up with tokens, how do I write the parser so that it checks if the whole token matches instead of just the beginning |
| 2024-11-12 00:49:20 +0100 | <glguy> | if you had it set up with tokens then that's already done |
| 2024-11-12 00:49:28 +0100 | <glguy> | by the thing that turned it into tokens |
| 2024-11-12 00:49:50 +0100 | <fp> | Sure but how did that check the whole string? |
| 2024-11-12 00:50:22 +0100 | <glguy> | you processed the string turning it into tokens until you got to the end of the string |
| 2024-11-12 00:50:44 +0100 | <glguy> | You have to write a program that processes the string using the rules you have in mind; there isn't a shortcut |
| 2024-11-12 00:52:43 +0100 | <glguy> | that wouldn't necessarily use parsec. If you want to do it in parsec I expect you'll have to use notFollowedBy to detect that your token ended on an OK boundary |
| 2024-11-12 00:54:18 +0100 | <glguy> | notFollowedBy or using lookAhead (same idea) to check that you're OK with the boundary that you ended on |
| 2024-11-12 00:54:39 +0100 | <glguy> | There will be some class of characters you don't mind ending on: whitespace, (, ), etc. |
| 2024-11-12 00:57:08 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-11-12 00:57:13 +0100 | <fp> | Ok I think I understand. The difference with tokens is that I'd be working with Parsec String, so errors would naturally occur for the whole token. I'd fall down to a Parsec Char just for the validation, which would bubble up. Does that sound right? |
| 2024-11-12 00:57:40 +0100 | <fp> | *the errors would bubble up |
| 2024-11-12 00:58:12 +0100 | agent314 | (~quassel@static-198-44-129-53.cust.tzulo.com) (Ping timeout: 276 seconds) |
| 2024-11-12 01:04:14 +0100 | fp | (~Thunderbi@87-92-78-48.bb.dnainternet.fi) (Remote host closed the connection) |
| 2024-11-12 01:04:26 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine) |
| 2024-11-12 01:04:46 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2024-11-12 01:08:53 +0100 | <haskellbridge> | <thirdofmay18081814goya> do the fmap definitions in prelude have some for of uniqueness property? |
| 2024-11-12 01:09:00 +0100 | <haskellbridge> | <thirdofmay18081814goya> some form* |
| 2024-11-12 01:10:35 +0100 | <haskellbridge> | <thirdofmay18081814goya> cough rewording |
| 2024-11-12 01:10:45 +0100 | <haskellbridge> | <thirdofmay18081814goya> do the fmap definitions in prelude satisfy some sort of uniqueness property? |
| 2024-11-12 01:13:03 +0100 | falafel | (~falafel@2600:1700:99f4:2050:c99f:7c1:9343:9cff) (Remote host closed the connection) |
| 2024-11-12 01:13:22 +0100 | falafel | (~falafel@2600:1700:99f4:2050:653b:1b0b:44f2:30f1) falafel |
| 2024-11-12 01:19:00 +0100 | falafel | (~falafel@2600:1700:99f4:2050:653b:1b0b:44f2:30f1) (Ping timeout: 276 seconds) |
| 2024-11-12 01:24:39 +0100 | <Leary> | @free fmap :: (a -> b) -> F a -> F b |
| 2024-11-12 01:24:39 +0100 | <lambdabot> | g . h = k . f => $map_F g . fmap h = fmap k . $map_F f |
| 2024-11-12 01:25:07 +0100 | <Leary> | thirdofmay: Parametricity and the first functor law give you uniqueness (and the second functor law). |
| 2024-11-12 01:25:56 +0100 | <haskellbridge> | <thirdofmay18081814goya> hm I'll read up on that, ty!! |
| 2024-11-12 01:32:11 +0100 | <haskellbridge> | <thirdofmay18081814goya> Leary: is there a specific sense in which you're using "parametricity" here? getting overwhelmed by the search results |
| 2024-11-12 01:33:44 +0100 | <Leary> | https://en.wikipedia.org/wiki/Parametricity |
| 2024-11-12 01:34:36 +0100 | xff0x | (~xff0x@2405:6580:b080:900:d852:39eb:7a5e:9b9f) (Ping timeout: 276 seconds) |
| 2024-11-12 01:34:37 +0100 | <haskellbridge> | <thirdofmay18081814goya> fantastic ty |
| 2024-11-12 01:52:30 +0100 | housemate | (~housemate@146.70.66.228) (Quit: "I saw it in a tiktok video and thought that it was the most smartest answer ever." ~ AnonOps Radio [some time some place] | I AM THE DERIVATIVE I AM GOING TANGENT TO THE CURVE!) |
| 2024-11-12 02:00:54 +0100 | td_ | (~td@i5387091E.versanet.de) (Ping timeout: 260 seconds) |
| 2024-11-12 02:02:17 +0100 | td_ | (~td@i53870914.versanet.de) |
| 2024-11-12 02:02:30 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2024-11-12 02:23:42 +0100 | biberu | (~biberu@user/biberu) biberu |
| 2024-11-12 02:28:00 +0100 | AlexNoo_ | (~AlexNoo@5.139.233.174) |
| 2024-11-12 02:29:14 +0100 | agent314 | (~quassel@static-198-44-129-53.cust.tzulo.com) agent314 |
| 2024-11-12 02:31:39 +0100 | AlexNoo | (~AlexNoo@5.139.233.174) (Ping timeout: 260 seconds) |
| 2024-11-12 02:31:54 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2024-11-12 02:43:25 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-12 02:54:04 +0100 | Axma72712 | (~Axman6@user/axman6) Axman6 |
| 2024-11-12 02:56:28 +0100 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 248 seconds) |
| 2024-11-12 02:56:39 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@79.127.217.37) Jeanne-Kamikaze |
| 2024-11-12 03:08:36 +0100 | notzmv | (~daniel@user/notzmv) (Remote host closed the connection) |
| 2024-11-12 03:09:51 +0100 | GuerrillaMonkey | (~Jeanne-Ka@static-198-54-134-103.cust.tzulo.com) Jeanne-Kamikaze |
| 2024-11-12 03:12:52 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@79.127.217.37) (Ping timeout: 272 seconds) |
| 2024-11-12 03:13:34 +0100 | GuerrillaMonkey | (~Jeanne-Ka@static-198-54-134-103.cust.tzulo.com) (Client Quit) |
| 2024-11-12 03:13:51 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@static-198-54-134-103.cust.tzulo.com) Jeanne-Kamikaze |
| 2024-11-12 03:14:36 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich) |
| 2024-11-12 03:14:56 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-12 03:35:22 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2024-11-12 03:38:07 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 252 seconds) |
| 2024-11-12 03:41:33 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2024-11-12 03:43:29 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-11-12 04:05:50 +0100 | longlongdouble | (~longlongd@49.36.234.128) |
| 2024-11-12 04:06:57 +0100 | longlongdouble | (~longlongd@49.36.234.128) (Remote host closed the connection) |
| 2024-11-12 04:07:10 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 04:07:11 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 04:07:35 +0100 | longlongdouble | (~longlongd@49.36.234.128) |
| 2024-11-12 04:08:26 +0100 | horm | (~horm@user/horm) (Quit: WeeChat 4.2.2) |
| 2024-11-12 04:11:16 +0100 | longlongdouble | (~longlongd@49.36.234.128) (Read error: Connection reset by peer) |
| 2024-11-12 04:17:36 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-12 04:17:41 +0100 | Patternmaster | (~georg@user/Patternmaster) (Ping timeout: 248 seconds) |
| 2024-11-12 04:18:49 +0100 | Axma72712 | Axman6 |
| 2024-11-12 04:27:07 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:27:53 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 04:28:35 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:30:48 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 04:31:57 +0100 | td_ | (~td@i53870914.versanet.de) (Ping timeout: 252 seconds) |
| 2024-11-12 04:32:01 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:33:54 +0100 | td_ | (~td@i5387092B.versanet.de) td_ |
| 2024-11-12 04:34:14 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 04:35:01 +0100 | longlongdouble | (~longlongd@49.36.234.128) |
| 2024-11-12 04:35:13 +0100 | longlongdouble | (~longlongd@49.36.234.128) (Remote host closed the connection) |
| 2024-11-12 04:35:32 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:35:45 +0100 | longlongdouble | (~longlongd@49.36.234.128) |
| 2024-11-12 04:37:27 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 04:39:01 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:41:17 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 04:41:45 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:42:18 +0100 | terrorjack4 | (~terrorjac@2a01:4f8:c17:dc9f::) (Quit: The Lounge - https://thelounge.chat) |
| 2024-11-12 04:42:37 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2024-11-12 04:43:01 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:44:00 +0100 | terrorjack4 | (~terrorjac@2a01:4f8:c17:dc9f::) terrorjack |
| 2024-11-12 04:45:20 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 04:45:48 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:48:05 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 04:48:33 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:51:04 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 04:51:32 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:53:51 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 04:54:19 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:56:46 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 04:57:14 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 04:58:07 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2024-11-12 04:58:31 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 05:01:02 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 05:01:30 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 05:03:56 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 05:04:24 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 05:06:43 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2024-11-12 05:07:12 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 05:22:02 +0100 | longlongdouble | (~longlongd@49.36.234.128) (Read error: Connection reset by peer) |
| 2024-11-12 05:27:39 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2024-11-12 05:40:10 +0100 | aforemny | (~aforemny@2001:9e8:6cde:dd00:e907:b368:5aa5:db2) aforemny |
| 2024-11-12 05:40:31 +0100 | piele | (~piele@tbonesteak.creativeserver.net) piele |
| 2024-11-12 05:41:04 +0100 | aforemny_ | (~aforemny@2001:9e8:6cfe:4400:bc92:ace3:acbf:4fb3) (Ping timeout: 272 seconds) |
| 2024-11-12 05:49:50 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@static-198-54-134-103.cust.tzulo.com) (Quit: Leaving) |
| 2024-11-12 05:59:49 +0100 | delyan_ | (sid523379@id-523379.hampstead.irccloud.com) (Ping timeout: 244 seconds) |
| 2024-11-12 06:03:07 +0100 | delyan_ | (sid523379@id-523379.hampstead.irccloud.com) |
| 2024-11-12 06:25:20 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-11-12 06:32:51 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2024-11-12 06:33:02 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2024-11-12 06:34:16 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
| 2024-11-12 06:44:26 +0100 | longlongdouble | (~longlongd@49.36.234.128) |
| 2024-11-12 06:44:37 +0100 | longlongdouble | (~longlongd@49.36.234.128) (Remote host closed the connection) |
| 2024-11-12 06:44:52 +0100 | longlongdouble | (~longlongd@49.36.234.128) |
| 2024-11-12 06:50:45 +0100 | jinsun | (~jinsun@user/jinsun) jinsun |
| 2024-11-12 06:54:04 +0100 | Patternmaster | (~georg@user/Patternmaster) Patternmaster |
| 2024-11-12 07:00:00 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-11-12 07:11:01 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2024-11-12 07:15:12 +0100 | jinsun | (~jinsun@user/jinsun) (Ping timeout: 276 seconds) |
| 2024-11-12 07:21:13 +0100 | alioguzhan | (~Thunderbi@78.173.69.189) (Remote host closed the connection) |
| 2024-11-12 07:22:02 +0100 | briandaed | (~root@185.234.210.211.r.toneticgroup.pl) |
| 2024-11-12 07:22:29 +0100 | alioguzhan | (~Thunderbi@78.173.69.189) |
| 2024-11-12 07:29:45 +0100 | michalz | (~michalz@185.246.207.197) |
| 2024-11-12 07:30:30 +0100 | longlongdouble | (~longlongd@49.36.234.128) (Remote host closed the connection) |
| 2024-11-12 07:32:06 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-11-12 07:37:52 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f3379b605d06685ed78.dip0.t-ipconnect.de) acidjnk |
| 2024-11-12 07:46:12 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-11-12 07:47:03 +0100 | tomboy64 | (~tomboy64@user/tomboy64) (Ping timeout: 276 seconds) |
| 2024-11-12 07:49:09 +0100 | tomboy64 | (~tomboy64@user/tomboy64) tomboy64 |
| 2024-11-12 07:54:26 +0100 | youthlic | (~Thunderbi@user/youthlic) (Ping timeout: 252 seconds) |
| 2024-11-12 07:56:11 +0100 | tomboy64 | (~tomboy64@user/tomboy64) (Read error: Connection reset by peer) |
| 2024-11-12 07:59:28 +0100 | tomboy64 | (~tomboy64@user/tomboy64) tomboy64 |
| 2024-11-12 08:11:40 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 252 seconds) |
| 2024-11-12 08:11:43 +0100 | youthlic | (~Thunderbi@user/youthlic) youthlic |
| 2024-11-12 08:15:13 +0100 | longlongdouble | (~longlongd@49.36.234.128) |
| 2024-11-12 08:34:55 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f3379b605d06685ed78.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2024-11-12 08:42:40 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-12 08:47:41 +0100 | Square | (~Square4@user/square) Square |
| 2024-11-12 08:51:07 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2024-11-12 08:52:03 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 245 seconds) |
| 2024-11-12 08:54:04 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2024-11-12 09:00:00 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-12 09:00:37 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-12 09:07:50 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-11-12 09:13:43 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2024-11-12 09:15:07 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-11-12 09:15:42 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2024-11-12 09:15:42 +0100 | ChanServ | +v haskellbridge |
| 2024-11-12 09:19:42 +0100 | misterfish | (~misterfis@h239071.upc-h.chello.nl) misterfish |
| 2024-11-12 09:27:35 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-11-12 09:27:45 +0100 | alp | (~alp@2001:861:e3d6:8f80:a99a:73f2:3cc3:6a6c) |
| 2024-11-12 09:29:50 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-11-12 09:37:45 +0100 | Square | (~Square4@user/square) (Ping timeout: 252 seconds) |
| 2024-11-12 09:41:02 +0100 | housemate | (~housemate@146.70.66.228) (Quit: "I saw it in a tiktok video and thought that it was the most smartest answer ever." ~ AnonOps Radio [some time some place] | I AM THE DERIVATIVE I AM GOING TANGENT TO THE CURVE!) |
| 2024-11-12 09:43:18 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 09:43:54 +0100 | poscat0x04 | (~poscat@user/poscat) (Ping timeout: 260 seconds) |
| 2024-11-12 09:45:10 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2024-11-12 09:47:57 +0100 | housemate | (~housemate@146.70.66.228) (Client Quit) |
| 2024-11-12 09:54:39 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-12 09:57:47 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-11-12 10:02:04 +0100 | hellwolf | (~user@2001:1530:70:545:ac66:99b5:ab1c:ca1) hellwolf |
| 2024-11-12 10:02:41 +0100 | <hellwolf> | testing: back to irc. |
| 2024-11-12 10:03:49 +0100 | ft | (~ft@p4fc2a216.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-11-12 10:04:04 +0100 | gorignak | (~gorignak@user/gorignak) (Read error: Connection reset by peer) |
| 2024-11-12 10:05:48 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f33dd403172660d4408.dip0.t-ipconnect.de) |
| 2024-11-12 10:07:14 +0100 | agent314 | (~quassel@static-198-44-129-53.cust.tzulo.com) (Ping timeout: 260 seconds) |
| 2024-11-12 10:11:51 +0100 | <haskellbridge> | <hellwolf> How much appeal would there be to make curry function n-ary friendly? Adding to that, having some sort of N-ary friendly type class that one can extend over? |
| 2024-11-12 10:11:53 +0100 | <haskellbridge> | I am asking because I built something for my project lately, and I have find the lack of better tuple (lest NP) friendly curry leads to my rebuilding wheels. |
| 2024-11-12 10:13:24 +0100 | misterfish | (~misterfis@h239071.upc-h.chello.nl) (Ping timeout: 252 seconds) |
| 2024-11-12 10:16:20 +0100 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2024-11-12 10:16:35 +0100 | hellwolf | (~user@2001:1530:70:545:ac66:99b5:ab1c:ca1) (Quit: rcirc on GNU Emacs 29.4) |
| 2024-11-12 10:16:49 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2024-11-12 10:16:57 +0100 | hellwolf | (~user@2001:1530:70:545:ac66:99b5:ab1c:ca1) hellwolf |
| 2024-11-12 10:17:13 +0100 | <Leary> | hellwolf: Large tuples are unidiomatic; I don't know who's going to be using enough of them to want such a thing. |
| 2024-11-12 10:18:22 +0100 | <hellwolf> | Fair enough. It is probably very specific to the use cases, which I happen to be in those. |
| 2024-11-12 10:19:55 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-12 10:29:47 +0100 | longlongdouble | (~longlongd@49.36.234.128) (Remote host closed the connection) |
| 2024-11-12 10:30:27 +0100 | ubert | (~Thunderbi@178.165.164.236.wireless.dyn.drei.com) ubert |
| 2024-11-12 10:31:33 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-12 10:36:14 +0100 | kuribas | (~user@2a02:1808:8c:1878:f2e0:c7f8:cbdc:6f5d) kuribas |
| 2024-11-12 11:00:26 +0100 | hgolden_ | (~hgolden@syn-172-251-233-141.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-11-12 11:05:10 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6c70:1ac0:d127:74dd) hgolden |
| 2024-11-12 11:07:54 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 260 seconds) |
| 2024-11-12 11:15:14 +0100 | longlongdouble | (~longlongd@49.36.234.128) |
| 2024-11-12 11:18:48 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-12 11:21:37 +0100 | longlongdouble | (~longlongd@49.36.234.128) (Remote host closed the connection) |
| 2024-11-12 11:21:50 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 11:22:09 +0100 | chele | (~chele@user/chele) chele |
| 2024-11-12 11:23:06 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-11-12 11:24:42 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-11-12 11:25:13 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 11:25:37 +0100 | longlongdouble | (~longlongd@49.36.234.128) |
| 2024-11-12 11:31:51 +0100 | longlongdouble | (~longlongd@49.36.234.128) (Read error: Connection reset by peer) |
| 2024-11-12 11:42:02 +0100 | petrichor | (~znc-user@user/petrichor) petrichor |
| 2024-11-12 11:42:53 +0100 | longlongdouble | (~longlongd@117.234.59.239) |
| 2024-11-12 11:43:11 +0100 | youthlic | (~Thunderbi@user/youthlic) (Ping timeout: 255 seconds) |
| 2024-11-12 11:44:01 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-12 11:44:36 +0100 | youthlic | (~Thunderbi@user/youthlic) youthlic |
| 2024-11-12 11:53:16 +0100 | longlongdouble | (~longlongd@117.234.59.239) (Remote host closed the connection) |
| 2024-11-12 11:53:34 +0100 | longlongdouble | (~longlongd@117.234.59.239) |
| 2024-11-12 11:59:21 +0100 | longlongdouble | (~longlongd@117.234.59.239) (Read error: Connection reset by peer) |
| 2024-11-12 11:59:59 +0100 | longlongdouble | (~longlongd@117.234.59.239) |
| 2024-11-12 12:06:23 +0100 | divya | (~user@139.5.11.223) divya |
| 2024-11-12 12:09:31 +0100 | xff0x | (~xff0x@2405:6580:b080:900:50c5:d80f:bb7d:df5c) |
| 2024-11-12 12:10:11 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2024-11-12 12:26:14 +0100 | Alecs | (~textual@nat16.software.imdea.org) alecs |
| 2024-11-12 12:27:16 +0100 | <bwe> | code organisation in modules: Since I've exported only exposed functions via `module XYZ (f1, f2) where`. That means no helper functions used by f1 and f2 defined in same module. Now I've created unit tests in test file, including for helpers. Now I need to export helper functions, too, from the module (to make the tests work). What's the right approach to organise my code? As a principle, any helpers in |
| 2024-11-12 12:27:22 +0100 | <bwe> | dedicated helpers module => existing module does not expose no unnecessary functions, while tests can import helpers? Or should I leave helpers in the module but put the tests in the module itself? What's your personal experience? |
| 2024-11-12 12:27:23 +0100 | longlongdouble | (~longlongd@117.234.59.239) (Remote host closed the connection) |
| 2024-11-12 12:27:32 +0100 | <Alecs> | Hi, quick question, do you know if there is already a proposal to add a zero quantity to -XLinearTypes? I've tried looking in the repo for proposal but the search feature on github sucks |
| 2024-11-12 12:27:39 +0100 | longlongdouble | (~longlongd@117.234.59.239) |
| 2024-11-12 12:28:04 +0100 | <tomsmeding> | bwe: rename your module to XYZ.Internal and just expose everything from there; then have `module XYZ (f1, f2) where import XYZ.Internal` |
| 2024-11-12 12:28:16 +0100 | <tomsmeding> | this has become convention |
| 2024-11-12 12:28:18 +0100 | longlongdouble | (~longlongd@117.234.59.239) (Read error: Connection reset by peer) |
| 2024-11-12 12:28:48 +0100 | longlongdouble | (~longlongd@117.234.59.239) |
| 2024-11-12 12:29:02 +0100 | cyphase | (~cyphase@user/cyphase) (Read error: Connection reset by peer) |
| 2024-11-12 12:29:40 +0100 | <bwe> | tomsmeding: so the real module is just reexporting the exports only, correct? |
| 2024-11-12 12:30:04 +0100 | <bwe> | tomsmeding: …and where are more of such conventions documented I since missed? |
| 2024-11-12 12:30:40 +0100 | cyphase | (~cyphase@user/cyphase) cyphase |
| 2024-11-12 12:33:09 +0100 | <tomsmeding> | yep |
| 2024-11-12 12:34:04 +0100 | <tomsmeding> | bwe: for bonus points, put {-# OPTIONS_HADDOCK not-home #-} on the .Internal module so that the f1 and f2 documentation are actually shown in the haddocks for XYZ, not through a `module` subpage into XYZ.Internal |
| 2024-11-12 12:34:06 +0100 | <tomsmeding> | ( https://haskell-haddock.readthedocs.io/latest/markup.html ) |
| 2024-11-12 12:34:22 +0100 | <tomsmeding> | I don't think conventions like these are explicitly documented anywhere |
| 2024-11-12 12:35:48 +0100 | longlongdouble | (~longlongd@117.234.59.239) (Remote host closed the connection) |
| 2024-11-12 12:36:30 +0100 | longlongdouble | (~longlongd@117.234.59.239) |
| 2024-11-12 12:40:10 +0100 | Square2 | (~Square@user/square) Square |
| 2024-11-12 12:40:51 +0100 | kuribas | (~user@2a02:1808:8c:1878:f2e0:c7f8:cbdc:6f5d) (Ping timeout: 265 seconds) |
| 2024-11-12 12:43:06 +0100 | todi_away | todi |
| 2024-11-12 12:43:35 +0100 | longlongdouble | (~longlongd@117.234.59.239) (Read error: Connection reset by peer) |
| 2024-11-12 12:44:20 +0100 | longlongdouble | (~longlongd@117.234.59.239) |
| 2024-11-12 12:50:23 +0100 | longlongdouble | (~longlongd@117.234.59.239) (Remote host closed the connection) |
| 2024-11-12 12:50:45 +0100 | longlongdouble | (~longlongd@117.234.59.239) |
| 2024-11-12 12:53:15 +0100 | <bwe> | tomsmeding: how do I go about Internals of different files when they are in the same directory? new sub directory and keep them separate or may I lump them together? |
| 2024-11-12 12:55:42 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-11-12 12:58:30 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 13:00:05 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-12 13:02:11 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-12 13:02:43 +0100 | longlongdouble | (~longlongd@117.234.59.239) (Read error: Connection reset by peer) |
| 2024-11-12 13:03:32 +0100 | longlongdouble | (~longlongd@117.234.59.239) |
| 2024-11-12 13:05:44 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-11-12 13:06:07 +0100 | <bwe> | tomsmeding: okay, I've solved it with MyModule/Internal.hs and MyModule.hs as siblings in a folder. |
| 2024-11-12 13:06:33 +0100 | <tomsmeding> | bwe: yeah, the idea is that if you have a module A.B.C that you want to do this trick with, you split it in A.B.C and A.B.C.Internal |
| 2024-11-12 13:13:11 +0100 | Square2 | Square |
| 2024-11-12 13:23:56 +0100 | youthlic1 | (~Thunderbi@user/youthlic) youthlic |
| 2024-11-12 13:27:19 +0100 | youthlic | (~Thunderbi@user/youthlic) (Ping timeout: 260 seconds) |
| 2024-11-12 13:27:19 +0100 | youthlic1 | youthlic |
| 2024-11-12 13:35:39 +0100 | longlongdouble | (~longlongd@117.234.59.239) (Remote host closed the connection) |
| 2024-11-12 13:36:17 +0100 | longlongdouble | (~longlongd@117.234.59.239) |
| 2024-11-12 13:42:36 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-11-12 13:45:12 +0100 | longlongdouble | (~longlongd@117.234.59.239) (Read error: Connection reset by peer) |
| 2024-11-12 13:47:58 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2024-11-12 13:49:05 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-11-12 13:51:30 +0100 | longlongdouble | (~longlongd@117.234.203.0) |
| 2024-11-12 13:53:08 +0100 | youthlic1 | (~Thunderbi@user/youthlic) youthlic |
| 2024-11-12 13:53:52 +0100 | AlexNoo_ | AlexNoo |
| 2024-11-12 13:56:38 +0100 | youthlic | (~Thunderbi@user/youthlic) (Ping timeout: 245 seconds) |
| 2024-11-12 13:56:39 +0100 | youthlic1 | youthlic |
| 2024-11-12 13:57:23 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2024-11-12 13:57:58 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2024-11-12 13:58:31 +0100 | youthlic | (~Thunderbi@user/youthlic) (Remote host closed the connection) |
| 2024-11-12 14:00:07 +0100 | youthlic | (~Thunderbi@user/youthlic) youthlic |
| 2024-11-12 14:00:14 +0100 | longlongdouble | (~longlongd@117.234.203.0) (Read error: Connection reset by peer) |
| 2024-11-12 14:01:19 +0100 | longlongdouble | (~longlongd@117.234.203.0) |
| 2024-11-12 14:06:59 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f33dd403172660d4408.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2024-11-12 14:07:05 +0100 | <divya> | Building an application requires rust-1.82.0 but guix only has rust 1.77, any way to deal with this? |
| 2024-11-12 14:07:18 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f33dd403172660d4408.dip0.t-ipconnect.de) |
| 2024-11-12 14:08:28 +0100 | mari-estel | (~mari-este@user/mari-estel) () |
| 2024-11-12 14:11:51 +0100 | longlongdouble | (~longlongd@117.234.203.0) (Remote host closed the connection) |
| 2024-11-12 14:11:55 +0100 | <briandaed> | divya build rust from sources and set paths to new version |
| 2024-11-12 14:12:07 +0100 | longlongdouble | (~longlongd@117.234.203.0) |
| 2024-11-12 14:12:21 +0100 | <briandaed> | divya probably more easier paths, I don't know your setup |
| 2024-11-12 14:18:45 +0100 | longlongdouble | (~longlongd@117.234.203.0) (Ping timeout: 248 seconds) |
| 2024-11-12 14:19:28 +0100 | longlongdouble | (~longlongd@117.234.149.157) |
| 2024-11-12 14:24:04 +0100 | longlongdouble | (~longlongd@117.234.149.157) (Ping timeout: 260 seconds) |
| 2024-11-12 14:24:43 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 14:26:31 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-11-12 14:26:55 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 14:27:10 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 14:35:18 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-11-12 14:37:01 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 14:37:25 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 14:38:13 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 14:40:37 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2024-11-12 14:40:37 +0100 | ljdarj1 | ljdarj |
| 2024-11-12 14:50:03 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 14:50:16 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 14:51:13 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-11-12 14:52:39 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 14:52:54 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 14:53:20 +0100 | <bwe> | tomsmeding: so, I document the function where it is defined not where re-exported? |
| 2024-11-12 14:58:57 +0100 | <divya> | briandaed: Elsewhere I was linked to a channel that had latest rust, might use that. |
| 2024-11-12 14:59:52 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-12 15:01:05 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 15:01:19 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 15:08:20 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 15:09:09 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 15:11:46 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) SlackCoder |
| 2024-11-12 15:18:00 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 15:18:12 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 15:23:44 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 15:23:58 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 15:26:47 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 15:27:00 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 15:33:27 +0100 | alp | (~alp@2001:861:e3d6:8f80:a99a:73f2:3cc3:6a6c) (Ping timeout: 246 seconds) |
| 2024-11-12 15:37:14 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-11-12 15:38:53 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 15:39:42 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 15:49:04 +0100 | hellwolf | (~user@2001:1530:70:545:ac66:99b5:ab1c:ca1) (Quit: rcirc on GNU Emacs 29.4) |
| 2024-11-12 15:49:21 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2024-11-12 15:49:25 +0100 | hellwolf | (~user@2001:1530:70:545:ac66:99b5:ab1c:ca1) hellwolf |
| 2024-11-12 15:50:44 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 15:50:58 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 15:54:04 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 15:54:53 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 15:55:24 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) (Ping timeout: 272 seconds) |
| 2024-11-12 15:57:15 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 15:57:50 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 16:01:55 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2024-11-12 16:01:55 +0100 | ljdarj1 | ljdarj |
| 2024-11-12 16:03:18 +0100 | Fijxu | (~Fijxu@user/fijxu) (Ping timeout: 252 seconds) |
| 2024-11-12 16:05:40 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 16:05:53 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 16:09:07 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-12 16:10:33 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2024-11-12 16:11:40 +0100 | Fijxu | (~Fijxu@user/fijxu) fijxu |
| 2024-11-12 16:13:10 +0100 | <yin> | i want to alter every value of an IntMap according to some calculations based on a state record type. the IntMap is one of the fields in the state. so i have a function that looks like `step :: MyState -> MyState ; step st = st { myIntMap = IntMap.mapWithKey (f st) (myIntMap st) }` |
| 2024-11-12 16:13:23 +0100 | <yin> | f does some duplicate calculations like `calculation (myIntMap st) x = ...`. does Haskell optimize this (avoiding duplicate operations by performing some kind of memoization)? |
| 2024-11-12 16:14:33 +0100 | <divya> | I'm thinking of presenting a talk, any particular areas of haskell that you guys might like getting covered? |
| 2024-11-12 16:16:25 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 16:17:22 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 16:17:22 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 16:17:35 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 16:19:56 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 255 seconds) |
| 2024-11-12 16:19:56 +0100 | Square | (~Square@user/square) (Ping timeout: 255 seconds) |
| 2024-11-12 16:20:15 +0100 | <yin> | would using foldrWithKey any differente for this? i'm guessing mapWithKey doesn not create an intermediate data structure at each step. would there be any benefit in fold vs map? |
| 2024-11-12 16:22:09 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 16:23:06 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 16:23:12 +0100 | <briandaed> | yin: I'm not aware any implicit memoization in Haskell, there are some techniques / libraries for it, as for foldrWithKey vs mapWithKey - make a benchmark and compare what is better for you |
| 2024-11-12 16:23:34 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 16:23:47 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 16:24:38 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 16:25:27 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 16:30:13 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 16:30:25 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 16:30:25 +0100 | Fijxu | (~Fijxu@user/fijxu) (Ping timeout: 248 seconds) |
| 2024-11-12 16:31:20 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 16:31:35 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 16:35:43 +0100 | Fijxu | (~Fijxu@user/fijxu) fijxu |
| 2024-11-12 16:35:45 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2024-11-12 16:44:01 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 16:50:27 +0100 | <EvanR> | yin, is that the MyState isn't being updated except for the intmap itself, so it's basically being treated like a reader |
| 2024-11-12 16:50:53 +0100 | <EvanR> | unless f does something weird |
| 2024-11-12 16:52:53 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-12 17:07:57 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-12 17:13:03 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 17:13:23 +0100 | <yin> | what's weird to me is that this still runs (m 0) twice: https://paste.jrvieira.com/1731427978188 |
| 2024-11-12 17:14:08 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 17:16:18 +0100 | mari-estel | (~mari-este@user/mari-estel) () |
| 2024-11-12 17:17:40 +0100 | <yin> | or maybe my profiling skills are very bad |
| 2024-11-12 17:18:29 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2024-11-12 17:18:29 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2024-11-12 17:18:51 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 17:19:44 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 17:27:00 +0100 | <yin> | ok so it turns out that in simples cases like this it does optimize |
| 2024-11-12 17:28:17 +0100 | <yin> | but if i make the key an argument, it doesn't: https://paste.jrvieira.com/1731428892637 |
| 2024-11-12 17:29:53 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 17:30:41 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 17:31:47 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-12 17:32:10 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2024-11-12 17:36:12 +0100 | Leonard26 | (~Leonard26@49.236.26.53) |
| 2024-11-12 17:41:01 +0100 | <yin> | this is a better example: https://paste.jrvieira.com/1731429650053 |
| 2024-11-12 17:41:36 +0100 | <yin> | if i substitute `(mod k 2)` for `1` in the last line, it memoized |
| 2024-11-12 17:42:08 +0100 | <yin> | unfortunately, it doesn't otherwise |
| 2024-11-12 17:46:34 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 17:50:02 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-12 17:51:31 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2024-11-12 17:54:59 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 17:55:11 +0100 | Leonard26 | (~Leonard26@49.236.26.53) (Ping timeout: 256 seconds) |
| 2024-11-12 17:55:59 +0100 | Leonard26 | (~Leonard26@49.236.26.53) |
| 2024-11-12 18:00:11 +0100 | <Leonard26> | I involuntarily disconnected for a second, I just sent a question on the chat above this, can you see it? |
| 2024-11-12 18:03:22 +0100 | <geekosaur> | I don't see anything in the past 2 hours |
| 2024-11-12 18:05:16 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 18:06:05 +0100 | <Leonard26> | Hello! =D How are you? |
| 2024-11-12 18:06:05 +0100 | <Leonard26> | I am trying to define a global variable in Haskell with `IORef` called `decodeElement` , it all seems to work but I am stumbling upon an error. |
| 2024-11-12 18:06:06 +0100 | <Leonard26> | I have the `elementLink` and `onElementPadAdded` function (https://hackage.haskell.org/package/gi-gst-1.0.29/docs/GI-Gst-Objects-Element.html#v:elementLink https://hackage.haskell.org/package/gi-gst-1.0.29/docs/GI-Gst-Objects-Element.html#v:onElementPadA…) both of which take an argument of type `Element` but the type of `decodeElement` is `:: |
| 2024-11-12 18:06:06 +0100 | <Leonard26> | (MonadIO m) => IORef(m (Maybe Gst.Element))` . |
| 2024-11-12 18:06:07 +0100 | <Leonard26> | The error complains about the type not having any known parent types, what does this mean? |
| 2024-11-12 18:06:07 +0100 | <Leonard26> | https://paste.tomsmeding.com/xUF04K10 |
| 2024-11-12 18:06:08 +0100 | <Leonard26> | https://paste.tomsmeding.com/PLQWn6hZ |
| 2024-11-12 18:06:08 +0100 | <Leonard26> | P.S. I can usually make `Gst.elementFactoryMake "decodebin" (Just "decoder")` work if I declare it in the `main` function by doing this `Just decode <- Gst.elementFactoryMake "decodebin" (Just "decoder")` so applying a `Just` to it. However I really need it to be a global variable and I can't really add a `Just` at the beginning of a type signature |
| 2024-11-12 18:06:09 +0100 | <Leonard26> | (I've tried'=D ). How could this be solved? Thank you in advance :) |
| 2024-11-12 18:06:09 +0100 | hellwolf | (~user@2001:1530:70:545:ac66:99b5:ab1c:ca1) (Read error: Connection reset by peer) |
| 2024-11-12 18:06:43 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 18:07:16 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 260 seconds) |
| 2024-11-12 18:07:30 +0100 | <EvanR> | "parent type" ? |
| 2024-11-12 18:07:36 +0100 | hellwolf | (~user@2001:1530:70:545:ac66:99b5:ab1c:ca1) hellwolf |
| 2024-11-12 18:09:03 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2024-11-12 18:10:39 +0100 | <Leonard26> | It's in the error message |
| 2024-11-12 18:10:40 +0100 | <glguy> | That sounds like a custom type error message |
| 2024-11-12 18:11:21 +0100 | <Leonard26> | Ok, how do I fix that? |
| 2024-11-12 18:11:44 +0100 | <glguy> | Dunno, but it'll be specific to that library; it's not an error message many people will have seen |
| 2024-11-12 18:13:19 +0100 | <Leonard26> | This wasn't super helpful. Anyone else know a solution to this? |
| 2024-11-12 18:13:52 +0100 | <glguy> | The error is specific to how gi-gst works. you'll need to read more into the details of how that API works and what it was expecting |
| 2024-11-12 18:14:12 +0100 | <EvanR> | it's not clear what you mean by global variable, because haskell doesn't do global variables, so you might be talking about that libraries internal logic, or some other weird inadvised hack to make a global variable |
| 2024-11-12 18:14:57 +0100 | <EvanR> | "make a global variable" sounds like the Y in the XY, so may or may not depend on the library |
| 2024-11-12 18:15:12 +0100 | <glguy> | the error comes from https://github.com/haskell-gi/haskell-gi/blob/ad1ded11a35e62be5fb7c0363bd3151378257a54/base/Data/G… |
| 2024-11-12 18:16:19 +0100 | <Leonard26> | It's not library dependent. I was implementing the answer to this post https://stackoverflow.com/questions/16811376/simulate-global-variable |
| 2024-11-12 18:17:56 +0100 | <Leonard26> | I pretty much remember the whole library in my head at this point, that's why I came here thinking I might get some other ideas |
| 2024-11-12 18:18:23 +0100 | <glguy> | The error message in your paste was library-dependent specifically |
| 2024-11-12 18:19:38 +0100 | <Leonard26> | Not really, the `IORef` shouldn't be there, it's not typical functionality |
| 2024-11-12 18:22:04 +0100 | <Leonard26> | I need to implement some sort of global variables because I'm trying to rewrite this C code in Haskell https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipula… |
| 2024-11-12 18:22:04 +0100 | <Leonard26> | You can see that there are these variables/pointers whatever they are (I'm not good in C) that I need to reproduce in Haskell somehow |
| 2024-11-12 18:22:05 +0100 | <Leonard26> | static GstPad *blockpad; |
| 2024-11-12 18:22:05 +0100 | <Leonard26> | static GstElement *conv_before; |
| 2024-11-12 18:22:06 +0100 | <Leonard26> | static GstElement *conv_after; |
| 2024-11-12 18:22:06 +0100 | <Leonard26> | static GstElement *cur_effect; |
| 2024-11-12 18:22:07 +0100 | <Leonard26> | static GstElement *pipeline; |
| 2024-11-12 18:22:36 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 18:22:48 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 18:26:34 +0100 | Fijxu | (~Fijxu@user/fijxu) (Ping timeout: 252 seconds) |
| 2024-11-12 18:27:09 +0100 | <briandaed> | glguy is right, error message has it's origin in this library, global variables sounds like trouble, you can achieve it by combining readert with mvars or whatever suits you |
| 2024-11-12 18:27:27 +0100 | turlando | (~turlando@user/turlando) () |
| 2024-11-12 18:28:01 +0100 | turlando | (~turlando@user/turlando) turlando |
| 2024-11-12 18:28:12 +0100 | <Leonard26> | Do you have an example of how that would work? |
| 2024-11-12 18:28:45 +0100 | Fijxu | (~Fijxu@user/fijxu) fijxu |
| 2024-11-12 18:29:05 +0100 | <briandaed> | https://tech.fpcomplete.com/blog/2017/06/readert-design-pattern/ |
| 2024-11-12 18:29:18 +0100 | <EvanR> | Reader, ReaderT |
| 2024-11-12 18:29:25 +0100 | <EvanR> | the url capitalization is painful |
| 2024-11-12 18:30:20 +0100 | <Leonard26> | Alright, I'll look into that, thank you :) |
| 2024-11-12 18:30:49 +0100 | <briandaed> | np, have fun |
| 2024-11-12 18:32:08 +0100 | <Leonard26> | I will! =D |
| 2024-11-12 18:33:44 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 18:34:07 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2024-11-12 18:36:33 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 18:37:14 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2024-11-12 18:37:14 +0100 | ljdarj1 | ljdarj |
| 2024-11-12 18:37:28 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 18:43:05 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 18:43:19 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 18:44:21 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f33dd403172660d4408.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2024-11-12 18:47:17 +0100 | Fijxu | (~Fijxu@user/fijxu) (Quit: XD!!) |
| 2024-11-12 18:47:55 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-11-12 18:51:12 +0100 | alp | (~alp@2001:861:e3d6:8f80:46dd:be45:db8:fbc7) |
| 2024-11-12 18:54:21 +0100 | Fijxu | (~Fijxu@user/fijxu) fijxu |
| 2024-11-12 18:54:39 +0100 | Leonard26 | (~Leonard26@49.236.26.53) (Quit: Client closed) |
| 2024-11-12 18:54:58 +0100 | turlando | (~turlando@user/turlando) () |
| 2024-11-12 18:56:14 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f33dd403172660d4408.dip0.t-ipconnect.de) |
| 2024-11-12 18:59:22 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-12 19:01:38 +0100 | jinsun | (~jinsun@user/jinsun) jinsun |
| 2024-11-12 19:01:46 +0100 | abrar | (~abrar@pool-72-78-199-167.phlapa.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-11-12 19:03:46 +0100 | abrar | (~abrar@pool-72-78-199-167.phlapa.fios.verizon.net) |
| 2024-11-12 19:04:19 +0100 | <bailsman> | Is there such a thing as 'readonly view to mutable data' in Haskell? can I pass a reference created with `unsafeFreeze` to a function, and once it returns (and thus will no longer use the reference), continue to mutate the array? The documentation seems to suggest you "can no longer mutate" but I'm not sure if that's while the immutable reference exists or... ever again. |
| 2024-11-12 19:05:16 +0100 | <Rembane> | bailsman: There's the ST monad which can help you with this. Vector has quite good support for working with mutable vectors in the ST monad. |
| 2024-11-12 19:05:49 +0100 | <bailsman> | Rembane: sure. I'm happy for the function I call to be in the ST monad. I'd like to have the compiler ensure that my callee does not modify the data. |
| 2024-11-12 19:06:07 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-11-12 19:07:13 +0100 | <Rembane> | bailsman: Do I understand you correctly, that you want to hand out a reference to mutable data that is then not modified? |
| 2024-11-12 19:07:20 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-11-12 19:07:49 +0100 | <bailsman> | I want to give a read-only view to the data to a function, that does whatever it wants with it so long as it modified, but then after that function returns, continue mutating the data. |
| 2024-11-12 19:08:00 +0100 | <bailsman> | so long as it is *not* modified |
| 2024-11-12 19:09:02 +0100 | <Rembane> | Got it. Stupid question: why? |
| 2024-11-12 19:09:49 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-11-12 19:10:45 +0100 | <bailsman> | so the code with the immutable reference can pretend it is pure |
| 2024-11-12 19:10:53 +0100 | <Rembane> | Because you can go from mutable to immutable and then back again. No worries at all. It's just quite expensive: https://hackage.haskell.org/package/vector-0.13.2.0/docs/Data-Vector.html#v:freeze |
| 2024-11-12 19:11:14 +0100 | <Rembane> | Depending a bit on what your budget is of course. |
| 2024-11-12 19:11:43 +0100 | <c_wraith> | there are also the unsafe versions of freeze and thaw that *can* be O(1), but are liable to crash your program if you don't understand laziness very well |
| 2024-11-12 19:11:50 +0100 | <bailsman> | Yes, I'd like to keep the data in place and avoid O(n) operations to copy the data. I'll do that if that's the best I can do, but I'd like to be able just to create a readonly reference |
| 2024-11-12 19:12:34 +0100 | tired | (~tired@user/tired) (Quit: /) |
| 2024-11-12 19:13:14 +0100 | tired | (~tired@user/tired) tired |
| 2024-11-12 19:13:23 +0100 | <bailsman> | Hold on, so it is possible to use unsafeFreeze safely if you can somehow ensure the function using the immutable reference has been fully evalauted and is not just a thunk? |
| 2024-11-12 19:13:37 +0100 | <c_wraith> | yes |
| 2024-11-12 19:14:49 +0100 | <c_wraith> | Though really, if you're going to keep mutating it afterwards, you should unsafeThaw the frozen version instead of re-using the previous mutable version |
| 2024-11-12 19:15:00 +0100 | <bailsman> | Well, unfortunately, I do not understand laziness very well. What are some ways I can ensure this? I know `seq` will not work, because it's perfectly possible for that to be in WHNF while the there's still a thunk inside with the immutable reference. |
| 2024-11-12 19:15:13 +0100 | <c_wraith> | It's still O(1), but it makes the data dependency more clear |
| 2024-11-12 19:15:32 +0100 | <bailsman> | OK, that's fine. I'll unsafeThaw it after the function using the immutable reference returns. |
| 2024-11-12 19:15:39 +0100 | <c_wraith> | the brute force is evaluate + force, if you're in IO |
| 2024-11-12 19:16:01 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-12 19:16:43 +0100 | <c_wraith> | evaluate is from Control.Exception, force is from Control.DeepSeq |
| 2024-11-12 19:17:26 +0100 | <c_wraith> | https://hackage.haskell.org/package/deepseq-1.5.1.0/docs/Control-DeepSeq.html#v:force mentions using it with evaluate |
| 2024-11-12 19:17:43 +0100 | <bailsman> | Documentation says: All in all, attempts to modify a vector produced by unsafeThaw fall out of domain of software engineering and into realm of black magic, dark rituals, and unspeakable horrors. The only advice that could be given is: "Don't attempt to mutate a vector produced by unsafeThaw unless you know how to prevent GHC from aliasing buffers accidentally. We don't." |
| 2024-11-12 19:19:54 +0100 | <bailsman> | I'm getting the feeling I should not be trying this, and should just either eat the O(n) copy and/or pass around mutable copies instead. |
| 2024-11-12 19:23:25 +0100 | <c_wraith> | It's certainly much less fragile to let GHC's assumptions about immutability be correct |
| 2024-11-12 19:23:30 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800:b27:4ecf:926d:786) ph88 |
| 2024-11-12 19:25:16 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 19:26:06 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 19:27:00 +0100 | KicksonButt | (~quassel@187.21.174.221) |
| 2024-11-12 19:27:26 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2024-11-12 19:28:59 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-11-12 19:29:02 +0100 | <bailsman> | I tracked down the github issue that introduced that comment: https://github.com/haskell/vector/issues/139 -- but that seems to demonstrate the problem you were talking about. if I deepseq the function that uses the immutable reference, and only then thaw it again, am I fine? |
| 2024-11-12 19:29:14 +0100 | <bailsman> | I like O(1) better than O(n) |
| 2024-11-12 19:30:12 +0100 | <c_wraith> | I think you *should* be, but it is fundamentally placing yourself in the position of fighting against how GHC works |
| 2024-11-12 19:30:36 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 19:30:50 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 19:31:34 +0100 | <bailsman> | Hm. And I cannot just keep using the mutable reference? |
| 2024-11-12 19:31:44 +0100 | <bailsman> | rather than thawing |
| 2024-11-12 19:32:02 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-12 19:32:05 +0100 | <bailsman> | That's because what I'm calling a reference, isn't, really, internally it's setting flags on the pointer? |
| 2024-11-12 19:35:56 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-11-12 19:36:30 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Read error: Connection reset by peer) |
| 2024-11-12 19:37:29 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 19:43:38 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 19:44:30 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2024-11-12 19:44:31 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 19:48:54 +0100 | <EvanR> | another thing you can do is use an immutable structure like IntMap or Sequence instead of a mutable array |
| 2024-11-12 19:49:07 +0100 | <EvanR> | then you can much more easily pretend it is "pure" |
| 2024-11-12 19:49:10 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 19:49:17 +0100 | <EvanR> | and GHC won't hate you |
| 2024-11-12 19:49:35 +0100 | <EvanR> | the GC works better with immutable data |
| 2024-11-12 19:50:23 +0100 | <EvanR> | another question would be how large your mutable array will typically be |
| 2024-11-12 19:51:04 +0100 | <EvanR> | if it is like "exactly 4" might as well just use immutable Vector for this or something like linear V4 |
| 2024-11-12 19:59:06 +0100 | longlongdouble | (~longlongd@49.36.232.34) |
| 2024-11-12 20:00:16 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 20:01:08 +0100 | tomku | (~tomku@user/tomku) (Ping timeout: 272 seconds) |
| 2024-11-12 20:02:33 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 252 seconds) |
| 2024-11-12 20:02:34 +0100 | ljdarj1 | ljdarj |
| 2024-11-12 20:04:29 +0100 | longlongdouble | (~longlongd@49.36.232.34) (Remote host closed the connection) |
| 2024-11-12 20:04:43 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) |
| 2024-11-12 20:05:42 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) (Read error: Connection reset by peer) |
| 2024-11-12 20:06:18 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-11-12 20:06:34 +0100 | <bailsman> | EvanR: what I want to do is something like: MVector Element, for each element updateSingleElement :: AllElements -> Element -> Element. So the update function can read the others, but update only its own thing. So updateSingleElement (and whatever it calls from there) can pretend it is in a pure world and be written simply and intuitively, but I was hoping GHC's optimizer would notice that |
| 2024-11-12 20:06:36 +0100 | <bailsman> | eventually it just gets assigned and not do any memory allocations in the hot loop. |
| 2024-11-12 20:07:34 +0100 | <bailsman> | Since this is O(n) anyway, doing a copy wouldn't change the fundamental complexity of the algorithm and likely is not going to be the slowest thing, so I can probably do an O(n) copy if I need to. |
| 2024-11-12 20:07:50 +0100 | <EvanR> | mutating objects which pure code has a reference to as if it was immutable just breaks the core logic of haskell |
| 2024-11-12 20:07:51 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2024-11-12 20:08:00 +0100 | <EvanR> | it might make more sense in another language |
| 2024-11-12 20:08:04 +0100 | <EvanR> | like C++ |
| 2024-11-12 20:08:13 +0100 | <bailsman> | Hm? But nothing gets mutated while updateSingleElement runs. Only once it is done, does it get assigned. |
| 2024-11-12 20:08:24 +0100 | <EvanR> | so you say |
| 2024-11-12 20:08:39 +0100 | <EvanR> | it's assuming a lot |
| 2024-11-12 20:08:46 +0100 | <EvanR> | that we don't normally have to assume or care about |
| 2024-11-12 20:09:09 +0100 | <EvanR> | how large is this vector anyway |
| 2024-11-12 20:09:24 +0100 | <bailsman> | Maybe 100K objects. |
| 2024-11-12 20:09:37 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) pointlessslippe1 |
| 2024-11-12 20:09:57 +0100 | <EvanR> | ok that's pretty big, so if you wanted max performance you need to worry about memory locality |
| 2024-11-12 20:10:38 +0100 | <bailsman> | I'm mostly just trying to discover how I should think about things in Haskell. |
| 2024-11-12 20:11:07 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2024-11-12 20:11:21 +0100 | zetef | (~quassel@86.124.126.227) zetef |
| 2024-11-12 20:11:21 +0100 | zetef | (~quassel@86.124.126.227) (Client Quit) |
| 2024-11-12 20:11:23 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2024-11-12 20:11:24 +0100 | <EvanR> | values are values, which don't change. If you mutate some object backing a value, then you have to make sure no one can ever see the old value anymore |
| 2024-11-12 20:11:31 +0100 | <EvanR> | which is tricky |
| 2024-11-12 20:11:39 +0100 | <bailsman> | Wait, I WANT the old value |
| 2024-11-12 20:11:49 +0100 | <EvanR> | the old value will be completely broken if you keep it around |
| 2024-11-12 20:11:55 +0100 | <bailsman> | there's no sequential updates, all updates are independent and should do update work based on the old value of AllElements |
| 2024-11-12 20:12:43 +0100 | longlongdouble | (~longlongd@2405:201:5c16:135:1989:242:cab1:419a) (Remote host closed the connection) |
| 2024-11-12 20:12:48 +0100 | <EvanR> | if you're treating it like a mutable array, it's not a value anymore. But anyone who still sees the value version will be screwed |
| 2024-11-12 20:13:09 +0100 | <EvanR> | I assume you think that's not happening, because you carefully cleared that part of the code |
| 2024-11-12 20:13:53 +0100 | <EvanR> | this is the purely theoretical part. The practical difficulty is that mutable and immutable objects are treated totally different in the runtime system |
| 2024-11-12 20:14:47 +0100 | <EvanR> | so when you thaw something it makes a copy unless there was a rewrite rule to avoid it because of reasons |
| 2024-11-12 20:15:10 +0100 | <bailsman> | I want to write most of the logic in "normal intuitive code" but then also have the optimizer notice that it's being updated in place and not do any allocations (because I've read somewhere allocations are bad - I've not actually done any profiling) |
| 2024-11-12 20:15:28 +0100 | <bailsman> | I think what I might want to do is just do an O(n) copy of the entire mutable vector using regular freeze (not unsafeFreeze) and then do something like modify (updateSingleElement frozenCopy) index? That's one allocation, but it's kind of outside the core loop, and the whole thing is already O(n) anyway and copying some memory over is fast. |
| 2024-11-12 20:16:39 +0100 | <EvanR> | the normal intuitive way sounds like you just want a mutable array. There is a thing where you can export a mutable array that you made as a "pure" immutable array from an ST action |
| 2024-11-12 20:16:47 +0100 | <EvanR> | "for free" |
| 2024-11-12 20:16:50 +0100 | <EvanR> | but not the other way around |
| 2024-11-12 20:17:08 +0100 | <bailsman> | Every iteration of the loop, every element is going to get updated again. I want to keep modifying them over and over (in place) |
| 2024-11-12 20:17:18 +0100 | <EvanR> | mutable array it is |
| 2024-11-12 20:17:28 +0100 | <bailsman> | No, because the "pure part" of the code should not write anywhere |
| 2024-11-12 20:17:33 +0100 | <EvanR> | what pure part |
| 2024-11-12 20:17:41 +0100 | <bailsman> | updateSingleElement and everything it calls |
| 2024-11-12 20:18:20 +0100 | <EvanR> | well, the frozenCopy is going to be expensive, and there's no real way around it |
| 2024-11-12 20:18:59 +0100 | <geekosaur> | am I understanding correctly that updateSingleElement only reads, and ultimately produces a value that the impure code will actually use to mutate? |
| 2024-11-12 20:19:05 +0100 | <EvanR> | accessing a mutable array involves more book keeping than an immutable array, in the gd |
| 2024-11-12 20:19:06 +0100 | <EvanR> | gc |
| 2024-11-12 20:19:07 +0100 | <bailsman> | Is it? I wonder if it's going to be the fastest part, so fast that I'll be embarrased to have enough wondered about the issue. |
| 2024-11-12 20:19:18 +0100 | <bailsman> | geekosaur: yes |
| 2024-11-12 20:19:21 +0100 | <EvanR> | copying 100k elements? |
| 2024-11-12 20:19:28 +0100 | <EvanR> | not cheap |
| 2024-11-12 20:19:45 +0100 | <EvanR> | especially if you do it once per loop and discard it all |
| 2024-11-12 20:19:47 +0100 | <bailsman> | it's just memcopy can't you do that at terrabytes per second or something |
| 2024-11-12 20:19:58 +0100 | <EvanR> | fine then |
| 2024-11-12 20:20:20 +0100 | <bailsman> | I mean that was pretty much my worry, and why I was looking for whether "immutable references to mutable data" are a thing |
| 2024-11-12 20:20:29 +0100 | <EvanR> | see if it fits into the gc first generation |
| 2024-11-12 20:20:52 +0100 | <EvanR> | since it's temporary maybe it won't be so bad |
| 2024-11-12 20:21:14 +0100 | <EvanR> | but I expect the total cost to defeat the purpose of all this optimization talk |
| 2024-11-12 20:21:20 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2024-11-12 20:21:50 +0100 | <bailsman> | So what I should do instead is design it to pass mutable references around and just not write to them where I'm not supposed to? |
| 2024-11-12 20:22:16 +0100 | <EvanR> | the whole thing being an ST action sounds like what ST is meant for |
| 2024-11-12 20:22:28 +0100 | <EvanR> | you can access the array however you want, and the whole operation will be considered pure in the end |
| 2024-11-12 20:22:48 +0100 | <bailsman> | I'm totally happy to annotate all the rest of the code however the type system needs me |
| 2024-11-12 20:23:07 +0100 | <bailsman> | but I would like the compiler to ensure that I'm not writing to the data where I don't want to be writing to it. |
| 2024-11-12 20:23:38 +0100 | <EvanR> | you can wrap your ST array in a newtype which won't allow you to write through it |
| 2024-11-12 20:24:08 +0100 | <bailsman> | Interesting. Can you make an example? |
| 2024-11-12 20:24:37 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Quit: Leaving) |
| 2024-11-12 20:24:48 +0100 | <bailsman> | If that's easy to do, why isn't it how freeze/thaw already works? |
| 2024-11-12 20:25:33 +0100 | <EvanR> | what I just suggested as in response to "compiler stops me from writing to it when I don't want to, because... I might accidentally write code to write to it for some reason" |
| 2024-11-12 20:25:54 +0100 | <EvanR> | which is a different subject from increasing the performance of working with an array |
| 2024-11-12 20:25:57 +0100 | <bailsman> | I wonder if that still causes the compiler to think the data is "actually mutable" and disables a ton of optimizations |
| 2024-11-12 20:26:17 +0100 | <bailsman> | I would like most of the code to be regular normal pure code |
| 2024-11-12 20:27:06 +0100 | <EvanR> | it certainly would still be treated like a mutable array |
| 2024-11-12 20:27:09 +0100 | <EvanR> | since it is |
| 2024-11-12 20:28:04 +0100 | <EvanR> | but someone noted the existence of unsafeThaw which is your trap door into "I know what I'm doing" |
| 2024-11-12 20:28:27 +0100 | <bailsman> | I don't though. |
| 2024-11-12 20:28:42 +0100 | <EvanR> | exactly |
| 2024-11-12 20:29:04 +0100 | <EvanR> | I've never really had any success violating haskell's semantics |
| 2024-11-12 20:29:13 +0100 | <EvanR> | it's just not that kind of language |
| 2024-11-12 20:29:32 +0100 | <int-e> | avoid success at all cost? |
| 2024-11-12 20:30:31 +0100 | <Rembane> | int-e: ...while studying the dark arts? |
| 2024-11-12 20:31:23 +0100 | <int-e> | . o O ( unsuccessfullyPerformIO :: IO a -> a; unsuccessfullyPerformIO = error "I'm afraid I cannot do that, Dave" ) |
| 2024-11-12 20:32:56 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-12 20:33:20 +0100 | <EvanR> | instead of breaking the system, maybe study ways of constructing a new system which is safe and does the optimizations |
| 2024-11-12 20:33:58 +0100 | <EvanR> | but this mindset requires respecting abstractions in play, once the game starts |
| 2024-11-12 20:34:27 +0100 | <EvanR> | and then proving what you did worked |
| 2024-11-12 20:35:02 +0100 | <EvanR> | and be willing to find the counterexamples which prove yourself wrong |
| 2024-11-12 20:36:42 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-12 20:37:25 +0100 | arthurvl | (~arthurvl@2a02-a469-f5e2-1-83d2-ca43-57a2-dc81.fixed6.kpn.net) (Ping timeout: 265 seconds) |
| 2024-11-12 20:39:22 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-11-12 20:39:26 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-11-12 20:39:45 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2024-11-12 20:42:26 +0100 | <int-e> | oh, one more: unsuccessfullyDupablePerformIO :: IO a -> a; unsuccessfullyDupablePerformIO = error (error "I'm afraid I cannot do that, Dave") |
| 2024-11-12 20:46:45 +0100 | <bailsman> | Does code like this `for_ [0 .. MV.length v - 1)] (MV.modify v f)` have any performance gotchas? I somehow got it into my head that I want to mutate data in place for performance reasons, but I'm slowly starting to have more and more doubts. |
| 2024-11-12 20:46:51 +0100 | <bailsman> | This kind of thing should start and end with profiling probably |
| 2024-11-12 20:51:37 +0100 | sprotte24 | (~sprotte24@p200300d16f2cc30041d9df5443f92151.dip0.t-ipconnect.de) |
| 2024-11-12 20:52:30 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-11-12 20:54:59 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-12 20:55:05 +0100 | <tomsmeding> | bwe: indeed, you put the haddocks on the function where it's defined, and with the not-home haddock option you ensure that the documentation gets generated in the right place |
| 2024-11-12 20:55:30 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-12 20:55:54 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2024-11-12 20:56:11 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 20:56:26 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
| 2024-11-12 20:58:15 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2024-11-12 21:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-12 21:00:38 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-12 21:01:45 +0100 | hellwolf | (~user@2001:1530:70:545:ac66:99b5:ab1c:ca1) (Ping timeout: 246 seconds) |
| 2024-11-12 21:04:45 +0100 | <EvanR> | bailsman, it seems like a fold over an IntMap might be more idiomatic and worth benchmarking (again) |
| 2024-11-12 21:05:10 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-12 21:05:40 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-12 21:06:27 +0100 | <EvanR> | mutable stuff can be faster but ghc puts a tax on all mutable refs for gc purposes |
| 2024-11-12 21:07:29 +0100 | ft | (~ft@p4fc2a216.dip0.t-ipconnect.de) ft |
| 2024-11-12 21:08:53 +0100 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2024-11-12 21:10:24 +0100 | jrm | (~jrm@user/jrm) jrm |
| 2024-11-12 21:14:08 +0100 | zenmov | (zenmov@user/dymenshen) dymenshen |
| 2024-11-12 21:15:21 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-12 21:15:52 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-12 21:17:10 +0100 | pera | (~pera@user/pera) pera |