Home liberachat/#haskell: Logs Calendar

Logs on 2022-06-22 (liberachat/#haskell)

00:00:09 → juri__ joins (~juri@79.140.115.124)
00:01:29 × [itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 248 seconds)
00:02:29 → jmdaemon joins (~jmdaemon@user/jmdaemon)
00:02:58 × quarkyalice quits (~quarkyali@user/quarkyalice) (Quit: quarkyalice)
00:03:05 × juri_ quits (~juri@79.140.115.72) (Ping timeout: 248 seconds)
00:05:40 → [itchyjunk] joins (~itchyjunk@user/itchyjunk/x-7353470)
00:06:07 → quarkyalice joins (~quarkyali@user/quarkyalice)
00:13:58 → vysn joins (~vysn@user/vysn)
00:21:04 <Axman6> dsal: isn't that just sequence?
00:21:28 <Axman6> > sequence ["ABC","TUV","XYZ"]
00:21:30 <lambdabot> ["ATX","ATY","ATZ","AUX","AUY","AUZ","AVX","AVY","AVZ","BTX","BTY","BTZ","BU...
00:27:27 → td_ joins (~td@muedsl-82-207-238-103.citykom.de)
00:29:28 <dsal> Axman6: It is in that case, I think, but this was groups of three of two things.
00:29:42 <dsal> > sequence [[True, False]]
00:29:44 <lambdabot> [[True],[False]]
00:30:13 <dsal> > sequence [[True], [False]]
00:30:15 <lambdabot> [[True,False]]
00:30:43 <dsal> I can't make that exciting.
00:30:50 × pleo quits (~pleo@user/pleo) (Ping timeout: 240 seconds)
00:35:27 → jmcarthur joins (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net)
00:36:06 × jmcarthur quits (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) (Client Quit)
00:38:38 × pretty_dumm_guy quits (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Ping timeout: 240 seconds)
00:40:45 → esrh joins (~user@res404s-128-61-105-50.res.gatech.edu)
00:42:12 <jackdk> it alternates, that's exciting!
00:46:11 <dsal> > sequence [[True, False]]
00:46:13 <lambdabot> [[True],[False]]
00:46:17 × xff0x quits (~xff0x@b133147.ppp.asahi-net.or.jp) (Ping timeout: 248 seconds)
00:46:28 <hpc> it'd be more fun if it was like that for all inputs
00:46:30 <dsal> My attention span is short enough that I just typed up a thing I already typed up to try it.
00:46:53 <dsal> > replicateM 3 ["ABC", "TUV", "XYZ"]
00:46:55 <Axman6> It could've changed in that time
00:46:55 <lambdabot> [["ABC","ABC","ABC"],["ABC","ABC","TUV"],["ABC","ABC","XYZ"],["ABC","TUV","A...
00:47:16 <dsal> > replicateM 3 "ABC" -- I guess at this point, it's just permutations of 3
00:47:18 <lambdabot> ["AAA","AAB","AAC","ABA","ABB","ABC","ACA","ACB","ACC","BAA","BAB","BAC","BB...
00:50:12 × quarkyalice quits (~quarkyali@user/quarkyalice) (Remote host closed the connection)
00:51:21 → rkk joins (~rkk@2601:547:b01:53f3:df8:eb6f:ddf9:a41f)
00:51:43 → quarkyalice joins (~quarkyali@user/quarkyalice)
00:55:03 × quarkyalice quits (~quarkyali@user/quarkyalice) (Client Quit)
00:57:06 × rkk quits (~rkk@2601:547:b01:53f3:df8:eb6f:ddf9:a41f) (Quit: Leaving)
00:59:23 → cheater1__ joins (~Username@user/cheater)
00:59:30 × cheater quits (~Username@user/cheater) (Ping timeout: 264 seconds)
00:59:37 cheater1__ is now known as cheater
01:01:58 × machinedgod quits (~machinedg@66.244.246.252) (Ping timeout: 240 seconds)
01:03:02 × cheater quits (~Username@user/cheater) (Client Quit)
01:03:47 → cheater joins (~Username@user/cheater)
01:04:02 → Guest27 joins (~Guest27@2601:281:d47f:1590::2df)
01:04:32 × notzmv quits (~zmv@user/notzmv) (Ping timeout: 255 seconds)
01:09:12 → moet joins (~moet@mobile-166-177-248-235.mycingular.net)
01:09:32 × moet quits (~moet@mobile-166-177-248-235.mycingular.net) (Client Quit)
01:10:32 <Guest27> Is Cabal supposed to cache ghc options by default? If I run `cabal build --ghc-options -ddump-splices`, future builds will always dump the splices even without any ghc options passed until running `cabal clean`
01:18:35 → nate4 joins (~nate@98.45.169.16)
01:20:22 × Guest27 quits (~Guest27@2601:281:d47f:1590::2df) (Quit: Client closed)
01:23:30 × nate4 quits (~nate@98.45.169.16) (Ping timeout: 268 seconds)
01:24:17 × stefan-_ quits (~cri@42dots.de) (Ping timeout: 246 seconds)
01:28:03 → yauhsien joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
01:28:42 × stackdroid18 quits (14094@user/stackdroid) (Quit: Lost terminal)
01:29:06 → stefan-_ joins (~cri@42dots.de)
01:30:39 → xff0x joins (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
01:33:13 × alp__ quits (~alp@user/alp) (Ping timeout: 248 seconds)
01:34:15 × esrh quits (~user@res404s-128-61-105-50.res.gatech.edu) (Remote host closed the connection)
01:50:01 × yauhsien quits (~yauhsien@61-231-23-53.dynamic-ip.hinet.net) (Ping timeout: 268 seconds)
01:56:12 × stiell quits (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 268 seconds)
02:04:33 → nibelungen joins (~asturias@2001:19f0:7001:638:5400:3ff:fef3:8725)
02:07:04 → kimjetwav joins (~user@2607:fea8:2340:da00:1282:4dfa:aaca:27db)
02:09:51 → stiell joins (~stiell@gateway/tor-sasl/stiell)
02:20:36 × FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
02:20:36 → finn_elija joins (~finn_elij@user/finn-elija/x-0085643)
02:20:36 finn_elija is now known as FinnElija
02:26:31 × Unicorn_Princess quits (~Unicorn_P@93-103-228-248.dynamic.t-2.net) (Remote host closed the connection)
02:27:24 → frost joins (~frost@user/frost)
02:36:38 × liz quits (~liz@cpc84585-newc17-2-0-cust60.16-2.cable.virginm.net) (Ping timeout: 240 seconds)
02:37:48 × jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 276 seconds)
02:39:45 × mikoto-chan quits (~mikoto-ch@esm-84-240-99-143.netplaza.fi) (Ping timeout: 276 seconds)
02:48:00 × yrlnry quits (~yrlnry@pool-108-2-150-109.phlapa.fios.verizon.net) (Remote host closed the connection)
02:56:26 → esrh joins (~user@res404s-128-61-105-50.res.gatech.edu)
03:02:30 × td_ quits (~td@muedsl-82-207-238-103.citykom.de) (Ping timeout: 264 seconds)
03:04:09 → td_ joins (~td@muedsl-82-207-238-203.citykom.de)
03:04:18 × vysn quits (~vysn@user/vysn) (Ping timeout: 264 seconds)
03:14:43 → notzmv joins (~zmv@user/notzmv)
03:16:35 × waleee quits (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 244 seconds)
03:18:37 → yrlnry joins (~yrlnry@pool-108-2-150-109.phlapa.fios.verizon.net)
03:21:07 → nate4 joins (~nate@98.45.169.16)
03:22:45 → z0k joins (~z0k@206.84.141.12)
03:22:58 × yrlnry quits (~yrlnry@pool-108-2-150-109.phlapa.fios.verizon.net) (Ping timeout: 240 seconds)
03:41:39 × stiell quits (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 268 seconds)
03:42:12 → stiell joins (~stiell@gateway/tor-sasl/stiell)
03:42:23 × [itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
03:43:19 × esrh quits (~user@res404s-128-61-105-50.res.gatech.edu) (Remote host closed the connection)
03:49:05 → yauhsien joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
04:05:38 × nate4 quits (~nate@98.45.169.16) (Ping timeout: 246 seconds)
04:09:39 × Vajb quits (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer)
04:10:09 → Vajb joins (~Vajb@2001:999:40:4c50:1b24:879c:6df3:1d06)
04:14:02 → Sgeo_ joins (~Sgeo@user/sgeo)
04:14:04 → Kaipei joins (~Kaiepi@156.34.47.253)
04:14:34 → Feuermagier_ joins (~Feuermagi@138.199.36.237)
04:14:42 → apache2 joins (apache2@anubis.0x90.dk)
04:15:14 → Katarushisu4 joins (~Katarushi@cpc147334-finc20-2-0-cust27.4-2.cable.virginm.net)
04:15:23 → EsoAlgo1 joins (~EsoAlgo@129.146.136.145)
04:15:32 → elkcl_ joins (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru)
04:15:36 → ulvarref` joins (~user@188.124.56.153)
04:15:47 × Natch quits (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Ping timeout: 246 seconds)
04:15:47 × lambdabot quits (~lambdabot@haskell/bot/lambdabot) (Ping timeout: 246 seconds)
04:16:29 × AlexZenon quits (~alzenon@178.34.160.206) (Ping timeout: 246 seconds)
04:16:29 × elkcl quits (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) (Ping timeout: 246 seconds)
04:16:29 × Henkru quits (~henkru@kapsi.fi) (Ping timeout: 246 seconds)
04:16:29 elkcl_ is now known as elkcl
04:16:50 × tv quits (~tv@user/tv) (Ping timeout: 246 seconds)
04:16:50 × gentauro quits (~gentauro@user/gentauro) (Ping timeout: 246 seconds)
04:16:50 × drewr quits (~drew@user/drewr) (Ping timeout: 246 seconds)
04:16:50 × Katarushisu quits (~Katarushi@cpc147334-finc20-2-0-cust27.4-2.cable.virginm.net) (Ping timeout: 246 seconds)
04:16:50 × turlando quits (~turlando@user/turlando) (Ping timeout: 246 seconds)
04:16:50 × EsoAlgo quits (~EsoAlgo@129.146.136.145) (Ping timeout: 246 seconds)
04:16:50 × echoreply quits (~echoreply@45.32.163.16) (Ping timeout: 246 seconds)
04:16:50 × Guest1698 quits (~Guest1698@20.83.116.49) (Ping timeout: 246 seconds)
04:16:50 Katarushisu4 is now known as Katarushisu
04:16:50 EsoAlgo1 is now known as EsoAlgo
04:17:11 × Kaiepi quits (~Kaiepi@156.34.47.253) (Ping timeout: 246 seconds)
04:17:11 × Sgeo quits (~Sgeo@user/sgeo) (Ping timeout: 246 seconds)
04:17:11 × ulvarrefr quits (~user@188.124.56.153) (Ping timeout: 246 seconds)
04:17:11 × apache quits (apache2@anubis.0x90.dk) (Ping timeout: 246 seconds)
04:17:11 × Dykam quits (Dykam@dykam.nl) (Ping timeout: 246 seconds)
04:17:11 × Feuermagier quits (~Feuermagi@user/feuermagier) (Ping timeout: 246 seconds)
04:17:11 × ezzieyguywuf quits (~Unknown@user/ezzieyguywuf) (Ping timeout: 246 seconds)
04:17:11 × hughjfchen quits (~hughjfche@vmi556545.contaboserver.net) (Ping timeout: 246 seconds)
04:17:11 × JimL quits (~quassel@89-162-2-132.fiber.signal.no) (Ping timeout: 246 seconds)
04:17:25 → turlando joins (~turlando@93.51.40.51)
04:17:25 × turlando quits (~turlando@93.51.40.51) (Changing host)
04:17:25 → turlando joins (~turlando@user/turlando)
04:17:43 → lambdabot joins (~lambdabot@silicon.int-e.eu)
04:17:43 × lambdabot quits (~lambdabot@silicon.int-e.eu) (Changing host)
04:17:43 → lambdabot joins (~lambdabot@haskell/bot/lambdabot)
04:17:48 → Dykam joins (Dykam@dykam.nl)
04:17:49 → JimL joins (~quassel@89-162-2-132.fiber.signal.no)
04:18:22 → Henkru joins (henkru@kapsi.fi)
04:18:54 → gentauro joins (~gentauro@user/gentauro)
04:19:06 → hughjfchen joins (~hughjfche@vmi556545.contaboserver.net)
04:19:07 → ezzieyguywuf joins (~Unknown@user/ezzieyguywuf)
04:20:37 → odnes joins (~odnes@5-203-249-68.pat.nym.cosmote.net)
04:20:45 → Natch joins (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se)
04:20:53 → AlexZenon joins (~alzenon@178.34.160.206)
04:21:55 × chexum quits (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.)
04:23:32 → chexum joins (~quassel@gateway/tor-sasl/chexum)
04:27:05 → _73 joins (~user@pool-108-49-252-36.bstnma.fios.verizon.net)
04:30:19 → echoreply joins (~echoreply@2001:19f0:9002:1f3b:5400:ff:fe6f:8b8d)
04:30:30 → Guest1698 joins (~Guest1698@20.83.116.49)
04:31:00 → drewr joins (~drew@user/drewr)
04:31:10 → tv joins (~tv@user/tv)
04:31:18 × yauhsien quits (~yauhsien@61-231-23-53.dynamic-ip.hinet.net) (Ping timeout: 264 seconds)
04:45:54 → yrlnry joins (~yrlnry@pool-108-2-150-109.phlapa.fios.verizon.net)
04:48:44 → yauhsien joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
04:50:42 × yrlnry quits (~yrlnry@pool-108-2-150-109.phlapa.fios.verizon.net) (Ping timeout: 268 seconds)
04:58:10 × odnes quits (~odnes@5-203-249-68.pat.nym.cosmote.net) (Remote host closed the connection)
05:18:49 × mvk quits (~mvk@2607:fea8:5ce3:8500::4588) (Ping timeout: 248 seconds)
05:18:58 × Kaipei quits (~Kaiepi@156.34.47.253) (Ping timeout: 240 seconds)
05:31:05 × Teacup quits (~teacup@user/teacup) (Quit: No Ping reply in 180 seconds.)
05:32:42 → Teacup joins (~teacup@user/teacup)
05:41:13 → michalz joins (~michalz@185.246.204.107)
05:42:40 → mjs22 joins (~mjs22@76.115.19.239)
05:48:14 → causal joins (~user@50.35.83.177)
05:48:34 → takuan joins (~takuan@178-116-218-225.access.telenet.be)
05:48:42 → mbuf joins (~Shakthi@122.164.15.152)
05:50:18 → _ht joins (~quassel@231-169-21-31.ftth.glasoperator.nl)
05:57:08 → jpds1 joins (~jpds@gateway/tor-sasl/jpds)
06:19:34 → acidjnk_new joins (~acidjnk@dynamic-046-114-169-114.46.114.pool.telefonica.de)
06:23:44 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:9:59a4:5055:fd8c) (Remote host closed the connection)
06:24:26 × mixfix41 quits (~sdenynine@user/mixfix41) (Ping timeout: 268 seconds)
06:24:27 × _ht quits (~quassel@231-169-21-31.ftth.glasoperator.nl) (Remote host closed the connection)
06:25:25 × HotblackDesiato quits (~HotblackD@gateway/tor-sasl/hotblackdesiato) (Remote host closed the connection)
06:25:28 → jgeerds joins (~jgeerds@55d45f48.access.ecotel.net)
06:25:46 → HotblackDesiato joins (~HotblackD@gateway/tor-sasl/hotblackdesiato)
06:26:32 → vysn joins (~vysn@user/vysn)
06:31:57 × Sgeo_ quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer)
06:37:16 → dsrt^ joins (~dsrt@50.237.44.186)
06:42:36 × chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
06:45:01 → chexum joins (~quassel@gateway/tor-sasl/chexum)
06:50:39 → leeb joins (~leeb@KD106155002239.au-net.ne.jp)
06:57:28 × kimjetwav quits (~user@2607:fea8:2340:da00:1282:4dfa:aaca:27db) (Remote host closed the connection)
06:57:53 → kimjetwav joins (~user@2607:fea8:2340:da00:b4b3:9de1:4864:1487)
06:59:02 → BusConscious joins (~martin@ip5f5bdedc.dynamic.kabel-deutschland.de)
07:00:15 × kimjetwav quits (~user@2607:fea8:2340:da00:b4b3:9de1:4864:1487) (Remote host closed the connection)
07:00:40 → kimjetwav joins (~user@2607:fea8:2340:da00:487c:b90f:99a5:bda3)
07:01:36 <BusConscious> hello everyone
07:01:40 <BusConscious> Could not find module ‘Data.ByteString.UTF8’
07:02:16 <BusConscious> What's going on there? I do have bytestring installed both globally and locally as dependency in my cabal
07:02:16 → jonathanx joins (~jonathan@dyn-5-sc.cdg.chalmers.se)
07:02:30 <Axman6> do you have a version of bytestring which has that module installed?
07:02:30 <BusConscious> and I can import Data.ByteString
07:02:45 → Infinite joins (~Infinite@2405:204:5381:d6e2:eefe:bfdb:b3b1:f5f4)
07:02:50 <Axman6> https://hackage.haskell.org/package/bytestring doesn't export that module
07:03:26 <tomsmeding> BusConscious: utf8-string exports that
07:03:36 <tomsmeding> what docs told you it was in 'bytestring'?
07:04:27 <BusConscious> I want to convert Strings to ByteStrings back and forth
07:04:38 <Axman6> I'm pretty sure it's never been part of bytestring
07:04:45 <BusConscious> (I don't want to do that, but I have to)
07:04:48 <Axman6> Have you looked at the text package?
07:04:52 <tomsmeding> I've been using utf8-string for that, seems to work well enough
07:04:58 <tomsmeding> that exports Data.ByteString.UTF8
07:06:01 × lagash quits (lagash@lagash.shelltalk.net) (Ping timeout: 248 seconds)
07:08:10 → dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net)
07:08:13 <BusConscious> ok that seems to work
07:08:30 × kimjetwav quits (~user@2607:fea8:2340:da00:487c:b90f:99a5:bda3) (Ping timeout: 264 seconds)
07:08:35 <Axman6> BusConscious: can you tell us more about what you actually want to do? because working with text is usually something we'd do using the text package
07:08:36 × frost quits (~frost@user/frost) (Quit: Client closed)
07:12:58 × bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
07:13:57 → bitdex joins (~bitdex@gateway/tor-sasl/bitdex)
07:14:20 <BusConscious> Axman6: So I'm trying to write a unix shell and people here have been telling me to not use String to represent filepaths and my string, because there is no requirement in POSIX, that these things should be utf-8 or whatever, which is an argument I can see for sure
07:14:30 → gmg joins (~user@user/gehmehgeh)
07:15:18 <tomsmeding> but you _are_ convering some things to String at some point, apparently
07:16:05 <tomsmeding> I guess what Axman6 is getting at is that you can probably replace all your uses of String with Text
07:16:05 <BusConscious> yes, because it's so much easier to work with and a lot of functions in the library only accept String
07:16:15 <BusConscious> https://hackage.haskell.org/package/unix-2.7.2.2/docs/System-Posix-IO.html
07:16:32 <tomsmeding> BusConscious: that sounds like a weird argument. We want to represent non-utf8 things, but then we work with it as strings because that's easier
07:16:56 <BusConscious> Even in the POSIX API FilePath is accepted which is a type synonym of String
07:17:24 <tomsmeding> right
07:17:50 → elkcl_ joins (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru)
07:17:58 × elkcl quits (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) (Ping timeout: 240 seconds)
07:17:58 elkcl_ is now known as elkcl
07:18:06 <tomsmeding> bytestring does have IO functions, but not to FDs https://hackage.haskell.org/package/bytestring-0.11.3.1/docs/Data-ByteString.html#v:hPut
07:18:41 <tomsmeding> like, if you're doing the IO in String form, why even use ByteString internally
07:20:20 <BusConscious> ok so I should stick to either String or Text? On the other hand I might have to use FFI again and converting to and from a CString may be easier with a ByteString..
07:20:31 <BusConscious> or I use text
07:20:43 <tomsmeding> if you want to avoid assuming UTF8, you should stick to ByteString :p
07:20:49 → benin0 joins (~benin@183.82.26.120)
07:20:56 <tomsmeding> https://hackage.haskell.org/package/base-4.14.0.0/docs/GHC-IO-FD.html has FD I/O functions, though with Ptr
07:21:11 <tomsmeding> if you are okay with assuming UTF8, use Text
07:21:23 tomsmeding is guilty of over-using String as well, but am lazy
07:21:45 → coot joins (~coot@213.134.190.95)
07:22:17 <tomsmeding> (that String argument to the read and write functions is simply a function name used in error messages)
07:22:34 → acidjnk joins (~acidjnk@dynamic-046-114-169-114.46.114.pool.telefonica.de)
07:23:19 → Everything joins (~Everythin@37.115.210.35)
07:24:17 → eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:9:59a4:5055:fd8c)
07:24:38 → mc47 joins (~mc47@xmonad/TheMC47)
07:25:11 → lortabac joins (~lortabac@2a01:e0a:541:b8f0:2cd:7ecf:235f:1481)
07:25:18 × acidjnk_new quits (~acidjnk@dynamic-046-114-169-114.46.114.pool.telefonica.de) (Ping timeout: 240 seconds)
07:26:08 → ubert joins (~Thunderbi@p200300ecdf0da56677798f1bce3bed29.dip0.t-ipconnect.de)
07:27:16 <BusConscious> I think I will stick with String for now. It may not be ideal because it assumes UTF8, but having to competing string types is such a pain in the ass. I won't get any joy out of fiddling all these types together.
07:27:41 <tomsmeding> if the goal is having fun, then do whatever you want :p
07:27:51 → mixfix41 joins (~sdenynine@user/mixfix41)
07:28:14 <tomsmeding> if you were writing production software, I would advise heeding the advice here more
07:28:17 → ccntrq joins (~Thunderbi@dynamic-077-003-064-244.77.3.pool.telefonica.de)
07:28:21 <tomsmeding> but don't let the real world spoil the fun
07:28:57 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:9:59a4:5055:fd8c) (Ping timeout: 248 seconds)
07:30:05 <BusConscious> One last Q: What happens if I write something like "\xff" in haskell? How is that represented byte-wise?
07:30:22 <Axman6> BusConscious: you've actually come across one of the more complicated situations where it's not immediately clear what you should use - for IO of data, it sounds like ByteString is the way to go, just (for now) assume you don't need to care about encoding; if you're piping strout from one process into another's stdin, just send whatever bytes you get. as for file paths, that is more complex, because Haskell's use of String is not a good choice
07:31:26 <tomsmeding> BusConscious: https://tomsmeding.com/ss/get/tomsmeding/SX1k9z
07:31:41 → ccntrq1 joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
07:31:49 × rendar quits (~rendar@user/rendar) (Ping timeout: 244 seconds)
07:32:03 <Axman6> BusConscious: describing them as competing string types isn't really fair, they all have their uses and their own tradeoffs
07:32:57 × ccntrq quits (~Thunderbi@dynamic-077-003-064-244.77.3.pool.telefonica.de) (Ping timeout: 256 seconds)
07:32:57 ccntrq1 is now known as ccntrq
07:33:29 <Axman6> "\xff" depends on what type that string looking thing is. if it's a haskell String, then you'll just have ['\xff']. if it's a text (2.0) it'll be the two byte encoding of the codepoint for 255
07:34:56 <Axman6> if it's a text < 1.0 Text, then it'll be the UTF-16 string with the codepoint 255 in it
07:35:29 <BusConscious> So what is '\xff' then is it a two byte encoding of the codepoint 255 as well?
07:35:45 <tomsmeding> '\xff' of type Char?
07:35:49 <BusConscious> yes
07:35:51 <Axman6> '\xff' is a Char, which represents a unicode codepoint
07:36:03 <tomsmeding> Char is just an Int internally
07:36:11 <Axman6> @src Char
07:36:11 <lambdabot> data Char = C# Char#
07:36:16 <Axman6> @src Char#
07:36:16 <lambdabot> Source not found. There are some things that I just don't know.
07:36:19 <Axman6> :(
07:36:48 <tomsmeding> https://hackage.haskell.org/package/ghc-prim-0.8.0/docs/src/GHC.Prim.html#Char%23
07:36:54 <Axman6> but ywah, Char# is basically (or actually?) an Int# (or Int32#?)
07:37:00 × Infinite quits (~Infinite@2405:204:5381:d6e2:eefe:bfdb:b3b1:f5f4) (Ping timeout: 252 seconds)
07:37:02 <BusConscious> Unicode sequences can be at most 3 or 4 bytes right, so they fit in a Int32
07:37:02 <tomsmeding> seems to be a primitive type
07:37:05 <BusConscious> makes sense
07:37:36 <Axman6> Chars are not utf-8 sequences, they are codepoints, they're just a number
07:37:48 → Infinite joins (~Infinite@49.39.123.213)
07:38:14 <Axman6> utf-8 is an encoding, which is what text now uses internally (it used to use utf-16, which was the worst of both worlds of utf-8 and utf-32)
07:38:39 → eod|fserucas joins (~eod|fseru@193.65.114.89.rev.vodafone.pt)
07:38:43 → eod|fserucas_ joins (~eod|fseru@193.65.114.89.rev.vodafone.pt)
07:39:16 <Axman6> A Char may be written, when encoded as utf-8, using 1, 2, 3 or 4 bytes, but a Char is always a 32 bit integer (probably, can't confirm from the link above but I believe that's true)
07:39:19 <tomsmeding> finally, found the definition https://hackage.haskell.org/package/base-4.16.0.0/docs/src/GHC.Base.html#line-189
07:39:37 <tomsmeding> sizeOf on Char returns 4, so presumably
07:45:54 × jgeerds quits (~jgeerds@55d45f48.access.ecotel.net) (Ping timeout: 276 seconds)
07:46:18 × jonathanx quits (~jonathan@dyn-5-sc.cdg.chalmers.se) (Ping timeout: 240 seconds)
07:47:09 × Infinite quits (~Infinite@49.39.123.213) (Quit: Client closed)
07:47:27 → kuribas joins (~user@ip-188-118-57-242.reverse.destiny.be)
07:48:59 → machinedgod joins (~machinedg@66.244.246.252)
07:51:42 × dsrt^ quits (~dsrt@50.237.44.186) (Ping timeout: 264 seconds)
07:51:56 → MajorBiscuit joins (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl)
07:53:21 × mjs22 quits (~mjs22@76.115.19.239) (Quit: Leaving)
07:54:42 → progress__ joins (~fffuuuu_i@45.112.243.220)
07:54:56 × raym quits (~raym@user/raym) (Remote host closed the connection)
07:58:10 AlexNoo_ is now known as AlexNoo
08:03:40 → nate4 joins (~nate@98.45.169.16)
08:06:28 → gurkenglas joins (~gurkengla@dslb-002-207-014-022.002.207.pools.vodafone-ip.de)
08:08:10 × nate4 quits (~nate@98.45.169.16) (Ping timeout: 240 seconds)
08:10:33 → Guest92 joins (~Guest92@2600:1000:b166:c4f9:ac93:f08:cf56:c856)
08:10:40 ← Guest92 parts (~Guest92@2600:1000:b166:c4f9:ac93:f08:cf56:c856) ()
08:11:04 × tzh quits (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz)
08:11:55 <merijn> Axman6: tbh, probably more :p
08:11:58 <merijn> Axman6: Char is boxed
08:12:59 <merijn> I like how 20(?) year after it was written I still have to link people to Joel's unicode blog
08:13:59 <Maxdamantus> I wonder when there'll be a standard Unicode string type in Haskell.
08:14:19 <Maxdamantus> (rather than one that's only limited to well-formed Unicode strings)
08:16:11 → Kaipei joins (~Kaiepi@156.34.47.253)
08:16:22 → jonathanx joins (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se)
08:18:47 <merijn> Maxdamantus: Please define well-formed unicode string :D
08:18:52 <merijn> See you in about a year
08:19:28 <merijn> oh, wait, I read that inverted
08:19:56 <Maxdamantus> merijn: these things are clearly defined in the Unicode standard. The `Text` library is limited to well-formed Unicode strings, but according to the Unicode standard, Unicode strings are not necessarily well-formed and are specifically allowed to be any sequence of code units (of a particular type).
08:20:58 <Maxdamantus> and the string libraries that are backed by the Unicode consortium (eg, ICU and Java `String`s) work according to the standard.
08:21:25 <merijn> Maxdamantus: I don't think Text is limited to well-formed unicode, is it?
08:21:51 <Maxdamantus> merijn: it certainly was last time I looked at it (when it was opaquely based on UTF-16).
08:22:21 <Maxdamantus> aiui they switched from opaque UTF-16 to opaque UTF-8, but that's mostly an implementation detail, since they don't support storing arbitrary code units.
08:22:26 <merijn> Maxdamantus: I mean, you can always use ByteString and text-icu for more niche use cases
08:22:31 → cfricke joins (~cfricke@user/cfricke)
08:22:38 → chomwitt joins (~chomwitt@2a02:587:dc0d:e600:1174:892d:39e3:5e01)
08:22:58 <Maxdamantus> Right, but I meant I was wondering when there'd be a reasonably ubiquitous Unicode string type.
08:23:18 <Maxdamantus> It's kind of crap that Unicode is only handled properly if you use `ByteString`s or ICU
08:23:18 <merijn> What purpose would that serve/
08:23:47 <merijn> I mean, you seem to have a very specific and niche definition of "handled properly" that is not helpful to 99% of code
08:23:47 <Maxdamantus> People could write proper APIs involving things like file names.
08:24:03 <merijn> Maxdamantus: No, that wouldn't be fixed by that
08:24:16 <merijn> Since the fundamental problem is file name APIs being different across platforms
08:24:41 → Neuromancer joins (~Neuromanc@user/neuromancer)
08:24:41 <Maxdamantus> There's a fairly sane way of representing them as UTF-8 strings on all of the common platforms.
08:25:00 × dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.5)
08:25:16 → eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e)
08:25:19 <Maxdamantus> particularly, pass through the bytes as-is on POSIX systems, and convert to WTF-8 on win32.
08:25:52 <tomsmeding> how is a sequence of random bytes (not including 0 and '/', okay) even a non-well-formed unicode string
08:26:01 <tomsmeding> in what encoding
08:26:04 <merijn> Maxdamantus: Windows filenames are explicitly UTF-16 on windows
08:26:14 <merijn> Maxdamantus: On linux they're "nothing remotely resembling unicode"
08:26:43 <merijn> On macOS they're "UTF-16, except that's no longer enforced by the low level filesystem APIs, only the high level ones, RIP you"
08:26:44 <Maxdamantus> tomsmeding: a Unicode string is a sequence of code units. In particular, a UTF-8 Unicode string is a sequence of bytes.
08:27:04 <Maxdamantus> I can quote the Unicode standard.
08:27:11 <tomsmeding> Maxdamantus: right, and not every linux filename is valid utf8. They _are_ all valid latin1, but then every byte sequence is valid latin1
08:27:23 <tomsmeding> but using latin1 encoding for windows filenames makes no sense
08:27:37 <Maxdamantus> tomsmeding: assuming by "valid" you mean "well-formed", that's not what I'm talking about.
08:27:49 <Maxdamantus> https://www.unicode.org/versions/Unicode14.0.0/ch03.pdf#G7404
08:27:52 <merijn> Maxdamantus: No, valid means "it's actually unicode"
08:28:10 <Maxdamantus> merijn: no.
08:28:12 <Maxdamantus> > D80 Unicode string: A code unit sequence containing code units of a particular Unicode
08:28:13 <lambdabot> <hint>:1:64: error: parse error on input ‘of’
08:28:15 <Maxdamantus> encoding form.
08:28:28 <Maxdamantus> D78 Code unit sequence: An ordered sequence of one or more code units
08:28:33 <Maxdamantus> When the code unit is an 8-bit unit, a code unit sequence may also be referred
08:28:33 <Maxdamantus> to as a byte sequence.
08:28:48 <Maxdamantus> "Unicode string" does *NOT* mean well-formed (or "valid") Unicode.
08:28:59 <Maxdamantus> The Unicode standard makes that fairly explicit in various places.
08:29:10 <tomsmeding> Maxdamantus: so for my understanding, removing well-formedness from the requirements not only makes incompatible sequences of code points allowed (e.g. modifiers that don't work on particular characters, or unpaired surrogates), but also something that doesn't even decode as individual utf8 code points?
08:29:13 <Maxdamantus> if you look up "Unicode string" in the glossary, they will even explicitly say that there.
08:29:28 <Maxdamantus> > Unicode String. A code unit sequence containing code units of a particular Unicode encoding form (whether well-formed or not). (See definition D80 in Section 3.9, Unicode Encoding Forms.)
08:29:29 <lambdabot> <hint>:1:60: error: parse error on input ‘of’
08:29:35 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e) (Ping timeout: 255 seconds)
08:29:38 <merijn> Maxdamantus: That disagrees what you're saying
08:29:45 <merijn> Maxdamantus: "a code unit sequence"
08:29:59 <Maxdamantus> merijn: right, that's what I've been saying.
08:29:59 <merijn> Maxdamantus: "Code unit: The minimal bit combination that can represent a unit of encoded text"
08:30:02 <merijn> for processing or interchange.
08:30:23 <merijn> Maxdamantus: I interpret that to mean only include *valid* encodings of unit code codepoints
08:30:38 <merijn> not all byte sequences are made up of only valid unicode codepoint encodings
08:30:50 <Maxdamantus> merijn: so what would be an example of a Unicode string that is not well-formed?
08:31:12 <merijn> Maxdamantus: A well-formed one says certain unicode codepoints can only occur before/after certain types of characters
08:31:17 <tomsmeding> Maxdamantus: is [\x80] a non-well-formed unicode string in utf8?
08:31:23 <merijn> think of "accent modifiers" like ` ' ^
08:31:27 <Maxdamantus> merijn: no. That's not what well-formedness is.
08:31:39 <Maxdamantus> merijn: well-formedness does not involve interpretation of code points.
08:32:02 <tomsmeding> ah, see D84
08:32:10 <Maxdamantus> merijn: well-formed simply means that it represents a sequence of Unicode scalar values.
08:32:41 <Maxdamantus> merijn: USVs can even be undefined, and you still have a well-formed Unicode string.
08:33:04 <tomsmeding> representing a non-well-formed unicode string then basically means either 1. storing (original bytes, purported encoding), or 2. some ugly sum type with various decode failures as options
08:33:11 <merijn> "Ill-formed: A Unicode code unit sequence that purports to be in a Unicode encoding"
08:33:14 <merijn> form is called ill-formed if and only if it does not follow the specification of that Unicode encoding form.
08:33:26 <tomsmeding> merijn: see the second bullet point under D84 about UTF8
08:33:30 <Maxdamantus> Feel free to read the Unicode standard. I'm quite familiar with chapter 3, which defines all of these things.
08:33:56 <Maxdamantus> merijn: right, the Unicode forms are "UTF-8", "UTF-16" and "UTF-32".
08:34:09 <merijn> Maxdamantus: You suggested utf-8 for linux filenames
08:34:15 <Maxdamantus> merijn: those exist independently of any interpretation of actual code points. That happens elsewhere in the standard.
08:34:22 <merijn> Maxdamantus: linux filenames are ill-formed per D84
08:34:42 <merijn> anyway, meeting
08:34:49 <tomsmeding> merijn: hence Maxdamantus is suggesting using a string type that can represent non-well-formed strings
08:34:54 <Maxdamantus> merijn: right, I would suggest treating filenames as UTF-8 Unicode strings, just ones that are not necessarily well-formed (aka, not necessarily "in UTF-8")
08:35:21 <merijn> Which seems rather inferior to the strictly more correct ByteString representation
08:35:28 <tomsmeding> Maxdamantus: how much of a performance penalty do you get from using such an implementation, as compared to one that can assume its internal representation _is_ well-formed
08:35:39 <tomsmeding> and what gains do you get :p
08:36:11 <tomsmeding> I'd expect that the only time when you want to get the "text-like" data in a linux filename is when you want to show it to the user -- and at that point you can just do a lenient UTF8 decode
08:36:19 <Maxdamantus> tomsmeding: it's a negative penalty. You pay a penalty when using restrictively well-formed strings because you need to check that the string is well-formed when reading it.
08:36:42 <Maxdamantus> tomsmeding: there's some interesting commentary around that in the documentation for Rust's `bstr` package.
08:37:07 <Maxdamantus> where the author gives examples of things like treating a mmapped file as a string.
08:37:36 <Maxdamantus> you can't do that if the string library requires the bytes be well-formed, since you'd have to scan through the entire file to check it before allowing it to be used.
08:37:43 × shriekingnoise quits (~shrieking@201.212.175.181) (Quit: Quit)
08:37:45 <Maxdamantus> https://docs.rs/bstr/latest/bstr/
08:39:06 × Henkru quits (henkru@kapsi.fi) (Ping timeout: 264 seconds)
08:39:11 <Maxdamantus> I don't think there would be any significant performance benefits in any cases by restricting to well-formed strings.
08:39:19 ← acidjnk parts (~acidjnk@dynamic-046-114-169-114.46.114.pool.telefonica.de) (Leaving)
08:39:20 <kritzefitz> Maxdamantus: regardless of performance, having to expect Texts to contain invalid encodings sounds like a nightmare to me. It's already a common enough pitfall to assume that any input you receive is well encoded, having to catch those failures on almost all Text operations would be far harder to handle than just having to catch failures when decoding.
08:39:26 <Maxdamantus> it only has negative performance impacts due to the extra checking that needs to be done at boundaries.
08:39:35 → Henkru joins (henkru@kapsi.fi)
08:40:13 <Maxdamantus> kritzefitz: that shouldn't be necessary.
08:40:42 <Maxdamantus> kritzefitz: the only operation that could "fail" would be iterating through code points, and that iterator could transparently emit replacement characters by default.
08:40:52 <tomsmeding> though UnnormText.unpack would return an Either
08:40:58 <Maxdamantus> (not that iterating through code points is a particularly common operation)
08:41:05 <tomsmeding> right
08:42:27 <Maxdamantus> What's `UnnormText.unpack`?
08:42:45 <Maxdamantus> in general these things shouldn't need to produce errors.
08:42:47 <tomsmeding> the unpack :: Text -> [Char] function of this hypothetical haskell library that implements non-well-formed strings
08:43:08 <tomsmeding> unless you expect it to round-trip with [Char] -> Text
08:43:19 <tomsmeding> that's going to fail if there are encoding errors in the bytestring
08:44:11 <tomsmeding> so you'd have unpackStrict :: Text -> Maybe [Char], or unpackStrict' :: Text -> [Either Word8 Char], or unpackLenient :: Text -> [Char] that replaces stuff with U+FFFD
08:44:18 <Maxdamantus> Right, I'd probably just expect it to emit replacement characters.
08:44:46 <Maxdamantus> since that's the normal thing to do when encountering errors while converting between Unicode representations.
08:45:14 <tomsmeding> I'd also want a round-tripping version, or at least one that alerts me that round-tripping isn't going to work
08:45:28 <Maxdamantus> eg, I suspect that's what will happen if you open a web browser console and do `document.body.innerHTML = "hello \ud800 world";`
08:45:49 <tomsmeding> it's not like we're dealing with the whole zoo of weird unicode encodings where you have 100% chance that _something_ in your text is going to be unrepresentable in one of those encodings
08:46:06 <tomsmeding> Maxdamantus: yes, but there we're dealing with UI :p
08:46:18 <tomsmeding> but yes, mostly one would use my unpackLenient
08:46:31 <tomsmeding> interesting, didn't think of this as an issue before
08:46:57 <tomsmeding> purists would say "what even are you thinking, linux filenames are not intended to be utf8 so treat them as bytestrings"
08:47:06 <tomsmeding> but practice says "well mostly they're utf8 mostly"
08:47:19 <Maxdamantus> Hm, interestingly Firefox actually renders the UTF-16 code unit as an error, and it converts it to a replacement character when doing something like copying to the clipboard. That's quite neat.
08:47:57 <kritzefitz> Maxdamantus: What do you expect to gain from a Text representation that allows badly encoded underlying bytestrings? Keeping the original bytes in a ByteString and only decoding when you want to do something that explicitly requires code points seems to me like it gets you the same behavior as you described.
08:48:22 <Maxdamantus> After people fix Unicode handling in programming languages, that's my next desire: text applications should be able to render UTF-8 errors, and it should be possible to copy the ill-formed UTF-8 arround without losing information.
08:48:34 <tomsmeding> kritzefitz: it would only give you convenience
08:49:05 <tomsmeding> Maxdamantus's example of Rust's bstr library explicitly says that most of its functionality you can obtain by piecing together existing code that e.g. does regex stuff on bytestrings
08:49:27 × Henkru quits (henkru@kapsi.fi) (Ping timeout: 256 seconds)
08:49:36 <Maxdamantus> kritzefitz: it means you can use the correct type for things. Things like filenames should be strings, not `ByteStrings`, and they should have convenient handling of Unicode.
08:50:07 <Maxdamantus> kritzefitz: at the moment, API designers have to decide whether to use `ByteString` for correctness or `Text` for convenience.
08:50:25 <Maxdamantus> kritzefitz: if `Text` handled ill-formed Unicode strings, you'd get both with one type.
08:50:54 <kritzefitz> But what convenient handling of unicode do you get? When is a Text actually more convenient if you're not allowed to assume that it contains only valid code points?
08:51:07 × foul_owl quits (~kerry@23.82.194.107) (Ping timeout: 260 seconds)
08:51:28 <Maxdamantus> kritzefitz: if `Text` is not more convenient, then why doesn't everyone just use `ByteString` for things like filenames or user input?
08:53:24 <merijn> Maxdamantus: Why should filenames be strings?
08:53:43 <tomsmeding> Maxdamantus: suggestion if you pitch this to people: avoid getting the unicode spec out. The argument does not rest on "non-well-formed" being defined by the unicode spec; the argument rests on convenience in software engineering. When you throw specs at people, they throw specs back, and the spec for linux filenames is _not_ that they are unicode
08:53:49 <tomsmeding> never mind reality where they mostly are
08:53:59 <tomsmeding> (but not always)
08:54:27 <merijn> Also, the ability to assume that any Text in your codebase will always remain valid unicode is pretty huge
08:54:28 <Maxdamantus> merijn: because there should be a ubiquitous string type for text.
08:54:29 <tomsmeding> the unicode spec just gives you precedent for your terminology, which is nice but not essential to the pitch
08:54:49 <merijn> Maxdamantus: Says who?
08:55:10 <merijn> If anything, I think we need *more* string types and better support for being polymorphic over them
08:55:31 <tomsmeding> (current IsString is awful for that)
08:55:49 <Maxdamantus> But what's the advantage of having the other string types?
08:55:53 <merijn> tomsmeding: I proposed a better interface for IsString and other polymorphic literals
08:56:03 <merijn> Maxdamantus: Different types are optimised for different uses
08:56:17 <merijn> tomsmeding: That's what led to validated-literals :p
08:56:25 <Maxdamantus> merijn: optimised in terms of API convenience, or optimised in terms of performance?
08:56:32 <merijn> Both
08:56:50 <merijn> Your proposal is less convenient for both for 99% of code
08:56:59 <Maxdamantus> I don't think you're going to get better performance by having different string types (in particular, I explained how it results in worse performance)
08:57:23 <Maxdamantus> and I don't think you get better API convenience either. As I said, it means that API designers have to pick from various string types.
08:57:55 <merijn> Maxdamantus: "i can never trust any string in my entire codebase" is a pretty fucking massive downgrade in API usability, no matter what else you propose
08:58:05 <Maxdamantus> which string library do I import again when using library xyz?
08:58:28 → raym joins (~raym@user/raym)
08:58:33 <merijn> Maxdamantus: See aforementioned point of "I'd rather get better solutions for being polymorphic across string types"
08:58:37 → arthurs115 joins (~arthurs11@163.5.10.155)
08:59:15 <merijn> because that will be useful for lots of other things too
08:59:21 <Maxdamantus> merijn: what do you mean by "trust any string"? Do you trust the string "􏿿"?
08:59:48 <merijn> Maxdamantus: "any string I make by combining well-formed Text will be well-formed Text"
08:59:50 <Maxdamantus> is "􏿿" more trustable than a string containing ill-formed UTF-8.
08:59:55 <Maxdamantus> s/.$/?/
09:00:10 × emliunix quits (~emliunixm@2001:470:69fc:105::2:12d1) (Quit: You have been kicked for being idle)
09:00:10 <merijn> Yes
09:00:27 <merijn> Because the former is much more well-behaved
09:00:29 → emliunix joins (~emliunixm@2001:470:69fc:105::2:12d1)
09:00:50 <Maxdamantus> It wouldn't be more well-behaved if there's only one string type.
09:00:59 <Maxdamantus> The behaviours only occur when converting between encodings.
09:01:13 <Maxdamantus> part of the point is to avoid converting between encodings.
09:01:29 ← emliunix parts (~emliunixm@2001:470:69fc:105::2:12d1) ()
09:01:31 <Maxdamantus> UTF-16 is dying out, so that shouldn't be a major concern.
09:02:02 <Maxdamantus> most string handling should be taking UTF-8 bytes from a network or filesystem and sending them back to the network or filesystem.
09:03:16 <kritzefitz> Maxdamantus: I think I mostly use Text to be able to handle unicode regardless of the underlying encoding and the sense of security merijn mentioned. For the cases that you mention, where you only retrieve UTF-8 from somewhere and only pass it back relatively unmodified, I really don't see why Text would be more convenient than ByteString.
09:03:24 <Maxdamantus> there might also be some awkwardness when converting to Haskell `String`s (aka, `[Char]`), but those issues already exist with `Text`
09:03:48 <Maxdamantus> eg, "\55296" is a possible `String`, but it can't be converted to `Text`.
09:04:01 <merijn> Maxdamantus: ???
09:04:11 <merijn> ALL strings are by definition convertible to Text
09:04:21 <Maxdamantus> merijn: I'm pretty sure that one isn't.
09:04:24 <merijn> Why?
09:04:28 <kritzefitz> Also I don't think the assumption that everything is UTF-8 and you don't need to care about other encodings is valid for a general purpose language. There are tons of contexts that need to deal with all kinds of encodings and they're not likely to go away.
09:04:33 <merijn> > text "\55296"
09:04:34 <lambdabot> mueval-core: <stdout>: hPutChar: invalid argument (invalid character)
09:04:36 <BusConscious> merijn: As you say I would be more inclined to use ByteString, if I could use it like a normal string in an overloaded syntax and if things like Text.Parsec.ByteString had the same functionality as say Text.Parsec.String
09:04:44 → foul_owl joins (~kerry@23.82.194.107)
09:04:55 <Maxdamantus> merijn: because it can't be encoded as a well-formed Unicode string.
09:04:58 <merijn> > generalCategory '\55296'
09:04:59 <lambdabot> Surrogate
09:05:20 <merijn> > text "\55296a"
09:05:22 <lambdabot> mueval-core: <stdout>: hPutChar: invalid argument (invalid character)
09:05:24 <Maxdamantus> merijn: none of the Unicode encoding forms allow that code point to be encoded (it is not a Unicode scalar value).
09:06:48 → chele joins (~chele@user/chele)
09:07:15 <kritzefitz> merijn: Apparently `Data.Text.pack "\55296"` has the same result as `Data.Text.pack "\65533"`.
09:07:40 <Maxdamantus> "\65533" is U+FFFD, ie, the replacement character.
09:08:04 <Maxdamantus> so that means that `pack` is emitting replacement characters on error, which is the behaviour I said is reasonable earlier.
09:10:02 → benin02 joins (~benin@183.82.26.120)
09:12:10 × benin0 quits (~benin@183.82.26.120) (Ping timeout: 268 seconds)
09:12:10 benin02 is now known as benin0
09:12:28 <kritzefitz> Maxdamantus: From what you said, it seems to me like we would need a new type MaybeInvalidText that preserves it's original encoding, while mostly acting like a Text. And I'm not trying to be argumentative here, but I really don't see when I gain from using it over a ByteString and I also didn't find your previous comments on that very enlightening. Can you give some example when it would do something for you ByteString can't?
09:12:30 × jmdaemon quits (~jmdaemon@user/jmdaemon) (Quit: ZNC 1.8.2 - https://znc.in)
09:13:47 <Maxdamantus> kritzefitz: it's useful because it can become the defacto string type. I suspect there are various APIs in Haskell that treat filenames as either `ByteString`, `String` or `Text`.
09:14:04 <Maxdamantus> kritzefitz: preferably there would only be one type for representing filenames.
09:14:35 <Maxdamantus> kritzefitz: and preferably there should be no cost (development or performance-wise) when using such strings for different purposes.
09:14:37 <kritzefitz> Ah, ok. I guess then I don't follow, because I just don't agree on the premise, that there needs to be one defacto string type.
09:15:51 <Maxdamantus> If I want to write a program that scans a directory and prints the filenames to standard out, I shouldn't have to convert from the `FileName` string type to the `PuttableString` string type.
09:16:19 <Maxdamantus> filenames are strings, and I can print strings to standard out.
09:16:56 <Maxdamantus> the "hello world" program shouldn't be converting to `ByteString` just because standard out is technically a binary file.p
09:17:34 × ubert quits (~Thunderbi@p200300ecdf0da56677798f1bce3bed29.dip0.t-ipconnect.de) (Remote host closed the connection)
09:17:52 → ubert joins (~Thunderbi@p200300ecdf0da56600626fc30d47cd25.dip0.t-ipconnect.de)
09:17:58 × progress__ quits (~fffuuuu_i@45.112.243.220) (Quit: Leaving)
09:20:10 <kritzefitz> I really don't see why you're so afraid of converting between things. Explicit conversion gives you the ability to actually specifiy things like what to do one errors. Having a one-size-fits-all typically leads to wrong behavior that you have no influence over.
09:20:58 <kritzefitz> And forcing people to actually mention the conversion explicitly forces them to think about what they're actually trying to do. Not having to think about the conversion will often mean being later surprised when it doesn't do what you intended.
09:21:22 <Maxdamantus> because conversion is not always possible. either information is lost (errors replaced by replacement characters), or errors are raised.
09:22:07 <Maxdamantus> if there's no fear in converting between things, there wouldn't be an API in Haskell that treats filenames as `ByteString`.
09:23:09 <Maxdamantus> https://hackage.haskell.org/package/unix-2.7.2.2/docs/System-Posix-ByteString.html#t:RawFilePath
09:23:45 <Maxdamantus> If there's no problem with conversion, they'd just have `type RawFilePath = Text` or `type RawFilePath = String`.
09:23:55 <sm> tuning in late, I'm sure it was already said, but filenames aren't strings
09:24:15 <kritzefitz> Using error replacements or raising errors is IMO a good thing. If you don't want that, you probably don't want Text. If you need a Text, you have to deal with the errors in some way anyway.
09:24:25 <Maxdamantus> They're not Haskell strings at least, but they are Unicode strings (aka, bytestrings in the case of UTF-8).
09:24:53 sm invokes maerwald
09:24:59 <Maxdamantus> sm: (earlier on I pointed out that standard Unicode strings are not necessarily well-formed, and that the standard describes UTF-8 as effectively equivalent to "bytestrings")
09:25:43 <Maxdamantus> anyway, it's also getting kind of late for me, need to do other stuff this evening.
09:26:11 <sm> very well, carry on!  👍🏻
09:28:38 <merijn> Maxdamantus: Unix package has lots of questionable API design regardless, tbh
09:32:41 → jgeerds joins (~jgeerds@55d45f48.access.ecotel.net)
09:40:22 → justromeon joins (~justromeo@120.29.68.81)
09:41:21 × justromeon quits (~justromeo@120.29.68.81) (Client Quit)
09:41:45 → justromeon joins (~justromeo@120.29.68.81)
09:44:06 × yauhsien quits (~yauhsien@61-231-23-53.dynamic-ip.hinet.net) (Remote host closed the connection)
09:44:29 × justromeon quits (~justromeo@120.29.68.81) (Client Quit)
09:45:04 → yauhsien joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
09:48:33 → justromeon joins (~justromeo@120.29.68.81)
09:49:50 × justromeon quits (~justromeo@120.29.68.81) (Client Quit)
09:49:54 × yauhsien quits (~yauhsien@61-231-23-53.dynamic-ip.hinet.net) (Ping timeout: 264 seconds)
09:55:02 → ccntrq1 joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
09:55:05 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Ping timeout: 248 seconds)
09:55:05 ccntrq1 is now known as ccntrq
09:58:50 → lisbeths joins (uid135845@id-135845.lymington.irccloud.com)
09:58:51 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Remote host closed the connection)
09:59:05 → ccntrq joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
10:02:34 → yauhsien joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
10:03:27 × arthurs115 quits (~arthurs11@163.5.10.155) (Remote host closed the connection)
10:04:27 → alp__ joins (~alp@user/alp)
10:05:04 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Remote host closed the connection)
10:05:49 → ccntrq joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
10:06:55 × adanwan quits (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection)
10:07:25 → adanwan joins (~adanwan@gateway/tor-sasl/adanwan)
10:08:22 × raym quits (~raym@user/raym) (Ping timeout: 244 seconds)
10:08:33 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Read error: Connection reset by peer)
10:08:45 → ccntrq joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
10:09:33 × kristjansson quits (sid126207@tinside.irccloud.com) (Ping timeout: 276 seconds)
10:10:23 → raym joins (~raym@user/raym)
10:11:05 × xff0x quits (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 248 seconds)
10:12:12 → kristjansson joins (sid126207@id-126207.tinside.irccloud.com)
10:13:53 × cfricke quits (~cfricke@user/cfricke) (Ping timeout: 256 seconds)
10:15:08 → ccntrq1 joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
10:15:16 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Remote host closed the connection)
10:15:18 ccntrq1 is now known as ccntrq
10:15:38 → Surobaki joins (~surobaki@137.44.222.80)
10:18:13 × econo quits (uid147250@user/econo) (Quit: Connection closed for inactivity)
10:20:18 → justromeon joins (~justromeo@120.29.68.81)
10:20:48 × justromeon quits (~justromeo@120.29.68.81) (Client Quit)
10:21:07 → justromeon joins (~justromeo@120.29.68.81)
10:21:18 × justromeon quits (~justromeo@120.29.68.81) (Client Quit)
10:21:25 → xnorfzt joins (~xnorfzt@2a02:908:d88:320:b5c0:b85f:3ec0:5838)
10:21:41 → justromeon joins (~justromeo@120.29.68.81)
10:22:28 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Ping timeout: 268 seconds)
10:24:10 <xnorfzt> Hi all! I'm trying to convert a number of seconds to the difference in hours, minutes and seconds as a `(Int, Int, Int)`. I can do the math by myself using divMod, but is there an ultra-readable way using the time library? I found out that I can create `DiffTime` values with `fromIntegral`, but how do I access the resulting single components
10:24:10 <xnorfzt> without `format`ting the time difference?
10:24:50 <xnorfzt> Whoops - sorry for the broken code markup. So used to markdown...
10:25:05 × justromeon quits (~justromeo@120.29.68.81) (Client Quit)
10:26:09 → ccntrq joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
10:26:56 → cfricke joins (~cfricke@user/cfricke)
10:27:35 → justromeon joins (~justromeo@120.29.68.81)
10:28:02 × justromeon quits (~justromeo@120.29.68.81) (Client Quit)
10:28:57 × BusConscious quits (~martin@ip5f5bdedc.dynamic.kabel-deutschland.de) (Remote host closed the connection)
10:29:13 × raym quits (~raym@user/raym) (Ping timeout: 248 seconds)
10:30:42 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Ping timeout: 264 seconds)
10:30:42 → ccntrq1 joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
10:30:59 → raym joins (~raym@user/raym)
10:32:09 × zaquest quits (~notzaques@5.130.79.72) (Remote host closed the connection)
10:33:11 ccntrq1 is now known as ccntrq
10:35:40 → Midjak joins (~Midjak@82.66.147.146)
10:36:02 → fnurglewitz joins (uid263868@id-263868.lymington.irccloud.com)
10:37:37 → chexum_ joins (~quassel@gateway/tor-sasl/chexum)
10:39:50 × chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
10:40:46 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Remote host closed the connection)
10:41:03 → ccntrq joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
10:42:50 × chexum_ quits (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 268 seconds)
10:46:47 → chexum joins (~quassel@gateway/tor-sasl/chexum)
10:48:23 × azimut quits (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 268 seconds)
10:48:57 × merijn quits (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds)
10:51:07 → zaquest joins (~notzaques@5.130.79.72)
10:52:50 → azimut joins (~azimut@gateway/tor-sasl/azimut)
10:58:14 <tomsmeding> to be honest if you want the most _readable_ option, I vote for \n -> (n `div` 3600, n `div` 60 `mod` 60, n `mod` 60)
10:58:28 × chomwitt quits (~chomwitt@2a02:587:dc0d:e600:1174:892d:39e3:5e01) (Quit: Leaving)
10:58:33 <tomsmeding> since 'time' doesn't seem to have a dedicated function for this
10:59:09 → Henkru joins (henkru@kapsi.fi)
11:00:56 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Remote host closed the connection)
11:01:19 <int-e> > (\case ts | (tm, s) <- ts `divMod` 60, (th, m) <- tm `divMod` 60 -> (th,m,s)) 4242 -- scnr
11:01:21 <lambdabot> (1,10,42)
11:01:51 → ccntrq joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
11:02:41 → xff0x joins (~xff0x@b133147.ppp.asahi-net.or.jp)
11:04:00 <tomsmeding> int-e: why a lambdacase instead of \ts -> let (tm, s) = ts `divMod` 60 ; ...
11:04:00 xnorfzt thinks about time-lens :D
11:04:16 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Remote host closed the connection)
11:04:32 <tomsmeding> nice variable names, though
11:04:49 <int-e> tomsmeding: because then I wouldn't get to (ab)use pattern guards
11:05:03 <tomsmeding> why are pattern guards better than simple let clauses in this case :p
11:05:04 <int-e> I wanted to call them all t.
11:05:12 <tomsmeding> right
11:05:19 <xnorfzt> tomsmeding int-e - makes sense, it's pretty short and readable, but not what I'm looking for. <3
11:05:56 → ccntrq joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
11:07:46 → lyle joins (~lyle@104.246.145.85)
11:08:43 × yauhsien quits (~yauhsien@61-231-23-53.dynamic-ip.hinet.net) (Remote host closed the connection)
11:09:18 → yauhsien joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
11:10:51 × xnorfzt quits (~xnorfzt@2a02:908:d88:320:b5c0:b85f:3ec0:5838) (Quit: xnorfzt)
11:12:30 × fryguybob quits (~fryguybob@cpe-74-67-169-145.rochester.res.rr.com) (Quit: leaving)
11:12:37 × sympt quits (~sympt@user/sympt) (Read error: Connection reset by peer)
11:13:45 → sympt joins (~sympt@user/sympt)
11:13:57 × yauhsien quits (~yauhsien@61-231-23-53.dynamic-ip.hinet.net) (Ping timeout: 256 seconds)
11:15:02 → merijn joins (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl)
11:15:47 → yauhsien joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
11:24:11 × geekosaur quits (~geekosaur@xmonad/geekosaur) (Read error: Connection reset by peer)
11:24:18 → allbery_b joins (~geekosaur@xmonad/geekosaur)
11:24:21 allbery_b is now known as geekosaur
11:27:46 × Surobaki quits (~surobaki@137.44.222.80) (Quit: Leaving)
11:28:12 → odnes joins (~odnes@5-203-220-108.pat.nym.cosmote.net)
11:30:23 → Surobaki joins (~surobaki@137.44.222.80)
11:30:41 × coot quits (~coot@213.134.190.95) (Quit: coot)
11:34:16 → coot joins (~coot@213.134.190.95)
11:35:36 → dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net)
11:39:01 × coot quits (~coot@213.134.190.95) (Client Quit)
11:40:07 <maerwald> Maxdamantus: https://github.com/haskellfoundation/tech-proposals/issues/35
11:42:26 → rendar joins (~Paxman@user/rendar)
11:42:39 × haritzondo quits (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) (Changing host)
11:42:39 → haritzondo joins (~hrtz@user/haritz)
11:42:48 haritzondo is now known as haritz
11:48:31 × geekosaur quits (~geekosaur@xmonad/geekosaur) (Ping timeout: 256 seconds)
11:49:29 → geekosaur joins (~geekosaur@xmonad/geekosaur)
11:50:02 × benin0 quits (~benin@183.82.26.120) (Quit: The Lounge - https://thelounge.chat)
11:50:35 <Maxdamantus> maerwald: hm, seems a lot more complicated/tedious than just using a string type capable of handling any byte sequence, where WTF-8 would be used for handling filenames.
11:51:01 <maerwald> Maxdamantus: I thought about using WTF-8, but I don't like it
11:51:22 <maerwald> I'm not sure you can easily reconstruct underlying encoding information from WTF-8... it would be complicated
11:51:23 <Maxdamantus> and yeah, the filenames thing is just an obvious example. The same thing applies to simply reading text from files.
11:51:40 <maerwald> the idea is to stop messing with the data that syscalls return
11:52:05 → dsrt^ joins (~dsrt@50.237.44.186)
11:53:37 <Maxdamantus> (reading text from files should be a simpler problem because files are at least still [Word8] on Windows, rather than [Word16])
11:54:27 <Maxdamantus> imo Windows' use of UTF-16 shouldn't be a reason to complicate the API for other platforms.
11:55:03 <Maxdamantus> WTF-8 is slightly ugly, but it's only used to address an ugly API that might be obsolete soon anyway.
11:55:08 <maerwald> Maxdamantus: how is the API more complicated? These details are hidden behind a newtype
11:55:53 <Maxdamantus> maerwald: how do you print a filename to standard out?
11:55:56 → raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
11:56:12 <maerwald> putStr filepath
11:56:12 <Maxdamantus> pcesumably involves a conversion.
11:57:01 <hpc> you have to pick an encoding anyway on linux, since it's not specified
11:57:12 × jgeerds quits (~jgeerds@55d45f48.access.ecotel.net) (Ping timeout: 248 seconds)
11:57:49 <Maxdamantus> maerwald: so filepath is still a `String`?
11:57:53 <maerwald> Maxdamantus: no
11:58:27 <Maxdamantus> so `putStr` is made polymorphic over things that are like strings?
11:58:50 <merijn> I wonder if this discussion will answer my questions vis-a-vis unstoppable forces and immovable objects :)
11:58:59 <hpc> it's not making the api more complicated, it's making it more accurate
11:59:02 <maerwald> Maxdamantus: sorry, I meant `print`
11:59:14 <hpc> the current api is simple in the same way javascript is simple
12:00:06 <hpc> right now, (putStr filepath) is complicated to the programmer in ridiculous ways
12:00:14 <Maxdamantus> hpc: JavaScript's API is simple and accurate as long as you only deal with Windows filename APIs.
12:00:24 <hpc> on windows it just works, because somewhere there was magic to convert from utf-16
12:00:35 <hpc> on linux you have to hope and pray, because filenames are just bytes
12:01:02 <maerwald> hpc: well, on windows, you also may have invalid UTF-16
12:01:10 <maerwald> the encoding is in fact UCS-2
12:01:19 <hpc> ugh, right
12:01:19 <maerwald> so you can have invalid surrogate pairs
12:02:00 <Maxdamantus> The fact that JS and windows are based around 16-bit strings is just a historical oddity. Going forward, the preference should be 8-bit strings, and we can use WTF-8 for backwards compatibility. Don't need to complicate the APIs for backwards-compatibility.
12:02:11 → yrlnry joins (~yrlnry@pool-108-2-150-109.phlapa.fios.verizon.net)
12:02:38 <merijn> maerwald: Pretty sure it's proper utf-16 now?
12:02:49 <merijn> not 100% sure though
12:02:53 <Maxdamantus> merijn: pretty sure it's not.
12:02:57 <maerwald> merijn: no, you can easily create filepaths via the system API that are not UTF-16
12:03:11 <Maxdamantus> unless you're talking about Windows 11. Haven't tested that personally.
12:03:37 <Maxdamantus> (I've certainly experimented with this stuff on Windows 10)
12:04:16 <hpc> wtf-8 doesn't solve the fact that linux filenames are bytes either
12:04:29 <maerwald> hpc: but it never fails, right?
12:04:54 <maerwald> haven't tested how it behaves in detail
12:05:10 → nate4 joins (~nate@98.45.169.16)
12:05:11 <maerwald> current conversion in base can fail for encoding that are not superset of ascii
12:05:37 <Maxdamantus> hpc: WTF-8 is just there to solve the Windows problem. There is no problem with translating paths to byte strings on Linux.
12:05:37 <maerwald> such as some korean encodings afair
12:05:57 <maerwald> Maxdamantus: there is, because roundtripping isn't always defined
12:06:25 <maerwald> see https://hackage.haskell.org/package/base-4.16.1.0/docs/GHC-IO-Encoding.html#v:mkTextEncoding
12:07:05 <maerwald> the other issue is that most APIs assume that the filepaths you're consuming correspond to the current locale... which is... uhm, dumb
12:07:32 <Maxdamantus> maerwald: by "path" I mean as used by the OS, not as used by current Haskell.
12:07:57 <maerwald> Maxdamantus: I don't understand that statement then
12:08:00 <Maxdamantus> Haskell's APIs inaccurately represent paths as `String`.
12:09:05 <maerwald> system APIs don't interpret encoding... things like path separators '/' are defined accurately (byte in the ascii set) and can be scanned for regardless of the actualy filename encoding
12:09:19 <Maxdamantus> maerwald: paths in Linux are already just sequences of bytes, so if a programming language defined a string as a sequence of bytes, there's a no-op mapping between paths and strings.
12:10:01 × nate4 quits (~nate@98.45.169.16) (Ping timeout: 248 seconds)
12:10:13 <maerwald> Maxdamantus: yes
12:10:19 <maerwald> that's what the new API does
12:10:42 <maerwald> there's literally no encoding/decoding
12:10:49 <maerwald> unless you want to get a Haskell String
12:12:39 <Maxdamantus> maerwald: but it's complicated because it introduces a new string type, which only exists because of a Windows API that might be being obsoleted.
12:12:53 <maerwald> Maxdamantus: no, it uses an exsiting string type
12:13:01 <maerwald> ShortByteString
12:13:02 <Maxdamantus> Which one?
12:13:09 <Maxdamantus> Hm.
12:14:02 <Maxdamantus> So do you get different `ShortString` values depending on whether the path was read on Windows/Linux?
12:14:25 <maerwald> yes, on windows you will have UCS-2LE bytestrings that contain \NUL bytes
12:14:27 <Maxdamantus> eg, for a filename that looks like "àéíóú"?
12:15:20 <Maxdamantus> and what, the `Show` instance converts differently depending on the OS?
12:15:41 <maerwald> Maxdamantus: yes... there's some tradeoff for the Show instance, because we have to convert to String
12:16:02 <maerwald> you can't define a total function that doesn't lose information and converts to String
12:16:18 × dsrt^ quits (~dsrt@50.237.44.186) (Ping timeout: 264 seconds)
12:17:36 <Maxdamantus> Sure, so there should be a de facto string type capable of handling practically all Unicode strings (except UTF-32 ones)
12:18:17 <Maxdamantus> that type would be equivalent ho `ByteString`, where WTF-8 is used for possibly ill-formed UTF-16.
12:19:00 <maerwald> the cool thing with this approach compared to WTF-8 is that you could easily use something like this https://hackage.haskell.org/package/charsetdetect-ae-1.1.0.4/docs/Codec-Text-Detect.html on the raw bytes
12:19:05 <maerwald> because we're not changing anything
12:19:44 <maerwald> Maxdamantus: I'm open to suggestions on how to handle the Show instances
12:20:21 <Maxdamantus> I'm not sure you can use that on a `ShornString`
12:20:39 <maerwald> https://hackage.haskell.org/package/filepath-2.0.0.3/candidate/docs/src/System.OsString.Internal.Types.html#line-202
12:20:42 <Maxdamantus> Unless it has surrogate code units in it, it could always be UTF-16.
12:21:41 <Maxdamantus> ie, if you read a filename into a `ShortString`, how does a detector know it's not UTF-16?
12:22:11 <maerwald> one way is to just convert Word8 to Char, but then you get garbled crap for most things... and the Show instance isn't really for serialization
12:22:38 <maerwald> Maxdamantus: see here https://hackage.haskell.org/package/filepath-2.0.0.3/candidate/docs/System-AbstractFilePath.html#g:3
12:22:44 <maerwald> there are 3 functions for conversion
12:23:14 <maerwald> one that assumes Utf-8/UTF-16, one that allows to specify the encoding and one that looks up the filesystem encoding... all of them can fail
12:23:28 → waleee joins (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
12:24:34 → jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
12:29:30 <Maxdamantus> Hm, so it's dependent on the OS.
12:29:48 <Maxdamantus> What happens when Windows starts offering bytestring-based filenames?
12:29:50 <maerwald> Maxdamantus: well, you could specify WTF-8 for both platforms
12:30:14 <maerwald> toAbstractFilePath wtf8 wtf8 fp
12:30:27 <maerwald> *toAbstractFilePathEnc
12:30:54 <maerwald> Maxdamantus: what do you mean?
12:31:20 <maerwald> filepaths on windows are already 'wchar_t*'
12:31:30 → alp_ joins (~alp@user/alp)
12:31:42 <Maxdamantus> maerwald: if Windows in the future deprecates use of its 16-bit APIs and offers 8-bit APIs instead, where old filenames are transparently converted to WTF-8.
12:31:52 <maerwald> Maxdamantus: it will not deprecate that ever
12:32:01 <maerwald> windows cares about backwards compat
12:32:08 <Maxdamantus> WTF-8 is backwards-compatible.
12:32:16 <maerwald> I'm talking about windows
12:32:20 <Maxdamantus> So am I.
12:32:22 <maerwald> WTF-8 is a rust specific thing
12:32:27 <maerwald> has nothing to do with windows
12:32:41 <Maxdamantus> Windows could adopt it as part of a migration strategy to 8-bit filenames.
12:32:45 <maerwald> windows will contain to provide wide character versions of their system API
12:32:59 <maerwald> see https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew
12:33:10 <maerwald> CreateFileW stands for *wide character*
12:33:15 <maerwald> it will not change its semantics
12:33:57 × alp__ quits (~alp@user/alp) (Read error: Connection reset by peer)
12:34:57 <Maxdamantus> Their current filesystems specifically support 16-bit strings, but it seems plausible that they might move away from that and just use 8-bit strings (cf. macOS). The new APIs could support old NTFS/FAT32 filenames still by transparently converting to WTF-8 (or something equivalent, but at this point there's no point in reinventing WTF-8).
12:35:08 <maerwald> no, it doesn't seem plausible
12:35:16 → [itchyjunk] joins (~itchyjunk@user/itchyjunk/x-7353470)
12:35:23 <maerwald> windows doesn't randomly break API
12:35:36 <maerwald> that's why they still haven't migrated to UTF-16, but still support UCS-2
12:35:44 <maerwald> after decades
12:35:49 <Maxdamantus> What API is being broken?
12:38:31 <maerwald> I don't understand what you're suggesting then. Wide character API works for all existing versions of windows. There's already an ANSI API that allows to configure stuff for UTF-8: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea
12:38:43 <maerwald> https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
12:38:52 <Maxdamantus> aiui Windows has been gradually migrating things from UCS-2 to either UTF-8 or bytes, though I'm not sure about the details.
12:38:52 <maerwald> but that isn't supported across all windows versions
12:38:58 <maerwald> so that is not a good default
12:39:07 → dsrt^ joins (~dsrt@50.237.44.186)
12:39:14 → fweht joins (uid404746@id-404746.lymington.irccloud.com)
12:39:45 <maerwald> And all that doesn't matter to us. What matters is what the Win32 bindings use, and they use the wide character API: https://hackage.haskell.org/package/Win32
12:42:12 <Maxdamantus> Right, but what happens if Windows starts supporting bytes-based filenames? Haskell should be able to switch over to the new API in order to handle them, but it's going to be awkward to do that if doing so means changing all of the `Show` behaviour etc for Windows users.
12:42:53 <Maxdamantus> eg, Windows has been adding integration for WSL. I think they're intending on running Android apps etc.
12:43:37 <maerwald> Maxdamantus: I don't think Win32 package will migrate to anything else. It will stick to wide character API.
12:43:58 <Maxdamantus> theoretically they could decide at some point to offer 8-bit filename APIs which are able to handle Linux filesystems without information loss, and they should also be fully capable of handling existing NTFS filesystems without information loss due to conversion to/from WTF-8.
12:44:13 <Maxdamantus> maerwald: I'm not saying they're going to remove the APIs.
12:44:51 <Maxdamantus> maerwald: just offer better ones that are usable in all the same cases as the current 16-bit ones, but also handle filenames from 8-bit systems, like WSL or network shares.
12:45:10 <maerwald> Maxdamantus: you're going to break Haskell for old windows versions then
12:46:23 <Maxdamantus> maerwald: you mean because Haskell has to pick to use either the new API (only supports Windows 13+) or the old API (supports all versions of Windows)?
12:46:32 <Maxdamantus> why can't it support both?
12:47:31 <maerwald> I don't understand what problem you're trying to solve. Of course it can provide bindings for both variants, but on some windows systems the UTF-8 one will *fail*.
12:48:08 <Maxdamantus> It will only fail when creating filenames that are unsupported on a filesystem, but that's already a possibility on Windows.
12:48:13 <Maxdamantus> eg, can't create a file called "con"
12:48:33 <geekosaur> uh
12:48:37 <Maxdamantus> or a file with some special characters in it, can't think of what they are off the top of my head.
12:48:56 <maerwald> "As of Windows Version 1903 (May 2019 Update), you can use the ActiveCodePage property in the appxmanifest for packaged apps, or the fusion manifest for unpackaged apps, to force a process to use UTF-8 as the process code page."
12:49:09 <geekosaur> so, wide vs. narrow characters are just a bit more intrusive than that
12:49:24 <Maxdamantus> anyway, need to go to bed.
12:49:26 <Maxdamantus> Thu Jun 23 12:49:26 AM NZST 2022
12:50:18 <maerwald> 1. it requires configuration, 2. it doesn't work on all windows versions, 3. it complicates filepath handling
12:50:20 <maerwald> what's the gain
12:59:55 × dsrt^ quits (~dsrt@50.237.44.186) (Ping timeout: 256 seconds)
13:00:30 × gurkenglas quits (~gurkengla@dslb-002-207-014-022.002.207.pools.vodafone-ip.de) (Ping timeout: 276 seconds)
13:01:48 × ridcully quits (~ridcully@pd951ff85.dip0.t-ipconnect.de) (Ping timeout: 276 seconds)
13:03:38 × juri__ quits (~juri@79.140.115.124) (Ping timeout: 240 seconds)
13:03:42 × renzhi quits (~xp@2607:fa49:6500:b100::f64a) (Ping timeout: 264 seconds)
13:04:08 → mrd joins (~mrd@user/mrd)
13:04:10 × dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.5)
13:09:12 × ChaiTRex quits (~ChaiTRex@user/chaitrex) (Remote host closed the connection)
13:10:54 × kuribas quits (~user@ip-188-118-57-242.reverse.destiny.be) (Ping timeout: 264 seconds)
13:12:16 → pleo joins (~pleo@user/pleo)
13:14:50 × odnes quits (~odnes@5-203-220-108.pat.nym.cosmote.net) (Remote host closed the connection)
13:15:09 × chexum quits (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 268 seconds)
13:15:12 → odnes joins (~odnes@5-203-220-108.pat.nym.cosmote.net)
13:15:16 → ChaiTRex joins (~ChaiTRex@user/chaitrex)
13:17:30 → chexum joins (~quassel@gateway/tor-sasl/chexum)
13:18:26 → zebrag joins (~chris@user/zebrag)
13:19:06 → shriekingnoise joins (~shrieking@201.212.175.181)
13:26:34 → Unicorn_Princess joins (~Unicorn_P@93-103-228-248.dynamic.t-2.net)
13:28:05 → toluene joins (~toluene@user/toulene)
13:28:12 → Infinite joins (~Infinite@49.39.125.113)
13:29:48 → dsrt^ joins (~dsrt@50.237.44.186)
13:30:33 → juri_ joins (~juri@79.140.115.124)
13:34:21 → crazazy joins (~user@130.89.171.62)
13:36:06 × vysn quits (~vysn@user/vysn) (Ping timeout: 264 seconds)
13:37:29 × cfricke quits (~cfricke@user/cfricke) (Ping timeout: 248 seconds)
13:37:29 → k` joins (~user@152.1.137.158)
13:39:23 <k`> How do I depend on a github repo in my cabal file? Currently I've written a 'source-repository' stanza for it, but cabal fails with 'unknown pagkage'.
13:39:35 <merijn> k`: You don't
13:39:47 <merijn> k`: You probably want a cabal.project file
13:40:16 <k`> merijn: Thanks, I'll open up the docs on that.
13:41:15 <k`> Do I use one cabal.project file for the entire project, or do I put one in each package subdir?
13:42:25 <sm> one for the project
13:42:52 × dsrt^ quits (~dsrt@50.237.44.186) (Remote host closed the connection)
13:42:59 <k`> sm: Thanks. That's what the name seems to imply but I didn't want to make any foolish assumptions.
13:43:04 <merijn> k`: So, the distinction is: a .cabal is a standalone description of a specific package (dependencies, flags, etc.) "cabal.project" is for defining the context in which a project (of one or more packages) is being used/built and allows you to override things (like saying to use a local directory or git repo to develop against unreleased code)
13:43:50 × eod|fserucas_ quits (~eod|fseru@193.65.114.89.rev.vodafone.pt) (Quit: Leaving)
13:44:06 <k`> So just out of curiosity, how would the individual packages be built when they don't have access to the overall project description?
13:45:04 <sm> there doesn't seem to be an introduction to cabal.project in the user guide
13:45:25 <merijn> k`: The idea is that individual package (when you release them) only depend on other released packages/versions, not git repos
13:45:31 <merijn> sm: There was a WIP to write one
13:46:07 <jackdk> the reference is at least thorough, but I'm not aware of any good intros: https://cabal.readthedocs.io/en/3.6/cabal-project.html
13:46:13 <sclv> https://cabal.readthedocs.io/en/3.6/cabal-project.html and https://cabal.readthedocs.io/en/3.6/nix-local-build.html#developing-multiple-packages
13:46:24 <sclv> the latter of the two i posted is sort of an intro
13:46:46 <k`> So, say I have packages 'foo-class', 'foo-pattern', and 'foo-type', with 'foo-pattern' and 'foo-type' both depending on 'foo-class'. Where do I give the repo for 'foo-class' in 'foo-type' so that 'foo-type' can be built independently?
13:47:10 <sclv> the packages all are like normal packages. the project file ties them all together
13:47:20 <merijn> k`: The idea would be that, eventually foo-class gets released on hackage
13:47:38 <merijn> k`: Basically "where to find a package" is NOT something .cabal files are concerned with
13:47:45 <merijn> They merely state "what package"
13:47:49 <merijn> (and version)
13:48:16 <merijn> k`: The implicit context is that "where" is "the package repository (aka Hackage instance) that you happen to point cabal-install at"
13:48:26 <k`> merijn: Fair enough. I'm just always hesitant to release anything to Hackage because my code quality is shit.
13:48:47 <k`> But I still want to make things properly modular.
13:48:53 <sclv> a hackage release is a package tarball. those don't include cabal.project files
13:48:56 <merijn> k`: You can run your own hackage and cabal-install can be pointed at a different (and even multiple!) hackages :)
13:49:07 <sclv> cabal.project files are _only_ for use in developing a collection of packages from a repo
13:49:15 <merijn> k`: So it's perfectly possible to have a personal/company/whatever Hackage repo
13:49:28 <merijn> sclv: Not *only* for that
13:49:29 <sclv> once you upload to hackage, you should ensure all the deps are already on hackage
13:50:13 → coot joins (~coot@213.134.190.95)
13:50:22 × motherfsck quits (~motherfsc@user/motherfsck) (Quit: quit)
13:51:05 <sm> ah there it is, https://cabal.readthedocs.io/en/3.6/nix-local-build.html#developing-multiple-packages . The cursed "nix-style" jargon strikes again
13:51:50 → cfricke joins (~cfricke@user/cfricke)
13:52:07 → motherfsck joins (~motherfsc@user/motherfsck)
13:52:10 <k`> Anyone know what happens when I list a source-repository-package that points to a subdir of a project that uses cabal.project to build? Just fails to build?
13:52:42 <sm> (I did search the site for "cabal.project", must have missed the Quickstart)
13:52:42 <merijn> k`: What do you mean?
13:53:24 <merijn> k`: If you have a cabal.project in a directory for project X, then X and all its dependencies should be findable via that 1 cabal.project
13:53:57 <merijn> k`: if you meant "X depends on Y and Y uses cabal.project to find Z", then cabal.project for X needs to include repo pointers for both Y and Z
13:54:35 <k`> merijn: Oh, that is good to know.
13:54:43 <k`> Would not have expected that.
13:56:04 <k`> So if I'm trying to modularize with multiple packages I should throw them all in one huge package repo so they can all find their dependencies, and I don't need to update the cabal.project of Z when a new transitive dependency is added.
13:56:35 <merijn> k`: If they're interdependent then I would say yes
13:56:48 <sclv> that's a common pattern, yes
13:56:51 <merijn> k`: See for example: https://github.com/merijn/broadcast-chan
13:57:38 <merijn> k`: Although once you get past, say, 10 packages in the same repo I would start questioning what I'm doing if I were you ;)
13:57:42 × gmg quits (~user@user/gehmehgeh) (Ping timeout: 268 seconds)
13:58:56 <k`> I see that there you give the direct paths to the subdirectories. Is it standard to do that rather than round tripping through github?
13:59:33 <merijn> k`: Yes, pointing at github will use whatever is currently on github *NOT* what you have in your local clone
13:59:34 × vglfr quits (~vglfr@coupling.penchant.volia.net) (Read error: Connection reset by peer)
13:59:41 → gmg joins (~user@user/gehmehgeh)
13:59:45 → vglfr joins (~vglfr@coupling.penchant.volia.net)
13:59:50 <merijn> k`: Whereas the subdirectories tell it to use whatever is in the local subdirectories *right now*
13:59:56 <merijn> Which is probably what you want
14:00:35 <merijn> (because if your locally changing foo-class, you probably want local versions of foo-instance to pick that up :p)
14:01:40 → Guest59 joins (~Guest59@148.253.134.213)
14:02:10 × Guest59 quits (~Guest59@148.253.134.213) (Client Quit)
14:02:20 × Infinite quits (~Infinite@49.39.125.113) (Quit: Client closed)
14:02:41 → Infinite joins (~Infinite@49.39.125.113)
14:02:55 → mecharyuujin joins (~mecharyuu@2409:4050:ece:7592:439d:86ae:5a53:fec7)
14:03:00 × pleo quits (~pleo@user/pleo) (Quit: quit)
14:04:44 <mecharyuujin> Heya, beginner here, am learning Haskell using the Learn You a Haskell tutorial
14:05:04 <mecharyuujin> head'' :: [a] -> a
14:05:11 <mecharyuujin> head'' = foldr1 (\x _ -> x)
14:05:26 <mecharyuujin> why does this version of head work on infinite lists?
14:06:57 <mecharyuujin> I thought foldr1 would need the last element of the list as the starting value, and even though it is useless in this case, how would GHC know that its useless here? Is GHC able to figure it out?
14:09:08 <k`> merijn, sclv, sm, thank you so much. I think I know what to do now.
14:09:35 <merijn> mecharyuujin: Consider this: Can you rewrite the application of head'' by replacing "foldr1" with the definition of foldr1?
14:09:47 <merijn> i.e. take foldr1, turn it into a lambda, insert in the code for head''
14:09:57 × albet70 quits (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
14:10:10 <k`> Maybe if I ever get better at programming some of this will make it to Hackage. But considering how little I've improved in the last 14 years of using in Haskell, it seems unlikely :-)
14:12:06 × Vajb quits (~Vajb@2001:999:40:4c50:1b24:879c:6df3:1d06) (Read error: Connection reset by peer)
14:12:12 <sm> it'll start to flow one of these days!
14:12:51 → Vajb joins (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi)
14:15:01 <carbolymer> do you know if I can somehow put seed into hedgehog to not have random output from generators?
14:15:14 <carbolymer> or into tasty
14:15:53 → pleo joins (~pleo@user/pleo)
14:16:04 → albet70 joins (~xxx@2400:8902::f03c:92ff:fe60:98d8)
14:17:41 <mecharyuujin> merijn, I am not sure how I would turn foldr1 into a lambda. If I had to implement it, I would probably do it like
14:17:45 ← jakalx parts (~jakalx@base.jakalx.net) (Error from remote client)
14:17:47 <mecharyuujin> foldr1 f [x] = x
14:17:55 <mecharyuujin> foldr1 f (x:xs) = f x (foldr1 xs)
14:20:05 → jakalx joins (~jakalx@base.jakalx.net)
14:21:50 <merijn> ok, so let's fill in the lambda from head'' in that code
14:22:07 <merijn> Clearly in the first case it will return the first item, yeah?
14:22:17 <merijn> So, let's look at the 2nd case
14:22:28 <mecharyuujin> yeah
14:22:30 <merijn> foldr1 f (x:xs) = f x (foldr1 f xs)
14:23:10 <merijn> Let's rename in head'' to get: head'' = foldr1 (\y _ -> y)
14:23:15 <merijn> (remove some name confusion)
14:24:06 <merijn> Actually, let's eta expand too: head'' (x:xs) = foldr1 (\y _ -> y) (x:xs)
14:24:46 <merijn> Expand foldr1 using it's definition and we get: (\y _ -> y) x (foldr1 (\y _ -> y) xs)
14:25:03 <mecharyuujin> Ah, I see
14:25:05 <merijn> Which will obviously return 'x' (so the head of the list)
14:25:06 <mecharyuujin> this is simply x
14:25:15 <mecharyuujin> Thanks a ton merijn, !
14:25:29 <merijn> And laziness means we only evaluate the 2nd argument (the recursive foldr1 call) when needed (i.e. never)
14:25:38 <mecharyuujin> yeah
14:30:10 → eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
14:32:44 × waleee quits (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 255 seconds)
14:33:10 × Infinite quits (~Infinite@49.39.125.113) (Ping timeout: 252 seconds)
14:33:13 × fnurglewitz quits (uid263868@id-263868.lymington.irccloud.com) (Quit: Connection closed for inactivity)
14:33:42 × HotblackDesiato quits (~HotblackD@gateway/tor-sasl/hotblackdesiato) (Remote host closed the connection)
14:33:58 → HotblackDesiato joins (~HotblackD@gateway/tor-sasl/hotblackdesiato)
14:34:41 × eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 268 seconds)
14:35:43 → Sgeo joins (~Sgeo@user/sgeo)
14:35:45 <mecharyuujin> How is foldl/foldl1 implemented? Using (init xs) and (last xs) doesn't seem particularly efficient...
14:39:00 → ccntrq1 joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
14:39:03 <k`> mecharyuujin: foldl folds from right to left, starting with the accumulator value.
14:39:30 <k`> Think of it as a loop onto an accumulator rather than a fold like foldr.
14:39:42 <k`> Sorry, left to right.
14:39:50 <k`> Just like foldr.
14:41:13 → Timely_Ratio9567 joins (~mecharyuu@2405:204:302a:37df:1901:27c8:4070:e6e2)
14:41:58 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Ping timeout: 240 seconds)
14:42:01 × Timely_Ratio9567 quits (~mecharyuu@2405:204:302a:37df:1901:27c8:4070:e6e2) (Client Quit)
14:42:12 → Timely_Ratio9567 joins (~mecharyuu@2405:204:302a:37df:1901:27c8:4070:e6e2)
14:43:16 × Timely_Ratio9567 quits (~mecharyuu@2405:204:302a:37df:1901:27c8:4070:e6e2) (Client Quit)
14:43:23 → ccntrq joins (~Thunderbi@exit-1.office.han.de.mhd.medondo.com)
14:43:28 → Timely_Ratio9567 joins (~mecharyuu@2405:204:302a:37df:1901:27c8:4070:e6e2)
14:43:29 × Timely_Ratio9567 quits (~mecharyuu@2405:204:302a:37df:1901:27c8:4070:e6e2) (Remote host closed the connection)
14:43:32 × mecharyuujin quits (~mecharyuu@2409:4050:ece:7592:439d:86ae:5a53:fec7) (Ping timeout: 255 seconds)
14:43:37 × ccntrq1 quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Ping timeout: 248 seconds)
14:45:18 → mecharyuujin joins (~mecharyuu@2405:204:302a:37df:1901:27c8:4070:e6e2)
14:45:50 × _73 quits (~user@pool-108-49-252-36.bstnma.fios.verizon.net) (Remote host closed the connection)
14:48:31 → Timely_Ratio9567 joins (~mecharyuu@2409:4050:2d4b:a853:8048:c716:f88e:d09f)
14:51:05 × mecharyuujin quits (~mecharyuu@2405:204:302a:37df:1901:27c8:4070:e6e2) (Ping timeout: 248 seconds)
14:51:42 → eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e)
14:59:36 × Timely_Ratio9567 quits (~mecharyuu@2409:4050:2d4b:a853:8048:c716:f88e:d09f) (Quit: Leaving)
15:03:50 × lortabac quits (~lortabac@2a01:e0a:541:b8f0:2cd:7ecf:235f:1481) (Quit: WeeChat 2.8)
15:10:13 <tomsmeding> @src foldl
15:10:13 <lambdabot> foldl f z [] = z
15:10:13 <lambdabot> foldl f z (x:xs) = foldl f (f z x) xs
15:13:44 → stackdroid18 joins (14094@user/stackdroid)
15:24:59 × Unicorn_Princess quits (~Unicorn_P@93-103-228-248.dynamic.t-2.net) (Remote host closed the connection)
15:28:05 × fweht quits (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity)
15:29:31 × ccntrq quits (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Remote host closed the connection)
15:31:37 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e) (Remote host closed the connection)
15:33:42 × chele quits (~chele@user/chele) (Remote host closed the connection)
15:33:54 → eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e)
15:36:02 × mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection)
15:37:32 × Vajb quits (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer)
15:37:43 → Vajb joins (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi)
15:38:10 × Vajb quits (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer)
15:38:50 → Vajb joins (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi)
15:44:19 × mbuf quits (~Shakthi@122.164.15.152) (Quit: Leaving)
15:45:22 → _xor joins (~xor@74.215.182.83)
15:45:41 × Surobaki quits (~surobaki@137.44.222.80) (Read error: Connection reset by peer)
15:47:31 × haritz quits (~hrtz@user/haritz) (Remote host closed the connection)
15:49:50 → ridcully joins (~ridcully@pd951f3bf.dip0.t-ipconnect.de)
15:51:37 × MajorBiscuit quits (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) (Ping timeout: 256 seconds)
15:55:12 × werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 260 seconds)
15:57:06 × merijn quits (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 264 seconds)
16:00:10 × shlevy[m] quits (~shlevymat@2001:470:69fc:105::1:d3b1) (Quit: You have been kicked for being idle)
16:03:53 <sm> I give up. How do you get the current system locale ?
16:04:05 <sm> or time locale ?
16:05:25 → lagash joins (lagash@lagash.shelltalk.net)
16:05:40 <geekosaur> afai8k you have to use the old-locale package to get the time locale. not sure about system locale unless it's buried in GHC.IO somewhere
16:06:41 → nate4 joins (~nate@98.45.169.16)
16:06:42 × cfricke quits (~cfricke@user/cfricke) (Ping timeout: 264 seconds)
16:06:58 <sm> that provides https://hackage.haskell.org/package/time-1.13/docs/Data-Time-Format.html#v:defaultTimeLocale , "Locale representing American usage." I'm not sure what that means now
16:08:07 × wagle quits (~wagle@quassel.wagle.io) (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
16:08:14 <sm> even though I'm using it plenty
16:08:23 × pavonia quits (~user@user/siracusa) (Quit: Bye!)
16:08:37 → wagle joins (~wagle@quassel.wagle.io)
16:09:03 <sm> alright, yes that's a constant. I want what's currently set eg with LC_TIME
16:09:15 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e) (Remote host closed the connection)
16:09:17 × terrorjack quits (~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat)
16:10:25 × odnes quits (~odnes@5-203-220-108.pat.nym.cosmote.net) (Remote host closed the connection)
16:10:47 → odnes joins (~odnes@5-203-220-108.pat.nym.cosmote.net)
16:11:30 × nate4 quits (~nate@98.45.169.16) (Ping timeout: 264 seconds)
16:13:32 <sm> https://stackoverflow.com/questions/28077322/getting-the-date-format-for-the-current-locale recommends current-locale (from 2015). I had tried this, but its TimeLocale is incompatible.. so not very useful. Strange..
16:14:26 <tomsmeding> sm: the C way would be to call setlocale(LC_ALL, NULL), I guess you could bind that manually
16:14:53 <tomsmeding> the ghc repo (hence base) doesn't contain any relevant calls to setlocale, and neither 'time' nor 'old-locale' have any hits when searching for setlocale in the git repo
16:15:14 <tomsmeding> side note, "The setlocale() function is used to set or query the program's current locale." illustrates the great naming of that function
16:15:19 <sm> does it mean that basically no haskell programs are aware of system time locale, eg for parsing/printing localised month names ?
16:15:48 <geekosaur> xmonad binds setlocale but only to force it to locale "C"
16:20:30 × pleo quits (~pleo@user/pleo) (Ping timeout: 264 seconds)
16:21:12 Andrew is now known as GNU\Andrew
16:21:26 <tomsmeding> also found this interesting library: https://hackage.haskell.org/package/env-locale-1.0.0.1/docs/src/System-Locale-Current.html#currentLocale
16:21:49 <tomsmeding> the funny thing being, that 'prepare_locale' binds to the function at the top here https://hackage.haskell.org/package/env-locale-1.0.0.1/src/cbits/glue.c
16:22:13 <tomsmeding> oh wait I misread the manpage, disregard
16:22:42 <tomsmeding> sm: did you check that library already, or is the TimeLocale of that thing incompatible too?
16:23:26 → merijn joins (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl)
16:24:39 <tomsmeding> the returned knownTimeZones is bogus though
16:26:20 <sm> tomsmeding: no I hadn't seen that one
16:26:37 × HotblackDesiato quits (~HotblackD@gateway/tor-sasl/hotblackdesiato) (Remote host closed the connection)
16:27:26 <sm> looking closer, current-locale's is I guess the TimeLocale defined by old-locale, but Data.Time.Format expects the one defined by time. So I guess current-locale needs an update to use that
16:27:33 → HotblackDesiato joins (~HotblackD@gateway/tor-sasl/hotblackdesiato)
16:28:16 <sm> env-locale's looks like the right one
16:28:29 <tomsmeding> Found using hackage search for "locale" :)
16:30:05 → yauhsien_ joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
16:30:05 × yauhsien quits (~yauhsien@61-231-23-53.dynamic-ip.hinet.net) (Read error: Connection reset by peer)
16:30:45 <sm> thanks tomsmeding
16:34:52 × jespada quits (~jespada@cpc121022-nmal24-2-0-cust171.19-2.cable.virginm.net) (Ping timeout: 260 seconds)
16:35:09 → dlbh^ joins (~dlbh@50.237.44.186)
16:36:05 × Feuermagier_ quits (~Feuermagi@138.199.36.237) (Quit: Leaving)
16:36:16 → Feuermagier joins (~Feuermagi@user/feuermagier)
16:36:34 → sjanssen joins (~sjanssenm@2001:470:69fc:105::1:61d8)
16:37:17 <tomsmeding> sm: I guess part of the problem is that e.g. I have my system set to en_US.UTF8 despite there being an ocean between us
16:37:21 → eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e)
16:37:50 <tomsmeding> Gimme the original text please, don't go translating my compiler errors
16:38:23 <tomsmeding> I've seen gcc errors getting translated on another person's machine and boy is that awkward
16:38:58 → cheater1__ joins (~Username@user/cheater)
16:39:00 <tomsmeding> Even apart from the fact that some errors aren't translated, and the flags aren't, etc
16:39:05 → jespada joins (~jespada@cpc121022-nmal24-2-0-cust171.19-2.cable.virginm.net)
16:39:06 × cheater quits (~Username@user/cheater) (Ping timeout: 264 seconds)
16:39:11 cheater1__ is now known as cheater
16:39:33 <sm> my context: someone wants hledger to parse their CSV dates correctly with %b recognising "abr" as april
16:39:58 <tomsmeding> Okay that makes a lot of sense, but I wouldn't want that to be dependent on the system locale
16:40:26 <sm> using the system locale would be the best default, no ?
16:40:31 <tomsmeding> Then you get excel-like shenanigand where soms systems want SUM(a, b) and others SUM(a; b), never mind SOM(a; b) in NL
16:40:58 <tomsmeding> I'd want en_US to be the default for consistency and reproducibility
16:41:11 <tomsmeding> But then as said I have my system locale set to that anyway :p
16:41:49 <tomsmeding> The thing being that if it recognises abr as April, then it doesn't recognise apr anymore (presumably)
16:41:57 <sm> well, I hear that. I was the same way about UTF8 (but lately I discovered I didn't enforce that from the start and people are reading with bizarro system encodings)
16:42:13 <sm> like "latin-1"
16:42:44 <k`> sm: I'm so sorry to hear that.
16:43:04 <tomsmeding> Is there a "system encoding", and is that set to latin-1 in those cases?
16:43:42 <sm> yes, I'm afraid there is and it is
16:44:08 <tomsmeding> ._.
16:44:09 <sm> tomsmeding: just to be clear, you'd favour sticking with en_US as default, but allowing user to override it at run time ?
16:44:37 <tomsmeding> Yes, and same for UTF8 actually - but apparentlt that ship has sailed. But this is just my opinion :)
16:44:46 <sm> and when I say people, I mean one guy.
16:45:01 <tomsmeding> :p
16:45:17 <tomsmeding> There are also people still running windows xp
16:45:28 <sm> revisiting the UTF8 thing is actually the current top priority hledger issue. But I'm taking a break as I got sick of it :)
16:46:46 <tomsmeding> Might even have an environment variable that instructs hledger to use a particular (or the system) locale, so that one doesn't have to set that each time, or to use a shell alias
16:46:51 <tomsmeding> But yes
16:47:18 sm guesses encoding and time locale should probably handled the same way, whatever that is
16:47:19 <k`> Hecate: Thoughts on Haskell parsing locale and then letting you write `classe Traversable (Soit c) ou traverser f = soit (pur . Gauche) (fmap Droite . f)` ?
16:47:40 <tomsmeding> Understandable to get sick from locales and encodings, my burn with locales was when my (C++) code started failing to parse my save files when I added a user interface
16:48:06 × even4void quits (even4void@came.here.for-some.fun) (Quit: fBNC - https://bnc4free.com)
16:48:06 × xacktm quits (xacktm@user/xacktm) (Quit: fBNC - https://bnc4free.com)
16:48:38 <tomsmeding> Turned out that that system had an nl_NL locale set for numeric, and my file format used floats, and the gtk library calls setlocale(LC_ALL, "") -- previously I'd unknowingly been running in the default, namely C
16:49:15 <sm> lovely
16:49:25 × leeb quits (~leeb@KD106155002239.au-net.ne.jp) (Ping timeout: 256 seconds)
16:49:37 → econo joins (uid147250@user/econo)
16:49:37 × andreas303 quits (andreas303@ip227.orange.bnc4free.com) (Quit: fBNC - https://bnc4free.com)
16:50:45 <tomsmeding> (we use , for decimals over here)
16:51:21 <k`> I have 'current format' set to English(Sweden). Wonder what that's subtly messing up.
16:51:45 <yushyin> tomsmeding: en_IE.UTF-8 is my preferred locale :)
16:57:30 <tomsmeding> yushyin: why specifically IE? (Are you in Ireland?)
16:58:05 → vysn joins (~vysn@user/vysn)
16:58:28 → gurkenglas joins (~gurkengla@dslb-002-207-014-022.002.207.pools.vodafone-ip.de)
17:00:43 <tomsmeding> I've heard that en_DK is ideal because they apparently use the yyyy-mm-dd date format — if I don't misremember
17:00:55 ← jakalx parts (~jakalx@base.jakalx.net) (Error from remote client)
17:00:59 <k`> Sweden does too.
17:01:14 × coot quits (~coot@213.134.190.95) (Quit: coot)
17:01:29 <tomsmeding> Ah
17:02:13 <tomsmeding> Can you guys please convert the rest of the world
17:02:57 <k`> Sorry, I'm just using the Sweding locale to get yyy-mm-dd!
17:03:05 <k`> *Swedish
17:04:02 → jakalx joins (~jakalx@base.jakalx.net)
17:04:15 <yushyin> tomsmeding: i wanted something that uses the metric system, sane date format i.e. dd/mm/yyyy and '.' for decimal separator. en_IE was the first thing I came across that fulfilled these conditions
17:04:18 × notzmv quits (~zmv@user/notzmv) (Ping timeout: 240 seconds)
17:07:37 × brettgilio quits (~brettgili@virtlab.gq) (Ping timeout: 248 seconds)
17:07:50 × lisbeths quits (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
17:11:01 <sm> ha
17:11:49 <sm> I like en_IE too, but I no longer think dd/mm/yyyy is the greatest format
17:11:56 × dlbh^ quits (~dlbh@50.237.44.186) (Ping timeout: 268 seconds)
17:12:45 <EvanR> dy/ym/dyym to keep things spicy
17:12:53 → andreas303 joins (andreas303@ip227.orange.bnc4free.com)
17:13:44 sm actually tried to parse that... day of year... year month... day of <explodes>
17:13:48 <k`> EvanR: Can I get you on board with 3-space indents and comments in Interlingua as a standard?
17:14:43 <yushyin> yyyy-mm-dd is indeed more fancy, but currency with en_DK is DKK and with en_IE it is EUR
17:14:51 × yauhsien_ quits (~yauhsien@61-231-23-53.dynamic-ip.hinet.net) (Remote host closed the connection)
17:15:18 <k`> You can set LC_MONETARY to something different than LC_TIME.
17:15:44 <EvanR> forgot about interlingua
17:16:44 → unit73e joins (~emanuel@2001:818:e8dd:7c00:32b5:c2ff:fe6b:5291)
17:17:16 → vhs joins (~vhs@c188-151-104-121.bredband.tele2.se)
17:17:48 <yushyin> k`: i know! but it was nice to find a locale that more or less is good enough without much mixing different locales
17:19:01 <EvanR> en_STATELESS_AND_LOVIN_IT
17:19:24 <yushyin> :D
17:20:37 → even4void joins (even4void@came.here.for-some.fun)
17:22:46 <k`> Glad you can put a positive spin on it...
17:24:58 × vhs quits (~vhs@c188-151-104-121.bredband.tele2.se) (Quit: Leaving)
17:25:31 × azimut quits (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 268 seconds)
17:25:47 → vhs joins (~vhs@c188-151-104-121.bredband.tele2.se)
17:26:14 → xacktm joins (xacktm@user/xacktm)
17:26:45 × stiell quits (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 268 seconds)
17:27:25 <monochrom> day of <explode> = dies irae >:)
17:27:37 → tzh joins (~tzh@c-24-21-73-154.hsd1.or.comcast.net)
17:28:21 × vhs quits (~vhs@c188-151-104-121.bredband.tele2.se) (Client Quit)
17:28:58 → vhs joins (~vhs@c188-151-104-121.bredband.tele2.se)
17:30:01 × jinsun quits (~jinsun@user/jinsun) (Ping timeout: 248 seconds)
17:30:09 <geekosaur> EvanR: d₂y₃/y₂m₂/d₁y₄y₁m₁
17:30:28 × vhs quits (~vhs@c188-151-104-121.bredband.tele2.se) (Client Quit)
17:31:07 → vhs joins (~vhs@c188-151-104-121.bredband.tele2.se)
17:31:27 → stiell joins (~stiell@gateway/tor-sasl/stiell)
17:34:49 × vhs quits (~vhs@c188-151-104-121.bredband.tele2.se) (Client Quit)
17:37:53 → jinsun joins (~jinsun@user/jinsun)
17:38:25 × Everything quits (~Everythin@37.115.210.35) (Quit: leaving)
17:38:25 <EvanR> nice, spontaneous symmetry breaking
17:41:02 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e) (Remote host closed the connection)
17:41:16 → eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e)
17:41:19 → dlbh^ joins (~dlbh@50.237.44.186)
17:41:57 → mjs22 joins (~mjs22@76.115.19.239)
17:42:51 → yauhsien joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
17:48:55 → waleee joins (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
17:52:40 → Unicorn_Princess joins (~Unicorn_P@93-103-228-248.dynamic.t-2.net)
17:55:03 → Infinite joins (~Infinite@2405:204:5381:d6e2:c80:a1c9:d209:de50)
17:57:37 × raym quits (~raym@user/raym) (Remote host closed the connection)
17:59:58 × raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds)
18:02:29 → _ht joins (~quassel@231-169-21-31.ftth.glasoperator.nl)
18:04:26 → raym joins (~raym@user/raym)
18:05:41 <shapr> I published my first thing to hackage yay! https://hackage.haskell.org/package/takedouble
18:11:46 <tomsmeding> shapr: nice and compact :)
18:11:54 <cjay> nice, congrats :)
18:11:58 shapr dances cheerfully
18:21:13 × vysn quits (~vysn@user/vysn) (Ping timeout: 248 seconds)
18:21:54 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e) (Remote host closed the connection)
18:32:59 → __monty__ joins (~toonn@user/toonn)
18:33:22 → misterfish joins (~misterfis@ip214-130-173-82.adsl2.static.versatel.nl)
18:37:03 <shapr> When I ran "cabal check" I got a warning that users may not need "-O2" for my package, how do I test whether it makes a difference?
18:37:18 → Infinite9 joins (~Infinite@2405:204:5381:d6e2:c147:f74f:65d9:3fcf)
18:37:22 × Infinite quits (~Infinite@2405:204:5381:d6e2:c80:a1c9:d209:de50) (Ping timeout: 252 seconds)
18:37:44 <shapr> Is there perhaps a known criterion workflow that can tell me?
18:38:31 <Infinite9> I'm trying to understand this line: dirs@Dirs{..} <- getAllDirs.
18:38:32 <Infinite9> The <- gets me Dir from IO Dir. Then Dirs{..} destructures so that we don't need to specify all the elements of the record. But I don't understand the @ here. I tried looking it up and visible type applications came up. If that's so, is the '@' conforming the type of dirs to Dir? https://pastebin.com/Ck4tWmBs
18:38:59 <shapr> Infinite9: the entire result is assigned to the name 'dirs'
18:39:29 <monochrom> Look for "as patterns" instead. This is just Haskell 2010 (and 98, and ...)
18:40:07 <monochrom> This is also why Google is still not sentient.
18:41:32 <Infinite9> monochrom thanks this helped
18:41:32 <Infinite9> Actually, I just randomly entered 'a@b' in ghci and it said  "Did you mean to enable TypeApplications?" so I tried looking that up.
18:41:57 <EvanR> oof
18:42:18 <k`> Think I'm in a very small minority here, but for that and a few other reasons I am not a fan of type applications.
18:42:35 <k`> Would much rather write (a :: b).
18:42:52 <EvanR> @ is doing double duty here
18:43:03 <geekosaur> not fond of them either. some people seem to love them, others consider them a mistake
18:43:37 <geekosaur> as patterns didn't get mentioned in ghci because you were in an expression as far as ghci was concerned, whereas as-patterns are part of pattern syntax
18:44:04 <EvanR> someone go back in time and increase the universe of ascii characters slightly
18:44:44 × maerwald quits (~maerwald@user/maerwald) (Ping timeout: 255 seconds)
18:46:39 <geekosaur> shapr, just time it with and without. beware that -O2 can actually slow things down in some cases
18:46:48 <monochrom> Oh ghci is not sentient either.
18:47:11 <geekosaur> so cabal strongly encourages you to use -O / -O1 instead
18:47:21 <monochrom> This is why I am against error messages doing second-guessing.
18:47:36 <geekosaur> and the ghc manual tells you -O2 is usually wasted time both in compilation and runni8ng
18:49:05 <int-e> hmm, is that true though?
18:49:26 <int-e> (The latter; the former... ugh, please leave trading compilation time for runtime to the user!)
18:49:47 <geekosaur> more specifically what it says is it usually slows compilation significantly while providing little if any benefit and occasionally making things worse, iirc
18:50:25 <int-e> I should do my own profiling. Not saying that I will...
18:51:54 → Pickchea joins (~private@user/pickchea)
18:54:03 <monochrom> I just idly wonder if the GHC user's guide is outdated on this.
18:54:35 <int-e> Well, maybe a sample: one random and tiny program sees a speedup of 15% from using -O2. And it takes just enough time for the runtime improvement to outweight the extra compilation time.
18:55:01 <int-e> (compile + execute is in the 2.5s ballpark for this sample)
18:55:02 <k`> I just idly wonder if `lens` is the package that most benefits from -O2, and yet is the package you least want to spend more time compiling.
18:55:43 <monochrom> haha
18:55:45 <int-e> k`: have you tried building regex-tdfa or haskell-src-exts?
18:55:46 <k`> (Much love to Ed K. for making one of the most beautiful, useful packages on Hackage.)
18:56:24 <k`> int-e: No. Are you saying that a regex library takes a long time to compile?
18:56:36 <int-e> this particular one does, IME
18:56:54 <int-e> I never looked into it though.
18:57:02 <int-e> (So I don't know why)
18:57:25 <monochrom> My idle wonder cuts both ways. bytestring and vector needed -O2 a decade ago. I also idly wonder whether today they still do.
18:57:57 → maerwald joins (~maerwald@mail.hasufell.de)
18:58:27 <monochrom> Forgive me for not even asking in #ghc, today is a hot day and I feel like chilling out and slacking off :)
19:00:16 <monochrom> But I'm happy enough that -O1 already does wonder and is the cabal default.
19:00:37 <dolio> I don't really understand why it matters much for those examples.
19:01:12 <dolio> If you're working on them, then I understand caring. But people using them recompile them like twice a year.
19:01:44 <monochrom> So in the case of bytestring and vector, my recollection is that -O2 turns on the last mile of aggressive fusion that they direly need.
19:02:51 <monochrom> So my guess is that takedouble does not need -O2.
19:03:27 <monochrom> takedouble is I/O-bound. It probably spends more time waiting for the OS.
19:03:31 × maerwald quits (~maerwald@mail.hasufell.de) (Changing host)
19:03:31 → maerwald joins (~maerwald@user/maerwald)
19:08:21 → pleo joins (~pleo@user/pleo)
19:13:58 → notzmv joins (~zmv@user/notzmv)
19:20:57 × machinedgod quits (~machinedg@66.244.246.252) (Ping timeout: 248 seconds)
19:21:12 × odnes quits (~odnes@5-203-220-108.pat.nym.cosmote.net) (Quit: Leaving)
19:21:37 → machinedgod joins (~machinedg@66.244.246.252)
19:22:18 → eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e)
19:26:49 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e) (Ping timeout: 248 seconds)
19:27:25 → kannon joins (~NK@135-180-47-54.fiber.dynamic.sonic.net)
19:28:14 <Franciman> sm: thank you very much for the podcast link, i'm enjoying it a lot
19:30:39 <shapr> is there some way a running haskell binary can ask cabal for the modules in the library stanza?
19:30:45 → szkl joins (uid110435@id-110435.uxbridge.irccloud.com)
19:30:49 <shapr> I should probably move this to #haskell-in-depth again
19:31:25 → eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
19:33:21 <monochrom> A running haskell binary may be running on a computer that has no cabal in the first place.
19:34:02 <shapr> yeah, true
19:34:34 → kimjetwav joins (~user@2607:fea8:2340:da00:59a1:33be:cb76:515a)
19:34:35 × dumptruckman quits (~dumptruck@45-79-173-88.ip.linodeusercontent.com) (Quit: ZNC - https://znc.in)
19:35:10 <int-e> For installed libraries, `ghc-pkg describe` has that kind of information.
19:35:15 <shapr> oh interesting
19:36:15 <geekosaur[m]> But a running program doesn't even know what libraries it's using
19:36:32 <int-e> sure, I shifted the goalpost to somewhere reachable
19:36:34 <shapr> I could shell out, but it's probably more trouble than it's worth at this stage
19:36:42 <kannon> hi, in this program, why the main in the if/else clause? It works the same without it: https://paste.tomsmeding.com/WYmwl13U
19:37:30 <kannon> edited: https://paste.tomsmeding.com/o8LJNdMJ
19:38:56 <int-e> hmm that's missing a "="
19:39:15 <int-e> ...so if by "it works the same" you mean that neither version is working...
19:39:42 <kannon> sorry yeah second edit https://paste.tomsmeding.com/XgSOUg7v
19:39:48 <int-e> but the idea here is to start over, asking for another line of input when the last input wasn't "quit"
19:39:51 <Maxdamantus> 00:50:20 < maerwald> what's the gain
19:40:13 <monochrom> I mean why not? This is just plain recursion expressing a plain loop.
19:40:53 <Maxdamantus> maerwald: I don't think it requires any of the things you listed (from the user of Haskell), but I guess to summarise the overall gain, it means that in general, it should be harder for code to be incorrect at handling data.
19:40:55 <int-e> So I'm not sure in which way the behavior is the same without that line... maybe this indicates lack of testing :P
19:41:13 <kannon> int-e I had it written correctly in ghci. they both worked whether main was in the clause or not..
19:41:30 <int-e> "worked"
19:41:44 <int-e> well, that may be the case, you didn't supply a specification
19:41:54 <monochrom> Yeah I call confirmation bias.
19:41:59 <Maxdamantus> maerwald: with the `ShortString` mechanism, someone clever could manually encode their UTF-8 or UTF-16 strings to `ShortString` without going through the proper APIs, and then they'll have code that seems to work on one platform but fails on the other platform even for well-formed Unicode.
19:42:28 <kannon> specification ? int-e
19:42:53 <int-e> "it works" is essentially devoid of meaning
19:43:09 <Maxdamantus> maerwald: and I have a feeling there could be security issues due to the mixing of encoding forms (that is, because `ShortString` sometimes represents UTF-8 and sometimes represents UTF-16).
19:43:16 <int-e> because it doesn't say what the expected behavior is
19:43:46 <int-e> kannon: http://paste.debian.net/1244895/ <-- this won't work the same way if you drop the call to `main` inside `main`.
19:45:18 <kannon> one moment thanks int-e
19:45:31 <Maxdamantus> maerwald: I think UTF-8 was pretty much designed around this principle. Unless you're usingh `wchar_t`, it's actually kind of hard to write C code that doesn't handle UTF-8 properly.
19:45:46 <maerwald> Maxdamantus: uhm... the UTF-8 roundtripping has security issues
19:45:57 <maerwald> see https://unicode.org/L2/L2009/09236-pep383-problems.html
19:46:04 <maerwald> and http://blog.omega-prime.co.uk/2011/03/29/security-implications-of-pep-383/
19:46:05 × juri_ quits (~juri@79.140.115.124) (Read error: Connection reset by peer)
19:46:18 <maerwald> if you don't touch the filepath encodings, there are none of those issues
19:46:20 → dumptruckman joins (~dumptruck@23-239-13-163.ip.linodeusercontent.com)
19:47:12 <maerwald> also: broken serialisation, broken equality checks, etc.
19:47:15 → juri_ joins (~juri@79.140.115.124)
19:47:21 × juri_ quits (~juri@79.140.115.124) (Read error: Connection reset by peer)
19:47:54 <Maxdamantus> maerwald: presumably you would be talking about security issues in my solution (using WTF-8) specifically on Windows?
19:48:06 <maerwald> no, I'm talking about PEP 383
19:48:08 <Maxdamantus> on Linux the conversion is a no-op.
19:48:21 <maerwald> which current Haskell code is using
19:48:22 → mc47 joins (~mc47@xmonad/TheMC47)
19:48:29 × dlbh^ quits (~dlbh@50.237.44.186) (Ping timeout: 256 seconds)
19:48:44 <maerwald> however, *without* enforcing UTF-8
19:49:20 <maerwald> and PEP 383 doesn't work for every encoding. It's only "total" under fully roundtrippable encodings and those that are ASCII supersets
19:50:05 <maerwald> the alternative would be forcing UTF-8 for all haskell code... then all your non-UTF8 filepaths have odd representations in Haskell
19:50:21 <maerwald> but they would at least be roundtrippable
19:50:34 <kannon> int-e: thanks I see the difference. cheers
19:50:35 <maerwald> but now you lost the original encoding, lol
19:50:43 <Maxdamantus> bytes are always roundtrippable, because there's no conversion.
19:50:48 <Maxdamantus> gtg
19:51:09 <maerwald> Maxdamantus: no,they are not
19:51:15 <Maxdamantus> or do you mean roundtrippable from [Char]?
19:51:34 <maerwald> https://peps.python.org/pep-0383/
19:51:37 <Maxdamantus> I think conversion from [Char] to filenames should just emit replacement characters on error.
19:51:49 <Maxdamantus> (eg, when using the PEP-383 encoding)
19:51:54 <Maxdamantus> I'm familiar with PEP-383.
19:52:16 → juri_ joins (~juri@79.140.115.124)
19:53:02 <maerwald> the problem now is also that conversion functions running on your filepath have to understand the meaning of those PEP-383 high surrogate pairs
19:53:08 <maerwald> or they might create security bugs
19:54:25 <maerwald> PEP-383 is only safe, if the user does nothing with the filepaths, but just passes them around
19:56:32 <maerwald> I dunno... why not just stop messing with them :p
19:56:39 × kannon quits (~NK@135-180-47-54.fiber.dynamic.sonic.net) (Quit: leaving)
19:57:04 <EvanR> formal abstract filepath algebra
19:57:27 <EvanR> filepath semigroupoids
19:57:52 <EvanR> don't worry about what they are, only worry about where they go
19:58:09 <Maxdamantus> maerwald: this only applies to conversion from [Char], which should emit replacement characters for surrogate Char values.
19:58:38 <maerwald> Maxdamantus: huh?
19:58:51 × juri_ quits (~juri@79.140.115.124) (Read error: Connection reset by peer)
19:58:57 <maerwald> if you emit replacement char, you break the semantics
19:59:10 → juri_ joins (~juri@79.140.115.124)
19:59:11 <maerwald> you might even delete a wrong file :p
19:59:40 <Maxdamantus> you can't in general round trip with [Char] to filenames.
20:00:00 <Maxdamantus> If you could, we could just continue using that for representing filenames.
20:00:06 <maerwald> roundtripping is well defined for UTF-8 with PEP 383
20:00:14 <maerwald> you can roundtrip any bytestring through that afaik
20:00:31 <EvanR> (but how do you utf-8 encode a surrogate Char)
20:00:54 <EvanR> or is that an obvious
20:01:47 × Infinite9 quits (~Infinite@2405:204:5381:d6e2:c147:f74f:65d9:3fcf) (Quit: Client closed)
20:02:51 <Maxdamantus> Well, you could do it that way, but that change would probably break current Haskell code.
20:03:42 × juri_ quits (~juri@79.140.115.124) (Ping timeout: 264 seconds)
20:03:45 → dlbh^ joins (~dlbh@50.237.44.186)
20:04:30 → juri_ joins (~juri@84-19-175-179.pool.ovpn.com)
20:04:31 <Maxdamantus> I think your method results in security issues because of the different representations of well-formed Unicode.
20:04:50 <maerwald> Maxdamantus: there's no unicode in abstract filepath.
20:05:31 × eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
20:05:33 × superbil quits (~superbil@1-34-176-171.hinet-ip.hinet.net) (Ping timeout: 265 seconds)
20:06:03 <Maxdamantus> eg, "à" is sometimes represented as [0x00c3, 0x00a0] and sometimes represented as [0x00e1|
20:06:19 <maerwald> Maxdamantus: those are different platforms
20:07:00 <Maxdamantus> if someone accidentally produces the wrong coding for the platform, you've got a string that is equal to the interpretation of ill-formed unicode.
20:07:14 <Maxdamantus> that's where security issues arise.
20:07:17 <maerwald> Maxdamantus: I don't understand what that means
20:08:10 → nate4 joins (~nate@98.45.169.16)
20:08:28 <maerwald> 1. there's no such thing as "wrong encoding" for abstract filepath, 2. they are distinct across platforms (they don't even have the same constructor)... so it's not even possible to accidentially compare a windows filepath with a unix filepath. That doesn't compile.
20:09:11 <maerwald> you'd have to explicitly convert them to ByteString or ShortByteString at which point, the library has no business with what you're doing anymore
20:09:39 <Maxdamantus> maerwald: if someone hardcodes [0x00e1] into their program because it works on Windows, then the program is run on Linux, I can match that string by providing the ill-formed UTF-8, <E1>
20:10:05 <maerwald> Maxdamantus: how would the user do that?
20:10:29 <maerwald> there is no *safe* function to do that
20:11:22 <Maxdamantus> maerwald: by providing a filename on Linux that contains thatminvalid UTF-8.
20:12:10 <Maxdamantus> maerwald: maybe it's a program that scans through a directory and executes a file if it's called "à"
20:12:13 <maerwald> this makes no sense to me... you're saying users can use unsafe API to construct wrong filepaths and then claim that's the fault of the library?
20:12:24 → johnw joins (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net)
20:12:27 <maerwald> you can already do that today with string based filepaths by switching encoding in between
20:13:11 <monochrom> unsafePerformIO comes from the library. It is the fault of the library. :)
20:13:14 × nate4 quits (~nate@98.45.169.16) (Ping timeout: 268 seconds)
20:13:36 <Maxdamantus> maerwald: the admin has other ways ofmpreventing people from making "à" files, but it turns out that that's not the actual name being tested.
20:13:49 <EvanR> now I'm imagining an idealized program which has a clean separation between pure code and the OS API, and being allowed to use both linux and windows at will, somehow xD
20:13:58 <Maxdamantus> anyway, need to stop typing. on phone on a bus and my hands are really cold.
20:14:29 <maerwald> Maxdamantus: I think you should check out the API. You'll see that it isn't easy to do what you're suggesting without either using internal modules or using functions that have the *unsafe* prefix
20:14:33 <monochrom> I thought the phone would be hot enough to warm your hands. Mine does.
20:15:04 <geekosaur> if you're relying on a unix filename being utf-8 you are sinning anyway
20:15:29 <monochrom> Yikes, I rely on utf-8 unix filenames all the time...
20:15:53 <maerwald> EvanR: I'm not sure about your proposal, I'll have to try a few examples
20:16:00 <monochrom> I have some Chinese filenames. Not going back to Big5. :)
20:16:01 <geekosaur> if yiou control those names it may be a safe assumption. until your backup program assumes latin-1…
20:16:30 <monochrom> Ah, true. Now I need to check that duplicity doesn't break my backup :)
20:16:31 <maerwald> EvanR: you mean basically bytestring that have all sorts of random surrogate chars... and whether pep 383 will choke on it?
20:16:50 <EvanR> maerwald, what I'm thinking of is impossible in practice... programs run on 1 OS at a time
20:17:00 <EvanR> as far as I know
20:17:13 <geekosaur> until windows decides to integrate wsl better
20:17:26 <geekosaur> (or goes back to the old posix subsystem stuff)
20:17:39 <maerwald> I ran a property test over the UTF-8 roundtrip encoding feeding it random bytestrings... it always roundtripped
20:18:06 <EvanR> I think issues with filepath exist way before we have such tech
20:19:12 → superbil joins (~superbil@1-34-176-171.hinet-ip.hinet.net)
20:19:23 → werneta joins (~werneta@137.78.30.207)
20:19:58 × z0k quits (~z0k@206.84.141.12) (Ping timeout: 240 seconds)
20:20:06 × _ht quits (~quassel@231-169-21-31.ftth.glasoperator.nl) (Remote host closed the connection)
20:20:12 <monochrom> EvanR: Continuing your crazy plan, we can re-define RPC to mean "relayed process control" meaning that you run a program on Windows and then you just suspend it and send its memory dump to a Linux host and resume running there. >:)
20:20:30 <EvanR> ah that might be a way
20:20:39 <geekosaur> isn't that where llvm came from?
20:20:49 <monochrom> Oh haha
20:20:49 <geekosaur> supercomputers want that tech
20:20:55 → eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e)
20:21:28 <monochrom> But blame it on ST:TNG for giving me that idea multiple times with its holodeck tricks.
20:21:52 <monochrom> holodeck+beaming tricks
20:22:23 <EvanR> moriarty I dare you to walk out that door
20:22:23 × shriekingnoise quits (~shrieking@201.212.175.181) (Quit: Quit)
20:22:29 <EvanR> no problem
20:22:31 <monochrom> Heh
20:22:44 → shriekingnoise joins (~shrieking@201.212.175.181)
20:23:22 <geekosaur> I stil want to know what numbskull didn't completely isolate those systems…
20:23:23 <EvanR> cogito ergo sum
20:23:48 → zeenk joins (~zeenk@2a02:2f04:a301:3d00:39df:1c4b:8a55:48d3)
20:24:02 <EvanR> TNG's optimistic future has lax computer security
20:24:09 <monochrom> I'm a great tautologist. I'll one-up Descarte with: cogito ergo cogito.
20:24:17 <k`> Well, look, sometimes when we get transporter transmissions we get data that can't be encoded as physical matter. So we send it to the holodeck and see what it looks like...
20:24:21 × bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 268 seconds)
20:24:51 <monochrom> Clearly Data is encoded as physical matter. >:)
20:25:55 <k`> You really don't want to create an anti-Riker just because a few bits got flipped in the transporter. But at the same time, you don't want to drop all his information because it's invalid.
20:26:17 <geekosaur> that's what ecc is for
20:26:25 → jmdaemon joins (~jmdaemon@user/jmdaemon)
20:26:34 <EvanR> anti-riker is impossible, how would you add a beard (because we shall not speak of anything featuring him without a beard)
20:26:36 <geekosaur> and fec, etc.
20:26:50 <k`> I think the Federation uses a patented Grey encoding.
20:27:33 → bitdex joins (~bitdex@gateway/tor-sasl/bitdex)
20:27:55 × yrlnry quits (~yrlnry@pool-108-2-150-109.phlapa.fios.verizon.net) (Remote host closed the connection)
20:28:06 <EvanR> wait is the transporter protocols and inevitable dramatic failures actually relevant to Filepath after all
20:28:21 <monochrom> Sorry!
20:28:47 → yrlnry joins (~yrlnry@pool-108-2-150-109.phlapa.fios.verizon.net)
20:29:10 <monochrom> But I guess inevitable dramatic failures in general are relevant to everything including file paths.
20:29:30 <k`> Is `git-annex` creating beardless Rikers?
20:29:43 <monochrom> The whole point why people are talking about inevitable dramatic failures when using PEP-383 for file paths.
20:30:25 <monochrom> I think no matter what you use for file paths, you will have dramatic failures.
20:30:55 → mikoto-chan joins (~mikoto-ch@esm-84-240-99-143.netplaza.fi)
20:31:12 <maerwald> the problem with PEP-383 is: 1. you lose the original encoding 2. it actually produces invalid UTF-8 in the strict sense
20:31:25 <maerwald> so if you run a strict UTF-8 converter over it, it fails
20:31:54 <maerwald> https://gist.github.com/hasufell/c600d318bdbe010a7841cc351c835f92#failure-6-re-encoding-pep-383-utf-8-based-filepath
20:32:42 <maerwald> that's not a great property to have lol
20:32:53 <k`> maerwald: The whole point of 383 is to not use strict UTF8 and to have a reversible encoder so you never lose the original encoding.
20:32:55 × mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection)
20:32:58 × yrlnry quits (~yrlnry@pool-108-2-150-109.phlapa.fios.verizon.net) (Ping timeout: 240 seconds)
20:33:54 <maerwald> k`: yes, but it doesn't work well
20:33:57 <monochrom> So in Haskell or any language with sum types, we can go like "data Path = Decodable [Char] | Undecodable ByteString", and neither case distorts the data.
20:34:14 <monochrom> (Replace [] by any efficient sequence container type you like)
20:34:33 <monochrom> Things like PEP-383 are invented by people who are afraid of sum types.
20:34:38 <maerwald> k`: a call to `setFileSystemEncoding` can make it fail... serializing the String is unsafe, etc.
20:34:52 <monochrom> or even the class-subclass encoding of sum types.
20:34:58 <EvanR> how about | Unencodable [Char] xD
20:35:13 × lyle quits (~lyle@104.246.145.85) (Quit: WeeChat 3.5)
20:35:19 <geekosaur> Char assumes Unicode codepoints. [Word8]
20:35:26 <k`> monochrom: So then when you append a Decodable prefix to an Undecodable filename you end up with an Undecodable path?
20:35:31 <geekosaur> which makes it just an inefficient ByteString
20:35:41 <EvanR> the utf16 surrogates...
20:35:46 → coot joins (~coot@213.134.190.95)
20:35:56 <monochrom> I want Unicode codepoints, Haskell Char, in the Decodable case.
20:35:58 <EvanR> oh, you meant utf32
20:35:59 <geekosaur> k`, what else could you end up with?
20:36:38 <monochrom> I think we should not allow that appending.
20:36:57 <geekosaur> probably the most correct solution
20:37:21 <EvanR> how can you deny the power of the /
20:37:22 <geekosaur> (granting that someone will want it, but in that case they should provide a Undecodable prefix)
20:38:17 <monochrom> Unpopular opinion: The whole point of PEP-383 is avoiding real sum types and rolling your own tagging.
20:38:25 <EvanR> if you have two valid paths, how could / not join them xD
20:38:45 <monochrom> Right? Use a high surrogate as tag for "I can't decode this byte, here is the byte itself"
20:38:59 <monochrom> In Haskell land we call it "Either Char Word8"
20:43:46 <k`> So is the string undecodable after the bad byte or just at the bad byte?
20:44:09 <monochrom> I guess my idea still doesn't answer the question of comparing a decodable path with an undecodable path, the latter being undecodable just because of misfortunate locale settings.
20:44:50 <monochrom> My idea declares the whole path undecodable. PEP-383 declares individual bytes undecodable.
20:45:26 <monochrom> I think there is no answer to that question.
20:45:40 <maerwald> the answer is: don't decode if you don't have to :p
20:45:51 <maerwald> and most of the time, you actually don't
20:46:07 <monochrom> Ah, right, I can stand behind that.
20:46:10 <maerwald> e.g. you don't need to understand the filename encoding when splitting filepaths
20:46:19 <maerwald> because the separator char '/' is well defined
20:46:24 <maerwald> and not encoding specific
20:46:30 <maerwald> you just scan and split, ignoring the rest
20:47:42 → nate4 joins (~nate@98.45.169.16)
20:47:42 × takuan quits (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
20:47:48 <k`> You also need to check for an escaped '/', but I see what you're saying.
20:48:13 <monochrom> I think I haven't seen a file system that provides for an escaped /
20:48:14 <maerwald> k`: so would you rather see Haskell enforcing UTF-8 so that PEP 383 actually works *all the time*?
20:48:42 <k`> maerwald: Yes.
20:48:43 <maerwald> that would mean to ignore locale
20:48:48 <monochrom> or windows providing for an escaped \
20:50:44 <EvanR> on mac typing / into the filename causes a fancy phantom / character from the astral plane to be used
20:50:52 <geekosaur> iirc namei() or equivalent is not per filesystem so there is no way to escape / regardless of filesystem
20:51:06 <geekosaur> back in the day that was converted to :
20:51:19 <geekosaur> and similarly : to / (whee ancient macos)
20:51:21 <EvanR> ascii / means /
20:51:36 <maerwald> k`: why not simply avoid roundtripping?
20:53:05 × Pickchea quits (~private@user/pickchea) (Ping timeout: 256 seconds)
20:54:04 → jgeerds joins (~jgeerds@55d45f48.access.ecotel.net)
20:56:02 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e) (Remote host closed the connection)
20:59:50 → Tuplanolla joins (~Tuplanoll@91-159-69-97.elisa-laajakaista.fi)
21:01:44 → eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e)
21:04:11 × bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
21:05:27 × coot quits (~coot@213.134.190.95) (Quit: coot)
21:06:21 → bitdex joins (~bitdex@gateway/tor-sasl/bitdex)
21:13:39 × pleo quits (~pleo@user/pleo) (Read error: Connection reset by peer)
21:14:01 → pleo joins (~pleo@user/pleo)
21:14:36 → MironZ3 joins (~MironZ@nat-infra.ehlab.uk)
21:14:55 → yrlnry joins (~yrlnry@pool-108-2-150-109.phlapa.fios.verizon.net)
21:14:57 × shriekingnoise quits (~shrieking@201.212.175.181) (Quit: Quit)
21:15:16 → shriekingnoise joins (~shrieking@201.212.175.181)
21:15:59 × MironZ quits (~MironZ@nat-infra.ehlab.uk) (Quit: Ping timeout (120 seconds))
21:15:59 MironZ3 is now known as MironZ
21:20:39 × rendar quits (~Paxman@user/rendar) (Quit: Leaving)
21:25:23 × mikoto-chan quits (~mikoto-ch@esm-84-240-99-143.netplaza.fi) (Ping timeout: 256 seconds)
21:25:59 → mikoto-chan joins (~mikoto-ch@esm-84-240-99-143.netplaza.fi)
21:28:28 × misterfish quits (~misterfis@ip214-130-173-82.adsl2.static.versatel.nl) (Ping timeout: 268 seconds)
21:28:59 → liz joins (~liz@host86-159-158-175.range86-159.btcentralplus.com)
21:35:01 × mikoto-chan quits (~mikoto-ch@esm-84-240-99-143.netplaza.fi) (Ping timeout: 244 seconds)
21:35:39 → bilegeek joins (~bilegeek@2600:1008:b06f:8528:b8b4:9bf9:3a8:ef97)
21:45:18 × __monty__ quits (~toonn@user/toonn) (Quit: leaving)
21:46:23 <tomsmeding> I believe it's still converted to : nowadays if you enter a / in Finder, or at least that worked a few years ago still
21:46:34 <tomsmeding> also ／
21:47:43 <EvanR> yeah that thing
21:47:58 <EvanR> proprietary solidus
21:49:11 × nate4 quits (~nate@98.45.169.16) (Ping timeout: 256 seconds)
21:51:14 × Qudit quits (~user@user/Qudit) (Remote host closed the connection)
21:52:46 <tomsmeding> スラッシュ
21:53:06 × eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e) (Remote host closed the connection)
21:53:26 → justsomeguy joins (~justsomeg@user/justsomeguy)
21:54:11 × gmg quits (~user@user/gehmehgeh) (Quit: Leaving)
21:57:31 × michalz quits (~michalz@185.246.204.107) (Remote host closed the connection)
22:06:40 × yauhsien quits (~yauhsien@61-231-23-53.dynamic-ip.hinet.net) (Remote host closed the connection)
22:07:19 × crazazy quits (~user@130.89.171.62) (Ping timeout: 256 seconds)
22:12:26 → yauhsien joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
22:16:58 × yauhsien quits (~yauhsien@61-231-23-53.dynamic-ip.hinet.net) (Ping timeout: 240 seconds)
22:23:41 → eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:99c9:a0a4:f69e:b22e)
22:25:08 × ubert quits (~Thunderbi@p200300ecdf0da56600626fc30d47cd25.dip0.t-ipconnect.de) (Ping timeout: 244 seconds)
22:33:43 → cosimone joins (~user@93-44-186-171.ip98.fastwebnet.it)
22:35:48 × Midjak quits (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep)
22:36:41 → Qudit joins (~user@user/Qudit)
22:43:04 × zer0bitz quits (~zer0bitz@2001:2003:f748:2000:b968:ef1b:5eee:ca89) (Ping timeout: 248 seconds)
22:46:22 → mikoto-chan joins (~mikoto-ch@esm-84-240-99-143.netplaza.fi)
22:47:26 × Inoperable quits (~PLAYER_1@fancydata.science) (Excess Flood)
22:50:00 → yauhsien joins (~yauhsien@61-231-23-53.dynamic-ip.hinet.net)
22:55:16 → Inoperable joins (~PLAYER_1@fancydata.science)
22:56:39 × werneta quits (~werneta@137.78.30.207) (Ping timeout: 268 seconds)
22:58:12 → werneta joins (~werneta@137.79.203.93)
22:58:13 × mikoto-chan quits (~mikoto-ch@esm-84-240-99-143.netplaza.fi) (Quit: WeeChat 3.5)
22:58:44 → mon_aaraj joins (~MonAaraj@user/mon-aaraj/x-4416475)
23:07:30 × Inoperable quits (~PLAYER_1@fancydata.science) (Excess Flood)
23:10:48 → Inoperable joins (~PLAYER_1@fancydata.science)
23:11:44 × Inoperable quits (~PLAYER_1@fancydata.science) (Excess Flood)
23:15:24 × mixfix41 quits (~sdenynine@user/mixfix41) (Quit: out for now)
23:19:34 → Inoperable joins (~PLAYER_1@fancydata.science)
23:20:06 × bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 268 seconds)
23:21:21 → superz joins (~superegg@user/superegg)
23:22:11 → sebastiandb joins (~sebastian@pool-108-31-128-56.washdc.fios.verizon.net)
23:22:18 → bitdex joins (~bitdex@gateway/tor-sasl/bitdex)
23:23:29 → Lord_of_Life_ joins (~Lord@user/lord-of-life/x-2819915)
23:23:58 × Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds)
23:24:24 → esrh joins (~user@sw-10121.atl5.as22384.net)
23:24:44 Lord_of_Life_ is now known as Lord_of_Life
23:26:15 × mon_aaraj quits (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 268 seconds)
23:26:15 × dlbh^ quits (~dlbh@50.237.44.186) (Ping timeout: 268 seconds)
23:28:05 → mon_aaraj joins (~MonAaraj@user/mon-aaraj/x-4416475)
23:28:06 × pleo quits (~pleo@user/pleo) (Quit: quit)
23:32:17 → mixfix41 joins (~sdenynine@user/mixfix41)
23:34:01 × lucifero quits (~satan@ip-046-223-003-068.um13.pools.vodafone-ip.de) (Ping timeout: 256 seconds)
23:35:57 → lucifero joins (~satan@ip-037-201-207-048.um10.pools.vodafone-ip.de)
23:39:29 → bucifero joins (~satan@ip-046-223-003-073.um13.pools.vodafone-ip.de)
23:39:41 × Tuplanolla quits (~Tuplanoll@91-159-69-97.elisa-laajakaista.fi) (Quit: Leaving.)
23:42:54 × lucifero quits (~satan@ip-037-201-207-048.um10.pools.vodafone-ip.de) (Ping timeout: 268 seconds)
23:44:21 ← pragma- parts (~chaos@user/pragmatic-chaos) (Bye!)
23:46:15 × justsomeguy quits (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.5)
23:46:51 → nate4 joins (~nate@98.45.169.16)
23:46:58 × werneta quits (~werneta@137.79.203.93) (Ping timeout: 240 seconds)
23:48:55 × zeenk quits (~zeenk@2a02:2f04:a301:3d00:39df:1c4b:8a55:48d3) (Quit: Konversation terminated!)
23:51:58 × jgeerds quits (~jgeerds@55d45f48.access.ecotel.net) (Ping timeout: 240 seconds)
23:54:25 × nate4 quits (~nate@98.45.169.16) (Ping timeout: 256 seconds)
23:55:15 × machinedgod quits (~machinedg@66.244.246.252) (Remote host closed the connection)
23:55:33 × alp_ quits (~alp@user/alp) (Ping timeout: 256 seconds)
23:56:42 <hololeap> Either x (y,z) -> (Either x y, z)
23:56:50 → machinedgod joins (~machinedg@66.244.246.252)
23:57:05 × sebastiandb quits (~sebastian@pool-108-31-128-56.washdc.fios.verizon.net) (Ping timeout: 268 seconds)
23:57:06 × esrh quits (~user@sw-10121.atl5.as22384.net) (Ping timeout: 264 seconds)
23:59:42 → mvk joins (~mvk@2607:fea8:5ce3:8500::4588)

All times are in UTC on 2022-06-22.