| 2022-08-01 00:00:30 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 00:01:26 +0200 | <pavonia> | I didnt do any profiling actually, but those Integer operations are the only ones the functions perform |
| 2022-08-01 00:01:51 +0200 | <monochrom> | Are the functions known to be hot spots? |
| 2022-08-01 00:03:05 +0200 | <pavonia> | Yeah |
| 2022-08-01 00:03:35 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org) |
| 2022-08-01 00:04:58 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 244 seconds) |
| 2022-08-01 00:10:36 +0200 | <monochrom> | OK I did an experiment with "f :: Int -> Int; f x = x * 16" or 17. |
| 2022-08-01 00:10:52 +0200 | <monochrom> | 16 becomes shlq $4, %rax |
| 2022-08-01 00:11:18 +0200 | <monochrom> | 17 becomes imulq $17, %rax |
| 2022-08-01 00:11:37 +0200 | <monochrom> | This is both -O and -O2 |
| 2022-08-01 00:11:41 +0200 | <geekosaur> | Integer, though? |
| 2022-08-01 00:12:05 +0200 | <geekosaur> | especially given switchable (even if not at runtime) backend |
| 2022-08-01 00:13:44 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-08-01 00:13:53 +0200 | <monochrom> | Integer is going to be just calling up GHC.Integer.Type.timesInteger_info |
| 2022-08-01 00:14:15 +0200 | <monochrom> | (16 or 17) |
| 2022-08-01 00:15:02 +0200 | <monochrom> | But you do not know that GMP does not optimize that :) |
| 2022-08-01 00:15:25 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2022-08-01 00:15:30 +0200 | <dolio> | For Integer it has multiple branches, too. |
| 2022-08-01 00:15:35 +0200 | <geekosaur> | right, but I also don't know with certainty that it's the GMP backend (and more to the point, neither does ghc) |
| 2022-08-01 00:15:40 +0200 | <dolio> | One looks similar to Int, and the other uses GMP. |
| 2022-08-01 00:15:56 +0200 | <dolio> | Except the Int branch will have to promote sometimes. |
| 2022-08-01 00:16:26 +0200 | <monochrom> | "What are birds? We just don't know." :) |
| 2022-08-01 00:18:30 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 00:20:09 +0200 | kimjetwav | (~user@2607:fea8:235e:b600:4fe5:aa4:5bfb:2ba6) (Remote host closed the connection) |
| 2022-08-01 00:20:54 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 00:24:43 +0200 | renzhi | (~xp@2607:fa49:6500:b100::47a5) |
| 2022-08-01 00:26:24 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-08-01 00:27:33 +0200 | acidjnk | (~acidjnk@p200300d6e70586358424384a1bd111e9.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2022-08-01 00:27:38 +0200 | haritz | (~hrtz@user/haritz) (Ping timeout: 240 seconds) |
| 2022-08-01 00:27:47 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-08-01 00:30:24 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-08-01 00:34:29 +0200 | MajorBiscuit | (~MajorBisc@86-88-79-148.fixed.kpn.net) (Quit: WeeChat 3.5) |
| 2022-08-01 00:37:04 +0200 | <sm> | (yes, it was 20266) |
| 2022-08-01 00:42:45 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Ping timeout: 252 seconds) |
| 2022-08-01 00:49:43 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-08-01 00:50:33 +0200 | califax | (~califax@user/califx) |
| 2022-08-01 00:51:00 +0200 | <pavonia> | I wasn't aware there are different Integer backends. Looking at the code is quite interesting, e.g. the integerLogBase implementation by repeated squaring is magnitudes faster than the naive version wiith repreated division |
| 2022-08-01 00:51:13 +0200 | <pavonia> | https://hackage.haskell.org/package/integer-gmp-1.0.3.0/docs/src/GHC.Integer.Logarithms.html#integ… |
| 2022-08-01 00:51:42 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 245 seconds) |
| 2022-08-01 00:52:18 +0200 | Jeanne-Kamikaze | (~Jeanne-Ka@142.147.89.203) |
| 2022-08-01 00:52:38 +0200 | <monochrom> | No wonder everyone was saying "bottom-up is faster than top-down" :) |
| 2022-08-01 00:54:43 +0200 | <geekosaur> | not only are there different backends, but the alternate backend changed in 9.2.x |
| 2022-08-01 00:55:10 +0200 | <geekosaur> | (the original was lists of Int and extremely slow; the new one is orders of magnitude faster if not quite as fast as GMP) |
| 2022-08-01 00:55:46 +0200 | <geekosaur> | the intent is that the backend will be runtime selectable in a future ghc version, which is one reason optimization is tricky |
| 2022-08-01 00:55:54 +0200 | <dolio> | GHC definitely knows which Haskell library it's building against, though. |
| 2022-08-01 00:56:25 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-08-01 00:56:43 +0200 | califax | (~califax@user/califx) |
| 2022-08-01 01:04:20 +0200 | noteness | (~noteness@user/noteness) (Remote host closed the connection) |
| 2022-08-01 01:04:37 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 245 seconds) |
| 2022-08-01 01:05:09 +0200 | noteness | (~noteness@user/noteness) |
| 2022-08-01 01:08:38 +0200 | renzhi | (~xp@2607:fa49:6500:b100::47a5) (Ping timeout: 240 seconds) |
| 2022-08-01 01:09:15 +0200 | <geekosaur> | hm, actually the release notes don't mention the new backend. wonder if it got bumped to 9.4 and I missed it? thought the first phase was already active |
| 2022-08-01 01:09:58 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2022-08-01 01:09:58 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2022-08-01 01:09:58 +0200 | haritz | (~hrtz@user/haritz) |
| 2022-08-01 01:12:34 +0200 | <geekosaur> | right, ghc-bignum has been released but current ghc releases don't use it yet, sorry. |
| 2022-08-01 01:12:42 +0200 | <geekosaur> | @hackage ghc-bignum |
| 2022-08-01 01:12:42 +0200 | <lambdabot> | https://hackage.haskell.org/package/ghc-bignum |
| 2022-08-01 01:12:57 +0200 | haritz | (~hrtz@user/haritz) (Remote host closed the connection) |
| 2022-08-01 01:18:24 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-204.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-08-01 01:20:21 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 01:23:15 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 260 seconds) |
| 2022-08-01 01:33:48 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 01:38:29 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2022-08-01 01:44:37 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) |
| 2022-08-01 01:46:22 +0200 | gurkenglas | (~gurkengla@p548ac71b.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-08-01 01:46:52 +0200 | haritzondo | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) |
| 2022-08-01 01:47:11 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) (Client Quit) |
| 2022-08-01 01:50:37 +0200 | haritzondo | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) (Client Quit) |
| 2022-08-01 01:50:50 +0200 | bilegeek | (~bilegeek@2600:1008:b008:7f81:14bd:cb07:613d:3322) |
| 2022-08-01 01:50:56 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2022-08-01 01:50:56 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2022-08-01 01:50:56 +0200 | haritz | (~hrtz@user/haritz) |
| 2022-08-01 01:53:31 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 252 seconds) |
| 2022-08-01 01:53:55 +0200 | cheater | (~Username@user/cheater) |
| 2022-08-01 01:56:41 +0200 | <Axman6> | pavonia: you might also want to look at using Natural as well, if everything is positive - avoids the branches on signs |
| 2022-08-01 02:01:50 +0200 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb2 - https://znc.in) |
| 2022-08-01 02:01:52 +0200 | <pavonia> | Yeah, good point |
| 2022-08-01 02:02:32 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Read error: Connection reset by peer) |
| 2022-08-01 02:02:42 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-08-01 02:03:18 +0200 | <Axman6> | and if you know the numbers will always be larger than an Int, then you could use its underlying BigNat https://hackage.haskell.org/package/integer-gmp-1.0.3.0/docs/GHC-Integer-GMP-Internals.html#t:BigNat |
| 2022-08-01 02:04:38 +0200 | <Axman6> | hmm, perhaps not, there's no Num instance, which is probably sensible |
| 2022-08-01 02:07:05 +0200 | machinedgod | (~machinedg@d172-219-86-154.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2022-08-01 02:08:09 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 02:08:29 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2022-08-01 02:08:29 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2022-08-01 02:08:29 +0200 | haritz | (~hrtz@user/haritz) |
| 2022-08-01 02:14:37 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 245 seconds) |
| 2022-08-01 02:18:50 +0200 | stilgart | (~Christoph@chezlefab.net) (Remote host closed the connection) |
| 2022-08-01 02:24:42 +0200 | <EvanR> | Natural hypothetically is optimized for positive only or that's actually a thing? |
| 2022-08-01 02:26:03 +0200 | <Axman6> | Integer is basically Natural + sign, so every Integer operation needs to branch on sign. it's not a huge cost but if it's unnecessary you might as well avoid it |
| 2022-08-01 02:26:44 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-01 02:26:52 +0200 | Jeanne-Kamikaze | (~Jeanne-Ka@142.147.89.203) (Quit: Leaving) |
| 2022-08-01 02:28:00 +0200 | <hpc> | is that what libgmp does? |
| 2022-08-01 02:28:07 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 02:28:19 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 02:29:39 +0200 | <Axman6> | actually that's a good point, I can't remember what happens when using GHP |
| 2022-08-01 02:29:41 +0200 | <Axman6> | GMP* |
| 2022-08-01 02:30:08 +0200 | <hpc> | hmm, seems to be that's what it does |
| 2022-08-01 02:30:11 +0200 | <hpc> | https://github.com/sethtroisi/libgmp/blob/master/mpz/aors_ui.h |
| 2022-08-01 02:30:37 +0200 | <hpc> | except not quite branching on sign, but (x + y) branches on if x and y are the same sign or different signs |
| 2022-08-01 02:31:16 +0200 | <hpc> | also a bunch of checks for if it has to grow the integer's memory |
| 2022-08-01 02:31:48 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-08-01 02:31:54 +0200 | <Axman6> | I wish we had mutable Integers, the algorithm pavonia is working on could very easily reuse storage |
| 2022-08-01 02:35:42 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2022-08-01 02:39:56 +0200 | <EvanR> | IOInteger, STInteger xD |
| 2022-08-01 02:40:15 +0200 | <EvanR> | LinearInteger |
| 2022-08-01 02:40:21 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2022-08-01 02:41:21 +0200 | <monochrom> | Uh then you will also need LinearNatural... |
| 2022-08-01 02:43:31 +0200 | <hpc> | we need a type system that's like that new state of matter they made last week, with two time dimensions |
| 2022-08-01 02:43:38 +0200 | <hpc> | we can call it euclidean types instead of linear types |
| 2022-08-01 02:44:07 +0200 | <hpc> | useful applications to be determined later :D |
| 2022-08-01 02:44:09 +0200 | <monochrom> | >_< |
| 2022-08-01 02:45:30 +0200 | <hpc> | actually hmm... would that be useful in some way? |
| 2022-08-01 02:45:43 +0200 | <EvanR> | instead of time crystals it'll be type crystals? |
| 2022-08-01 02:47:02 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5) |
| 2022-08-01 02:50:15 +0200 | <pavonia> | Axman6: What algorithm am I working on? :p |
| 2022-08-01 02:58:12 +0200 | <Axman6> | well you were wortking on fermat factorisation |
| 2022-08-01 02:59:19 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) |
| 2022-08-01 03:02:07 +0200 | xff0x | (~xff0x@ap007189.d.east.v6connect.net) (Ping timeout: 245 seconds) |
| 2022-08-01 03:02:42 +0200 | <pavonia> | Ah right, but I moved forward to Lehman's optimization, and now I'm looking at Shank's algorithm |
| 2022-08-01 03:04:04 +0200 | <pavonia> | Also I read through the paper for fast square root finding, but it seems to be a bit to compilcated |
| 2022-08-01 03:05:52 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 245 seconds) |
| 2022-08-01 03:06:00 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-08-01 03:06:20 +0200 | califax | (~califax@user/califx) |
| 2022-08-01 03:06:28 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 03:07:12 +0200 | Batzy_ | (~quassel@user/batzy) |
| 2022-08-01 03:07:37 +0200 | Batzy_ | (~quassel@user/batzy) (Client Quit) |
| 2022-08-01 03:08:08 +0200 | Batzy | (~quassel@user/batzy) |
| 2022-08-01 03:10:52 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 245 seconds) |
| 2022-08-01 03:17:07 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-08-01 03:18:13 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 244 seconds) |
| 2022-08-01 03:24:19 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) |
| 2022-08-01 03:24:25 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) () |
| 2022-08-01 03:30:39 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-08-01 03:31:08 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-01 03:31:46 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-08-01 03:31:54 +0200 | noteness | (~noteness@user/noteness) (Ping timeout: 268 seconds) |
| 2022-08-01 03:32:23 +0200 | noteness | (~noteness@user/noteness) |
| 2022-08-01 03:32:37 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-08-01 03:38:36 +0200 | sandydoo | (~sandydoo@185.209.196.136) (Ping timeout: 268 seconds) |
| 2022-08-01 03:38:48 +0200 | <mon_aaraj> | so I have something like this: ``[ max (show x) (y <> z) | x <- [1..100] | y <- cycle ["","","Fizz"] | z <- cycle ["","","","","Buzz"] ]`` any idea how i'd only specify `cycle` once for both of the lists to cycle? It reminds me of the ``on`` function, but this isn't a zip, this is only a list comprehension |
| 2022-08-01 03:40:34 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-08-01 03:42:47 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 252 seconds) |
| 2022-08-01 03:43:25 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 03:46:19 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) |
| 2022-08-01 03:46:26 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) (Changing host) |
| 2022-08-01 03:46:26 +0200 | Guest3 | (~textual@user/polo) |
| 2022-08-01 03:47:35 +0200 | Guest3 | (~textual@user/polo) (Client Quit) |
| 2022-08-01 03:47:51 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) |
| 2022-08-01 03:50:26 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) (Changing host) |
| 2022-08-01 03:50:26 +0200 | Guest3 | (~textual@user/polo) |
| 2022-08-01 03:50:27 +0200 | Guest3 | Polo |
| 2022-08-01 03:58:08 +0200 | <[Leary]> | mon_aaraj: Looks like a zip to me: (zipWith3 (\x y z -> ...) [1..100] `on` cycle) [...] [...] |
| 2022-08-01 03:58:44 +0200 | <mon_aaraj> | yep, i had that, though it was longer.. this is sort of a golf |
| 2022-08-01 03:59:57 +0200 | <mon_aaraj> | i suppose i just need a readable way to shorten ``\x y z -> max (show x) (y <> z)`` |
| 2022-08-01 04:02:55 +0200 | lemonsni- | (~lemonsnic@cpc159519-perr18-2-0-cust114.19-1.cable.virginm.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-08-01 04:04:44 +0200 | <mon_aaraj> | maybe the `cycle` with the lists empty strings are also long, but i think i might know a way to get it shorter |
| 2022-08-01 04:06:41 +0200 | Dashkal | (~dashkal@user/dashkal) (Ping timeout: 255 seconds) |
| 2022-08-01 04:12:58 +0200 | mokee | (~mokee@37.228.215.83) |
| 2022-08-01 04:20:12 +0200 | lemonsnicks | (~lemonsnic@cpc159519-perr18-2-0-cust114.19-1.cable.virginm.net) |
| 2022-08-01 04:22:43 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-08-01 04:22:43 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-08-01 04:22:43 +0200 | finn_elija | FinnElija |
| 2022-08-01 04:23:32 +0200 | mikoto-chan | (~mikoto-ch@85-76-82-245-nat.elisa-mobile.fi) |
| 2022-08-01 04:25:39 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) (Remote host closed the connection) |
| 2022-08-01 04:28:05 +0200 | <Axman6> | yeah I didn't like it much as a paper, I wanted to see code, I have a feeling a lot of the formulae would actually be straight forward code. I hate it when papers which are definitely software related opt to use only maths - it may be universal but it also usually misses the optimisations in the algorithm |
| 2022-08-01 04:31:35 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-08-01 04:32:38 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 240 seconds) |
| 2022-08-01 04:32:47 +0200 | zebrag | (~chris@user/zebrag) (Read error: Connection reset by peer) |
| 2022-08-01 04:33:02 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-08-01 04:33:12 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 04:33:32 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) |
| 2022-08-01 04:35:27 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Ping timeout: 245 seconds) |
| 2022-08-01 04:37:16 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 268 seconds) |
| 2022-08-01 04:37:32 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 245 seconds) |
| 2022-08-01 04:37:50 +0200 | Polo | (~textual@user/polo) (Quit: Textual IRC Client: www.textualapp.com) |
| 2022-08-01 04:37:50 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) (Ping timeout: 240 seconds) |
| 2022-08-01 04:38:46 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) |
| 2022-08-01 04:39:57 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) |
| 2022-08-01 04:40:19 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) (Changing host) |
| 2022-08-01 04:40:19 +0200 | Guest3 | (~textual@user/polo) |
| 2022-08-01 04:40:25 +0200 | Guest3 | Gambino |
| 2022-08-01 04:40:31 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 04:41:22 +0200 | Gambino | (~textual@user/polo) (Client Quit) |
| 2022-08-01 04:42:32 +0200 | td_ | (~td@94.134.91.252) (Ping timeout: 245 seconds) |
| 2022-08-01 04:42:38 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-08-01 04:42:44 +0200 | machinedgod | (~machinedg@d172-219-86-154.abhsia.telus.net) |
| 2022-08-01 04:44:18 +0200 | td_ | (~td@muedsl-82-207-238-015.citykom.de) |
| 2022-08-01 04:44:43 +0200 | jargon | (~jargon@184.101.188.251) |
| 2022-08-01 04:45:27 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 245 seconds) |
| 2022-08-01 04:48:41 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-08-01 04:53:57 +0200 | Me-me | (~me-me@user/me-me) (Remote host closed the connection) |
| 2022-08-01 04:54:44 +0200 | Me-me | (~me-me@tunnel690570-pt.tunnel.tserv12.mia1.ipv6.he.net) |
| 2022-08-01 04:59:03 +0200 | <onosendi> | "Couldn't match type ‘t0 a0 -> Char -> [Char]" - What's the difference between [Char] and Char? |
| 2022-08-01 04:59:12 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 04:59:18 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 240 seconds) |
| 2022-08-01 05:00:12 +0200 | <mon_aaraj> | ``[Char]`` is a list of ``Char``, ``[Char]`` is just ``String`` |
| 2022-08-01 05:00:50 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 260 seconds) |
| 2022-08-01 05:00:52 +0200 | <mon_aaraj> | huh.. i found this piece of code from 10 years ago: ``[ maybe (show x) id $ [ "fizz" | rem x 3 < 1 ] [ "buzz" | rem x 5 < 1 ] | x <- [1..100] ]``, and it supposedly worked? it uses monad comprehensions.. I can't figure out how to get it to work though |
| 2022-08-01 05:03:42 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-08-01 05:03:56 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-08-01 05:04:23 +0200 | <onosendi> | I just did a fizzbuzz :P |
| 2022-08-01 05:04:46 +0200 | frost | (~frost@user/frost) |
| 2022-08-01 05:05:46 +0200 | <pavonia> | > [ maybe (show x) id $ [ "fizz" | rem x 3 < 1 ] [ "buzz" | rem x 5 < 1 ] | x <- [1..100] ] |
| 2022-08-01 05:05:48 +0200 | <lambdabot> | error: |
| 2022-08-01 05:05:48 +0200 | <lambdabot> | • Couldn't match expected type ‘[[Char]] -> Maybe String’ |
| 2022-08-01 05:05:48 +0200 | <lambdabot> | with actual type ‘[[Char]]’ |
| 2022-08-01 05:05:52 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 245 seconds) |
| 2022-08-01 05:06:36 +0200 | <pavonia> | > [ maybe (show x) id $ listToMaybe [ "fizz" | rem x 3 < 1 ] <> [ "buzz" | rem x 5 < 1 ] | x <- [1..100] ] |
| 2022-08-01 05:06:38 +0200 | <lambdabot> | error: |
| 2022-08-01 05:06:38 +0200 | <lambdabot> | • Couldn't match expected type ‘Maybe [Char]’ |
| 2022-08-01 05:06:38 +0200 | <lambdabot> | with actual type ‘[[Char]]’ |
| 2022-08-01 05:06:49 +0200 | <pavonia> | > [ maybe (show x) id $ listToMaybe $ [ "fizz" | rem x 3 < 1 ] <> [ "buzz" | rem x 5 < 1 ] | x <- [1..100] ] |
| 2022-08-01 05:06:51 +0200 | <lambdabot> | ["1","2","fizz","4","buzz","fizz","7","8","fizz","buzz","11","fizz","13","14... |
| 2022-08-01 05:16:24 +0200 | frost | (~frost@user/frost) (Quit: Client closed) |
| 2022-08-01 05:16:30 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-08-01 05:21:35 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2022-08-01 05:29:50 +0200 | mikoto-chan | (~mikoto-ch@85-76-82-245-nat.elisa-mobile.fi) (Ping timeout: 240 seconds) |
| 2022-08-01 05:30:43 +0200 | mikoto-chan | (~mikoto-ch@85-76-82-245-nat.elisa-mobile.fi) |
| 2022-08-01 05:35:32 +0200 | frost | (~frost@user/frost) |
| 2022-08-01 05:43:47 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) () |
| 2022-08-01 05:50:25 +0200 | lbseale | (~quassel@user/ep1ctetus) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-08-01 05:53:52 +0200 | lechner | (lechner@debian/lechner) (Quit: WeeChat 3.5) |
| 2022-08-01 05:54:47 +0200 | lbseale | (~quassel@user/ep1ctetus) |
| 2022-08-01 05:57:12 +0200 | lbseale | (~quassel@user/ep1ctetus) (Client Quit) |
| 2022-08-01 05:59:11 +0200 | noteness | (~noteness@user/noteness) (Remote host closed the connection) |
| 2022-08-01 05:59:35 +0200 | noteness | (~noteness@user/noteness) |
| 2022-08-01 05:59:47 +0200 | Inst | (~Inst@2601:6c4:4080:3f80:e980:509e:df5:6868) |
| 2022-08-01 06:02:10 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in) |
| 2022-08-01 06:02:30 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-01 06:04:35 +0200 | lbseale | (~quassel@user/ep1ctetus) |
| 2022-08-01 06:07:03 +0200 | noteness | (~noteness@user/noteness) (Remote host closed the connection) |
| 2022-08-01 06:07:28 +0200 | noteness | (~noteness@user/noteness) |
| 2022-08-01 06:10:13 +0200 | lbseale | (~quassel@user/ep1ctetus) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-08-01 06:13:22 +0200 | Dashkal | (~dashkal@user/dashkal) |
| 2022-08-01 06:17:13 +0200 | lbseale | (~quassel@user/ep1ctetus) |
| 2022-08-01 06:19:33 +0200 | machinedgod | (~machinedg@d172-219-86-154.abhsia.telus.net) (Ping timeout: 268 seconds) |
| 2022-08-01 06:20:10 +0200 | Batzy | (~quassel@user/batzy) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-08-01 06:20:27 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 06:20:40 +0200 | Batzy | (~quassel@user/batzy) |
| 2022-08-01 06:24:51 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2022-08-01 06:31:12 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-08-01 06:32:37 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 06:33:47 +0200 | mikoto-chan | (~mikoto-ch@85-76-82-245-nat.elisa-mobile.fi) (Ping timeout: 245 seconds) |
| 2022-08-01 06:33:47 +0200 | lbseale | (~quassel@user/ep1ctetus) (Read error: Connection reset by peer) |
| 2022-08-01 06:35:39 +0200 | lbseale | (~quassel@user/ep1ctetus) |
| 2022-08-01 06:37:07 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 245 seconds) |
| 2022-08-01 06:44:07 +0200 | machinedgod | (~machinedg@d172-219-86-154.abhsia.telus.net) |
| 2022-08-01 06:49:47 +0200 | vglfr | (~vglfr@194.9.14.33) (Read error: Connection reset by peer) |
| 2022-08-01 06:50:23 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 06:51:43 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-08-01 06:53:49 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 06:54:09 +0200 | mbuf | (~Shakthi@122.165.55.71) |
| 2022-08-01 06:54:33 +0200 | vglfr | (~vglfr@194.9.14.33) (Ping timeout: 252 seconds) |
| 2022-08-01 06:54:39 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 06:58:57 +0200 | vglfr | (~vglfr@194.9.14.33) (Ping timeout: 252 seconds) |
| 2022-08-01 06:59:08 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 07:03:25 +0200 | <mon_aaraj> | ah, nice! thank you |
| 2022-08-01 07:05:48 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-08-01 07:07:04 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-08-01 07:10:54 +0200 | notzmv | (~zmv@user/notzmv) |
| 2022-08-01 07:12:31 +0200 | elkcl | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) (Ping timeout: 252 seconds) |
| 2022-08-01 07:13:40 +0200 | elkcl | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) |
| 2022-08-01 07:19:15 +0200 | elkcl_ | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) |
| 2022-08-01 07:21:07 +0200 | elkcl | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) (Ping timeout: 272 seconds) |
| 2022-08-01 07:21:07 +0200 | elkcl_ | elkcl |
| 2022-08-01 07:23:10 +0200 | trillp | (~trillp@69.233.98.238) |
| 2022-08-01 07:24:12 +0200 | <mon_aaraj> | hmm, though it seems to misbehave a bit. is there a way to make it so that without listToMaybe, ``[ "fizz" | rem x 3 < 1 ] <> [ "buzz" | rem x 5 < 1 ]``, would never return a Char? because it seems GHC thinks there's a char here for whatever reason. My guess is because on empty cases, it would return one empty character or some such. |
| 2022-08-01 07:24:48 +0200 | <mon_aaraj> | fwiw, the piece of code i am trying is ``[ max (show x) $ [ "fizz" | rem x 3 < 1 ] <> [ "buzz" | rem x 5 < 1 ] | x <- [1..100] ]`` |
| 2022-08-01 07:29:47 +0200 | acidjnk | (~acidjnk@p200300d6e705867880cba01054dd5d6a.dip0.t-ipconnect.de) |
| 2022-08-01 07:30:05 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2022-08-01 07:31:57 +0200 | machinedgod | (~machinedg@d172-219-86-154.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2022-08-01 07:34:19 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Client Quit) |
| 2022-08-01 07:34:50 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2022-08-01 07:36:06 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 268 seconds) |
| 2022-08-01 07:36:41 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-08-01 07:42:33 +0200 | elkcl_ | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) |
| 2022-08-01 07:43:55 +0200 | elkcl | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) (Ping timeout: 272 seconds) |
| 2022-08-01 07:43:56 +0200 | elkcl_ | elkcl |
| 2022-08-01 07:44:12 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-08-01 07:49:35 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 268 seconds) |
| 2022-08-01 07:50:49 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 268 seconds) |
| 2022-08-01 07:52:16 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-08-01 07:53:05 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-01 07:53:25 +0200 | yin | (~yin@user/zero) |
| 2022-08-01 08:02:45 +0200 | vglfr | (~vglfr@194.9.14.33) (Read error: Connection reset by peer) |
| 2022-08-01 08:02:57 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 08:05:49 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 08:10:02 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 245 seconds) |
| 2022-08-01 08:12:36 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-08-01 08:12:53 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-08-01 08:15:27 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 245 seconds) |
| 2022-08-01 08:16:26 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 08:17:40 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-08-01 08:22:04 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) (Read error: Connection reset by peer) |
| 2022-08-01 08:22:04 +0200 | noteness | (~noteness@user/noteness) (Remote host closed the connection) |
| 2022-08-01 08:22:04 +0200 | califax | (~califax@user/califx) (Read error: Connection reset by peer) |
| 2022-08-01 08:22:04 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-08-01 08:22:04 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-08-01 08:22:04 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Read error: Connection reset by peer) |
| 2022-08-01 08:22:04 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2022-08-01 08:22:25 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-08-01 08:22:45 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-08-01 08:22:51 +0200 | noteness | (~noteness@user/noteness) |
| 2022-08-01 08:22:55 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-08-01 08:22:56 +0200 | califax | (~califax@user/califx) |
| 2022-08-01 08:22:57 +0200 | mokee | (~mokee@37.228.215.83) (Ping timeout: 245 seconds) |
| 2022-08-01 08:23:03 +0200 | gmg | (~user@user/gehmehgeh) (Client Quit) |
| 2022-08-01 08:23:21 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-08-01 08:23:39 +0200 | trillp | (~trillp@69.233.98.238) (Ping timeout: 252 seconds) |
| 2022-08-01 08:23:48 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-08-01 08:24:56 +0200 | mokee | (~mokee@37.228.215.83) |
| 2022-08-01 08:26:29 +0200 | michalz | (~michalz@185.246.204.97) |
| 2022-08-01 08:26:42 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) |
| 2022-08-01 08:32:32 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 245 seconds) |
| 2022-08-01 08:32:48 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-08-01 08:32:51 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:93dd:6a2f:9b9:59b0) |
| 2022-08-01 08:33:46 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-08-01 08:34:07 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-08-01 08:36:27 +0200 | mokee | (~mokee@37.228.215.83) (Ping timeout: 268 seconds) |
| 2022-08-01 08:38:01 +0200 | mokee | (~mokee@37.228.215.83) |
| 2022-08-01 08:38:27 +0200 | Digit | (~user@user/digit) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | nibelungen | (~asturias@2001:19f0:7001:638:5400:3ff:fef3:8725) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | glider | (~glider@user/glider) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | wz1000 | (~zubin@static.11.113.47.78.clients.your-server.de) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | jakalx | (~jakalx@base.jakalx.net) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | acro | (~acro@user/acro) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | nonzen | (~nonzen@user/nonzen) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | _\_ | (~o@user/offon) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | degraafk | (sid71464@id-71464.lymington.irccloud.com) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | glowcoil | (sid3405@id-3405.tinside.irccloud.com) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | edwtjo | (~edwtjo@fsf/member/edwtjo) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | Noinia | (~Frank@77-162-168-71.fixed.kpn.net) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | sooch_ | (sid533113@id-533113.hampstead.irccloud.com) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | xnbya | (~xnbya@2a01:4f8:c17:cbdd::1) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | laman | (~laman@rego.ai) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | dispater | (~dispater@user/brprice) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | siers | (~ij@user/ij) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | Unhammer | (~Unhammer@user/unhammer) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | mvanderhallen[m] | (~mvanderha@2001:470:69fc:105::2:3a88) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | Teacup | (~teacup@user/teacup) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | mrkajetanp | (~mrkajetan@2a01:4b00:ea36:6c00:7994:941c:3f5d:2b88) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | welterde | (welterde@thinkbase.srv.welterde.de) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | Guest585 | (~mike@2406:d501::79ae:5f3e) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | krjst | (~krjst@2604:a880:800:c1::16b:8001) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | nshepperd | (nshepperd@2600:3c03::f03c:92ff:fe28:92c9) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | berberman | (~berberman@user/berberman) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | arkeet | (arkeet@moriya.ca) (*.net *.split) |
| 2022-08-01 08:38:27 +0200 | rodental | (~rodental@38.146.5.222) (Remote host closed the connection) |
| 2022-08-01 08:38:34 +0200 | xnbya | (~xnbya@2a01:4f8:c17:cbdd::1) |
| 2022-08-01 08:38:37 +0200 | arkeet | (arkeet@moriya.ca) |
| 2022-08-01 08:38:38 +0200 | sooch_ | (sid533113@id-533113.hampstead.irccloud.com) |
| 2022-08-01 08:38:38 +0200 | glowcoil | (sid3405@id-3405.tinside.irccloud.com) |
| 2022-08-01 08:38:38 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2022-08-01 08:38:39 +0200 | degraafk | (sid71464@id-71464.lymington.irccloud.com) |
| 2022-08-01 08:38:41 +0200 | Noinia | (~Frank@77-162-168-71.fixed.kpn.net) |
| 2022-08-01 08:38:44 +0200 | Teacup | (~teacup@user/teacup) |
| 2022-08-01 08:38:44 +0200 | wz1000 | (~zubin@static.11.113.47.78.clients.your-server.de) |
| 2022-08-01 08:38:45 +0200 | edwtjo | (~edwtjo@h-109-228-137-133.A213.priv.bahnhof.se) |
| 2022-08-01 08:38:59 +0200 | Unhammer | (~Unhammer@2a01:799:61:c500::237) |
| 2022-08-01 08:38:59 +0200 | nshepperd | (nshepperd@2600:3c03::f03c:92ff:fe28:92c9) |
| 2022-08-01 08:39:01 +0200 | edwtjo | (~edwtjo@h-109-228-137-133.A213.priv.bahnhof.se) (Changing host) |
| 2022-08-01 08:39:01 +0200 | edwtjo | (~edwtjo@fsf/member/edwtjo) |
| 2022-08-01 08:39:02 +0200 | Guest585 | (~mike@2406:d501::79ae:5f3e) |
| 2022-08-01 08:39:07 +0200 | nibelungen | (~asturias@2001:19f0:7001:638:5400:3ff:fef3:8725) |
| 2022-08-01 08:39:07 +0200 | laman | (~laman@rego.ai) |
| 2022-08-01 08:39:10 +0200 | Unhammer | (~Unhammer@2a01:799:61:c500::237) (Signing in (Unhammer)) |
| 2022-08-01 08:39:10 +0200 | Unhammer | (~Unhammer@user/unhammer) |
| 2022-08-01 08:39:11 +0200 | Guest585 | (~mike@2406:d501::79ae:5f3e) (Signing in (Guest585)) |
| 2022-08-01 08:39:11 +0200 | Guest585 | (~mike@user/feetwind) |
| 2022-08-01 08:39:15 +0200 | dispater | (~dispater@user/brprice) |
| 2022-08-01 08:39:21 +0200 | welterde | (welterde@thinkbase.srv.welterde.de) |
| 2022-08-01 08:39:29 +0200 | _\_ | (~o@user/offon) |
| 2022-08-01 08:39:29 +0200 | acro | (~acro@user/acro) |
| 2022-08-01 08:39:30 +0200 | siers | (~ij@user/ij) |
| 2022-08-01 08:39:32 +0200 | mrkajetanp | (~mrkajetan@2a01:4b00:ea36:6c00:7994:941c:3f5d:2b88) |
| 2022-08-01 08:39:32 +0200 | nonzen | (~nonzen@user/nonzen) |
| 2022-08-01 08:39:34 +0200 | berberman | (~berberman@user/berberman) |
| 2022-08-01 08:39:46 +0200 | glider | (~glider@user/glider) |
| 2022-08-01 08:40:31 +0200 | krjst | (~krjst@2604:a880:800:c1::16b:8001) |
| 2022-08-01 08:41:59 +0200 | Digit | (~user@user/digit) |
| 2022-08-01 08:41:59 +0200 | vglfr | (~vglfr@194.9.14.33) (Read error: Connection reset by peer) |
| 2022-08-01 08:42:18 +0200 | acidjnk | (~acidjnk@p200300d6e705867880cba01054dd5d6a.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-08-01 08:42:34 +0200 | nshepperd | (nshepperd@2600:3c03::f03c:92ff:fe28:92c9) (Client Quit) |
| 2022-08-01 08:42:42 +0200 | nshepperd | (nshepperd@2600:3c03::f03c:92ff:fe28:92c9) |
| 2022-08-01 08:43:07 +0200 | mvanderhallen[m] | (~mvanderha@2001:470:69fc:105::2:3a88) |
| 2022-08-01 08:43:34 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 08:47:57 +0200 | vglfr | (~vglfr@194.9.14.33) (Ping timeout: 245 seconds) |
| 2022-08-01 08:48:26 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 08:50:55 +0200 | ccntrq | (~Thunderbi@exit-3.office.han.de.mhd.medondo.com) |
| 2022-08-01 08:50:57 +0200 | goran[m] | (~goranoour@2001:470:69fc:105::2:1b44) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | bjobjo | (~bjobjo@user/bjobjo) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | even4void[m] | (~even4void@2001:470:69fc:105::2:4b9c) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | entheogenesis[m] | (~entheogen@2001:470:69fc:105::1:e7c4) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | Yumemi | (~Yumemi@chamoin.net) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | dragestil | (~znc@user/dragestil) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | hongminhee | (sid295@id-295.tinside.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | megeve | (sid523379@id-523379.hampstead.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | sa1 | (sid7690@id-7690.ilkley.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | scav | (sid309693@user/scav) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | nrr____ | (sid20938@id-20938.lymington.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | jocke-l | (jocke-l@a.x0.is) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | nisstyre | (wes@user/nisstyre) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | liskin | (~liskin@xmonad/liskin) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | eternalforms | (~obsrwr@46.101.168.131) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | df | (~ben@justworks.xyz) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | sphynx | (~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | ysh_ | (sid6017@id-6017.ilkley.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | macabre | (~m@161.35.15.236) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | jamestmartin | (~james@jtmar.me) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | steve[m] | (~stevetrou@2001:470:69fc:105::e0b) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | chessai | (sid225296@id-225296.lymington.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | philpax_ | (sid516926@id-516926.lymington.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | mesaoptimizer | (sid546676@user/PapuaHardyNet) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | dyniec_ | (~dyniec@mail.dybiec.info) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | immae1 | (~immae@2a01:4f8:141:53e7::) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | cjay | (cjay@nerdbox.nerd2nerd.org) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | bw | (sid2730@user/betawaffle) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | agander_m_ | (sid407952@id-407952.tinside.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | Boarders__ | (sid425905@id-425905.lymington.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | kevinsjoberg | (sid499516@id-499516.lymington.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | jmct | (sid160793@id-160793.tinside.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | gonz______ | (sid304396@id-304396.lymington.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:57 +0200 | wallymathieu | (sid533252@id-533252.uxbridge.irccloud.com) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | brprice | (~brprice@user/brprice) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | bah | (~bah@l1.tel) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | xerox | (~edi@user/edi) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | LambdaDuck | (~anka@ksit.fixme.fi) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | Ristovski | (~Ristovski@hellomouse/perf/ristovski) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | davl_ | (~davl@207.154.228.18) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | Hafydd | (~Hafydd@user/hafydd) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | dka_ | (~code-is-a@ns3059207.ip-193-70-33.eu) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | ringo__ | (~ringo@157.230.117.128) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | mht-wtf | (~mht@2a03:b0c0:3:e0::1e2:c001) (*.net *.split) |
| 2022-08-01 08:50:58 +0200 | relrod | (~relrod@redhat/ansible.staff.relrod) (*.net *.split) |
| 2022-08-01 08:51:04 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-08-01 08:51:06 +0200 | jamestmartin | (~james@jtmar.me) |
| 2022-08-01 08:51:06 +0200 | ysh_ | (sid6017@id-6017.ilkley.irccloud.com) |
| 2022-08-01 08:51:07 +0200 | scav | (sid309693@user/scav) |
| 2022-08-01 08:51:07 +0200 | sa1 | (sid7690@id-7690.ilkley.irccloud.com) |
| 2022-08-01 08:51:07 +0200 | LambdaDuck | (~anka@ksit.fixme.fi) |
| 2022-08-01 08:51:09 +0200 | dka | (~code-is-a@ns3059207.ip-193-70-33.eu) |
| 2022-08-01 08:51:10 +0200 | mesaoptimizer | (sid546676@user/PapuaHardyNet) |
| 2022-08-01 08:51:11 +0200 | df | (~ben@justworks.xyz) |
| 2022-08-01 08:51:11 +0200 | hongminhee | (sid295@id-295.tinside.irccloud.com) |
| 2022-08-01 08:51:12 +0200 | sphynx | (~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288) |
| 2022-08-01 08:51:13 +0200 | bah | (~bah@l1.tel) |
| 2022-08-01 08:51:13 +0200 | xerox | (~edi@user/edi) |
| 2022-08-01 08:51:13 +0200 | eternalforms | (~obsrwr@46.101.168.131) |
| 2022-08-01 08:51:13 +0200 | dyniec_ | (~dyniec@mail.dybiec.info) |
| 2022-08-01 08:51:15 +0200 | philpax_ | (sid516926@id-516926.lymington.irccloud.com) |
| 2022-08-01 08:51:21 +0200 | chessai | (sid225296@id-225296.lymington.irccloud.com) |
| 2022-08-01 08:51:23 +0200 | cjay | (cjay@nerdbox.nerd2nerd.org) |
| 2022-08-01 08:51:24 +0200 | jmct | (sid160793@id-160793.tinside.irccloud.com) |
| 2022-08-01 08:51:28 +0200 | liskin | (~liskin@ackle.nomi.cz) |
| 2022-08-01 08:51:28 +0200 | Hafydd | (jc@owlchat.newnet.net) |
| 2022-08-01 08:51:30 +0200 | nrr____ | (sid20938@id-20938.lymington.irccloud.com) |
| 2022-08-01 08:51:30 +0200 | immae1 | (~immae@2a01:4f8:141:53e7::) |
| 2022-08-01 08:51:31 +0200 | nisstyre | (wes@2600:3c00::f03c:91ff:fe69:7f3d) |
| 2022-08-01 08:51:32 +0200 | mht-wtf | (~mht@2a03:b0c0:3:e0::1e2:c001) |
| 2022-08-01 08:51:35 +0200 | jocke-l | (jocke-l@a.x0.is) |
| 2022-08-01 08:51:37 +0200 | relrod | (~relrod@redhat/ansible.staff.relrod) |
| 2022-08-01 08:51:37 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) |
| 2022-08-01 08:51:39 +0200 | macabre | (~m@161.35.15.236) |
| 2022-08-01 08:51:45 +0200 | gonz______ | (sid304396@id-304396.lymington.irccloud.com) |
| 2022-08-01 08:51:49 +0200 | wallymathieu | (sid533252@id-533252.uxbridge.irccloud.com) |
| 2022-08-01 08:51:50 +0200 | kevinsjoberg | (sid499516@id-499516.lymington.irccloud.com) |
| 2022-08-01 08:51:50 +0200 | liskin | (~liskin@ackle.nomi.cz) (Changing host) |
| 2022-08-01 08:51:50 +0200 | liskin | (~liskin@xmonad/liskin) |
| 2022-08-01 08:51:50 +0200 | agander_m_ | (sid407952@id-407952.tinside.irccloud.com) |
| 2022-08-01 08:51:52 +0200 | megeve | (sid523379@id-523379.hampstead.irccloud.com) |
| 2022-08-01 08:51:53 +0200 | Boarders__ | (sid425905@id-425905.lymington.irccloud.com) |
| 2022-08-01 08:52:07 +0200 | bw | (sid2730@user/betawaffle) |
| 2022-08-01 08:52:14 +0200 | brprice | (~brprice@user/brprice) |
| 2022-08-01 08:52:19 +0200 | Ristovski | (~Ristovski@hellomouse/perf/ristovski) |
| 2022-08-01 08:52:27 +0200 | dragestil | (~znc@user/dragestil) |
| 2022-08-01 08:52:28 +0200 | Yumemi | (~Yumemi@chamoin.net) |
| 2022-08-01 08:52:29 +0200 | davl | (~davl@207.154.228.18) |
| 2022-08-01 08:52:42 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-08-01 08:52:47 +0200 | ringo__ | (~ringo@157.230.117.128) |
| 2022-08-01 08:52:59 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2022-08-01 08:54:09 +0200 | steve[m] | (~stevetrou@2001:470:69fc:105::e0b) |
| 2022-08-01 08:54:28 +0200 | entheogenesis[m] | (~entheogen@2001:470:69fc:105::1:e7c4) |
| 2022-08-01 08:54:53 +0200 | even4void[m] | (~even4void@2001:470:69fc:105::2:4b9c) |
| 2022-08-01 08:54:55 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 08:55:35 +0200 | goran[m] | (~goranoour@2001:470:69fc:105::2:1b44) |
| 2022-08-01 08:56:12 +0200 | bjobjo | (~bjobjo@user/bjobjo) |
| 2022-08-01 09:00:29 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-01 09:02:37 +0200 | coot | (~coot@213.134.190.95) |
| 2022-08-01 09:06:57 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 244 seconds) |
| 2022-08-01 09:09:56 +0200 | chele | (~chele@user/chele) |
| 2022-08-01 09:16:03 +0200 | gurkenglas | (~gurkengla@p548ac71b.dip0.t-ipconnect.de) |
| 2022-08-01 09:16:05 +0200 | cosimone | (~user@93-44-186-171.ip98.fastwebnet.it) (Ping timeout: 252 seconds) |
| 2022-08-01 09:18:33 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-08-01 09:20:27 +0200 | lagash | (lagash@2605:6400:20:b4:9c76:1538:3398:ce71) (Quit: ZNC - https://znc.in) |
| 2022-08-01 09:20:27 +0200 | yin | (~yin@user/zero) (Ping timeout: 245 seconds) |
| 2022-08-01 09:20:39 +0200 | lagash | (lagash@lagash.shelltalk.net) |
| 2022-08-01 09:27:03 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-01 09:27:48 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-01 09:37:14 +0200 | mikoto-chan | (~mikoto-ch@85-76-82-245-nat.elisa-mobile.fi) |
| 2022-08-01 09:48:01 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 09:48:52 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-01 09:52:01 +0200 | benin0 | (~benin@183.82.177.174) |
| 2022-08-01 09:55:52 +0200 | machined1od | (~machinedg@d172-219-86-154.abhsia.telus.net) |
| 2022-08-01 09:56:23 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-08-01 09:59:09 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-01 10:01:03 +0200 | yin | (~yin@user/zero) |
| 2022-08-01 10:02:14 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-08-01 10:03:28 +0200 | GoldsteinQ | (~goldstein@goldstein.rs) (Ping timeout: 268 seconds) |
| 2022-08-01 10:05:27 +0200 | mikoto-chan | (~mikoto-ch@85-76-82-245-nat.elisa-mobile.fi) (Ping timeout: 245 seconds) |
| 2022-08-01 10:20:36 +0200 | mncheck | (~mncheck@193.224.205.254) |
| 2022-08-01 10:23:09 +0200 | zxx7529 | (~Thunderbi@user/zxx7529) |
| 2022-08-01 10:27:49 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 10:29:50 +0200 | eod|fserucas | (~eod|fseru@83.223.235.72) |
| 2022-08-01 10:30:00 +0200 | eod|fserucas | (~eod|fseru@83.223.235.72) (Client Quit) |
| 2022-08-01 10:30:19 +0200 | fserucas | (~fserucas@83.223.235.72) |
| 2022-08-01 10:32:28 +0200 | cosimone | (~user@93-44-186-171.ip98.fastwebnet.it) |
| 2022-08-01 10:32:57 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 245 seconds) |
| 2022-08-01 10:35:24 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-08-01 10:37:24 +0200 | yvan-sraka | (~yvan-srak@209.red-2-139-126.dynamicip.rima-tde.net) |
| 2022-08-01 10:37:58 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-08-01 10:38:02 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2022-08-01 10:39:40 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-08-01 10:39:54 +0200 | __monty__ | (~toonn@user/toonn) |
| 2022-08-01 10:40:46 +0200 | cyphase | cyphase_eviltwin |
| 2022-08-01 10:47:59 +0200 | vglfr | (~vglfr@194.9.14.33) (Read error: Connection reset by peer) |
| 2022-08-01 10:49:37 +0200 | __monty__ | (~toonn@user/toonn) (Ping timeout: 245 seconds) |
| 2022-08-01 10:49:52 +0200 | __monty__ | (~toonn@user/toonn) |
| 2022-08-01 10:50:13 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-08-01 10:50:22 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
| 2022-08-01 10:55:27 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 245 seconds) |
| 2022-08-01 10:56:36 +0200 | MajorBiscuit | (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) |
| 2022-08-01 10:57:55 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-08-01 10:58:07 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-08-01 11:01:51 +0200 | yvan-sraka | (~yvan-srak@209.red-2-139-126.dynamicip.rima-tde.net) (Remote host closed the connection) |
| 2022-08-01 11:03:54 +0200 | yvan-sraka | (~yvan-srak@209.red-2-139-126.dynamicip.rima-tde.net) |
| 2022-08-01 11:05:39 +0200 | sandydoo | (~sandydoo@185.209.196.136) |
| 2022-08-01 11:05:46 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 268 seconds) |
| 2022-08-01 11:06:08 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-08-01 11:07:34 +0200 | acidjnk | (~acidjnk@p200300d6e70586787d91d659871fc0c4.dip0.t-ipconnect.de) |
| 2022-08-01 11:07:55 +0200 | Colere | (~colere@about/linux/staff/sauvin) (Ping timeout: 252 seconds) |
| 2022-08-01 11:08:42 +0200 | Colere | (~colere@about/linux/staff/sauvin) |
| 2022-08-01 11:11:05 +0200 | Furor | (~colere@about/linux/staff/sauvin) |
| 2022-08-01 11:11:29 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-08-01 11:14:28 +0200 | Colere | (~colere@about/linux/staff/sauvin) (Ping timeout: 268 seconds) |
| 2022-08-01 11:14:53 +0200 | ridcully_ | (~ridcully@p508ac7ad.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-08-01 11:16:14 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 240 seconds) |
| 2022-08-01 11:16:37 +0200 | mikoto-chan | (~mikoto-ch@85-76-82-245-nat.elisa-mobile.fi) |
| 2022-08-01 11:17:05 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-01 11:17:50 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 11:17:51 +0200 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-08-01 11:19:13 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 11:20:11 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2022-08-01 11:21:48 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 268 seconds) |
| 2022-08-01 11:22:19 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-08-01 11:22:19 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-01 11:22:33 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-08-01 11:23:20 +0200 | Furor | Colere |
| 2022-08-01 11:24:40 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-08-01 11:25:01 +0200 | ridcully | (~ridcully@p57b5218b.dip0.t-ipconnect.de) |
| 2022-08-01 11:26:59 +0200 | jargon | (~jargon@184.101.188.251) (Remote host closed the connection) |
| 2022-08-01 11:27:17 +0200 | jargon | (~jargon@184.101.188.251) |
| 2022-08-01 11:29:45 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 11:33:31 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 268 seconds) |
| 2022-08-01 11:35:14 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-08-01 11:37:35 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 11:39:40 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-08-01 11:43:22 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-08-01 11:52:05 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2022-08-01 11:55:12 +0200 | mncheck | (~mncheck@193.224.205.254) (Remote host closed the connection) |
| 2022-08-01 11:57:24 +0200 | bilegeek | (~bilegeek@2600:1008:b008:7f81:14bd:cb07:613d:3322) (Quit: Leaving) |
| 2022-08-01 11:58:35 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 12:02:38 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-08-01 12:09:37 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 245 seconds) |
| 2022-08-01 12:10:41 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-08-01 12:11:43 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 252 seconds) |
| 2022-08-01 12:25:10 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-08-01 12:26:32 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-08-01 12:28:14 +0200 | vglfr | (~vglfr@194.9.14.33) (Ping timeout: 240 seconds) |
| 2022-08-01 12:28:54 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 12:32:32 +0200 | yvan-sraka | (~yvan-srak@209.red-2-139-126.dynamicip.rima-tde.net) (Remote host closed the connection) |
| 2022-08-01 12:35:15 +0200 | mikoto-chan | (~mikoto-ch@85-76-82-245-nat.elisa-mobile.fi) (Ping timeout: 268 seconds) |
| 2022-08-01 12:38:37 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-08-01 12:40:05 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-01 12:40:16 +0200 | tcard | (~tcard@p945242-ipngn9701hodogaya.kanagawa.ocn.ne.jp) (Remote host closed the connection) |
| 2022-08-01 12:40:31 +0200 | tcard | (~tcard@p945242-ipngn9701hodogaya.kanagawa.ocn.ne.jp) |
| 2022-08-01 12:43:30 +0200 | yaroot_ | (~yaroot@p3374048-ipngn8502souka.saitama.ocn.ne.jp) |
| 2022-08-01 12:43:41 +0200 | mikoto-chan | (~mikoto-ch@85-76-82-245-nat.elisa-mobile.fi) |
| 2022-08-01 12:44:07 +0200 | yaroot | (~yaroot@2409:12:ac0:2300:680e:dbff:fe1e:4953) (Ping timeout: 272 seconds) |
| 2022-08-01 12:44:07 +0200 | yaroot_ | yaroot |
| 2022-08-01 12:48:37 +0200 | stilgart | (~Christoph@chezlefab.net) |
| 2022-08-01 12:51:36 +0200 | CiaoSen | (~Jura@p200300c9570ffb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-08-01 12:51:50 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-08-01 12:52:13 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 12:52:57 +0200 | mikoto-chan | (~mikoto-ch@85-76-82-245-nat.elisa-mobile.fi) (Ping timeout: 245 seconds) |
| 2022-08-01 12:54:06 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-08-01 12:54:47 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Write error: Connection reset by peer) |
| 2022-08-01 12:54:47 +0200 | noteness | (~noteness@user/noteness) (Write error: Connection reset by peer) |
| 2022-08-01 12:54:47 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) (Write error: Connection reset by peer) |
| 2022-08-01 12:54:47 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Write error: Connection reset by peer) |
| 2022-08-01 12:54:47 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-08-01 12:55:21 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-08-01 12:55:26 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-08-01 12:55:45 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-08-01 12:56:05 +0200 | noteness | (~noteness@user/noteness) |
| 2022-08-01 12:57:29 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-08-01 12:58:58 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-08-01 13:05:56 +0200 | xff0x | (~xff0x@2405:6580:b080:900:66f:76f7:bef0:7fa2) |
| 2022-08-01 13:16:15 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-08-01 13:20:55 +0200 | mncheck | (~mncheck@193.224.205.254) |
| 2022-08-01 13:29:19 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2022-08-01 13:33:22 +0200 | yin | (~yin@user/zero) (Ping timeout: 245 seconds) |
| 2022-08-01 13:38:07 +0200 | rembo10 | (~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-08-01 13:40:32 +0200 | rembo10 | (~rembo10@main.remulis.com) |
| 2022-08-01 13:41:39 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-01 13:42:57 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-204.elisa-laajakaista.fi) |
| 2022-08-01 13:43:04 +0200 | causal | (~user@50.35.83.177) (Quit: WeeChat 3.6) |
| 2022-08-01 13:43:23 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-01 13:46:36 +0200 | mncheckm | (~mncheck@193.224.205.254) |
| 2022-08-01 13:49:02 +0200 | mncheck | (~mncheck@193.224.205.254) (Ping timeout: 240 seconds) |
| 2022-08-01 13:52:26 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) |
| 2022-08-01 13:52:44 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) (Remote host closed the connection) |
| 2022-08-01 13:53:59 +0200 | <perrierjouet> | stack install pandoc ... no setup information found |
| 2022-08-01 13:54:25 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 272 seconds) |
| 2022-08-01 13:55:16 +0200 | kaskal- | (~kaskal@213-225-33-152.nat.highway.a1.net) (Ping timeout: 268 seconds) |
| 2022-08-01 13:56:18 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-01 13:56:56 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-08-01 13:59:06 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-08-01 14:00:31 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 14:05:13 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) |
| 2022-08-01 14:05:17 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 268 seconds) |
| 2022-08-01 14:07:26 +0200 | acidjnk | (~acidjnk@p200300d6e70586787d91d659871fc0c4.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-08-01 14:07:38 +0200 | acidjnk | (~acidjnk@p200300d6e70586787c323b0967d8caa3.dip0.t-ipconnect.de) |
| 2022-08-01 14:08:16 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2022-08-01 14:08:58 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 14:11:11 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) (Quit: ZNC - https://znc.in) |
| 2022-08-01 14:13:15 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-08-01 14:14:37 +0200 | vglfr | (~vglfr@194.9.14.33) (Ping timeout: 245 seconds) |
| 2022-08-01 14:15:02 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 14:15:53 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) |
| 2022-08-01 14:18:20 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) (Client Quit) |
| 2022-08-01 14:19:49 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) |
| 2022-08-01 14:25:06 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-01 14:27:50 +0200 | <chreekat> | mon_aaraj: the Char is from the Strings `"fizz"` and `"buzz"` :) |
| 2022-08-01 14:30:24 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-08-01 14:33:26 +0200 | lbseale | (~quassel@user/ep1ctetus) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-08-01 14:34:24 +0200 | <mon_aaraj> | huh, how come? i mean, in all cases they should always return strings |
| 2022-08-01 14:34:33 +0200 | <mon_aaraj> | it's a moand comprehension after all |
| 2022-08-01 14:34:58 +0200 | <mon_aaraj> | wait... i think i might understand... the `[]` is the monad, so GHC infers `Char` to be the actual type, is that the case |
| 2022-08-01 14:36:03 +0200 | coot | (~coot@213.134.190.95) |
| 2022-08-01 14:39:40 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-08-01 14:42:54 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 268 seconds) |
| 2022-08-01 14:44:44 +0200 | <mon_aaraj> | Well, Identity functor, here we go! |
| 2022-08-01 14:45:51 +0200 | <geekosaur> | that code is very confused |
| 2022-08-01 14:46:15 +0200 | <mon_aaraj> | i agree! the resources that exist on monad comprehensions are about non-existent |
| 2022-08-01 14:46:43 +0200 | <merijn> | mon_aaraj: Have you checked the GHC User Guide on them? |
| 2022-08-01 14:46:43 +0200 | Vajb | (~Vajb@n1zigc3rgo9mpde2w-1.v6.elisa-mobile.fi) (Read error: Connection reset by peer) |
| 2022-08-01 14:46:51 +0200 | <mon_aaraj> | yep, i have |
| 2022-08-01 14:47:12 +0200 | <mon_aaraj> | it's really the only maybe-kind-of decent resource i can find |
| 2022-08-01 14:47:21 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3ad-40.dhcp.inet.fi) |
| 2022-08-01 14:48:08 +0200 | jpds1 | jpds |
| 2022-08-01 14:48:08 +0200 | tdkilus^ | (~tdkilus@c-73-237-117-119.hsd1.ga.comcast.net) |
| 2022-08-01 14:49:11 +0200 | ggVGc | does not really know anything about monad comprehensions at all |
| 2022-08-01 14:49:31 +0200 | <merijn> | ggVGc: List comprehensions, but for monads other than list :p |
| 2022-08-01 14:49:56 +0200 | <ggVGc> | oh, well, that makes sense I guess |
| 2022-08-01 14:50:14 +0200 | <ggVGc> | I really don't use list comprehensions as much as I probably should |
| 2022-08-01 14:50:15 +0200 | <ggVGc> | not sure why |
| 2022-08-01 14:50:28 +0200 | <mon_aaraj> | yeah, they used to exist 10 years ago but then were removed for weird reasons then added back, which is generally why all the resources you can find are probably outdated by now |
| 2022-08-01 14:51:13 +0200 | <ggVGc> | I also want to get into using applicative and ApplicativeDo more |
| 2022-08-01 14:51:18 +0200 | <ggVGc> | but old habits die hard |
| 2022-08-01 14:51:20 +0200 | <mon_aaraj> | one other thing i know people would be surprised: TransformListComp exists! it really surprised me when i first saw it |
| 2022-08-01 14:51:56 +0200 | <merijn> | ggVGc: tbh, in practice most people rarely use list comprehensions |
| 2022-08-01 14:52:05 +0200 | <merijn> | function composition usually composes better |
| 2022-08-01 14:52:18 +0200 | <ggVGc> | yeah I guess that's why I mostly don't end up using it |
| 2022-08-01 14:52:30 +0200 | <ggVGc> | also, I generally have the attitude, in any language, to just use as few things as possible |
| 2022-08-01 14:52:36 +0200 | <ggVGc> | and Haskell has... too many things |
| 2022-08-01 14:55:59 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2022-08-01 14:56:09 +0200 | <mon_aaraj> | yeah, using as few things may be the most productive way to do things. i like to do things the best way possible, and that generally causes me to hurt my productivity a lot |
| 2022-08-01 14:57:04 +0200 | <mon_aaraj> | i think, after toying with list comprehensions via ParallelListComp, TransformListComp, MonadComprehensions... I can safely say I prefer ``zipWith`` over list comprehensions whenever possible :P |
| 2022-08-01 14:57:12 +0200 | <chreekat> | mon_aaraj: I don't think you are using monad comprehensions. It's just a list there |
| 2022-08-01 14:57:31 +0200 | <mon_aaraj> | ``[ "fizz" | rem x 3 < 1 ]`` |
| 2022-08-01 14:57:49 +0200 | <mon_aaraj> | GHC itself thinks (rightfully so) I am using monad comprehensions in these cases |
| 2022-08-01 14:58:12 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-08-01 14:58:28 +0200 | <chreekat> | hm ok I was looking at the examples with `... x <- [1..100] ]` |
| 2022-08-01 14:58:32 +0200 | <mon_aaraj> | though I don't really know any good replacements for monad comprehensions that are short-hand and simple other than good ole do notation, and also Idris 2's bang notation |
| 2022-08-01 14:59:05 +0200 | Guest3 | (~textual@user/polo) |
| 2022-08-01 14:59:15 +0200 | <mon_aaraj> | which I suppose isn't a replacement for monad comprehensions, it's just a very short and readable way to get a value from inside a monad which makes things shorter and easier to read |
| 2022-08-01 15:01:09 +0200 | Guest3 | Polo |
| 2022-08-01 15:02:23 +0200 | <chreekat> | what value are you expected from `["fizz" | rem x 3 < 1]` ? |
| 2022-08-01 15:02:29 +0200 | <chreekat> | *expecting |
| 2022-08-01 15:06:25 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-01 15:07:16 +0200 | <geekosaur> | @undo ["fizz" | rem x 3 < 1] |
| 2022-08-01 15:07:16 +0200 | <lambdabot> | if rem x 3 < 1 then ["fizz"] else [] |
| 2022-08-01 15:09:05 +0200 | frost | (~frost@user/frost) (Quit: Client closed) |
| 2022-08-01 15:09:33 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2022-08-01 15:10:03 +0200 | <mon_aaraj> | chreekat: i honestly don't know myself. the way it was used in the wild 10 years ago was ``[ max (show x) $ [ "fizz" | rem x 3 < 1 ] [ "buzz" | rem x 5 < 1 ] | x <- [1..100] ]``, which didn't make sense to me |
| 2022-08-01 15:10:41 +0200 | <mon_aaraj> | fwiw, here's the exact comment: https://www.codefugue.com/fizzbuzz-in-haskell/#comment-1381730105 |
| 2022-08-01 15:10:54 +0200 | <ggVGc> | that's pretty confusing to me (["fizz" | rem x 3 < 1]) |
| 2022-08-01 15:10:59 +0200 | <ggVGc> | the expanded form is much clearer |
| 2022-08-01 15:11:06 +0200 | <ggVGc> | and I'd probably disagree with the former in a core review |
| 2022-08-01 15:11:10 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) |
| 2022-08-01 15:11:11 +0200 | <ggVGc> | code* |
| 2022-08-01 15:11:31 +0200 | Polo | (~textual@user/polo) (Quit: Textual IRC Client: www.textualapp.com) |
| 2022-08-01 15:11:46 +0200 | <ggVGc> | it adds a lot of mental overhead for barely any syntactical gain |
| 2022-08-01 15:11:57 +0200 | <mon_aaraj> | i really like how ``["fizz" | rem x 2 == 0 ]`` reads, personally, and also how it functions because it kind of resembles sending events |
| 2022-08-01 15:12:07 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 245 seconds) |
| 2022-08-01 15:13:14 +0200 | <ggVGc> | well, is the "I think it reads nicely" worth it relative the overhead it adds, in the context of working with others, project growing in complexity, ageing, being taken over by someone else etc. |
| 2022-08-01 15:13:33 +0200 | <naso> | using `Debug.trace x` we can print a message immediately before x was evaluated. is there somehow we can also get a message immediately AFTER x is evaluated? |
| 2022-08-01 15:13:33 +0200 | <ggVGc> | or "myself at 4am doing a quickfix" |
| 2022-08-01 15:13:51 +0200 | <naso> | that should be ... `Debug.trace "msg" x` |
| 2022-08-01 15:14:13 +0200 | <ggVGc> | naso: for this reason I usually use these, https://gist.github.com/e127758549621bbe189211c9500eafde |
| 2022-08-01 15:15:27 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 245 seconds) |
| 2022-08-01 15:15:43 +0200 | <ggVGc> | ah, wait, I misunderstood |
| 2022-08-01 15:15:44 +0200 | <ggVGc> | sorry :( |
| 2022-08-01 15:16:14 +0200 | <ggVGc> | or...maybe not, not sure what you meant I think |
| 2022-08-01 15:17:02 +0200 | <ggVGc> | debug = flip trace allows: (some expression) `debug` "Title:" |
| 2022-08-01 15:17:12 +0200 | <naso> | not sure i understand what tracef does |
| 2022-08-01 15:17:26 +0200 | <ggVGc> | it allows a transformation before tracing |
| 2022-08-01 15:17:28 +0200 | <mon_aaraj> | ggVGc: I think for this case, it very much is worth it for everything you were talking about... if it's a case that fits nicely for monad comprehensions, monad comprehensions are readable enough and easy to understand and maintain, that i think it's overall a plus. but that's just my opinion and the FP people I'm usually around with |
| 2022-08-01 15:19:20 +0200 | <ggVGc> | naso: sometimes I'm not interested in the actual Show instance of the thing I am printing (or it doesn't have one). So I then use debugf like something `debugf` ("Some property", \something -> show (property something)) |
| 2022-08-01 15:19:40 +0200 | <naso> | ggVGc: maybe it helps if i explain why i want this. often there is an exception in my program but i dont know where it is, so i use a Debug.trace. If I see the trace message i confirm that the exception occurs later in the evaluation, but i dont know how much later. In particularm if I do `Debug.trace msg x` I don't know if it was x that caused the exception. If I could also have a message immediately after evaluting x, i could get im |
| 2022-08-01 15:19:40 +0200 | <naso> | mediate feedback if x is the problem |
| 2022-08-01 15:19:43 +0200 | <ggVGc> | in a case where "something" might not have a show instance, but I want to trace the value of "property" |
| 2022-08-01 15:20:20 +0200 | <geekosaur> | naso, sounds to me like you want -prof and +RTS -xc |
| 2022-08-01 15:20:23 +0200 | <ggVGc> | naso: sounds like you need to trace the thing that uses the result then, rather than the value itself |
| 2022-08-01 15:20:48 +0200 | <naso> | ggVGc: this is the actual function i use to trace https://paste.tomsmeding.com/c1t0IOBG |
| 2022-08-01 15:20:55 +0200 | <ggVGc> | print debugging Haskell is... intersting, compared to other languages |
| 2022-08-01 15:21:40 +0200 | <merijn> | naso: FYI, you can get stack traces from exceptions :p |
| 2022-08-01 15:21:55 +0200 | <ggVGc> | also, yeah, maybe try to get rid of the code that produces exceptions also :) |
| 2022-08-01 15:22:09 +0200 | <ggVGc> | And use HasCallstack to get stack traces from functions that crash |
| 2022-08-01 15:22:21 +0200 | <ggVGc> | HasCallstack has made my haskell experience a lot better |
| 2022-08-01 15:22:31 +0200 | <naso> | any good guides to learn about this? |
| 2022-08-01 15:22:33 +0200 | <mon_aaraj> | oh, ``debugf`` is interesting. i always had the problem of not wanting to implement show instance because they'd be useless or are frusturating to create (in the context of Trees That Grow), so I wondered if there was something to inspect types without having the show instance |
| 2022-08-01 15:22:52 +0200 | <ggVGc> | naso: maybe read through this, https://maksbotan.github.io/posts/2021-01-20-callstacks.html |
| 2022-08-01 15:22:57 +0200 | <merijn> | naso: See geekosaur's comments. A profile binary with +RTS -xc will log callstacks to stderr |
| 2022-08-01 15:23:06 +0200 | <naso> | mon_aaraj: anythingToString is good for that too |
| 2022-08-01 15:23:08 +0200 | <merijn> | naso: The GHC User's Guide has a bunch of info |
| 2022-08-01 15:23:25 +0200 | <mon_aaraj> | that's the first time i've heard about anythingToString |
| 2022-08-01 15:23:57 +0200 | <ggVGc> | mon_aaraj: yeah it's a simple little helper :) It basically allows for defining local Show implementations for logging things |
| 2022-08-01 15:24:00 +0200 | <naso> | merijn: geekosaur: thanks i was aware of that but it requires a recompile right? i usually go for that when i can't solve the problem quickly with tracing |
| 2022-08-01 15:24:35 +0200 | <geekosaur> | with exceptions what you really want is a backtrace of the exception itself. it'd be nice if that didn't require a profiling executable, but… |
| 2022-08-01 15:24:41 +0200 | <ggVGc> | merijn: HasCallstack is a much more pleasant experience than doing the profiling dance, imo |
| 2022-08-01 15:25:04 +0200 | <merijn> | ggVGc: Only works if you can change the code throwing the exception |
| 2022-08-01 15:25:13 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-08-01 15:25:17 +0200 | <merijn> | if the exception is thrown in some library that doesn't use HasCallstack, it doesn't work |
| 2022-08-01 15:25:20 +0200 | <ggVGc> | sure, but most of the time we can, for use-cases like this, I think? |
| 2022-08-01 15:25:27 +0200 | <ggVGc> | At leat that's the case for me |
| 2022-08-01 15:25:31 +0200 | <ggVGc> | but I don't work in industry :) |
| 2022-08-01 15:25:38 +0200 | <ggVGc> | ah, right, that's true |
| 2022-08-01 15:25:47 +0200 | <ggVGc> | well, don't use libraries that throw. Simple. |
| 2022-08-01 15:26:48 +0200 | <mon_aaraj> | i don't know how to find where anythingToString is defined, it isn't in hoogle |
| 2022-08-01 15:26:52 +0200 | <geekosaur> | like base? |
| 2022-08-01 15:27:07 +0200 | <ggVGc> | yeah, don't use base |
| 2022-08-01 15:27:09 +0200 | <ggVGc> | who needs it |
| 2022-08-01 15:27:31 +0200 | <naso> | mon_aaraj: https://hackage.haskell.org/package/recover-rtti |
| 2022-08-01 15:28:28 +0200 | kuribas | (~user@ptr-17d51eouctrvjmo29s7.18120a2.ip6.access.telenet.be) |
| 2022-08-01 15:28:38 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2022-08-01 15:28:55 +0200 | <mon_aaraj> | would've been nice if that was in base |
| 2022-08-01 15:29:43 +0200 | <ggVGc> | naso: Imo this is the issue with logging in haskell through Debug.Trace. We get logs backwards, since the last thing you'll see is what was last evaluated, not what triggered the evaluation of that thing. Which is not what we're used to from other platforms. Hence the proper way is to do logging through a monad I reckon |
| 2022-08-01 15:30:56 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 268 seconds) |
| 2022-08-01 15:32:24 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 15:32:41 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-08-01 15:33:33 +0200 | <naso> | it would be nice if the breakpoint functionality was integrated into HLS somehow |
| 2022-08-01 15:34:06 +0200 | <naso> | i don;t want to have to change my type signatures for debugging |
| 2022-08-01 15:36:40 +0200 | dualnygma_ | (~dualnygma@2601:152:100:b460:1bb6:449a:fb92:4b09) |
| 2022-08-01 15:38:48 +0200 | <ggVGc> | I've never used a breakpoint in haskell |
| 2022-08-01 15:39:39 +0200 | <ggVGc> | actually, the only times I've ever used them is ages ago when doing game development in C++ and wanting to inspect memory at certain times (since memory corruption is a real risk always looming :) ) |
| 2022-08-01 15:39:51 +0200 | <ggVGc> | when do you use breakpoints during haskell development? |
| 2022-08-01 15:40:59 +0200 | <naso> | i've never actually used it, i just recently read about it (https://downloads.haskell.org/~ghc/7.4.1/docs/html/users_guide/ghci-debugger.html) and it sounds potentially useful but kind of clunky using it from the repl |
| 2022-08-01 15:41:57 +0200 | <ggVGc> | If you're referring to HasCallstack, I don't use it as a temporary thing when debugging. Rather, whever a crash pops up in my program, I add a chain of HasCallstack that lets me get enough information from where the crash originated, or try to remove the thing that caused it in the first place. This is prefixed by habitually adding a HasCallstack to any function which uses `error` or some other |
| 2022-08-01 15:41:59 +0200 | <ggVGc> | non-total function (like fromJust for example) |
| 2022-08-01 15:43:49 +0200 | <naso> | ggVGc: i was referring to the logging through the monad. The HasCallStack looks helpful, thanks. So if I add that constraint to every function that uses `error` that should be helpful? |
| 2022-08-01 15:44:23 +0200 | ystael | (~ystael@user/ystael) |
| 2022-08-01 15:45:23 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-08-01 15:49:37 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-08-01 15:49:54 +0200 | mikail | (~mikail@2a02:c7f:bc47:8c00:5aa7:b193:11e3:d108) (Remote host closed the connection) |
| 2022-08-01 15:52:12 +0200 | <naso> | but in the guide you linked, we also need HasCallStack on the function `bar` which doesnt itself ues error (it calls `foo` that uses `error`). Is there anywhere where it is bad to put `HasCallStack`? if not why is it not on by default |
| 2022-08-01 15:52:32 +0200 | sandydoo | (~sandydoo@185.209.196.136) (Ping timeout: 245 seconds) |
| 2022-08-01 15:52:59 +0200 | <geekosaur> | it causes overhead |
| 2022-08-01 15:53:12 +0200 | zxx7529 | (~Thunderbi@user/zxx7529) (Ping timeout: 268 seconds) |
| 2022-08-01 15:53:48 +0200 | <naso> | compilation time? performance? |
| 2022-08-01 15:53:50 +0200 | hasbae | hippoid |
| 2022-08-01 15:53:54 +0200 | <merijn> | naso: performance overhead |
| 2022-08-01 15:55:07 +0200 | <naso> | in that case, it would be nice if there was a compilation flag to globall switch on/off HasCallStack for everything ? |
| 2022-08-01 15:55:17 +0200 | <ggVGc> | yeah, but as long as the program runs well enough for the use-case I personally can live with that |
| 2022-08-01 15:55:40 +0200 | <naso> | because performance is important to me, i need an easy way to switch it off... |
| 2022-08-01 15:56:14 +0200 | acidjnk | (~acidjnk@p200300d6e70586787c323b0967d8caa3.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-08-01 15:56:14 +0200 | <ggVGc> | naso: what I do is I put it on the level where I know there'a a risk of a crash, and if it happens I add it to where it was called from (as far up as I deem necessary). The good thing is you'll always know one step, so you can easily decide how far you want to go |
| 2022-08-01 15:56:21 +0200 | <ggVGc> | this all relies on being able to reproduce the issue though |
| 2022-08-01 15:56:43 +0200 | <ggVGc> | but the upside is that eventuelly your codebase will be structured so that when issues happen in the wild you get decent traces |
| 2022-08-01 15:57:15 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-08-01 15:58:17 +0200 | <ggVGc> | naso: performance is important to everyone, but there's a tradeoff to be made between wanting good error traces without needing to recompile and re-run, and faster runtime |
| 2022-08-01 15:58:20 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-08-01 15:58:33 +0200 | <ggVGc> | the latter can be measured and then decided if it's acceptable or not |
| 2022-08-01 15:58:38 +0200 | CiaoSen | (~Jura@p200300c9570ffb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-08-01 15:58:50 +0200 | <ggVGc> | for my use-cases HasCallstack has not added any noticable overhead |
| 2022-08-01 15:59:12 +0200 | zxx7529 | (~Thunderbi@user/zxx7529) |
| 2022-08-01 16:00:06 +0200 | <ggVGc> | meanwhile I've gained something I always wanted from haskell, e.g the ability to actually use non-total functions where I really think they should be safe, and having an informative trace when my expection breaks |
| 2022-08-01 16:01:06 +0200 | <naso> | ggVGc: cool, sounds like good advice thanks. i'll experiment with it. yes in what i'm doing i have partial functions all over the place |
| 2022-08-01 16:01:45 +0200 | <[exa]> | ggVGc: I think you can alias HasCallStack for a trivial constraint to switch off the performance overhead (like #ifdef DEBUG in Cs) |
| 2022-08-01 16:01:58 +0200 | <geekosaur> | there isn't a ghc issue to decorate all functions but there's one to decorate all partial functions |
| 2022-08-01 16:02:27 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 16:04:21 +0200 | <naso> | https://gitlab.haskell.org/ghc/ghc/-/issues/13360 |
| 2022-08-01 16:05:04 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-08-01 16:05:04 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-01 16:05:33 +0200 | <naso> | "Thanks for sharing the benchmarks. They seem to be reporting a 50-250% slowdown with HasCallstack. My hunch is that the slowdown is linear wrt the depth of the call-stack. Will need to do some benchmarking to be sure of this." |
| 2022-08-01 16:05:38 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-01 16:06:38 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-08-01 16:06:53 +0200 | zxx7529 | (~Thunderbi@user/zxx7529) (Quit: zxx7529) |
| 2022-08-01 16:07:05 +0200 | dualnygma_ | (~dualnygma@2601:152:100:b460:1bb6:449a:fb92:4b09) (Ping timeout: 255 seconds) |
| 2022-08-01 16:07:40 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-08-01 16:08:50 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-08-01 16:12:31 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 16:12:33 +0200 | <geekosaur> | read on |
| 2022-08-01 16:12:38 +0200 | <merijn> | naso: That flag exists, it's called --profile ;) |
| 2022-08-01 16:13:12 +0200 | <merijn> | naso: basically, the profiling infrastructure needs callstacks for profiling purposes, which is why you can always get stack traces for profiled executables |
| 2022-08-01 16:13:50 +0200 | <geekosaur> | there's a difference, profiling has a pretty high overhead, HasCallStack a fairly low one when not triggered |
| 2022-08-01 16:14:24 +0200 | <geekosaur> | also HasCallStack doesn't force you to compile every other module with it also |
| 2022-08-01 16:14:47 +0200 | <geekosaur> | whereas you can't mix profiled and non-profiled ways |
| 2022-08-01 16:16:34 +0200 | sandydoo | (~sandydoo@185.209.196.136) |
| 2022-08-01 16:18:06 +0200 | <merijn> | geekosaur: Sure, but his original question was "I wanna enable HasCallStack everywhere with a flag" |
| 2022-08-01 16:19:43 +0200 | <naso> | merijn: when i compile with the profiling flag, like this: `cabal run --enable-profiling project-exe --ghc-options="-fprof-auto -rtsopts -O2 -optc-O3" -- +RTS -xc` , it recompiles all my dependencie and takes like half an hour. |
| 2022-08-01 16:20:28 +0200 | <naso> | (is this the correct command by the way? i've made notes of several different commands like this but not 100% sure about it all) |
| 2022-08-01 16:22:26 +0200 | <geekosaur[m]> | -optc-O3 does nothing |
| 2022-08-01 16:23:10 +0200 | <geekosaur[m]> | ghc hasn't compiled via C in almost a decade |
| 2022-08-01 16:23:43 +0200 | <geekosaur[m]> | Also profiling mostly disables optimization |
| 2022-08-01 16:23:57 +0200 | <merijn> | naso: Yeah, I normally compile without -O2 for profiling |
| 2022-08-01 16:24:23 +0200 | <merijn> | I generally just do "cabal build --enable-profiling" and run the result, but that cabal run should work too |
| 2022-08-01 16:24:36 +0200 | <merijn> | naso: It should only recompile your dependencies the first time, though |
| 2022-08-01 16:24:48 +0200 | <naso> | geekosaur[m]: thanks, must have got that from an out of date guide |
| 2022-08-01 16:24:51 +0200 | <merijn> | naso: After that they're already available |
| 2022-08-01 16:24:59 +0200 | <naso> | ok |
| 2022-08-01 16:25:36 +0200 | <merijn> | naso: If you don't normally build with profiling enabled you only install unprofiled dependencies, so the first time you build with profiling it has to compile the profiled versions too, but that should only happen once (unless your dependencies change, obv) |
| 2022-08-01 16:26:02 +0200 | <naso> | merijn: ahh i see |
| 2022-08-01 16:26:15 +0200 | GoldsteinQ | (~goldstein@goldstein.rs) |
| 2022-08-01 16:27:00 +0200 | <merijn> | After that it should only recompile your own code for profiling |
| 2022-08-01 16:27:47 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-08-01 16:28:07 +0200 | dualnygma_ | (~dualnygma@2601:152:100:b460:9acb:38e3:4e54:496f) |
| 2022-08-01 16:29:51 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-01 16:30:19 +0200 | <ggVGc> | naso: the thing is, it's not really a direct comparison. HasCallstack and profile builds give different things. Debugging issues by recompiling and rerunning allows you to avoid the overhead of HasCallstack, but it makes it harder to debug issues that are difficult to reproduce (like ones from users that are not yourself). On the other hand HasCallstack gives the long-term benefit of giving good |
| 2022-08-01 16:30:21 +0200 | <ggVGc> | information on the first occurance, with the cost of some overhead. I really think that "overhead" is not something that should be avoided at all costs, in any environment, and I think it's a mistake many developers make. The fact is that the vast majority of functionality in the vast majority of software doesn't need to be that fast |
| 2022-08-01 16:30:44 +0200 | <ggVGc> | and the parts that need to be fast can be found through profiling and handled on a case-by-case basis |
| 2022-08-01 16:31:08 +0200 | <ggVGc> | In the end we're using a garbage collected language so there's already tradeoffs being made |
| 2022-08-01 16:31:56 +0200 | <ggVGc> | or using type classes which might result in dynamic dispatch rather than doing things manually with a lot more code |
| 2022-08-01 16:32:00 +0200 | <ggVGc> | etc. |
| 2022-08-01 16:32:01 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 16:32:03 +0200 | tdkilus^ | (~tdkilus@c-73-237-117-119.hsd1.ga.comcast.net) (Ping timeout: 268 seconds) |
| 2022-08-01 16:32:17 +0200 | <naso> | ggVGc: agreed |
| 2022-08-01 16:33:22 +0200 | dualnygma_ | (~dualnygma@2601:152:100:b460:9acb:38e3:4e54:496f) (Ping timeout: 244 seconds) |
| 2022-08-01 16:34:44 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-08-01 16:34:44 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Read error: Connection reset by peer) |
| 2022-08-01 16:36:04 +0200 | tubogram44 | (~tubogram@user/tubogram) (Ping timeout: 240 seconds) |
| 2022-08-01 16:36:41 +0200 | tubogram44 | (~tubogram@user/tubogram) |
| 2022-08-01 16:37:11 +0200 | acidjnk | (~acidjnk@p200300d6e70586786c92b9403fbc0a82.dip0.t-ipconnect.de) |
| 2022-08-01 16:37:42 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) (Quit: ZNC - https://znc.in) |
| 2022-08-01 16:39:09 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-08-01 16:41:24 +0200 | CiaoSen | (~Jura@p200300c9570ffb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-08-01 16:43:27 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) |
| 2022-08-01 16:44:50 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-08-01 16:46:08 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-08-01 16:47:17 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-08-01 16:48:00 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 16:48:37 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-08-01 16:49:02 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-08-01 16:51:26 +0200 | acidjnk | (~acidjnk@p200300d6e70586786c92b9403fbc0a82.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-08-01 16:52:32 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 245 seconds) |
| 2022-08-01 16:59:19 +0200 | ccntrq | (~Thunderbi@exit-3.office.han.de.mhd.medondo.com) (Quit: ccntrq) |
| 2022-08-01 17:03:13 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-08-01 17:04:04 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-08-01 17:04:22 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-08-01 17:05:58 +0200 | kuribas | (~user@ptr-17d51eouctrvjmo29s7.18120a2.ip6.access.telenet.be) (Ping timeout: 268 seconds) |
| 2022-08-01 17:07:00 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:93dd:6a2f:9b9:59b0) (Quit: WeeChat 2.8) |
| 2022-08-01 17:07:07 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 245 seconds) |
| 2022-08-01 17:07:35 +0200 | <albet70> | how can I config parameter for Main.hs in my-project.cabal? |
| 2022-08-01 17:07:59 +0200 | <albet70> | just in main-is : Main.hs parameter? |
| 2022-08-01 17:09:12 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-01 17:10:45 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-08-01 17:10:46 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-08-01 17:11:19 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-08-01 17:11:19 +0200 | <merijn> | albet70: Not quite sure what you mean? |
| 2022-08-01 17:12:22 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) (Quit: ZNC - https://znc.in) |
| 2022-08-01 17:12:44 +0200 | yin | (~yin@user/zero) |
| 2022-08-01 17:13:00 +0200 | albet70_ | (~user@114.250.139.224) |
| 2022-08-01 17:14:10 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) (Remote host closed the connection) |
| 2022-08-01 17:14:52 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) |
| 2022-08-01 17:14:57 +0200 | <geekosaur> | you can't specify parameters in the cabal file; the whole point of parameters is they're specifies by the user. are you sure you don't want a parameter parser that supports defaults? |
| 2022-08-01 17:15:16 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) |
| 2022-08-01 17:15:18 +0200 | <geekosaur> | cmdargs and optparse-applicative come to mins |
| 2022-08-01 17:15:41 +0200 | <geekosaur> | *specified |
| 2022-08-01 17:16:09 +0200 | sandy_doo | (~sandydoo@185.209.196.136) |
| 2022-08-01 17:17:15 +0200 | <albet70_> | yes, I found it out I can use `cabal v2-run my-project parameter` to do it |
| 2022-08-01 17:17:32 +0200 | yin | (~yin@user/zero) (Ping timeout: 245 seconds) |
| 2022-08-01 17:17:57 +0200 | <merijn> | You can just run instead of v2-run (and if you can't, your using a cabal-install that's too old :p) |
| 2022-08-01 17:18:04 +0200 | <geekosaur> | you may need to watch out for parameters with leading dashes, which will be eaten by cabal. cabal v2-run -- my-project --whatever |
| 2022-08-01 17:18:14 +0200 | <geekosaur> | (the -- is important in that case) |
| 2022-08-01 17:18:18 +0200 | sandydoo | (~sandydoo@185.209.196.136) (Ping timeout: 268 seconds) |
| 2022-08-01 17:19:31 +0200 | <albet70_> | geekosaur what -- does there? |
| 2022-08-01 17:20:08 +0200 | <albet70_> | merijn: cabal v3's command usage are same as v2? |
| 2022-08-01 17:20:26 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 17:20:27 +0200 | sandy_doo | (~sandydoo@185.209.196.136) (Ping timeout: 245 seconds) |
| 2022-08-01 17:20:30 +0200 | <geekosaur> | it tells cabal (or stack) to stop reading parameters starting with - for itself, so they go to your program |
| 2022-08-01 17:20:33 +0200 | <geekosaur> | as I just said |
| 2022-08-01 17:21:00 +0200 | <geekosaur> | cabal v3 defaults to the v2-commands, you have to use v1-… to get the old commands |
| 2022-08-01 17:22:01 +0200 | <geekosaur> | so in cabal v3 `cabal run` is the same as `cabal v2-run`, whereas in cabal 2 `cabal run` is the same as `cabal v1-run` |
| 2022-08-01 17:25:26 +0200 | <albet70_> | there're `my-code arg1 arg2` and `my-code --arg1 value1 --arg2 value2` two ways to pass parameter to code, cabal can do the second way with --? |
| 2022-08-01 17:25:35 +0200 | <albet70_> | sorry, my English is not good |
| 2022-08-01 17:25:50 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-08-01 17:26:00 +0200 | <merijn> | albet70_: v2 isn't about cabal versions, it's about the UI version (which only has 2) |
| 2022-08-01 17:26:20 +0200 | <geekosaur> | albet70_, yes |
| 2022-08-01 17:26:36 +0200 | <albet70_> | merijn: cabal is a cmd line tool IIRC, since when it had a UI? |
| 2022-08-01 17:26:50 +0200 | <c_wraith> | text is still a user interface |
| 2022-08-01 17:26:53 +0200 | <geekosaur> | without the `--` cabal will consume all options of the form `--*` itself, you need the bare `--` to tell it to stop |
| 2022-08-01 17:26:57 +0200 | <yushyin> | cli is a UserInterface |
| 2022-08-01 17:27:13 +0200 | <albet70_> | c_wraith: is that called TUI nowdays? |
| 2022-08-01 17:27:29 +0200 | <albet70_> | nowaday |
| 2022-08-01 17:28:17 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-08-01 17:28:19 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) (Remote host closed the connection) |
| 2022-08-01 17:28:37 +0200 | <geekosaur> | often, yes |
| 2022-08-01 17:28:47 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-08-01 17:28:50 +0200 | <yushyin> | strange how the v2- stuff confuses people rather than helps ^^ |
| 2022-08-01 17:28:50 +0200 | <geekosaur> | but even so you can have more than one TUI. |
| 2022-08-01 17:29:23 +0200 | <geekosaur> | not that strange, text user interfaces are rather limited in that area |
| 2022-08-01 17:29:27 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) |
| 2022-08-01 17:30:38 +0200 | <geekosaur> | tbh I think I'd have just made all the undecorated commands errors and forced users to say v1- xxx or v2- xxx |
| 2022-08-01 17:31:21 +0200 | <geekosaur> | clearer that way, instead of switching what xxx means. (people still follow cabal v1 instructions from a decade ago and get confused when using it with cabal 3.x) |
| 2022-08-01 17:32:32 +0200 | jespada | (~jespada@45.162.228.187) (Read error: Connection reset by peer) |
| 2022-08-01 17:32:45 +0200 | jespada_ | (~jespada@45.162.228.187) |
| 2022-08-01 17:33:38 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 17:34:20 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) (Ping timeout: 268 seconds) |
| 2022-08-01 17:34:27 +0200 | phma | (~phma@host-67-44-208-130.hnremote.net) (Read error: Connection reset by peer) |
| 2022-08-01 17:35:17 +0200 | motherfsck | (~motherfsc@user/motherfsck) |
| 2022-08-01 17:36:12 +0200 | phma | (phma@2001:5b0:212a:9df8:d7c:fd9f:422b:bc91) |
| 2022-08-01 17:36:48 +0200 | benin0 | (~benin@183.82.177.174) (Quit: The Lounge - https://thelounge.chat) |
| 2022-08-01 17:37:07 +0200 | <yushyin> | i don't have a problem with non-versioned commands, but for tutorials or instructions, perhaps the versioned commands should be used? but what is the plan? are the v1- to be removed at some point? because then it almost doesn't matter whether you are faced with the problem that at some point there is no longer a v1- or that the commands no longer do what they are supposed to do. and instructions |
| 2022-08-01 17:37:09 +0200 | <yushyin> | and tutorials on the internet become obsolete/outdated at some point anyway |
| 2022-08-01 17:38:06 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-08-01 17:38:27 +0200 | <geekosaur> | supposedly they'll be gone in cabal 4.x |
| 2022-08-01 17:39:20 +0200 | <geekosaur> | they want to make sure that all use cases for the v1 commands are covered by v2 commands |
| 2022-08-01 17:39:29 +0200 | <sm> | cabal doesn't have enough leadership to make good UI decisions |
| 2022-08-01 17:40:34 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-01 17:40:52 +0200 | <albet70_> | lack of users? |
| 2022-08-01 17:41:23 +0200 | <sm> | no, it has a ton of users |
| 2022-08-01 17:41:43 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Quit: _) |
| 2022-08-01 17:41:56 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-08-01 17:42:31 +0200 | acidjnk | (~acidjnk@p200300d6e70586786c92b9403fbc0a82.dip0.t-ipconnect.de) |
| 2022-08-01 17:44:31 +0200 | sonologico | (~raphael@dhcp-077-251-118-129.chello.nl) |
| 2022-08-01 17:45:36 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 17:46:51 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 252 seconds) |
| 2022-08-01 17:47:28 +0200 | yin | (~yin@user/zero) |
| 2022-08-01 17:48:34 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) (Quit: ZNC - https://znc.in) |
| 2022-08-01 17:49:03 +0200 | <sclv> | i think its more just that switching underlying behavior seamlessly is a hard thing, and there are a lot of options and opinions and also its technically fiddly |
| 2022-08-01 17:49:25 +0200 | <sclv> | especially when there's a large established user base |
| 2022-08-01 17:50:09 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) |
| 2022-08-01 17:50:56 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-08-01 17:51:13 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) |
| 2022-08-01 17:52:39 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) (Remote host closed the connection) |
| 2022-08-01 17:53:46 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) |
| 2022-08-01 17:54:15 +0200 | <sm> | yes, and pushing through all that is almost impossible unless there's a someone or a group of people with the mandate/power/will to make impactful UI decisions |
| 2022-08-01 17:54:19 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) (Client Quit) |
| 2022-08-01 17:55:39 +0200 | <sm> | it needs a bit of ruthlessness |
| 2022-08-01 17:55:46 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) |
| 2022-08-01 17:56:11 +0200 | haritz | (~hrtz@user/haritz) (Read error: Connection reset by peer) |
| 2022-08-01 17:56:28 +0200 | <sm> | along with deep expertise and insight and taste. Not so easy |
| 2022-08-01 17:56:58 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 17:59:36 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-08-01 18:01:11 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-01 18:01:21 +0200 | <sm> | as you're saying, it's not at all just a matter of UI; many UI difficulties are a manifestation of structural/architectural difficulties, whether in cabal or Cabal or ghc or ... |
| 2022-08-01 18:01:31 +0200 | <sclv> | i mean its almost certain that if another set of decisions had been made people would have been unhappy with that set too. there's no way to change stuff without people feeling frustrated about the process of the change, and about having to learn new things |
| 2022-08-01 18:02:15 +0200 | <yushyin> | ^ |
| 2022-08-01 18:02:19 +0200 | <sm> | this is why some people like stack, it made a big contribution here |
| 2022-08-01 18:02:36 +0200 | <sclv> | the main issue that is underattended in UI is a good workflow for cabal env files imho. the ball was dropped there. but less so with the versioning deprecation story which is pretty well worked out and sorted through, tho not necessarily the same plan others would have picked. |
| 2022-08-01 18:03:10 +0200 | zxx7529 | (~Thunderbi@user/zxx7529) |
| 2022-08-01 18:04:20 +0200 | <sm> | that's right, we will complain about any change. Ideally good changes get made anyway.. and before long most of complainers realise they are good and we all move on |
| 2022-08-01 18:04:38 +0200 | michalz | (~michalz@185.246.204.97) (Ping timeout: 240 seconds) |
| 2022-08-01 18:04:55 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 18:05:02 +0200 | sonologico | (~raphael@dhcp-077-251-118-129.chello.nl) (Ping timeout: 240 seconds) |
| 2022-08-01 18:05:52 +0200 | michalz | (~michalz@185.246.204.75) |
| 2022-08-01 18:05:54 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) (Quit: ZNC - https://znc.in) |
| 2022-08-01 18:06:24 +0200 | <[itchyjunk]> | Hi, wanted to make sure i understand why my code works here : https://bpa.st/CNRA |
| 2022-08-01 18:06:26 +0200 | <sm> | backwards compatibility is generally good, but there needs to be a strategy and plan for evolution and cleanup |
| 2022-08-01 18:07:02 +0200 | <sm> | (not saying cabal devs didn't have those, I'm sure they did.. executing them successfully is a whole nother kettle of worms) |
| 2022-08-01 18:07:11 +0200 | <[itchyjunk]> | for `addList [1..5] [5..10]`, its going 1:2:3:4, then it hits the addList [] yes case. |
| 2022-08-01 18:07:41 +0200 | <[itchyjunk]> | and ys is 5:6:7:8:9:10:[] |
| 2022-08-01 18:07:43 +0200 | kaskal | (~kaskal@213-225-33-152.nat.highway.a1.net) |
| 2022-08-01 18:07:44 +0200 | <[itchyjunk]> | oops i forgot a 5 |
| 2022-08-01 18:07:50 +0200 | <[itchyjunk]> | but that's basically why this works right? |
| 2022-08-01 18:08:20 +0200 | sonologico | (~raphael@dhcp-077-251-118-129.chello.nl) |
| 2022-08-01 18:08:47 +0200 | <[itchyjunk]> | i.e i end up with `1:2:3:4:5:5:6:7:8:9:10:[]` |
| 2022-08-01 18:08:47 +0200 | <sclv> | i mean there is literally an executed plan for evolution and cleanup of v1 to v2 to onwards |
| 2022-08-01 18:09:12 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-08-01 18:09:24 +0200 | <geekosaur> | [itchyjunk], yes |
| 2022-08-01 18:09:55 +0200 | <[itchyjunk]> | nice! |
| 2022-08-01 18:10:06 +0200 | CiaoSen | (~Jura@p200300c9570ffb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-08-01 18:10:38 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-08-01 18:10:50 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-08-01 18:15:19 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-08-01 18:16:20 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-08-01 18:16:44 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-08-01 18:16:47 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!) |
| 2022-08-01 18:17:48 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-08-01 18:20:32 +0200 | nisstyre | (wes@2600:3c00::f03c:91ff:fe69:7f3d) (Changing host) |
| 2022-08-01 18:20:32 +0200 | nisstyre | (wes@user/nisstyre) |
| 2022-08-01 18:20:35 +0200 | MajorBiscuit | (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) (Ping timeout: 268 seconds) |
| 2022-08-01 18:22:26 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-01 18:23:26 +0200 | sonologico | (~raphael@dhcp-077-251-118-129.chello.nl) (Ping timeout: 240 seconds) |
| 2022-08-01 18:26:39 +0200 | naso | (~naso@193-116-244-197.tpgi.com.au) () |
| 2022-08-01 18:27:18 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-01 18:27:46 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 18:28:44 +0200 | sonologico | (~raphael@dhcp-077-251-118-129.chello.nl) |
| 2022-08-01 18:31:50 +0200 | yin | (~yin@user/zero) (Ping timeout: 240 seconds) |
| 2022-08-01 18:32:07 +0200 | <hippoid> | is there a guide for using lambdabot? I want to import a module into it like import Text.ParserCombinators.Parsec and then do :t many |
| 2022-08-01 18:33:01 +0200 | <[exa]> | hippoid: you might have better luck with yahb, that behaves pretty much as a normal ghci |
| 2022-08-01 18:33:05 +0200 | <geekosaur> | that's generally best done in local ghci |
| 2022-08-01 18:33:11 +0200 | <[exa]> | +1 ^ |
| 2022-08-01 18:33:55 +0200 | <geekosaur> | this reminds me though that I still haven't PRed my updated help docs |
| 2022-08-01 18:34:09 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2022-08-01 18:34:46 +0200 | <hippoid> | ok, when I do 'import Text.ParserCombinators.Parsec; :t many' I get many :: Text.Parsec.Prim.ParsecT s u m a -> Text.Parsec.Prim.ParsecT s u m [a] |
| 2022-08-01 18:35:13 +0200 | <geekosaur> | you'd get the same from lambdabot, why would you expect otherwise? |
| 2022-08-01 18:35:29 +0200 | albet70_ | (~user@114.250.139.224) (Remote host closed the connection) |
| 2022-08-01 18:35:42 +0200 | albet70_ | (~user@114.250.139.224) |
| 2022-08-01 18:35:46 +0200 | <hippoid> | well I didn't get that with lambdabot. I got something about Alternative |
| 2022-08-01 18:36:08 +0200 | <geekosaur> | without parsec imported, yes, you'd get the Alternative version of `many` |
| 2022-08-01 18:36:10 +0200 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) (Ping timeout: 240 seconds) |
| 2022-08-01 18:36:22 +0200 | <hippoid> | but my question is about the type Text.Parsec.Prim.ParsecT. What's the long . separated type name? |
| 2022-08-01 18:36:29 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2022-08-01 18:36:29 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2022-08-01 18:36:29 +0200 | haritz | (~hrtz@user/haritz) |
| 2022-08-01 18:36:29 +0200 | <geekosaur> | parsec provides an optimized version |
| 2022-08-01 18:36:59 +0200 | <geekosaur> | you probably want the haddocks |
| 2022-08-01 18:37:05 +0200 | <geekosaur> | @haddock ParsecT |
| 2022-08-01 18:37:05 +0200 | <lambdabot> | Unknown command, try @list |
| 2022-08-01 18:37:14 +0200 | <geekosaur> | @hoogle ParsecT |
| 2022-08-01 18:37:14 +0200 | <lambdabot> | Text.Parsec data ParsecT s u m a |
| 2022-08-01 18:37:14 +0200 | <lambdabot> | Text.Parsec.Prim data ParsecT s u m a |
| 2022-08-01 18:37:14 +0200 | <lambdabot> | Text.Megaparsec data ParsecT e s m a |
| 2022-08-01 18:37:18 +0200 | <geekosaur> | derp |
| 2022-08-01 18:37:26 +0200 | <geekosaur> | hoogle.haskell.org |
| 2022-08-01 18:37:28 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-08-01 18:37:50 +0200 | sonologico | (~raphael@dhcp-077-251-118-129.chello.nl) (Ping timeout: 240 seconds) |
| 2022-08-01 18:38:00 +0200 | <hippoid> | import Text.ParserCombinators.Parsec |
| 2022-08-01 18:38:05 +0200 | <hippoid> | :t many |
| 2022-08-01 18:38:07 +0200 | <lambdabot> | Alternative f => f a -> f [a] |
| 2022-08-01 18:38:29 +0200 | <geekosaur> | @let import Text.ParserCombinators.Parsec |
| 2022-08-01 18:38:30 +0200 | <lambdabot> | /sandbox/tmp/.L.hs:142:1: error: |
| 2022-08-01 18:38:30 +0200 | <lambdabot> | Text.ParserCombinators.Parsec: Can't be safely imported! |
| 2022-08-01 18:38:30 +0200 | <lambdabot> | The package (parsec-3.1.14.0) the module resides in isn't trusted. |
| 2022-08-01 18:38:37 +0200 | <geekosaur> | ah, well |
| 2022-08-01 18:38:41 +0200 | <hippoid> | lol |
| 2022-08-01 18:38:48 +0200 | <geekosaur> | % import Text.ParserCombinators.Parsec |
| 2022-08-01 18:38:48 +0200 | <yahb2> | <no output> |
| 2022-08-01 18:38:53 +0200 | <geekosaur> | % :t many |
| 2022-08-01 18:38:53 +0200 | <yahb2> | many ; :: Text.Parsec.Prim.ParsecT s u m a ; -> Text.Parsec.Prim.ParsecT s u m [a] |
| 2022-08-01 18:39:48 +0200 | <ggVGc> | is anyone here working professionally with Haskell, and in that case, what auto-formatter do you use? |
| 2022-08-01 18:39:49 +0200 | <geekosaur> | anyway, parsec internally carries around a state, a user defined value you can use for anything you need, and an underlying monad (which is usually but not always IO) |
| 2022-08-01 18:40:00 +0200 | <hippoid> | how should I understand Text.Parsec.Prim.ParsecT. like why is it such a long period delimited type name? |
| 2022-08-01 18:40:03 +0200 | <ggVGc> | My impression is that ormolu is trying to be the industry standard, but not sure what the reality is |
| 2022-08-01 18:40:11 +0200 | <geekosaur> | because that module isn't imported |
| 2022-08-01 18:40:20 +0200 | <geekosaur> | % import Text.Parsec.Prim |
| 2022-08-01 18:40:20 +0200 | <yahb2> | <no output> |
| 2022-08-01 18:40:25 +0200 | <geekosaur> | :t many |
| 2022-08-01 18:40:26 +0200 | <lambdabot> | Alternative f => f a -> f [a] |
| 2022-08-01 18:40:41 +0200 | <geekosaur> | hm |
| 2022-08-01 18:41:18 +0200 | <geekosaur> | % import Text.ParserCombinators.Parsec |
| 2022-08-01 18:41:18 +0200 | <yahb2> | <no output> |
| 2022-08-01 18:41:21 +0200 | <geekosaur> | :t many |
| 2022-08-01 18:41:22 +0200 | <lambdabot> | Alternative f => f a -> f [a] |
| 2022-08-01 18:41:30 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-01 18:41:33 +0200 | <hippoid> | oh. so we imported the module Text.ParserCombinators.Parsec, which imported many, but not all the types that many is comprised of? |
| 2022-08-01 18:41:51 +0200 | <geekosaur> | yes, so it fully qualifies the missing types |
| 2022-08-01 18:41:56 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-08-01 18:41:57 +0200 | <geekosaur> | in ghci (but not ghc) that works |
| 2022-08-01 18:42:11 +0200 | <hippoid> | wild |
| 2022-08-01 18:42:24 +0200 | <hippoid> | thanks for clarifying |
| 2022-08-01 18:45:03 +0200 | <geekosaur> | (also the name "Text.ParserCombinators.Parsec" has been deprecated for a long time; it's just "Text.Parsec" these days_ |
| 2022-08-01 18:45:05 +0200 | <geekosaur> | ) |
| 2022-08-01 18:45:58 +0200 | <geekosaur> | that was the hierarchy parsec v1 used. nobody likes typing such a long name, so parsec v2 and later dropped the "ParserCombinators" part |
| 2022-08-01 18:46:28 +0200 | fserucas | (~fserucas@83.223.235.72) (Quit: Leaving) |
| 2022-08-01 18:46:41 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-01 18:47:25 +0200 | albet70_ | tmp_away |
| 2022-08-01 18:48:07 +0200 | <pavonia> | Is there a way to do something like `_ | even i && (Just j <- foo) -> ...` in one case alternative? |
| 2022-08-01 18:48:25 +0200 | tmp_away | (~user@114.250.139.224) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2022-08-01 18:48:48 +0200 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) |
| 2022-08-01 18:50:56 +0200 | mbuf | (~Shakthi@122.165.55.71) (Quit: Leaving) |
| 2022-08-01 18:51:26 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-08-01 18:52:07 +0200 | <dolio> | `even i, Just j <- foo` |
| 2022-08-01 18:52:39 +0200 | jespada_ | (~jespada@45.162.228.187) (Ping timeout: 268 seconds) |
| 2022-08-01 18:52:39 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 18:52:54 +0200 | <dolio> | You can mix boolean and pattern guards, comma separated. |
| 2022-08-01 18:53:11 +0200 | <dolio> | It's equivalent to the conjunction of them. |
| 2022-08-01 18:53:32 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-08-01 18:53:47 +0200 | <pavonia> | Excellent, thanks |
| 2022-08-01 18:54:38 +0200 | machined1od | (~machinedg@d172-219-86-154.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2022-08-01 18:56:17 +0200 | jespada | (~jespada@45.162.228.190) |
| 2022-08-01 18:58:56 +0200 | tmp_away | (~user@114.250.139.224) |
| 2022-08-01 18:59:31 +0200 | <tmp_away> | how to turn a char to text char? |
| 2022-08-01 18:59:48 +0200 | <tmp_away> | like "\123" to a text char |
| 2022-08-01 19:00:08 +0200 | <[exa]> | the "\123" is a String? |
| 2022-08-01 19:00:39 +0200 | <geekosaur> | do you mean you want the actual display character, or a value of type Text? |
| 2022-08-01 19:00:50 +0200 | zxx7529 | (~Thunderbi@user/zxx7529) (Quit: zxx7529) |
| 2022-08-01 19:01:07 +0200 | <hippoid> | who does the T at the end of ParsecT signal? |
| 2022-08-01 19:01:15 +0200 | <geekosaur> | "transformer" |
| 2022-08-01 19:01:17 +0200 | lagash | (lagash@lagash.shelltalk.net) (Ping timeout: 255 seconds) |
| 2022-08-01 19:01:24 +0200 | <hippoid> | monad transformer? |
| 2022-08-01 19:01:34 +0200 | <geekosaur> | it means the "m" in the type is another monad, which ParsecT transforms into a parser |
| 2022-08-01 19:01:39 +0200 | <geekosaur> | yes |
| 2022-08-01 19:01:47 +0200 | <tmp_away> | for example, there is text "\123 whatever msg", now I want to filter that "\123" |
| 2022-08-01 19:02:03 +0200 | <tmp_away> | remove it |
| 2022-08-01 19:03:01 +0200 | <geekosaur> | > filter (/= '\123') "\123 whatever msg" |
| 2022-08-01 19:03:03 +0200 | <lambdabot> | " whatever msg" |
| 2022-08-01 19:03:22 +0200 | <tmp_away> | [exa]: a string is [Char], what Text is? |
| 2022-08-01 19:03:24 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 19:03:31 +0200 | <tmp_away> | [Text-Char]? |
| 2022-08-01 19:03:50 +0200 | <merijn> | tmp_away: Text is Text |
| 2022-08-01 19:03:50 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Ping timeout: 240 seconds) |
| 2022-08-01 19:04:24 +0200 | <tmp_away> | merijn: 'a' is a Text, "ab" is a Text? |
| 2022-08-01 19:04:58 +0200 | <merijn> | tmp_away: Neither of those are Text |
| 2022-08-01 19:05:01 +0200 | <geekosaur> | 'a' is a Char, "a" aka ('a':[]) is a Strikg aka [Char], Text is a different type entirely representing an optimized representation for strings |
| 2022-08-01 19:05:59 +0200 | <geekosaur> | because String is a really wasteful representation for strings, unless you're processing them in a streaming fashion which means the list is never even constructed |
| 2022-08-01 19:06:08 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-08-01 19:06:16 +0200 | <geekosaur> | for most things you probably want Text |
| 2022-08-01 19:06:40 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-08-01 19:07:42 +0200 | <tmp_away> | geekosaur then when haskell would remove String out? |
| 2022-08-01 19:08:02 +0200 | <geekosaur> | probably never since all the core APIs are defined in terms of String |
| 2022-08-01 19:08:02 +0200 | <merijn> | tmp_away: Never? Why would you do that? |
| 2022-08-01 19:08:07 +0200 | <geekosaur> | it's an ongoing argument |
| 2022-08-01 19:08:20 +0200 | <tmp_away> | lots of Text.pack and unpack and -XOverloadedStrings |
| 2022-08-01 19:08:24 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-08-01 19:08:28 +0200 | <merijn> | geekosaur: I don't see it going away even when APIs are reformulated, it's just to convenient |
| 2022-08-01 19:09:20 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-01 19:12:19 +0200 | ski | (~ski@ext-1-213.eduroam.chalmers.se) |
| 2022-08-01 19:13:58 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2022-08-01 19:14:38 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-08-01 19:22:13 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-08-01 19:22:15 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-08-01 19:24:01 +0200 | <albet70> | would there be haskell-2020? |
| 2022-08-01 19:24:24 +0200 | <albet70> | just like haskell-98 and haskell-2010 |
| 2022-08-01 19:26:05 +0200 | lagash | (lagash@lagash.shelltalk.net) |
| 2022-08-01 19:26:19 +0200 | <dsal> | There's GHC2021 which is close enough. |
| 2022-08-01 19:26:47 +0200 | <sm> | https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html#extension-GHC2021 |
| 2022-08-01 19:27:01 +0200 | <albet70> | dsal , but why they are haskell-xx, this is GHC2021? |
| 2022-08-01 19:27:08 +0200 | <merijn> | dsal: It's really not |
| 2022-08-01 19:27:25 +0200 | <merijn> | dsal: In fact, GHC2021 isn't remotely *close* to a Haskell20XX |
| 2022-08-01 19:27:41 +0200 | <merijn> | dsal: It doesn't do any of the actual important (but hard) bits |
| 2022-08-01 19:27:43 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-01 19:27:50 +0200 | <geekosaur> | albet70, the haskell language committee is waiting for someone to formalize at least some of the extensions that have been made to haskell2010 |
| 2022-08-01 19:27:55 +0200 | <sm> | not enough demand for a new language report right now, a common set of GHC extensions was much easier |
| 2022-08-01 19:28:07 +0200 | <geekosaur> | nothing has been done about this, or documenting how various extensions interact, etc. |
| 2022-08-01 19:28:10 +0200 | econo | (uid147250@user/econo) |
| 2022-08-01 19:28:37 +0200 | <albet70> | merijn , then what's the point of GHC2021? |
| 2022-08-01 19:28:37 +0200 | <merijn> | geekosaur: Or more importantl, what they SHOULD do and how they SHOULD interact (as opposed to how they *happen* to interact) |
| 2022-08-01 19:28:51 +0200 | <merijn> | albet70: People dislike writing 20 extensions into their files |
| 2022-08-01 19:28:56 +0200 | <merijn> | That's the sole point of it |
| 2022-08-01 19:29:04 +0200 | geekosaur | does wonder how much of this is also that nobody wants to properly document how base haskell does 🙂 |
| 2022-08-01 19:29:30 +0200 | AlexZenon | (~alzenon@178.34.150.131) (Ping timeout: 268 seconds) |
| 2022-08-01 19:29:30 +0200 | Alex_test | (~al_test@178.34.150.131) (Ping timeout: 268 seconds) |
| 2022-08-01 19:30:05 +0200 | <geekosaur> | (go look at the one sentence that describes standard Haskell's type system…) |
| 2022-08-01 19:30:40 +0200 | <geekosaur> | one suspects they'd need to expand it in order to fit e.g. type families into it |
| 2022-08-01 19:30:52 +0200 | AlexNoo | (~AlexNoo@178.34.150.131) (Ping timeout: 245 seconds) |
| 2022-08-01 19:31:02 +0200 | lagash | (lagash@lagash.shelltalk.net) (Ping timeout: 240 seconds) |
| 2022-08-01 19:31:19 +0200 | AlexNoo | (~AlexNoo@178.34.150.131) |
| 2022-08-01 19:35:06 +0200 | tmp_away | (~user@114.250.139.224) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2022-08-01 19:37:19 +0200 | Alex_test | (~al_test@178.34.150.131) |
| 2022-08-01 19:38:24 +0200 | AlexZenon | (~alzenon@178.34.150.131) |
| 2022-08-01 19:38:48 +0200 | lagash | (lagash@lagash.shelltalk.net) |
| 2022-08-01 19:38:56 +0200 | <albet70> | import qualified lots of modules is also annoying |
| 2022-08-01 19:39:35 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 19:40:12 +0200 | <albet70> | and all the type signature is like X.Y |
| 2022-08-01 19:40:57 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-08-01 19:43:08 +0200 | <sm> | VS Code + HLS helps with that a bit |
| 2022-08-01 19:43:12 +0200 | <yushyin> | it's a common pattern to import the types not qualified but only the functions |
| 2022-08-01 19:43:30 +0200 | <sm> | it makes adding imports easy. I don't think it adds type signatures for you yet. |
| 2022-08-01 19:43:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 245 seconds) |
| 2022-08-01 19:51:13 +0200 | <albet70> | yushyin , but when functions have same names? |
| 2022-08-01 19:51:49 +0200 | <geekosaur> | but it's a single click |
| 2022-08-01 19:52:01 +0200 | <geekosaur> | as for qualification, last I checked it had a code action for that |
| 2022-08-01 19:54:24 +0200 | <albet70> | which module id or const come from? |
| 2022-08-01 19:54:49 +0200 | <albet70> | since it works on arbitrary type |
| 2022-08-01 19:55:47 +0200 | <geekosaur> | hls knows what the type is and can do what ghc refuses to: type directed name resolution |
| 2022-08-01 19:59:09 +0200 | <geekosaur> | not saying that it does, but it seems to offer that option |
| 2022-08-01 20:01:29 +0200 | Guest|74 | (~Guest|74@KH42117.karlshof.wh.tu-darmstadt.de) |
| 2022-08-01 20:01:57 +0200 | Guest|74 | (~Guest|74@KH42117.karlshof.wh.tu-darmstadt.de) (Client Quit) |
| 2022-08-01 20:03:56 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-08-01 20:04:12 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 245 seconds) |
| 2022-08-01 20:06:37 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2022-08-01 20:15:52 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 245 seconds) |
| 2022-08-01 20:17:53 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 20:21:45 +0200 | <sm> | geekosaur, did you say there's a single click to add a type signature ? |
| 2022-08-01 20:22:10 +0200 | <geekosaur> | it shows a type signature above anything missing one. click it and it gets inserted |
| 2022-08-01 20:23:22 +0200 | <geekosaur> | (I found that by accident, and it caused my program to not compile because it needed 2 additional imports it didn't bother to add…) |
| 2022-08-01 20:23:41 +0200 | <geekosaur> | (so it's not quite perfect as yet) |
| 2022-08-01 20:25:20 +0200 | mikoto-chan | (~mikoto-ch@85-76-162-130-nat.elisa-mobile.fi) |
| 2022-08-01 20:29:00 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 20:30:52 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 245 seconds) |
| 2022-08-01 20:31:52 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 268 seconds) |
| 2022-08-01 20:36:52 +0200 | mikoto-chan | (~mikoto-ch@85-76-162-130-nat.elisa-mobile.fi) (Ping timeout: 268 seconds) |
| 2022-08-01 20:37:35 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: Leaving) |
| 2022-08-01 20:38:38 +0200 | mikoto-chan | (~mikoto-ch@85-76-118-24-nat.elisa-mobile.fi) |
| 2022-08-01 20:39:02 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-08-01 20:40:36 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-01 20:42:26 +0200 | Midjak | (~Midjak@82.66.147.146) (Client Quit) |
| 2022-08-01 20:48:10 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-01 20:48:17 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 20:50:17 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-204.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-08-01 20:51:13 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-08-01 20:53:01 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-01 20:59:12 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 245 seconds) |
| 2022-08-01 21:03:14 +0200 | vglfr | (~vglfr@194.9.14.33) (Ping timeout: 268 seconds) |
| 2022-08-01 21:04:10 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 21:10:10 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 268 seconds) |
| 2022-08-01 21:16:48 +0200 | doelie | (~tom@c-73-17-195-134.hsd1.ma.comcast.net) (Ping timeout: 268 seconds) |
| 2022-08-01 21:18:48 +0200 | vglfr | (~vglfr@194.9.14.33) (Read error: Connection reset by peer) |
| 2022-08-01 21:19:03 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 21:20:02 +0200 | mikoto-chan | (~mikoto-ch@85-76-118-24-nat.elisa-mobile.fi) (Ping timeout: 268 seconds) |
| 2022-08-01 21:22:12 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) |
| 2022-08-01 21:23:35 +0200 | mikoto-chan | (~mikoto-ch@85-76-40-9-nat.elisa-mobile.fi) |
| 2022-08-01 21:24:08 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Write error: Connection reset by peer) |
| 2022-08-01 21:24:08 +0200 | gmg | (~user@user/gehmehgeh) (Read error: Connection reset by peer) |
| 2022-08-01 21:24:08 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Read error: Connection reset by peer) |
| 2022-08-01 21:24:33 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-08-01 21:25:09 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-08-01 21:25:26 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-08-01 21:26:23 +0200 | vglfr | (~vglfr@194.9.14.33) (Read error: Connection reset by peer) |
| 2022-08-01 21:26:38 +0200 | Guest3 | (~textual@pool-100-11-18-203.phlapa.fios.verizon.net) (Client Quit) |
| 2022-08-01 21:27:00 +0200 | <ggVGc> | Can someone help correct my thinking here? :( https://gist.github.com/d3234983e9bf086e62378979e6a9890a |
| 2022-08-01 21:27:16 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 21:28:10 +0200 | <ggVGc> | The whole thing doesn't make much sense I guess |
| 2022-08-01 21:28:49 +0200 | <merijn> | ggVGc: Do you have GADTs enabled? |
| 2022-08-01 21:28:55 +0200 | <ggVGc> | yes |
| 2022-08-01 21:29:37 +0200 | <merijn> | ggVGc: oh, wait, you don't actually have a 'def' value, so assuming getName needs an actual value, you're screwed |
| 2022-08-01 21:29:43 +0200 | <ggVGc> | Basically, I want to have a Def class, from which I can create Refs (which hold the Def as a phantom param), and later on be able to get the name of the Def from a Ref |
| 2022-08-01 21:30:14 +0200 | <ggVGc> | I feel like this should be achievable without resorting to carrying an instance of Def with each Ref? |
| 2022-08-01 21:30:28 +0200 | VictorHugenay | (~jh@user/VictorHugenay) |
| 2022-08-01 21:30:30 +0200 | <ggVGc> | Since a Ref is statically associated with a Def through the type... |
| 2022-08-01 21:30:30 +0200 | <geekosaur> | I think if it's phantom then all you have is the type, not something you can call getName on |
| 2022-08-01 21:30:41 +0200 | <ggVGc> | yeah, the getName part is what's wrong I think |
| 2022-08-01 21:31:01 +0200 | mokee | (~mokee@37.228.215.83) (Quit: off) |
| 2022-08-01 21:31:03 +0200 | <ggVGc> | I need to do it through some other mechanism than a class, but I'm not able to figure out how |
| 2022-08-01 21:31:05 +0200 | <geekosaur> | unless you can somehow move the name into the type level, but that probably means a whole new level of pain |
| 2022-08-01 21:31:35 +0200 | <ggVGc> | Making Refs have to carry instances of Def also adds some levels of pain for me ;( |
| 2022-08-01 21:33:23 +0200 | sandy_doo | (~sandydoo@2a03:1b20:6:f011::a07e) |
| 2022-08-01 21:33:54 +0200 | <ggVGc> | wait, my mistake is making getName require a dummy value... I don't actually ever need that |
| 2022-08-01 21:34:03 +0200 | <ggVGc> | tired and sloppy |
| 2022-08-01 21:34:34 +0200 | <geekosaur> | don't you need it to make the typeclass resolve? |
| 2022-08-01 21:35:05 +0200 | <geekosaur> | unless you enable AllowAmbiguousTypes and use a TypeApplication |
| 2022-08-01 21:35:21 +0200 | <merijn> | geekosaur: I think he just realised he doesn't need 'a -> String' |
| 2022-08-01 21:35:27 +0200 | <merijn> | geekosaur: But can use 'Proxy a -> String' |
| 2022-08-01 21:36:05 +0200 | <ggVGc> | I mean... I didn't, haha :( Yes, the typeclass resolution is the issue and why I had it from the start |
| 2022-08-01 21:37:57 +0200 | mikoto-chan | (~mikoto-ch@85-76-40-9-nat.elisa-mobile.fi) (Ping timeout: 245 seconds) |
| 2022-08-01 21:38:59 +0200 | <geekosaur> | @ask int-e COMMANDS seems to no longer be a part of lambdabot (I don't rven remember what used to point to it). Is there somewhere for my replacement to fit, aside from doc/ ? |
| 2022-08-01 21:39:00 +0200 | <lambdabot> | Consider it noted. |
| 2022-08-01 21:39:14 +0200 | <mrianbloom> | Is it possible to hold a constraint dictionary in a datatype so that anywhere I deconstruct the datatype I can use the constraint? |
| 2022-08-01 21:39:18 +0200 | <geekosaur> | "rven". I can type 😛 |
| 2022-08-01 21:39:34 +0200 | <geekosaur> | mrianbloom, that sounds like a GADT to me |
| 2022-08-01 21:40:16 +0200 | <mrianbloom> | I see. |
| 2022-08-01 21:40:47 +0200 | <ski> | mrianbloom : yes, `data Foo ... = C a => MkFoo ...' or `data Foo ... :: ... where MkFoo :: C a => ... -> Foo ...' (with optional `forall a.') |
| 2022-08-01 21:41:09 +0200 | <ski> | (first is `GADTs', second is `ExistentialQuantification') |
| 2022-08-01 21:41:17 +0200 | <ski> | (er .. other way around) |
| 2022-08-01 21:42:13 +0200 | <mrianbloom> | I see, so far I haven't been able to really use existential quantification to good effect. I think part of the problem is, I'm using type families. |
| 2022-08-01 21:43:14 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3ad-40.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-08-01 21:43:26 +0200 | vglfr | (~vglfr@194.9.14.33) (Ping timeout: 240 seconds) |
| 2022-08-01 21:45:37 +0200 | <ski> | (this is not really existential quantification, but the corresponding "constraint provision" part. also, `ExistentialQuantification' is arguably a misnomer (since it doesn't enable a syntax like `exists a. C a *> ..a..' .. iirc LHC did allow `exists a. ..a..', albeit only in contravariant position (iow to the left of function arrows, in argument types))) |
| 2022-08-01 21:46:44 +0200 | Vajb | (~Vajb@n1zigc3rgo9mpde2w-1.v6.elisa-mobile.fi) |
| 2022-08-01 21:48:21 +0200 | <geekosaur> | doesn't UHC have `exists`? |
| 2022-08-01 21:48:32 +0200 | <merijn> | geekosaur: I think so? |
| 2022-08-01 21:48:36 +0200 | <ski> | maybe it was UHC i was thinking about |
| 2022-08-01 21:48:38 +0200 | <geekosaur> | granting that nobody outside of Utrecht uses it |
| 2022-08-01 21:48:42 +0200 | <dolio> | You can't use it with constraints, though. |
| 2022-08-01 21:48:47 +0200 | <dolio> | As I recall. |
| 2022-08-01 21:49:08 +0200 | <ski> | (imho, something like `ExistentialDataConstructors' or `ExistentialConstructors', or maybe `ExistentialDataTypes', would be a better name for what the extension actually does .. although, maybe to properly indicate the context provision part, one could imagine something like `BundledConstructors' .. although that may need more work to not sound as vague) |
| 2022-08-01 21:49:52 +0200 | VictorHugenay | (~jh@user/VictorHugenay) (Quit: Konversation terminated!) |
| 2022-08-01 21:50:24 +0200 | <ski> | (bundling a data constructor with types ior constraints, not visible from the outside, i.e.) |
| 2022-08-01 21:58:06 +0200 | <ggVGc> | I'm confused again... https://gist.github.com/d3234983e9bf086e62378979e6a9890a |
| 2022-08-01 21:58:38 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-01 21:58:53 +0200 | yvan-sraka | (~yvan-srak@209.red-2-139-126.dynamicip.rima-tde.net) |
| 2022-08-01 22:00:29 +0200 | <ggVGc> | Adding the HasDefName constraint as suggested yields this instead: https://gist.github.com/d3234983e9bf086e62378979e6a9890a |
| 2022-08-01 22:01:43 +0200 | <geekosaur> | don't you actually have to match on the (value) Ref to get at the enclosed HasDefName? |
| 2022-08-01 22:03:26 +0200 | <hippoid> | is there an example of a commonly used Functor which is not also a Monad? |
| 2022-08-01 22:03:53 +0200 | <ski> | yes, you have to match |
| 2022-08-01 22:03:55 +0200 | <ggVGc> | I mean, I'm not entirely sure what I'm doing :) Hence why I am failing... I just feel there should be a way to get the name from Def instances without making a Ref carry a Def value |
| 2022-08-01 22:04:58 +0200 | yvan-sraka | (~yvan-srak@209.red-2-139-126.dynamicip.rima-tde.net) (Remote host closed the connection) |
| 2022-08-01 22:05:45 +0200 | <ski> | hippoid : `Coyoneda f' maybe ? (e.g. `Coyoneda IORef' is basically `data ReadIORef a = forall b. MkReadIORef (b -> a) (IORef b)') |
| 2022-08-01 22:05:49 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-08-01 22:06:13 +0200 | <ski> | .. i don't recall if we determined `ZipList' to actually satisfy the monad laws or not |
| 2022-08-01 22:06:28 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 22:08:52 +0200 | <hippoid> | ski: according to this, it does not https://www.reddit.com/r/haskell/comments/nfyvy/instance_monad_ziplist_where/ |
| 2022-08-01 22:09:01 +0200 | <ski> | ggVGc : hm, looking closer at your code (i guess you replace the middle paste by the last one, so i can't see the middle one), it looks like `getName' for `Def (Ref def)' can't call `getName' for `Def def', without you getting hold of a `Ref def' (which contains the provided/bundled `Def def' instance) there |
| 2022-08-01 22:09:10 +0200 | yvan-sraka | (~yvan-srak@209.red-2-139-126.dynamicip.rima-tde.net) |
| 2022-08-01 22:09:16 +0200 | <merijn> | ski: It can't, at least not as newtype |
| 2022-08-01 22:09:36 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-08-01 22:10:18 +0200 | <merijn> | ski: Simple counter example "foo >>= return" cannot be equivalent to foo |
| 2022-08-01 22:10:32 +0200 | <merijn> | because return doesn't know how many initial elements you had |
| 2022-08-01 22:10:52 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 245 seconds) |
| 2022-08-01 22:11:24 +0200 | <merijn> | The applicative uses "pure = repeat" |
| 2022-08-01 22:11:41 +0200 | <ski> | i'm not seeing why that would fail |
| 2022-08-01 22:11:50 +0200 | <merijn> | But "ZipList [1] >>= return" would produce an infinite ZipList of 1s |
| 2022-08-01 22:11:51 +0200 | <ggVGc> | ski: yeah, I gave up and made Refs hold a Def instance for now... https://gist.github.com/4d208a6751919aa39e088605fa7a5a7d (I guess that's what you meant?) |
| 2022-08-01 22:11:55 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-01 22:12:18 +0200 | <merijn> | ski: Whereas monad laws dictate that "ZipList [1] >>= return" = "ZipList [1] |
| 2022-08-01 22:12:35 +0200 | <ski> | merijn : why ? .. you `map repeat', then take the diagonal |
| 2022-08-01 22:13:01 +0200 | <monochrom> | Hey that's a much simpler problem than what I ran into :) I ran into associativity problems with join... |
| 2022-08-01 22:13:21 +0200 | <ski> | yea, iirc, last i was thinking about it, i was unsure about associativity |
| 2022-08-01 22:13:35 +0200 | TonyStone | (~TonyStone@2603-7080-8607-c36a-d0dd-a126-3a7b-298c.res6.spectrum.com) (Remote host closed the connection) |
| 2022-08-01 22:13:35 +0200 | machinedgod | (~machinedg@d172-219-86-154.abhsia.telus.net) |
| 2022-08-01 22:13:46 +0200 | <merijn> | ski: You do "map repeat" on what? |
| 2022-08-01 22:13:52 +0200 | <ski> | (istr i was thinking by making it appropriately partial, one could possibly get associativity) |
| 2022-08-01 22:13:57 +0200 | <ski> | merijn : on `foo' |
| 2022-08-01 22:14:01 +0200 | <merijn> | monochrom: I had to think of an example on the fly and I'm dumb, so I can only conceive simple examples |
| 2022-08-01 22:14:16 +0200 | <merijn> | ski: How does that work out in my example of "ZipList [1] >>= return"? |
| 2022-08-01 22:14:19 +0200 | <ski> | `foo >>= repeat = diag (map repeat foo)' |
| 2022-08-01 22:14:45 +0200 | <ski> | so you get `diag [repeat 1]', which is `[1]' |
| 2022-08-01 22:14:46 +0200 | <merijn> | What does diag do? |
| 2022-08-01 22:15:28 +0200 | <ski> | takes 0th element of 0th list, 1st element of 1st list, &c., until some diagonal element fails to exist, at which point we end the list |
| 2022-08-01 22:15:31 +0200 | <merijn> | hmmm |
| 2022-08-01 22:15:49 +0200 | <ski> | (it's the proper `join' to try with `repeat' as `return'/`pure') |
| 2022-08-01 22:15:49 +0200 | <monochrom> | diag [xs0, xs1, xs2, ...] = [xs0 !! 0, xs1 !! 1, xs2 !! 2, ...] |
| 2022-08-01 22:16:03 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) |
| 2022-08-01 22:16:21 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-01 22:16:23 +0200 | <ski> | (`join' is not `concat', in this case) |
| 2022-08-01 22:16:36 +0200 | <dolio> | Making it partial doesn't help. I've tried. |
| 2022-08-01 22:16:41 +0200 | pavonia | (~user@user/siracusa) |
| 2022-08-01 22:16:50 +0200 | <ski> | associativity still fails ? |
| 2022-08-01 22:16:51 +0200 | cosimone | (~user@93-44-186-171.ip98.fastwebnet.it) (Read error: Connection reset by peer) |
| 2022-08-01 22:17:03 +0200 | <dolio> | Yes. |
| 2022-08-01 22:17:18 +0200 | <ski> | nice. i'll have to check it in detail |
| 2022-08-01 22:17:38 +0200 | <dolio> | I think the only way you can make it associative is to use something like codensity to force a canonical associativity of the entire computation. |
| 2022-08-01 22:18:00 +0200 | <ski> | mhm .. might be interesting to work out what the resulting behaviour of that would be |
| 2022-08-01 22:18:02 +0200 | <monochrom> | Well, stopping early vs bottoming early is only a difference between [] and _|_ that doesn't really matter... |
| 2022-08-01 22:18:11 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) |
| 2022-08-01 22:18:17 +0200 | <ski> | (well, i guess it'll just right-associate the `(>>=)'s) |
| 2022-08-01 22:19:03 +0200 | <ski> | istr thinking one could run into problems with diagonal element happening to exist with one way to squash the cube, but not the other way around |
| 2022-08-01 22:20:03 +0200 | <dolio> | Right. |
| 2022-08-01 22:20:36 +0200 | <dolio> | The essential problem is that you can't really tell what to do with a slice just by looking at a slice. It depends on all the slices involved. |
| 2022-08-01 22:22:02 +0200 | <dolio> | E.G. if your strategy is to fill in with bottoms, you don't know how many bottoms to fill without knowing the dimensions of all slices. |
| 2022-08-01 22:23:10 +0200 | <ski> | mhm |
| 2022-08-01 22:23:33 +0200 | yauhsien | (~yauhsien@118-167-41-184.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2022-08-01 22:24:04 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 22:24:06 +0200 | <dolio> | And without that global information, you'll end up with different results depending on which direction you slice things. |
| 2022-08-01 22:24:29 +0200 | <ski> | yea |
| 2022-08-01 22:25:53 +0200 | <monochrom> | The good news is that diagonalling works for infinite lists :) |
| 2022-08-01 22:26:22 +0200 | vglfr | (~vglfr@194.9.14.33) |
| 2022-08-01 22:26:35 +0200 | <monochrom> | It's when you want to truncate that you have inconsistent truncations. |
| 2022-08-01 22:26:50 +0200 | <dolio> | Yeah, any fixed size works. |
| 2022-08-01 22:27:19 +0200 | <dolio> | Then you do know how big every cube is. |
| 2022-08-01 22:27:52 +0200 | <monochrom> | The beautiful correspondences between "it's always 5 items" and SetOf5->a, and between infinite list and Natural->a |
| 2022-08-01 22:28:38 +0200 | <ski> | (bag ?) |
| 2022-08-01 22:28:39 +0200 | <monochrom> | (I learned it the hard way!) |
| 2022-08-01 22:28:47 +0200 | <ski> | (what was the hard way ?) |
| 2022-08-01 22:29:15 +0200 | <monochrom> | OK so one day I wondered how to make "data Two a = Two a a" a monod. |
| 2022-08-01 22:29:18 +0200 | <monochrom> | err, monad. |
| 2022-08-01 22:29:27 +0200 | <merijn> | ski: going over every single natural to check |
| 2022-08-01 22:29:30 +0200 | <ggVGc> | Sweet, I got it working :) Now I can make typechecked connections between "things" based on the range of values that inputs and outputs accept: https://gist.github.com/c20c3a04d2516b61db5f8a82e875a162 |
| 2022-08-01 22:29:33 +0200 | <ski> | hehe |
| 2022-08-01 22:30:16 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 268 seconds) |
| 2022-08-01 22:30:19 +0200 | <monochrom> | So I said "OK this is the composition of two adjoint functors, there is a formula for join = what happens to composing two adjoint functors, let me shut up and calculate..." |
| 2022-08-01 22:30:23 +0200 | <ggVGc> | I still feel I shouldn't need that Def value in each Ref instance, but can't figure it out any other way... |
| 2022-08-01 22:30:48 +0200 | yvan-sraka | (~yvan-srak@209.red-2-139-126.dynamicip.rima-tde.net) (Remote host closed the connection) |
| 2022-08-01 22:30:51 +0200 | <monochrom> | Two hours later I got the correct answer. Then I hopped in here to report my achievement. |
| 2022-08-01 22:31:00 +0200 | <ggVGc> | SInce the result of getName for each Def doesn't rely on a runtime value, but is a static string based on the type |
| 2022-08-01 22:31:08 +0200 | <monochrom> | Then someone bursted the bubble with "dude that's (->) Bool" |
| 2022-08-01 22:31:37 +0200 | <monochrom> | (I'm paraphrasing. They didn't say "dude", they were much nicer heh) |
| 2022-08-01 22:32:07 +0200 | <geekosaur> | ggVGc, as I mentioned earlier, that puts you into the realm of type level strings (Symbols). you can use the singletons library to get there, if you dare |
| 2022-08-01 22:32:21 +0200 | <ggVGc> | yeah, that's what I figured... |
| 2022-08-01 22:32:23 +0200 | <ski> | ggVGc : `State' ? |
| 2022-08-01 22:32:38 +0200 | <monochrom> | On the bright side, I turned it into many exam questions. :) |
| 2022-08-01 22:32:44 +0200 | <ggVGc> | and I do not dare... I think, at least for now. I value my time |
| 2022-08-01 22:32:46 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) |
| 2022-08-01 22:32:48 +0200 | cosimone | (~user@93-44-186-171.ip98.fastwebnet.it) |
| 2022-08-01 22:33:40 +0200 | <darkling> | Good exam questions are good to find. :) |
| 2022-08-01 22:33:41 +0200 | <ski> | ggVGc : how's `HasDefName' and `Pin' defined ? |
| 2022-08-01 22:33:52 +0200 | <ski> | merijn : nice :) |
| 2022-08-01 22:34:13 +0200 | <ski> | er .. monochrom ^ |
| 2022-08-01 22:34:32 +0200 | <ggVGc> | ski: you mean to keep the state of the bound instances? Yeah, that's the future plan. Actually, I already have all that working right now (and have been using this software for a few years making music stuff). It's the same idea with defs and refs and input/outputs inside a State monad. But I am trying to transition most of the range checking from runtime to compile-time. So, this is the prototype |
| 2022-08-01 22:34:33 +0200 | <ggVGc> | for what I will then gradually sneak into my existing State monad |
| 2022-08-01 22:35:04 +0200 | <ski> | mhm |
| 2022-08-01 22:35:41 +0200 | <ggVGc> | ski: https://gist.github.com/8b7f276ec0b6b877960bb342e1adf06f |
| 2022-08-01 22:36:19 +0200 | <ski> | ok, so no constraint in `Pin' |
| 2022-08-01 22:37:06 +0200 | <monochrom> | Whoever invented/discovered representable functors should have named their paper "the next 700 functors" :) |
| 2022-08-01 22:37:22 +0200 | <ski> | there's a difference betweem `NonZeroPos' and `Positive' ? you're using french convention for "positive" ? and "negative" ? (or assembler / machine code notion of "positive" ?) |
| 2022-08-01 22:37:32 +0200 | <ggVGc> | I don't need it, for now. Since I never extract anything out of it. Pin is just to tie a def to some range, and produce a runtime value which I then use for code generation (spitting out C++) |
| 2022-08-01 22:38:25 +0200 | <ggVGc> | I never care about negative numbers, at least not for now. But I do care specifically about non-negative ones, and I do care about non-zero ones :) |
| 2022-08-01 22:38:29 +0200 | <ski> | ggVGc : trying to figure out how `HasDefName' get (presumably) used in `connectionTest' |
| 2022-08-01 22:39:09 +0200 | <ski> | just saying that it's common for "positive" to already be taken to exclude zero .. unless in the two contexts i mentioned, that i know of |
| 2022-08-01 22:39:22 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-08-01 22:39:53 +0200 | <ggVGc> | ski: this is the whole thing: https://gist.github.com/66e360b02ac2a894b06b26a220f0a61b |
| 2022-08-01 22:40:10 +0200 | ski | 's been disassembling and trying to grok a piece of software, from 1986, lately |
| 2022-08-01 22:40:31 +0200 | <ggVGc> | ah, yeah, for lack of better terminology I use Positive to include zero, since I care about the non-zero positive case specifically |
| 2022-08-01 22:40:32 +0200 | <ski> | (more specifically, a Prolog implementation for the Commodore 64) |
| 2022-08-01 22:41:08 +0200 | <monochrom> | That's some feat. 64KB does not look like enough for Prolog... |
| 2022-08-01 22:41:33 +0200 | <ggVGc> | It's outrageous to me the software that was made for C64s and amigas |
| 2022-08-01 22:41:49 +0200 | <ggVGc> | or.. even Amiga OS itself |
| 2022-08-01 22:42:08 +0200 | <monochrom> | Next thing you know "ghc -fllvm" works on C64 too. |
| 2022-08-01 22:43:27 +0200 | <ski> | (i would use a kind signature for `SRangeType') |
| 2022-08-01 22:43:45 +0200 | <ski> | hehe |
| 2022-08-01 22:44:16 +0200 | <ggVGc> | there are definitely tons of improvements I could make. I am using this as a chance to get out of my "writing Haskell like a toddler" zone a bit |
| 2022-08-01 22:44:36 +0200 | <ggVGc> | while still having the goal of making it practically useful for myself in a near future |
| 2022-08-01 22:45:17 +0200 | <ggVGc> | Even after having used Haskell for many years, I never really did much type-level stuff |
| 2022-08-01 22:45:50 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2022-08-01 22:48:13 +0200 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) (Ping timeout: 268 seconds) |
| 2022-08-01 22:48:45 +0200 | <ski> | it's a very basic Prolog .. has only basic Edinburgh compatibility (put/1,get0/1,get/1,see/1,seeing/1,seen/0,tell/1,telling/1,told/1,clause/2,arg/3,(no setarg/3),functor/2,...,(is)/2,basic arithmetic operations and relations, equality and identity checks (negation is indicated with `/', since C64 doesn't have a `\' sign) .. also, no floats, and integers only `0' through `8191' .. relatively low limits on |
| 2022-08-01 22:48:51 +0200 | <ski> | arity, number of goals in a rule, number of variables in a clause or query, or in use at the same time (it seems to use a substitution model, rather than using update-in-place). there's some machine specific predicates for graphics (including Turtle), sound, randomness) .. also, i'd like to add Last/Tail Call optimization, and mutatis mutandis for failures rather than successes) |
| 2022-08-01 22:50:17 +0200 | <ski> | anyway, the code itself is only 12 K. stack is a bit over 32 K, and heap is 8 K |
| 2022-08-01 22:50:24 +0200 | <ggVGc> | haha, "integers only `0' through `8191'" |
| 2022-08-01 22:50:26 +0200 | <ggVGc> | beautiful |
| 2022-08-01 22:50:54 +0200 | <ski> | they're stored in-word (16 bits), with a few bits used for tagging |
| 2022-08-01 22:51:36 +0200 | <ski> | there is firmware (KERNAL ROM) routines for floating-point (an unusual 5-byte one), which i'm thinking about employing |
| 2022-08-01 22:53:02 +0200 | machinedgod | (~machinedg@d172-219-86-154.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2022-08-01 22:56:11 +0200 | sts-q | (~sts-q@2a01:41e1:239e:8600:5ca9:a95b:5e06:aaf8) |
| 2022-08-01 22:56:50 +0200 | <ski> | i started with figuring out the format of the symbol table, then the representation for the predicate clauses (some built-in predicates are primitives, defined by a machine code routine, some are defined by Prolog clauses, which are stored as lists of terms). next i figured out the bank-switching (between firmware BASIC ROM, which it reuses a little bit of, for tokens i think. it also uses KERNAL for I/O, |
| 2022-08-01 22:56:56 +0200 | <ski> | and the screen editor), and start-up code. then i found the primitive routine table, and now i'm looking at the corresponding routines, and some various other ones |
| 2022-08-01 22:58:55 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-08-01 23:00:10 +0200 | causal | (~user@50.35.83.177) |
| 2022-08-01 23:00:35 +0200 | <ski> | (trying to make an assembler source which will assemble to the same as the original file .. then i'll try to think about enhancements, and modifications .. also, there was a few bugs/misfeatures i was looking to improve upon .. but i may need to add some more bank-switching, if i need to use more memory for the code .. and it looks like my assembler (an inline/in-memory one, not offline/to-disk) can't hold |
| 2022-08-01 23:00:41 +0200 | <ski> | all the required source, and the object code, in memory at the same time, so i'll need to split and figure out how to resolve the symbol/label interdependencies) |
| 2022-08-01 23:02:42 +0200 | <ski> | monochrom : years ago, i was thinking about trying to do a combinator-based architecture on it (for an FPL), inspired by Philip Koopman's Ph. D. thesis ("TIGRE") |
| 2022-08-01 23:02:57 +0200 | <ski> | (graph reduction, i.e.) |
| 2022-08-01 23:06:23 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 23:06:47 +0200 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) |
| 2022-08-01 23:08:09 +0200 | pavonia | (~user@user/siracusa) (Read error: Connection reset by peer) |
| 2022-08-01 23:09:49 +0200 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) (Max SendQ exceeded) |
| 2022-08-01 23:10:52 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 245 seconds) |
| 2022-08-01 23:11:27 +0200 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) |
| 2022-08-01 23:13:18 +0200 | pavonia | (~user@user/siracusa) |
| 2022-08-01 23:13:59 +0200 | coot | (~coot@213.134.190.95) |
| 2022-08-01 23:20:59 +0200 | Inoperable | (~PLAYER_1@fancydata.science) (Quit: All your buffer are belong to us!) |
| 2022-08-01 23:21:06 +0200 | <EvanR> | ggVGc, arguably, "useful for myself" and "type level stuff" are orthogonal xD |
| 2022-08-01 23:22:36 +0200 | <EvanR> | ski, do I dare ask what mutatis mutandis is or do I need to go to wizard school |
| 2022-08-01 23:23:26 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 240 seconds) |
| 2022-08-01 23:25:11 +0200 | <ski> | "changing what needs to be changed" |
| 2022-08-01 23:25:26 +0200 | acidjnk | (~acidjnk@p200300d6e70586786c92b9403fbc0a82.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-08-01 23:26:10 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-01 23:31:19 +0200 | noteness | (~noteness@user/noteness) (Ping timeout: 268 seconds) |
| 2022-08-01 23:31:27 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-08-01 23:32:25 +0200 | <ski> | proper tail calls amount to eta-reducing, or rather, not uselessly eta-expanding, the continuation. so `jmp last_call' in place of `jsr last_call' followed by `rts'. in case of logic programming, with backtracking, we have two levels of continuations (`ContT o (ContT p m)'), success continuations and failure continuations (the former takes one of the latter as a parameter, called "redo"). if you say "Last |
| 2022-08-01 23:32:31 +0200 | <ski> | Call" (discovered in LP independently of "Tail Call" in FP), you typically mean wrt the success continuations, so calling the last predicate (if no more clauses, and no new choice points are still extant) will reuse (the memory of) the current frame. "tail failure", for failure continuations, means that it doesn't uselessly try to find (the non-existent) clause after the last one, and that there is also no |
| 2022-08-01 23:32:37 +0200 | <ski> | choice-point for the last disjunct in a disjunction. so it's reusing the failure continuation (as well), for the last alternative, just like reusing the success continuation, for the last conjunct in a conjunction |
| 2022-08-01 23:33:12 +0200 | <ski> | @unmtl ContT o (ContT p m) a |
| 2022-08-01 23:33:12 +0200 | <lambdabot> | (a -> (o -> m p) -> m p) -> (o -> m p) -> m p |
| 2022-08-01 23:33:56 +0200 | noteness | (~noteness@user/noteness) |
| 2022-08-01 23:34:33 +0200 | <EvanR> | makes sense |
| 2022-08-01 23:34:42 +0200 | <ski> | the first argument is the success continuation, the second is the failure continuation. the success continuation also takes a failure/redo continuation, which tells it where to retry (it amounts to the choice-point), if something later (in the sequence of conjuncts in the conjunction) fails, and we have to backtrack, reversing normal order of execution |
| 2022-08-01 23:36:43 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-08-01 23:37:47 +0200 | <ski> | (of course, at assembler level, `p' would basically be `Void', so no "final return/answer/result". when encoding backtracking with functions, it's possible (e.g. i've seen this in lambdaProlog (Terzo interpreter),Lolli) to use the implicit continuations in the host language as failure continuations, only having the success continuations as explicit callback function parameters. in that case, the function |
| 2022-08-01 23:37:53 +0200 | <ski> | calls its callback deeper, on success, and fails by returning normally. disjunction becomes doing one call after the other has returned, and conjunction is nesting inside the callbacks) |
| 2022-08-01 23:39:17 +0200 | <ski> | (both those implementations were written in SML, so could provide an initial success continuation which used side-effects to print out the top-level answer to a query) |
| 2022-08-01 23:39:43 +0200 | tired- | (~tired@user/tired) |
| 2022-08-01 23:39:50 +0200 | caubert_ | (~caubert@user/caubert) |
| 2022-08-01 23:40:04 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 23:40:17 +0200 | <ski> | (hm .. also commit to a solution (avoid generating more) was implemented by throwing a host language exception) |
| 2022-08-01 23:40:30 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-01 23:40:51 +0200 | terrorjack5 | (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 2022-08-01 23:41:02 +0200 | alinab_ | (sid468903@id-468903.helmsley.irccloud.com) |
| 2022-08-01 23:41:03 +0200 | teehemkay__ | (sid14792@id-14792.lymington.irccloud.com) |
| 2022-08-01 23:41:04 +0200 | aristid_ | (sid1599@id-1599.uxbridge.irccloud.com) |
| 2022-08-01 23:41:04 +0200 | alanz_ | (sid110616@id-110616.uxbridge.irccloud.com) |
| 2022-08-01 23:41:04 +0200 | conjunctive_ | (sid433686@id-433686.helmsley.irccloud.com) |
| 2022-08-01 23:41:05 +0200 | lightandlight_ | (sid135476@id-135476.helmsley.irccloud.com) |
| 2022-08-01 23:41:05 +0200 | taktoa[c]_ | (sid282096@id-282096.tinside.irccloud.com) |
| 2022-08-01 23:41:05 +0200 | sclv_ | (sid39734@haskell/developer/sclv) |
| 2022-08-01 23:41:06 +0200 | NemesisD_ | (sid24071@id-24071.lymington.irccloud.com) |
| 2022-08-01 23:41:14 +0200 | another-axel-bee | (~axel-bee@alexbenishek.com) |
| 2022-08-01 23:41:21 +0200 | dmj`_ | (sid72307@id-72307.hampstead.irccloud.com) |
| 2022-08-01 23:41:38 +0200 | micro | (~micro@user/micro) (Ping timeout: 255 seconds) |
| 2022-08-01 23:41:55 +0200 | jludwig89 | (~justin@li657-110.members.linode.com) |
| 2022-08-01 23:42:08 +0200 | danso_o | (~danso@danso.ca) |
| 2022-08-01 23:42:14 +0200 | <EvanR> | all you need are exceptions |
| 2022-08-01 23:42:24 +0200 | Jon | (jon@dow.land) (Ping timeout: 268 seconds) |
| 2022-08-01 23:42:40 +0200 | kawen_ | (~quassel@static.208.191.216.95.clients.your-server.de) |
| 2022-08-01 23:42:47 +0200 | koz_ | (~koz@121.99.240.58) |
| 2022-08-01 23:42:50 +0200 | robertm | (robertm@lattice.rojoma.com) (Ping timeout: 244 seconds) |
| 2022-08-01 23:42:50 +0200 | Hobbyboy | (Hobbyboy@hobbyboy.co.uk) (Ping timeout: 244 seconds) |
| 2022-08-01 23:43:01 +0200 | Rembane | (~Rembane@li346-36.members.linode.com) (Ping timeout: 268 seconds) |
| 2022-08-01 23:43:02 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-08-01 23:43:15 +0200 | eldritch_ | (~eldritch@user/eldritch) |
| 2022-08-01 23:43:18 +0200 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) (Ping timeout: 264 seconds) |
| 2022-08-01 23:43:18 +0200 | statusfailed | (~statusfai@statusfailed.com) (Ping timeout: 264 seconds) |
| 2022-08-01 23:43:18 +0200 | dexter1 | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) (Ping timeout: 264 seconds) |
| 2022-08-01 23:43:25 +0200 | jocke-l | (jocke-l@a.x0.is) (Ping timeout: 272 seconds) |
| 2022-08-01 23:43:44 +0200 | haveo_ | (~haveo@sl35.iuwt.fr) |
| 2022-08-01 23:43:47 +0200 | aweinsto1k | (~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) |
| 2022-08-01 23:43:47 +0200 | hpc_ | (~juzz@ip98-169-32-242.dc.dc.cox.net) |
| 2022-08-01 23:43:58 +0200 | funsafe_ | (~funsafe@2601:1c1:4200:9ac:84cb:185c:2a3c:c92c) |
| 2022-08-01 23:44:03 +0200 | _koolazer | (~koo@user/koolazer) |
| 2022-08-01 23:44:10 +0200 | rush | (~sloorush@52.187.184.81) |
| 2022-08-01 23:44:12 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 245 seconds) |
| 2022-08-01 23:44:18 +0200 | anderson_ | (~ande@user/anderson) |
| 2022-08-01 23:44:31 +0200 | Patternm1ster | (~georg@li1192-118.members.linode.com) |
| 2022-08-01 23:44:33 +0200 | heartbur1 | (~gass@2a00:d880:3:1::b1e4:b241) |
| 2022-08-01 23:44:41 +0200 | fryguybo1 | (~fryguybob@cpe-74-67-169-145.rochester.res.rr.com) |
| 2022-08-01 23:45:03 +0200 | walt | (~ggVGc@a.lowtech.earth) |
| 2022-08-01 23:45:03 +0200 | ddb1 | (~ddb@ipv6two.tilde.club) |
| 2022-08-01 23:45:19 +0200 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-08-01 23:46:05 +0200 | <ski> | i might try to implement my goal-implications idea (arbitrary left-nested implications, also goal-universals .. not assuming implications (like lambdaProlog,Lolli), but generate&test .. but better than `forall(A,S)' / `\+ (A,\+ S)' in Prolog, which can't export information (instantiations) on success, due to being based on negation-as-failure .. there's also a foreach/2, but it doesn't interleave the |
| 2022-08-01 23:46:11 +0200 | <ski> | execution. basically it generates as many copies of the succedent as there's solutions to the antecedent (also messing up possible variable aliasing, and attributes, due to copying)) |
| 2022-08-01 23:46:34 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-08-01 23:46:41 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-01 23:47:11 +0200 | Square2 | (~a@user/square) |
| 2022-08-01 23:47:17 +0200 | <ski> | .. but that's more advanced stuff. i'll see how far i get, even with last call/clause, and before that, basic understanding of the system and how it might be extended |
| 2022-08-01 23:47:41 +0200 | adamCS_ | (~adamCS@ec2-34-207-160-255.compute-1.amazonaws.com) |
| 2022-08-01 23:48:16 +0200 | notzmv | (~zmv@user/notzmv) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | funsafe | (~funsafe@2601:1c1:4200:9ac:84cb:185c:2a3c:c92c) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | anderson | (~ande@user/anderson) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | andjjj23_ | (~irc@107.170.228.47) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | axel-bee | (~axel-bee@alexbenishek.com) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | arahael | (~arahael@203.220.205.108) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | koolazer | (~koo@user/koolazer) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | haveo | (~haveo@sl35.iuwt.fr) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | Patternmaster | (~georg@user/Patternmaster) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | fryguybob | (~fryguybob@cpe-74-67-169-145.rochester.res.rr.com) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | kawen | (~quassel@static.208.191.216.95.clients.your-server.de) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | Square | (~a@user/square) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | tired | (~tired@user/tired) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | aweinstock | (~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | APic | (apic@apic.name) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | alinab | (sid468903@id-468903.helmsley.irccloud.com) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | sektor[m] | (~sektor@2001:470:69fc:105::2:3f60) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | hpc | (~juzz@ip98-169-32-242.dc.dc.cox.net) (*.net *.split) |
| 2022-08-01 23:48:16 +0200 | lambdabot | (~lambdabot@haskell/bot/lambdabot) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | eldritch | (~eldritch@user/eldritch) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | sloorush | (~sloorush@52.187.184.81) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | danso | (danso@danso.ca) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | caubert | (~caubert@user/caubert) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | jludwig | (~justin@li657-110.members.linode.com) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | ddb | (~ddb@ipv6two.tilde.club) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | bastelfreak | (bastelfrea@libera/staff/VoxPupuli.bastelfreak) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | alanz | (sid110616@id-110616.uxbridge.irccloud.com) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | NemesisD | (sid24071@id-24071.lymington.irccloud.com) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | sclv | (sid39734@haskell/developer/sclv) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | lightandlight | (sid135476@id-135476.helmsley.irccloud.com) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | dmj` | (sid72307@id-72307.hampstead.irccloud.com) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | conjunctive | (sid433686@id-433686.helmsley.irccloud.com) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | taktoa[c] | (sid282096@id-282096.tinside.irccloud.com) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | teehemkay_ | (sid14792@id-14792.lymington.irccloud.com) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | koz | (~koz@121.99.240.58) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | bu99ed[m] | (~bu99edm4t@2001:470:69fc:105::1:bd9e) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | adamCS | (~adamCS@ec2-34-207-160-255.compute-1.amazonaws.com) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | ggVGc | (~ggVGc@a.lowtech.earth) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | heartburn | (~gass@2a00:d880:3:1::b1e4:b241) (*.net *.split) |
| 2022-08-01 23:48:17 +0200 | aristid_ | aristid |
| 2022-08-01 23:48:17 +0200 | anderson_ | anderson |
| 2022-08-01 23:48:17 +0200 | teehemkay__ | teehemkay_ |
| 2022-08-01 23:48:17 +0200 | jludwig89 | jludwig |
| 2022-08-01 23:48:17 +0200 | terrorjack5 | terrorjack |
| 2022-08-01 23:48:17 +0200 | alinab_ | alinab |
| 2022-08-01 23:48:17 +0200 | lightandlight_ | lightandlight |
| 2022-08-01 23:48:17 +0200 | eldritch_ | eldritch |
| 2022-08-01 23:48:17 +0200 | adamCS_ | adamCS |
| 2022-08-01 23:48:17 +0200 | sclv_ | sclv |
| 2022-08-01 23:48:17 +0200 | alanz_ | alanz |
| 2022-08-01 23:48:17 +0200 | taktoa[c]_ | taktoa[c] |
| 2022-08-01 23:48:18 +0200 | NemesisD_ | NemesisD |
| 2022-08-01 23:48:18 +0200 | dmj`_ | dmj` |
| 2022-08-01 23:48:18 +0200 | conjunctive_ | conjunctive |
| 2022-08-01 23:49:34 +0200 | lambdabot | (~lambdabot@silicon.int-e.eu) |
| 2022-08-01 23:49:34 +0200 | lambdabot | (~lambdabot@silicon.int-e.eu) (Changing host) |
| 2022-08-01 23:49:34 +0200 | lambdabot | (~lambdabot@haskell/bot/lambdabot) |
| 2022-08-01 23:50:59 +0200 | <ski> | (i prototyped the goal-implication idea, years ago, in Haskell. basic idea for doing LP and (typed) logic variables (using update-in-place) was inspired by a paper by Silvija Seres & Mike Spivey, and a response to that by Koen Claessen. but i dreamed up the main goal-implication idea when attempting to port a Common Lisp implementation of Sudoku to Prolog, and getting side-tracked with expressing general |
| 2022-08-01 23:51:05 +0200 | <ski> | utility predicates for multi-dimensional arrays -- banging my head into limitations or misunderstandings regarding setarg/3 (mutation) (and friend predicates) in SWI-Prolog ..) |
| 2022-08-01 23:52:17 +0200 | <ski> | (.. anyway, the core of it is a way to "backtrack backtracking" (possibly nested more times), and a way of flipping between logic variables and skolems on polarity shift (implication antecedent, negation)) |
| 2022-08-01 23:52:32 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-01 23:52:54 +0200 | zer0bitz | (~zer0bitz@2001:2003:f748:2000:98f8:2cf6:f3d:5610) (Ping timeout: 264 seconds) |
| 2022-08-01 23:54:29 +0200 | APic | (apic@apic.name) |
| 2022-08-01 23:55:14 +0200 | arahael | (~arahael@203.220.205.108) |
| 2022-08-01 23:55:47 +0200 | andjjj23_ | (~irc@107.170.228.47) |
| 2022-08-01 23:55:54 +0200 | bastelfreak | (bastelfrea@libera/staff/VoxPupuli.bastelfreak) |
| 2022-08-01 23:57:27 +0200 | bu99ed[m] | (~bu99edm4t@2001:470:69fc:105::1:bd9e) |
| 2022-08-01 23:59:45 +0200 | sektor[m] | (~sektor@2001:470:69fc:105::2:3f60) |