| 2023-01-30 00:00:15 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 248 seconds) |
| 2023-01-30 00:01:38 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@142.147.89.202) |
| 2023-01-30 00:02:15 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Read error: Connection reset by peer) |
| 2023-01-30 00:06:04 +0100 | cheater | (~Username@user/cheater) (Quit: Going offline, see ya! (www.adiirc.com)) |
| 2023-01-30 00:06:24 +0100 | <hololeap> | instance {-# OVERLAPPABLE #-} Monad m => MonadSay (EnvT m) where |
| 2023-01-30 00:06:31 +0100 | <hololeap> | instance {-# OVERLAPPING #-} MonadSay (EnvT IO) where |
| 2023-01-30 00:06:32 +0100 | cheater | (~Username@user/cheater) |
| 2023-01-30 00:06:53 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2023-01-30 00:07:05 +0100 | <hololeap> | I get an error about overlapping instances here: Monad m => EnvT m (Set Cabal.PackageId, Set FilePath) |
| 2023-01-30 00:07:36 +0100 | <hololeap> | what can I do about this, other than just get rid of that first instance? |
| 2023-01-30 00:07:48 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-01-30 00:08:51 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) (Remote host closed the connection) |
| 2023-01-30 00:09:49 +0100 | <hololeap> | basically, I want `MonadSay (EnvT IO)` to be the special case and anything else to fallback to the first instance |
| 2023-01-30 00:10:11 +0100 | danza | (~francesco@151.57.36.192) (Read error: Connection reset by peer) |
| 2023-01-30 00:10:36 +0100 | <hololeap> | here's the full error: http://sprunge.us/xCb2rL |
| 2023-01-30 00:14:08 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 00:15:18 +0100 | <hololeap> | adding IncoherentInstances to both modules didn't change the error |
| 2023-01-30 00:23:17 +0100 | eruditass | (uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-01-30 00:24:23 +0100 | danza | (~francesco@rm-19-52-159.service.infuturo.it) |
| 2023-01-30 00:28:10 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) (Ping timeout: 260 seconds) |
| 2023-01-30 00:33:56 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2023-01-30 00:37:02 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-01-30 00:38:08 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2023-01-30 00:39:09 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-01-30 00:41:24 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) |
| 2023-01-30 00:47:53 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2023-01-30 00:50:42 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-01-30 00:51:41 +0100 | Nolrai | (~Nolrai@c-73-240-99-98.hsd1.or.comcast.net) |
| 2023-01-30 00:53:27 +0100 | <Nolrai> | Hey, so I used to use summoner for making new projects in Haskell, but it hasn't been updated since 2020, should I use a cabal-install template or what? |
| 2023-01-30 00:55:57 +0100 | jwiegley | (~jwiegley@2600:1700:cf00:db0:ad33:58f8:1ff9:4d13) |
| 2023-01-30 00:59:57 +0100 | Nolrai | (~Nolrai@c-73-240-99-98.hsd1.or.comcast.net) (Quit: Client closed) |
| 2023-01-30 01:00:33 +0100 | <monochrom> | I think I haven't heard of other people here using summoner at all in the past. |
| 2023-01-30 01:01:18 +0100 | Nolrai | (~Nolrai@c-73-240-99-98.hsd1.or.comcast.net) |
| 2023-01-30 01:01:33 +0100 | <Nolrai> | Man it is quiet here. |
| 2023-01-30 01:01:53 +0100 | sawilagar | (~sawilagar@user/sawilagar) |
| 2023-01-30 01:02:35 +0100 | <monochrom> | So what do they use? cabal has a "cabal init", stack has a similar command, and I also heard that some people keep around their favourite starter directory structures. |
| 2023-01-30 01:06:31 +0100 | <geekosaur> | dunno about where you are, but it's Sunday night here and as usual for Sunday it has indeed been quiet |
| 2023-01-30 01:08:11 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:4fa4:6245:cbff:fe9f:48b1) (Quit: Leaving) |
| 2023-01-30 01:08:27 +0100 | <geekosaur> | and I just copy a cabal file, LICENSE, etc. from some other project to get started 🙂 |
| 2023-01-30 01:13:04 +0100 | <jackdk> | I copy a previous project or `cabal init` |
| 2023-01-30 01:13:47 +0100 | <yushyin> | i bet some use nix flake templates |
| 2023-01-30 01:16:44 +0100 | bhall | (~brunohall@138.199.22.99) |
| 2023-01-30 01:17:16 +0100 | <EvanR> | can you guys keep it down in here, it's Sunday |
| 2023-01-30 01:17:36 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 248 seconds) |
| 2023-01-30 01:18:36 +0100 | <Nolrai> | :P |
| 2023-01-30 01:18:45 +0100 | <Nolrai> | Anyway, thanks! |
| 2023-01-30 01:22:23 +0100 | <jackdk> | No it's not. |
| 2023-01-30 01:22:53 +0100 | <geekosaur> | noticed that, just ticked over 20ish minutes ago UTC |
| 2023-01-30 01:25:26 +0100 | acidjnk | (~acidjnk@p200300d6e715c427397aaa65a333c5a9.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2023-01-30 01:27:01 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 01:30:59 +0100 | mikoto-chan | (~mikoto-ch@2001:999:58c:394a:63de:7cd7:5e1f:8502) |
| 2023-01-30 01:31:46 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 268 seconds) |
| 2023-01-30 01:32:08 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Quit: Leaving) |
| 2023-01-30 01:35:10 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-01-30 01:35:11 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-01-30 01:35:11 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2023-01-30 01:37:37 +0100 | <sclv> | Nolrai: I just use "cabal init" and go from there |
| 2023-01-30 01:37:37 +0100 | danza | (~francesco@rm-19-52-159.service.infuturo.it) (Read error: Connection reset by peer) |
| 2023-01-30 01:37:58 +0100 | <sclv> | i find any other scaffolding beyond that is way too specific to one or another specific type of project |
| 2023-01-30 01:38:01 +0100 | danza | (~francesco@rm-19-52-159.service.infuturo.it) |
| 2023-01-30 01:40:21 +0100 | mikoto-chan | (~mikoto-ch@2001:999:58c:394a:63de:7cd7:5e1f:8502) (Ping timeout: 252 seconds) |
| 2023-01-30 01:43:04 +0100 | Inst | (~Inst@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 260 seconds) |
| 2023-01-30 01:46:05 +0100 | laalyn | (~laalyn@c-73-241-126-7.hsd1.ca.comcast.net) (Quit: Client closed) |
| 2023-01-30 01:46:23 +0100 | jwiegley | (~jwiegley@2600:1700:cf00:db0:ad33:58f8:1ff9:4d13) (Quit: ZNC - http://znc.in) |
| 2023-01-30 01:46:23 +0100 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in) |
| 2023-01-30 01:47:14 +0100 | mikoto-chan | (~mikoto-ch@2001:999:68c:b163:558d:f376:4e18:be8e) |
| 2023-01-30 02:00:12 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 02:01:33 +0100 | Nolrai | (~Nolrai@c-73-240-99-98.hsd1.or.comcast.net) (Quit: Client closed) |
| 2023-01-30 02:04:33 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 252 seconds) |
| 2023-01-30 02:04:34 +0100 | Ranhir | (~Ranhir@157.97.53.139) (Read error: Connection reset by peer) |
| 2023-01-30 02:07:33 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 252 seconds) |
| 2023-01-30 02:09:11 +0100 | mikoto-chan | (~mikoto-ch@2001:999:68c:b163:558d:f376:4e18:be8e) (Quit: WeeChat 3.6) |
| 2023-01-30 02:09:47 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds) |
| 2023-01-30 02:11:40 +0100 | Ranhir | (~Ranhir@157.97.53.139) |
| 2023-01-30 02:11:44 +0100 | <jean-paul[m]> | https://github.com/JonathanLorimer/templates/blob/main/template/haskell/flake.nix is nice for doing stuff like getting a compatible haskell-language-server installed and setting up formatting commit hooks |
| 2023-01-30 02:12:18 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-01-30 02:14:21 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) (Remote host closed the connection) |
| 2023-01-30 02:14:25 +0100 | <jean-paul[m]> | you still have to run cabal init yourself |
| 2023-01-30 02:15:08 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 02:18:26 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-01-30 02:19:52 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 268 seconds) |
| 2023-01-30 02:21:13 +0100 | Guest75 | (~Guest75@178.141.149.12) (Ping timeout: 260 seconds) |
| 2023-01-30 02:25:52 +0100 | xff0x | (~xff0x@2405:6580:b080:900:ccbb:e6cd:6139:338f) (Ping timeout: 248 seconds) |
| 2023-01-30 02:29:47 +0100 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) (Ping timeout: 265 seconds) |
| 2023-01-30 02:35:52 +0100 | cheater | (~Username@user/cheater) (Read error: Connection reset by peer) |
| 2023-01-30 02:40:26 +0100 | <sm> | hmm.. what tricks exist for re-exporting qualified imports, eg in a batteries-included module for beginners ? |
| 2023-01-30 02:40:56 +0100 | <sm> | I've got the required imports down to |
| 2023-01-30 02:40:56 +0100 | <sm> | import qualified "text" Data.Text as T |
| 2023-01-30 02:40:56 +0100 | <sm> | import qualified "text" Data.Text.IO as T |
| 2023-01-30 02:40:56 +0100 | <sm> | import Hledger.Cli.Script |
| 2023-01-30 02:41:11 +0100 | <sm> | which is not quite beginner friendly |
| 2023-01-30 02:48:41 +0100 | potash | (~foghorn@user/foghorn) |
| 2023-01-30 02:51:52 +0100 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) |
| 2023-01-30 03:00:06 +0100 | potash | (~foghorn@user/foghorn) (Read error: Connection reset by peer) |
| 2023-01-30 03:00:07 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Read error: Connection reset by peer) |
| 2023-01-30 03:01:22 +0100 | freeside | (~mengwong@122.11.248.245) |
| 2023-01-30 03:04:48 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 248 seconds) |
| 2023-01-30 03:09:04 +0100 | jargon | (~jargon@184.101.188.5) (Remote host closed the connection) |
| 2023-01-30 03:11:59 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2023-01-30 03:14:51 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) |
| 2023-01-30 03:15:10 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@142.147.89.202) (Ping timeout: 252 seconds) |
| 2023-01-30 03:17:19 +0100 | <sm> | I notice there's ImportQualifiedPost, which makes it: |
| 2023-01-30 03:17:19 +0100 | <sm> | import "text" Data.Text qualified as T |
| 2023-01-30 03:17:19 +0100 | <sm> | import "text" Data.Text.IO qualified as T |
| 2023-01-30 03:17:19 +0100 | <sm> | (less alignment-hostile) |
| 2023-01-30 03:18:12 +0100 | oldfashionedcow | A_Cow[broke] |
| 2023-01-30 03:18:34 +0100 | sm | wants PackageImportsPost too |
| 2023-01-30 03:19:10 +0100 | <sm> | import Data.Text as T qualified from "text" |
| 2023-01-30 03:19:34 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) (Ping timeout: 252 seconds) |
| 2023-01-30 03:20:06 +0100 | A_Cow[broke] | oldfashionedcow |
| 2023-01-30 03:20:30 +0100 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Quit: ZNC - https://znc.in) |
| 2023-01-30 03:20:59 +0100 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-01-30 03:21:03 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) |
| 2023-01-30 03:21:06 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-01-30 03:22:08 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-01-30 03:24:31 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 248 seconds) |
| 2023-01-30 03:26:47 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2023-01-30 03:30:45 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 260 seconds) |
| 2023-01-30 03:33:54 +0100 | opticblast | (~Thunderbi@172.58.84.5) (Ping timeout: 260 seconds) |
| 2023-01-30 03:38:12 +0100 | ddb | (~ddb@tilde.club) |
| 2023-01-30 03:38:16 +0100 | opticblast | (~Thunderbi@172.58.85.230) |
| 2023-01-30 03:39:26 +0100 | mei | (~mei@user/mei) (Ping timeout: 268 seconds) |
| 2023-01-30 03:40:15 +0100 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) (Ping timeout: 252 seconds) |
| 2023-01-30 03:40:34 +0100 | razetime | (~Thunderbi@117.193.5.58) |
| 2023-01-30 03:42:07 +0100 | cheater | (~Username@user/cheater) |
| 2023-01-30 03:42:15 +0100 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) |
| 2023-01-30 03:46:37 +0100 | pragma- | (~chaos@user/pragmatic-chaos) (Bye!) |
| 2023-01-30 03:47:05 +0100 | jero98772 | (~jero98772@2800:484:1d80:d8ce:4f4f:dc32:b9c4:cb5b) (Remote host closed the connection) |
| 2023-01-30 03:49:28 +0100 | Sgeo_ | (~Sgeo@user/sgeo) |
| 2023-01-30 03:50:28 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-01-30 03:52:48 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2023-01-30 04:09:00 +0100 | danza | (~francesco@rm-19-52-159.service.infuturo.it) (Read error: Connection reset by peer) |
| 2023-01-30 04:10:01 +0100 | AkechiShiro | (~licht@user/akechishiro) (Ping timeout: 252 seconds) |
| 2023-01-30 04:11:05 +0100 | AkechiShiro | (~licht@user/akechishiro) |
| 2023-01-30 04:12:52 +0100 | carbolymer | (~carbolyme@dropacid.net) (Ping timeout: 252 seconds) |
| 2023-01-30 04:13:01 +0100 | carbolymer | (~carbolyme@dropacid.net) |
| 2023-01-30 04:14:47 +0100 | td_ | (~td@i5387093F.versanet.de) (Ping timeout: 252 seconds) |
| 2023-01-30 04:16:49 +0100 | td_ | (~td@i53870926.versanet.de) |
| 2023-01-30 04:18:33 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2023-01-30 04:18:42 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving) |
| 2023-01-30 04:24:28 +0100 | danza | (~francesco@151.43.48.52) |
| 2023-01-30 04:27:55 +0100 | freeside | (~mengwong@122.11.248.245) (Ping timeout: 252 seconds) |
| 2023-01-30 04:28:17 +0100 | bilegeek | (~bilegeek@2600:1008:b049:eb4:91c5:5c6c:4cde:3554) |
| 2023-01-30 04:35:33 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2023-01-30 04:35:37 +0100 | freeside | (~mengwong@122.11.248.245) |
| 2023-01-30 04:41:07 +0100 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-01-30 04:41:07 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-01-30 04:41:07 +0100 | finn_elija | FinnElija |
| 2023-01-30 04:53:35 +0100 | freeside | (~mengwong@122.11.248.245) (Ping timeout: 248 seconds) |
| 2023-01-30 05:05:38 +0100 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds) |
| 2023-01-30 05:13:07 +0100 | danza | (~francesco@151.43.48.52) (Read error: Connection reset by peer) |
| 2023-01-30 05:13:31 +0100 | danza | (~francesco@151.43.48.52) |
| 2023-01-30 05:14:03 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-01-30 05:14:42 +0100 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-01-30 05:22:34 +0100 | h2017 | (~h2017@bras-base-clbaon0201w-grc-20-184-144-57-44.dsl.bell.ca) (Quit: Leaving) |
| 2023-01-30 05:24:48 +0100 | <smol-hors> | hmm, I'm trying to build a ghc to cross compile from linux to windows.. I tried `ghcup compile ghc -j 4 -b 9.0.2 -v 9.2.5 -x i686-w64-mingw32`, but I don't think that's right because I get `fatal error: windows.h: No such file or directory` |
| 2023-01-30 05:26:26 +0100 | <Lycurgus> | why do you need a cross compile? why not compile separately? |
| 2023-01-30 05:27:03 +0100 | <Lycurgus> | hs isn't binary portable |
| 2023-01-30 05:27:41 +0100 | <Lycurgus> | even if it is the math java |
| 2023-01-30 05:28:03 +0100 | <smol-hors> | as in compile on windows? I tried but I had problems linking the C++ and C parts of my program to the Haskell parts of my program |
| 2023-01-30 05:28:28 +0100 | <Lycurgus> | cross compile isn't the solution |
| 2023-01-30 05:29:05 +0100 | <smol-hors> | had Warning: corrupt .drectve at end of def file |
| 2023-01-30 05:29:23 +0100 | <smol-hors> | ok |
| 2023-01-30 05:29:50 +0100 | <Lycurgus> | yeah if you mess in hs at the ffi level bad stuff happens with ease if you're not sure of what ur doin |
| 2023-01-30 05:31:05 +0100 | <Lycurgus> | others can say, but i'm not sure how good the ghc windows support is |
| 2023-01-30 05:31:22 +0100 | <smol-hors> | it runs on mingw anyway :p |
| 2023-01-30 05:31:33 +0100 | <smol-hors> | which is apparently where the above warning comes from |
| 2023-01-30 05:31:36 +0100 | <Lycurgus> | oh yeah and there's that |
| 2023-01-30 05:31:40 +0100 | <Lycurgus> | unix in dos |
| 2023-01-30 05:32:05 +0100 | <smol-hors> | so what's the proper way to write a program in C++ and Haskell on Windows? |
| 2023-01-30 05:32:20 +0100 | <Lycurgus> | only used mingw once, a contract to do a branded version of mozilla on three platforms |
| 2023-01-30 05:32:48 +0100 | <Lycurgus> | use regular ghc for windows |
| 2023-01-30 05:33:04 +0100 | <smol-hors> | oh, is there a native ghc for windows? |
| 2023-01-30 05:33:07 +0100 | <Lycurgus> | and regular windows for c |
| 2023-01-30 05:33:12 +0100 | <smol-hors> | I just used ghcup because I thought it was recommended |
| 2023-01-30 05:33:13 +0100 | <Lycurgus> | you don't need mingw |
| 2023-01-30 05:33:21 +0100 | <smol-hors> | oh, good |
| 2023-01-30 05:33:47 +0100 | <Lycurgus> | ghcup is just a convenience tool |
| 2023-01-30 05:33:58 +0100 | <smol-hors> | all right. thanks :) |
| 2023-01-30 05:34:05 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2023-01-30 05:34:15 +0100 | <Lycurgus> | np |
| 2023-01-30 05:34:36 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-01-30 05:35:30 +0100 | Lycurgus | checks ghc on dos |
| 2023-01-30 05:35:37 +0100 | nattiestnate | (~nate@202.138.250.37) (Quit: WeeChat 3.8) |
| 2023-01-30 05:36:31 +0100 | oldfashionedcow | newfashionedcow |
| 2023-01-30 05:36:43 +0100 | <Lycurgus> | yeah there's two, depending on how you wanna handle bignums |
| 2023-01-30 05:36:49 +0100 | <smol-hors> | https://www.haskell.org/ghc/download_ghc_9_4_4.html#windows64 |
| 2023-01-30 05:37:05 +0100 | <smol-hors> | am I in the right place? I can only see mingw |
| 2023-01-30 05:37:09 +0100 | newfashionedcow | oldfashionedrat |
| 2023-01-30 05:37:39 +0100 | oldfashionedrat | A_Cow |
| 2023-01-30 05:37:42 +0100 | <Lycurgus> | the gmp would be preferable but then you gotta get gmp on windows so maybe the haskell implementation is better |
| 2023-01-30 05:38:24 +0100 | razetime | (~Thunderbi@117.193.5.58) (Ping timeout: 248 seconds) |
| 2023-01-30 05:38:31 +0100 | <Lycurgus> | ah yeah i see now |
| 2023-01-30 05:38:38 +0100 | <Lycurgus> | was afraid of that |
| 2023-01-30 05:38:52 +0100 | <Lycurgus> | see ppl don't like windows |
| 2023-01-30 05:39:13 +0100 | <Lycurgus> | and so the ghc ppl have pinned the dos impl on mingw |
| 2023-01-30 05:39:16 +0100 | <Lycurgus> | bummer |
| 2023-01-30 05:39:24 +0100 | <smol-hors> | rip |
| 2023-01-30 05:39:55 +0100 | <Lycurgus> | instead of doing a proper dos port |
| 2023-01-30 05:40:13 +0100 | <Lycurgus> | it's win32 too so ur c needs to use win32 |
| 2023-01-30 05:40:55 +0100 | <Lycurgus> | that's what you typically find in advanced computing cultures, not just hs |
| 2023-01-30 05:42:17 +0100 | <Lycurgus> | if possible i'd see if i could run the haskell on unix and communicate with whatever has to be on dos |
| 2023-01-30 05:43:34 +0100 | <smol-hors> | that is why I thought of cross-compilation using mingw. I got it working with C and C++ but the -x i686-w64-mingw32 for ghcup wanted a windows.h :S |
| 2023-01-30 05:44:29 +0100 | <Lycurgus> | yeah you'll have to hang out here or another hs channel for somebody with hs on dos experience, if such individuals exist |
| 2023-01-30 05:44:50 +0100 | <Lycurgus> | prolly somebody will suggest F# |
| 2023-01-30 05:44:55 +0100 | <smol-hors> | ok |
| 2023-01-30 05:46:56 +0100 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 248 seconds) |
| 2023-01-30 05:47:02 +0100 | <Lycurgus> | windows.h will be in win32 headers |
| 2023-01-30 05:47:27 +0100 | <Lycurgus> | installing visual studio should get it but havent' done dos dev in a while |
| 2023-01-30 05:47:59 +0100 | <Lycurgus> | unless that means somebody elses (mingw, ghc) windows.h |
| 2023-01-30 05:48:59 +0100 | <smol-hors> | hmm |
| 2023-01-30 05:49:02 +0100 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 2023-01-30 05:49:18 +0100 | <Lycurgus> | there days dos has a unix env but I don't know anything about it |
| 2023-01-30 05:49:56 +0100 | <Lycurgus> | hs on windows sounds like a footgun operation |
| 2023-01-30 05:51:24 +0100 | <Lycurgus> | s/there/these/ |
| 2023-01-30 05:56:24 +0100 | Vajb | (~Vajb@2001:999:404:9516:d621:6cbe:c71e:5686) (Read error: Connection reset by peer) |
| 2023-01-30 05:56:47 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2023-01-30 05:59:09 +0100 | phma | (~phma@2001:5b0:210b:94b8:7a1f:f3bb:5a0c:334d) (Read error: Connection reset by peer) |
| 2023-01-30 06:00:02 +0100 | phma | (~phma@host-67-44-208-154.hnremote.net) |
| 2023-01-30 06:01:26 +0100 | A_Cow | (~Rahul_San@user/oldfashionedcow) (Quit: WeeChat 3.8) |
| 2023-01-30 06:02:56 +0100 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2023-01-30 06:02:58 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-01-30 06:03:27 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-01-30 06:05:32 +0100 | <Lycurgus> | also you might search the logs for 'windows' |
| 2023-01-30 06:06:03 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt: personae.ai-integration.biz) |
| 2023-01-30 06:07:33 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2023-01-30 06:07:36 +0100 | khumba | (~khumba@user/khumba) |
| 2023-01-30 06:08:06 +0100 | Vajb | (~Vajb@2001:999:404:9516:d621:6cbe:c71e:5686) |
| 2023-01-30 06:11:23 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
| 2023-01-30 06:12:00 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2023-01-30 06:12:42 +0100 | <Lycurgus> | also looks like there's a build from source for windows, that might be a proper port |
| 2023-01-30 06:13:02 +0100 | <smol-hors> | o |
| 2023-01-30 06:13:46 +0100 | Lycurgus | (~juan@user/Lycurgus) (Client Quit) |
| 2023-01-30 06:16:03 +0100 | Neuromancer | (~Neuromanc@user/neuromancer) (Ping timeout: 260 seconds) |
| 2023-01-30 06:21:48 +0100 | <smol-hors> | on ghcup there is ghcup compile ghc |
| 2023-01-30 06:24:04 +0100 | <smol-hors> | not sure why they'd only package it with mingw if that is the case |
| 2023-01-30 06:24:21 +0100 | <smol-hors> | but worth a try |
| 2023-01-30 06:26:27 +0100 | <smol-hors> | hmm, I can probably just use the -x blah command line from windows... |
| 2023-01-30 06:26:32 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2023-01-30 06:26:52 +0100 | <smol-hors> | oh, but that defeats the purpose, nvm |
| 2023-01-30 06:27:32 +0100 | <smol-hors> | hmm |
| 2023-01-30 06:31:04 +0100 | <smol-hors> | if this doesn't work I can just cross-compile the C/C++ parts on linux to make them mingw-y and then the Haskell parts on Windows to make them mingw-y :S |
| 2023-01-30 06:32:01 +0100 | <smol-hors> | Fetching https://downloads.haskell.org/ghc/mingw/0.3/x86_64/mingw-w64-x86_64-mpfr-4.0.2-2-any.pkg.tar.xz => ghc-tarballs/mingw-w64/x86_64/mingw-w64-x86_64-mpfr-4.0.2-2-any.pkg.tar.xz |
| 2023-01-30 06:32:02 +0100 | <smol-hors> | ye |
| 2023-01-30 06:38:12 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-01-30 06:46:44 +0100 | <smol-hors> | ok, that works. I just need ghc.exe as my ghc and x86_64-w64-mingw-g{cc, ++} as my C/C++ compilers :p |
| 2023-01-30 06:48:07 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2023-01-30 06:48:26 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2023-01-30 06:48:37 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Read error: Connection reset by peer) |
| 2023-01-30 06:48:59 +0100 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 248 seconds) |
| 2023-01-30 06:50:44 +0100 | cyphase | (~cyphase@user/cyphase) |
| 2023-01-30 06:58:37 +0100 | mcglk | (~mcglk@131.191.49.120) (Read error: Connection reset by peer) |
| 2023-01-30 07:01:35 +0100 | mcglk | (~mcglk@131.191.49.120) |
| 2023-01-30 07:01:46 +0100 | johnw | (~johnw@2600:1700:cf00:db0:f0d6:3852:1ef5:be75) |
| 2023-01-30 07:01:49 +0100 | bilegeek | (~bilegeek@2600:1008:b049:eb4:91c5:5c6c:4cde:3554) (Quit: Leaving) |
| 2023-01-30 07:02:00 +0100 | Guest75 | (~Guest75@178.141.149.12) |
| 2023-01-30 07:02:21 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 252 seconds) |
| 2023-01-30 07:04:27 +0100 | mechap | (~mechap@user/mechap) |
| 2023-01-30 07:06:20 +0100 | varoo | (~varoo@122.161.91.19) |
| 2023-01-30 07:06:56 +0100 | opticblast | (~Thunderbi@172.58.85.230) (Ping timeout: 248 seconds) |
| 2023-01-30 07:06:56 +0100 | jbalint | (~jbalint@2600:6c44:117f:e98a:816a:9488:fb1:7b7) (Ping timeout: 248 seconds) |
| 2023-01-30 07:11:04 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-01-30 07:14:00 +0100 | freeside | (~mengwong@122.11.248.245) |
| 2023-01-30 07:17:34 +0100 | jbalint | (~jbalint@2600:6c44:117f:e98a:816a:9488:fb1:7b7) |
| 2023-01-30 07:26:00 +0100 | khumba | (~khumba@user/khumba) () |
| 2023-01-30 07:32:15 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-01-30 07:32:15 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-01-30 07:32:15 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2023-01-30 07:36:45 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2023-01-30 07:37:11 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-01-30 07:37:11 +0100 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) |
| 2023-01-30 07:40:04 +0100 | razetime | (~Thunderbi@117.193.5.58) |
| 2023-01-30 07:40:13 +0100 | mcglk | (~mcglk@131.191.49.120) (Quit: (seeya)) |
| 2023-01-30 07:47:19 +0100 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 268 seconds) |
| 2023-01-30 07:48:48 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2023-01-30 07:49:20 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-01-30 07:54:18 +0100 | trev | (~trev@user/trev) |
| 2023-01-30 08:00:30 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2023-01-30 08:03:11 +0100 | michalz | (~michalz@185.246.207.197) |
| 2023-01-30 08:03:47 +0100 | teddyc | (theodorc@cassarossa.samfundet.no) (Ping timeout: 246 seconds) |
| 2023-01-30 08:08:44 +0100 | danza | (~francesco@151.43.48.52) (Read error: Connection reset by peer) |
| 2023-01-30 08:15:22 +0100 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-01-30 08:17:08 +0100 | teddyc | (theodorc@cassarossa.samfundet.no) |
| 2023-01-30 08:18:52 +0100 | mcglk | (~mcglk@131.191.49.120) |
| 2023-01-30 08:19:38 +0100 | freeside | (~mengwong@122.11.248.245) (Ping timeout: 252 seconds) |
| 2023-01-30 08:21:10 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2023-01-30 08:24:25 +0100 | danza | (~francesco@151.35.92.17) |
| 2023-01-30 08:26:44 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-01-30 08:30:18 +0100 | phma | (~phma@host-67-44-208-154.hnremote.net) (Read error: Connection reset by peer) |
| 2023-01-30 08:31:12 +0100 | phma | (phma@2001:5b0:212a:9278:328d:f1cd:3dee:19c5) |
| 2023-01-30 08:36:26 +0100 | kenran | (~user@user/kenran) |
| 2023-01-30 08:42:29 +0100 | mmhat | (~mmh@p200300f1c707beafee086bfffe095315.dip0.t-ipconnect.de) |
| 2023-01-30 08:43:01 +0100 | mmhat | (~mmh@p200300f1c707beafee086bfffe095315.dip0.t-ipconnect.de) (Client Quit) |
| 2023-01-30 08:46:15 +0100 | mei | (~mei@user/mei) |
| 2023-01-30 09:02:09 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-01-30 09:04:31 +0100 | zeenk | (~zeenk@2a02:2f04:a014:8700::7fe) |
| 2023-01-30 09:04:36 +0100 | kenran` | (~user@user/kenran) |
| 2023-01-30 09:05:49 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:8095:1260:6fef:5d26) |
| 2023-01-30 09:06:24 +0100 | kenran | (~user@user/kenran) (Ping timeout: 248 seconds) |
| 2023-01-30 09:12:34 +0100 | kuribas | (~user@ptr-17d51emy7j9a6t4odfa.18120a2.ip6.access.telenet.be) |
| 2023-01-30 09:16:52 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2023-01-30 09:17:04 +0100 | elkcl | (~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) (Ping timeout: 248 seconds) |
| 2023-01-30 09:22:49 +0100 | <kuribas> | Would it be possible to create a lightweight langage with dependent types but without the complexity of current DT language? |
| 2023-01-30 09:23:49 +0100 | <merijn> | That depends on where you perceive the complexity of those languages to be? |
| 2023-01-30 09:24:14 +0100 | <kuribas> | well, for example full dependence of values and types. |
| 2023-01-30 09:24:24 +0100 | <kuribas> | requiring partial evaluation. |
| 2023-01-30 09:24:39 +0100 | <kuribas> | instead of just allowing functions at type level. |
| 2023-01-30 09:25:06 +0100 | <merijn> | kuribas: How would you know if something type checks with functions at the type level, but no partial evaluation? |
| 2023-01-30 09:25:07 +0100 | <tomsmeding> | that's not "dependent types" :p |
| 2023-01-30 09:25:15 +0100 | <kuribas> | merijn: full evaluation? |
| 2023-01-30 09:25:30 +0100 | <merijn> | kuribas: You don't always have the data for full evaluation |
| 2023-01-30 09:25:45 +0100 | <merijn> | kuribas: What if part of the type data is coming from runtime data? |
| 2023-01-30 09:25:46 +0100 | elkcl | (~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) |
| 2023-01-30 09:25:47 +0100 | <kuribas> | how is dependent haskell going to do that? |
| 2023-01-30 09:26:18 +0100 | <merijn> | kuribas: The same way as Agda and Coq, presumably |
| 2023-01-30 09:26:22 +0100 | <tomsmeding> | doesn't ghc _already_ do symbolic evaluation at the type level with type families |
| 2023-01-30 09:26:24 +0100 | <merijn> | (or Idris) |
| 2023-01-30 09:26:28 +0100 | <merijn> | tomsmeding: yes |
| 2023-01-30 09:26:29 +0100 | <kuribas> | merijn: indeed, not "real" dependent types then. |
| 2023-01-30 09:26:39 +0100 | <merijn> | kuribas: ?? |
| 2023-01-30 09:26:56 +0100 | <merijn> | How do agda and coq not have "real" dependent types?? |
| 2023-01-30 09:27:03 +0100 | <tomsmeding> | kuribas: I haven't read this, but might be relevant, and sounds good given the author list http://strictlypositive.org/Easy.pdf |
| 2023-01-30 09:27:20 +0100 | <kuribas> | merijn: I mean they have. But my hypothetical language not. |
| 2023-01-30 09:28:51 +0100 | <tomsmeding> | also relevant: https://github.com/VictorTaelin/Formality |
| 2023-01-30 09:29:09 +0100 | <kuribas> | hmm, but then adding unknown sized vectors gives a partial expression... |
| 2023-01-30 09:29:25 +0100 | <kuribas> | like "Vector (n + m) Int" |
| 2023-01-30 09:31:33 +0100 | <kuribas> | I guess partial evaluation is necessary then. |
| 2023-01-30 09:31:58 +0100 | <tomsmeding> | (point of these two links is to show that implementing a full dependently-typed language is not super hard, apparently) |
| 2023-01-30 09:32:14 +0100 | <tomsmeding> | (though they probably miss a couple of the niceties that other languages have) |
| 2023-01-30 09:32:18 +0100 | <kuribas> | tomsmeding: ghc does, but I believe dependent haskell will allow you to run actual haskell functions at type level, no? |
| 2023-01-30 09:32:25 +0100 | <tomsmeding> | kuribas: how is that different |
| 2023-01-30 09:32:45 +0100 | <tomsmeding> | once you have partial evaluation, the "only" thing that's necessary is expanding the language on which you do so |
| 2023-01-30 09:33:00 +0100 | <kuribas> | tomsmeding: well, the semantics of value and type functions are different in haskell. |
| 2023-01-30 09:33:07 +0100 | <tomsmeding> | difficulty is that the current partial evaluation model is I think not suited for _efficiently_ doing so |
| 2023-01-30 09:33:22 +0100 | <tomsmeding> | what's the difference? |
| 2023-01-30 09:33:24 +0100 | <kuribas> | the haskell one? |
| 2023-01-30 09:33:32 +0100 | <tomsmeding> | yeah |
| 2023-01-30 09:33:40 +0100 | <kuribas> | tomsmeding: well, type functions are bidirectional, like in prolog. |
| 2023-01-30 09:33:48 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 09:33:50 +0100 | <tomsmeding> | that's just additional interpretations of existing code |
| 2023-01-30 09:33:55 +0100 | <tomsmeding> | existing semantics doesn't change, right? |
| 2023-01-30 09:34:17 +0100 | <tomsmeding> | it's not like those extra rules are _inconsistent_ with the existing semantics |
| 2023-01-30 09:34:40 +0100 | <kuribas> | tomsmeding: I think idris typechecking is more efficient than haskell typelevel programming. There is normalization by evaluation which is supposedly very efficient. |
| 2023-01-30 09:34:54 +0100 | <tomsmeding> | right, and ghc doesn't do that AFAIK |
| 2023-01-30 09:35:19 +0100 | <kuribas> | tomsmeding: I guess not, just very tricky to implement... |
| 2023-01-30 09:35:27 +0100 | <tomsmeding> | to a first approximation, I believe it evaluates a bit whenever it needs the information in order to continue typechecking |
| 2023-01-30 09:35:36 +0100 | <tomsmeding> | like demand-driven evaluation, not "go for it now" |
| 2023-01-30 09:36:48 +0100 | <tomsmeding> | previously with a weird flattening algorithm that did something special with type families, now (after richard eisenberg's recent simplifications) a less weird algorithm but one that still does something weird with type families |
| 2023-01-30 09:37:10 +0100 | <kuribas> | type families are just very hard to reason about in haskell. |
| 2023-01-30 09:37:18 +0100 | <kuribas> | I think dependent types are much easier. |
| 2023-01-30 09:37:36 +0100 | <kuribas> | I don't get why so much haskell people have this conception that DT make stuff more complicated. |
| 2023-01-30 09:37:46 +0100 | <kuribas> | stuff being type level programming of course. |
| 2023-01-30 09:38:36 +0100 | <kuribas> | There is something to say about keeping things simple, but I don't like the clojure way of throwing away all static types. |
| 2023-01-30 09:40:10 +0100 | <kuribas> | people at my work have been saying haskell and type system is too complicated, but I can do it because I have "a big brain". |
| 2023-01-30 09:40:16 +0100 | <kuribas> | I am pretty sure that is not the case. |
| 2023-01-30 09:40:25 +0100 | <kuribas> | At least not bigger than my colleages. |
| 2023-01-30 09:41:02 +0100 | nerdypepper | (~nerdypepp@user/nerdypepper) (WeeChat 3.8) |
| 2023-01-30 09:41:12 +0100 | <kuribas> | So I have been thinking about where the complexity is. |
| 2023-01-30 09:41:25 +0100 | <tomsmeding> | are you sure it's not just familiarity? |
| 2023-01-30 09:41:30 +0100 | <kuribas> | yeah indeed. |
| 2023-01-30 09:41:37 +0100 | <kuribas> | And a lot of this knowledge builds up. |
| 2023-01-30 09:41:49 +0100 | <kuribas> | IMO understanding DT starts with understanding curry-howard. |
| 2023-01-30 09:42:01 +0100 | <tomsmeding> | programming experience with non-functional languages is almost useless when starting with haskell |
| 2023-01-30 09:42:11 +0100 | <tomsmeding> | only later do you find the bits that you _can_ reuse |
| 2023-01-30 09:42:13 +0100 | <kuribas> | well, these guys do clojure. |
| 2023-01-30 09:42:23 +0100 | <tomsmeding> | I guess the same goes for functional but untyped languages, to a lesser extent |
| 2023-01-30 09:42:36 +0100 | <kuribas> | But IMO clojure is closer to lisps than to static typed functional languages. |
| 2023-01-30 09:42:46 +0100 | <kuribas> | because they use little abstraction |
| 2023-01-30 09:43:03 +0100 | <kuribas> | instead use symbolic manipulation |
| 2023-01-30 09:43:09 +0100 | <tomsmeding> | there is a significant jump from mostly-functional-with-a-bit-of-mutation to purely functional |
| 2023-01-30 09:43:53 +0100 | <energizer> | isn't clojure purely functional? |
| 2023-01-30 09:44:24 +0100 | <tomsmeding> | (I thought it used commonly used set! like lisps do, but I haven't actually used clojure, kuribas must answer this one) |
| 2023-01-30 09:44:35 +0100 | <energizer> | i haven't either |
| 2023-01-30 09:44:49 +0100 | <kuribas> | tomsmeding: they try to avoid mutation |
| 2023-01-30 09:45:00 +0100 | <tomsmeding> | ah so it's better than most lisps |
| 2023-01-30 09:45:02 +0100 | <tomsmeding> | "better" |
| 2023-01-30 09:45:14 +0100 | <kuribas> | scheme as well. |
| 2023-01-30 09:45:28 +0100 | <kuribas> | but common lisp is mostly imperative. |
| 2023-01-30 09:46:08 +0100 | <kuribas> | IMO mutable in the large is worse than mutable in the small (mutating a function local variable). |
| 2023-01-30 09:46:27 +0100 | <tomsmeding> | local mutation is not a problem, see ST |
| 2023-01-30 09:46:50 +0100 | <kuribas> | Python in particular makes immutable hard, because it has frozen dataclasses, but no way to update a single variable. |
| 2023-01-30 09:47:03 +0100 | <tomsmeding> | in fact I'd like a language that let me do local mutation without the ceremony that ST requires |
| 2023-01-30 09:47:06 +0100 | avicenzi | (~avicenzi@2a00:ca8:a1f:b004::c32) |
| 2023-01-30 09:47:25 +0100 | <energizer> | aren't most languages like that? |
| 2023-01-30 09:47:27 +0100 | <kuribas> | tomsmeding: you mean provable pure, right? |
| 2023-01-30 09:47:40 +0100 | <tomsmeding> | in my wish language, yes |
| 2023-01-30 09:48:04 +0100 | <tomsmeding> | that would probably need language support in the form of some additional syntax |
| 2023-01-30 09:48:05 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 252 seconds) |
| 2023-01-30 09:48:07 +0100 | <energizer> | are you allowed to mutate the arguments in wishlang? |
| 2023-01-30 09:48:37 +0100 | <tomsmeding> | perhaps if we also have some form of linear types |
| 2023-01-30 09:48:41 +0100 | <tomsmeding> | probably uniqueness types |
| 2023-01-30 09:49:14 +0100 | <kuribas> | tomsmeding: I'd like polymorphic effects, like in flix https://flix.dev/ |
| 2023-01-30 09:49:24 +0100 | <tomsmeding> | well, what do you mean with "mutate the arguments" |
| 2023-01-30 09:49:46 +0100 | <tomsmeding> | that only presents problems when you mutate internals, and mutating internals is a thing that I'd need to watch out for anyway |
| 2023-01-30 09:49:56 +0100 | <tomsmeding> | at least if you have lazy semantics, less so with strict semantics |
| 2023-01-30 09:50:08 +0100 | <kuribas> | tomsmeding: hmm, I think flix allows local mutation. |
| 2023-01-30 09:50:17 +0100 | <energizer> | this sounds like rust |
| 2023-01-30 09:50:46 +0100 | <kuribas> | energizer: rust doesn't have purity annotations, does it? |
| 2023-01-30 09:50:47 +0100 | <tomsmeding> | but then with like 10% of the boilerplate lol |
| 2023-01-30 09:50:51 +0100 | <tomsmeding> | and that |
| 2023-01-30 09:50:58 +0100 | <energizer> | if it's not `mut`, you're not mutating it |
| 2023-01-30 09:51:00 +0100 | <tomsmeding> | I like haskell for its concise syntax |
| 2023-01-30 09:51:15 +0100 | <Hecate> | oh hi tomsmeding o/ |
| 2023-01-30 09:51:21 +0100 | <tomsmeding> | hello! |
| 2023-01-30 09:51:33 +0100 | <Hecate> | kuribas: what I like in flix is the datalog :D |
| 2023-01-30 09:52:57 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-01-30 09:53:15 +0100 | <dminuoso> | 09:43:53 energizer | isn't clojure purely functional? |
| 2023-01-30 09:53:20 +0100 | <dminuoso> | What is that "purely functional" anyway? |
| 2023-01-30 09:53:40 +0100 | <tomsmeding> | kuribas: I should look at Flix, sounds cool |
| 2023-01-30 09:53:43 +0100 | <dminuoso> | I think in general there's different conflating ideas, some of them not well principled. |
| 2023-01-30 09:53:59 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 09:54:04 +0100 | <dminuoso> | And more to the point, I think `purely` and `functional` are orthoginal ideas. |
| 2023-01-30 09:54:39 +0100 | <kuribas> | I think it typically means that functions don't perform side-effects. |
| 2023-01-30 09:54:53 +0100 | <kuribas> | so clojure isn't "pure". |
| 2023-01-30 09:55:33 +0100 | <dminuoso> | I think a more valuable notion lies in Haskell - i.e. distinguishing between evaluation and execution. |
| 2023-01-30 09:55:45 +0100 | <dminuoso> | And that isnt directly linked to whatever "function" is or means |
| 2023-01-30 09:56:17 +0100 | acidjnk | (~acidjnk@p200300d6e715c47228ee5485b7272aa0.dip0.t-ipconnect.de) |
| 2023-01-30 09:56:19 +0100 | <kuribas> | it does in the sense that a function always returns the same answer for the same inputs. |
| 2023-01-30 09:56:20 +0100 | <dminuoso> | Because clealy we have the same notion of C routines that are effectful `putStrLn :: String -> IO ()` for instance |
| 2023-01-30 09:56:34 +0100 | shriekingnoise_ | (~shrieking@186.137.175.87) (Ping timeout: 260 seconds) |
| 2023-01-30 09:57:20 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) (Remote host closed the connection) |
| 2023-01-30 09:58:12 +0100 | <dminuoso> | kuribas: I think people focusing on that idea really mean to talk about referential transparencyu |
| 2023-01-30 09:58:17 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 252 seconds) |
| 2023-01-30 09:58:50 +0100 | <dminuoso> | Anyway |
| 2023-01-30 09:59:01 +0100 | <dminuoso> | "purely functional" conflates "pure functions" with "functional" and I think its a bit silly |
| 2023-01-30 09:59:13 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-01-30 09:59:25 +0100 | <energizer> | there are a whole bunch of things that pure means |
| 2023-01-30 09:59:28 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2023-01-30 09:59:44 +0100 | <energizer> | or, can |
| 2023-01-30 10:00:37 +0100 | <dminuoso> | I think `pure` usually refers to functions being pure "deterministic output and lack of side effects", or expressions being pure (no non-pure functions being used in a given expression). Are there other notions? |
| 2023-01-30 10:00:39 +0100 | <maerwald> | kuribas: what does "answer" mean? |
| 2023-01-30 10:00:44 +0100 | <energizer> | "no side effects" seems like a stricter thing than "referentially transparent" |
| 2023-01-30 10:02:16 +0100 | <energizer> | example, one take on "computational effects" breaks it down into various components https://bpa.st/QB4NG |
| 2023-01-30 10:03:31 +0100 | nschoe | (~q@141.101.51.197) |
| 2023-01-30 10:03:45 +0100 | varoo | (~varoo@122.161.91.19) (Read error: Connection reset by peer) |
| 2023-01-30 10:04:05 +0100 | varoo | (~varoo@122.161.91.19) |
| 2023-01-30 10:05:04 +0100 | <Hecate> | I have no idea why we still use the terminology of "no side-effect" instead of "effect tracking" |
| 2023-01-30 10:05:17 +0100 | <Hecate> | which seems closer to (my) reality (at least :p) |
| 2023-01-30 10:05:37 +0100 | <dminuoso> | "effect tracking" is a bit of an exaggeration though |
| 2023-01-30 10:06:06 +0100 | <dminuoso> | But sure, effect tracking - but that is done by separating evaluation from execution |
| 2023-01-30 10:06:25 +0100 | <dminuoso> | Though it is ironic that in the underlying model execution happens *in* evaluation (that is we actually have an impure underlying language) |
| 2023-01-30 10:06:48 +0100 | <dminuoso> | In the absence of unsafePerformIO, it is just an implementation detail however |
| 2023-01-30 10:07:14 +0100 | <Hecate> | dminuoso: Certainly when you only have 'IO a' as a return type it's a bit obfuscated, but we can also have 'insertPackage :: (DB :> es) => Package -> Eff es ()' |
| 2023-01-30 10:07:58 +0100 | <Hecate> | and tbh I have yet to see F#/C# get the same thing :D Instead they pass the implementation/handlers as function parameters |
| 2023-01-30 10:08:12 +0100 | <dminuoso> | Hecate: Given that, enough extensions enabled, our type system is turing complete, then Haskell is anything that is expressiblie in a turing complete language. |
| 2023-01-30 10:08:24 +0100 | <dminuoso> | Im not entirely sure whether being able to *model* it as a library is necessarily a property of the language |
| 2023-01-30 10:10:10 +0100 | <Hecate> | dminuoso: no no don't derail the conversation, we were in the distinction between "no side-effect" and "tracking side-effects" :p |
| 2023-01-30 10:10:22 +0100 | CiaoSen | (~Jura@p200300c9573284002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2023-01-30 10:10:54 +0100 | <dminuoso> | Okay but then "we dont really track side-effects in the language", but rather "you could do it..." |
| 2023-01-30 10:11:22 +0100 | <Hecate> | dminuoso: on my side it's the rigidity of the wording of "no side-effects" that bugs me |
| 2023-01-30 10:12:08 +0100 | <Franciman> | would you prefer «no observable side-effects»? |
| 2023-01-30 10:12:11 +0100 | <Hecate> | unless we really start from the basis that "side-effect" means "unchecked yet observable IO" |
| 2023-01-30 10:12:45 +0100 | <Hecate> | yeah I guess should synchronise our watches here |
| 2023-01-30 10:13:14 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2023-01-30 10:13:18 +0100 | <Hecate> | my usage (and understanding) of "side-effect" is that it is 1. observable and 2. in what we would customarily call "IO" |
| 2023-01-30 10:13:39 +0100 | <Franciman> | a question: observable from who? And from where? |
| 2023-01-30 10:13:53 +0100 | <Hecate> | from the user |
| 2023-01-30 10:14:10 +0100 | <Hecate> | that's why FFI to C for addition is not necessarily relevant to be put in IO |
| 2023-01-30 10:14:25 +0100 | <Hecate> | whereas FFI that can block a program's execution would be a more relevant candidate |
| 2023-01-30 10:14:48 +0100 | <dminuoso> | Hecate: Its interesting, there is certainly notions that consider "side-effects" stuff that you cannot observe from within your domain. |
| 2023-01-30 10:14:58 +0100 | <dminuoso> | (the term "side-effects" almost literally implies it even) |
| 2023-01-30 10:16:07 +0100 | <Hecate> | dminuoso: yes! whereas people outside of Haskell seem to hear "no side-effect" and automatically reply "well if I can't perform side-effects what the fuck am I supposed to do with this language? add numbers until the heat death of the universe?" |
| 2023-01-30 10:16:41 +0100 | <Hecate> | let's check Wikipedia |
| 2023-01-30 10:16:53 +0100 | <Hecate> | > In computer science, an operation, function or expression is said to have a side effect if it modifies some state variable value(s) outside its local environment, which is to say if it has any observable effect other than its primary effect of returning a value to the invoker of the operation |
| 2023-01-30 10:16:54 +0100 | <lambdabot> | <hint>:1:20: error: parse error on input ‘,’ |
| 2023-01-30 10:17:07 +0100 | <Hecate> | bugger off lambdabot |
| 2023-01-30 10:18:26 +0100 | <Hecate> | dminuoso: so I partly agree that it is "non-observable from within [a] domain" except that the domain of the user / outside world is the superset of all domains that can have effects escaping these domains unchecked :p |
| 2023-01-30 10:18:45 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-01-30 10:18:46 +0100 | <Hecate> | here domain = local environment |
| 2023-01-30 10:19:08 +0100 | <dminuoso> | What is local environment? |
| 2023-01-30 10:19:40 +0100 | <Hecate> | dminuoso: isn't that the domain that you were talking about? |
| 2023-01-30 10:19:47 +0100 | <Hecate> | or do you have another definition in mind? |
| 2023-01-30 10:19:48 +0100 | <dminuoso> | Oh that domain |
| 2023-01-30 10:19:48 +0100 | <[exa]> | Hecate: adding numbers produces a heat side effect btw :D |
| 2023-01-30 10:19:57 +0100 | <Hecate> | [exa]: :3 |
| 2023-01-30 10:20:18 +0100 | <dminuoso> | And adding numbers also allocates registers, using a value pollutes cache, alters timings |
| 2023-01-30 10:20:30 +0100 | <dminuoso> | Using CPU time degrades system performance |
| 2023-01-30 10:20:39 +0100 | <dminuoso> | So there's even non-hypothetical effects |
| 2023-01-30 10:21:04 +0100 | <Hecate> | hence the concept of user-observability |
| 2023-01-30 10:21:10 +0100 | <Hecate> | use 2 registers -> meh |
| 2023-01-30 10:21:20 +0100 | <Hecate> | block the execution -> okay now that's a bit more visible |
| 2023-01-30 10:21:20 +0100 | <dminuoso> | Maybe a good definition of `side-effects` would be that of syscalls. |
| 2023-01-30 10:22:06 +0100 | <dminuoso> | Hecate: there's certainly code that is only correct under the assumption of certain timing properties - namely cryptographic code. |
| 2023-01-30 10:22:28 +0100 | <Hecate> | dminuoso: and that's observable as shit yeah |
| 2023-01-30 10:22:30 +0100 | <dminuoso> | So in that sense, even an extra register allocation from the register file can alter timings of code |
| 2023-01-30 10:23:06 +0100 | <Hecate> | hmm |
| 2023-01-30 10:23:11 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 248 seconds) |
| 2023-01-30 10:23:13 +0100 | <Hecate> | dminuoso: have you read the article btw? |
| 2023-01-30 10:23:15 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2023-01-30 10:23:19 +0100 | <Hecate> | https://en.wikipedia.org/wiki/Side_effect_(computer_science) |
| 2023-01-30 10:23:27 +0100 | <Hecate> | temporality is talked about |
| 2023-01-30 10:23:42 +0100 | <[exa]> | the discussion about purity seems completely skewed by the sole definition of purity being a negative (!∃) clause in an open world |
| 2023-01-30 10:24:14 +0100 | akegalj | (~akegalj@93-138-129-164.adsl.net.t-com.hr) |
| 2023-01-30 10:24:15 +0100 | <dminuoso> | Hecate: Sure, I think one important part that is missing here is that purity has a tolerance level. |
| 2023-01-30 10:24:29 +0100 | <dminuoso> | That is, purity is not just about altering state outside the local environment, but whether you care about that at all. |
| 2023-01-30 10:24:40 +0100 | <dminuoso> | whether that is relevant for the correctness/meaning of your program |
| 2023-01-30 10:25:06 +0100 | <[exa]> | ( ^ yep, you can't have purity without closing the world. ) |
| 2023-01-30 10:25:34 +0100 | jespada_ | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2023-01-30 10:25:55 +0100 | <dminuoso> | which begs the question what "local environment" even means |
| 2023-01-30 10:26:23 +0100 | <dminuoso> | Because if your program semantics depend upon it, isnt that part of its "environment" as well? |
| 2023-01-30 10:26:38 +0100 | <Hecate> | it means pretty much what you need to mean to ensure that your model of purity & unchecked side-effects enabled you to write programs that are correct according to how you need them to be :P |
| 2023-01-30 10:28:01 +0100 | <[exa]> | Hecate: that's the usual practice in programming everywhere (sometimes not wrt. purity but wrt. data consistency and other properties.) |
| 2023-01-30 10:28:38 +0100 | <Hecate> | dminuoso: a vague, vague defintion of "local environment" is "the thing that holds your state" and then I'll refer you to idempotence :P |
| 2023-01-30 10:28:52 +0100 | <[exa]> | you need to draw the line, and many people accept the usual line drawn (usually C-ish or math-ish) as the universal truth |
| 2023-01-30 10:29:00 +0100 | <dminuoso> | Hecate: but clearly, if it "modifies other state" and you care about that state, then that "other state is part of your state as well" |
| 2023-01-30 10:29:08 +0100 | <Hecate> | dminuoso: yep |
| 2023-01-30 10:29:41 +0100 | <Hecate> | that being said I'm more in favour of bounded contexts |
| 2023-01-30 10:30:17 +0100 | <Hecate> | and so you explicitly acknowledge boundaries between entities based on what they do, and not necessarily on what they depend on, in the sense of business operations |
| 2023-01-30 10:30:22 +0100 | <Hecate> | (business as in domain) |
| 2023-01-30 10:32:54 +0100 | <Hecate> | (come to my talk at FOSDEM if you want to learn more about bounded contexts) |
| 2023-01-30 10:33:00 +0100 | <Hecate> | (#ad) |
| 2023-01-30 10:33:09 +0100 | kuribas | (~user@ptr-17d51emy7j9a6t4odfa.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2023-01-30 10:41:53 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2023-01-30 10:43:06 +0100 | jespada | (~jespada@148.252.133.207) |
| 2023-01-30 10:45:07 +0100 | danza | (~francesco@151.35.92.17) (Read error: Connection reset by peer) |
| 2023-01-30 10:45:11 +0100 | chele | (~chele@user/chele) |
| 2023-01-30 10:51:31 +0100 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2023-01-30 10:52:34 +0100 | malte | (~malte@mal.tc) |
| 2023-01-30 10:55:20 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-01-30 10:57:47 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) |
| 2023-01-30 11:00:25 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 11:02:30 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) (Ping timeout: 255 seconds) |
| 2023-01-30 11:02:56 +0100 | danza | (~francesco@151.53.27.222) |
| 2023-01-30 11:04:43 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 252 seconds) |
| 2023-01-30 11:08:00 +0100 | haritz | (~hrtz@user/haritz) (Ping timeout: 248 seconds) |
| 2023-01-30 11:09:02 +0100 | ft | (~ft@p4fc2a257.dip0.t-ipconnect.de) (Quit: leaving) |
| 2023-01-30 11:10:46 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-01-30 11:11:49 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 260 seconds) |
| 2023-01-30 11:20:16 +0100 | maerwald | (~maerwald@mail.hasufell.de) (Changing host) |
| 2023-01-30 11:20:16 +0100 | maerwald | (~maerwald@user/maerwald) |
| 2023-01-30 11:20:28 +0100 | <akegalj> | How come haskell has so much less security issues reported than other languages https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Haskell ? Is it just that it is not used much in security contexts so nobody found problems ? |
| 2023-01-30 11:21:10 +0100 | <akegalj> | (I mean, nobody was looking for the problems) |
| 2023-01-30 11:22:38 +0100 | <merijn> | akegalj: I think 2 main things: 1) not a lot of user facing services, and 2) memory safety |
| 2023-01-30 11:22:39 +0100 | <[_________]> | it's because Haskell is safe language. |
| 2023-01-30 11:23:16 +0100 | <merijn> | akegalj: Google's Project Zero found that something, like 60% of CVEs relates to memory safety issues. So being memory safe by default rules out close to two-thirds of issues ;) |
| 2023-01-30 11:23:44 +0100 | <maerwald> | akegalj: it's not used in security contexts |
| 2023-01-30 11:24:26 +0100 | <maerwald> | and generally has less popular libraries/systems that are regularly screened |
| 2023-01-30 11:24:46 +0100 | <[exa]> | the other 40% of the issues is traditionally input validation, which is also super easy to do right in haskell |
| 2023-01-30 11:25:10 +0100 | talismanick | (~talismani@2601:200:c181:4c40::1be2) (Ping timeout: 252 seconds) |
| 2023-01-30 11:25:28 +0100 | <[exa]> | re security context, maybe hledger should count in there |
| 2023-01-30 11:26:05 +0100 | <merijn> | I think the two main security issues with Haskell would be either 1) DOS attacks due to libraries not being battle-tested enough for that and 2) wildly unsafe crypto due to insufficient reviewing and laziness making constant time crypto computations hard |
| 2023-01-30 11:26:25 +0100 | <maerwald> | oh, but we have types... it must be safe |
| 2023-01-30 11:26:45 +0100 | <merijn> | [exa]: hledger is run on a local system, to exploit any bugs in hleder the user's system has to already be compromised |
| 2023-01-30 11:26:59 +0100 | <merijn> | At which point you don't need bugs in hledger anymore |
| 2023-01-30 11:27:10 +0100 | <[exa]> | ah true |
| 2023-01-30 11:27:22 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 252 seconds) |
| 2023-01-30 11:27:32 +0100 | <merijn> | And most famous Haskell things are like that |
| 2023-01-30 11:28:17 +0100 | <merijn> | I guess bazqux and maybe shellcheck's website are the only big "public facing" Haskell services I know |
| 2023-01-30 11:28:20 +0100 | <maerwald> | we have TUF implemented in Haskell... well, half-assed, that is |
| 2023-01-30 11:28:28 +0100 | <maerwald> | not sure it has been reviewed |
| 2023-01-30 11:28:34 +0100 | <maerwald> | hackage/cabal rely on it |
| 2023-01-30 11:28:43 +0100 | <merijn> | maerwald: why half-assed? |
| 2023-01-30 11:28:49 +0100 | <maerwald> | because it's tied to hackage |
| 2023-01-30 11:28:54 +0100 | <[exa]> | "hackage relies on it" might count as a pretty tough review |
| 2023-01-30 11:29:01 +0100 | <maerwald> | [exa]: no |
| 2023-01-30 11:29:10 +0100 | <merijn> | [exa]: how so? |
| 2023-01-30 11:29:24 +0100 | __monty__ | (~toonn@user/toonn) |
| 2023-01-30 11:29:38 +0100 | <maerwald> | merijn: https://github.com/haskell/hackage-security/issues/249 |
| 2023-01-30 11:29:46 +0100 | <[exa]> | it's on internet and no one sploited it yet? |
| 2023-01-30 11:29:56 +0100 | <maerwald> | [exa]: how do you know? |
| 2023-01-30 11:30:10 +0100 | [exa] | starts feeling unsafe |
| 2023-01-30 11:31:08 +0100 | <merijn> | maerwald: I mean, I don't think that makes the implementation half-assed. Not as useful as it could be, but "implemented half-assed" sounds like the actual code implementing it is of negligent quality |
| 2023-01-30 11:31:30 +0100 | <maerwald> | yes, that is definitely half-assed |
| 2023-01-30 11:31:41 +0100 | <maerwald> | TUF is a framework that you're supposed to implement as a library |
| 2023-01-30 11:31:47 +0100 | <maerwald> | no idea what this is |
| 2023-01-30 11:32:30 +0100 | <maerwald> | and I'm questioning whether you can have a clean implementation if it's NOT implemented as a library |
| 2023-01-30 11:33:36 +0100 | jespada | (~jespada@148.252.133.207) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2023-01-30 11:33:40 +0100 | <maerwald> | you can't even audit it properly that way |
| 2023-01-30 11:38:28 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2023-01-30 11:39:31 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-01-30 11:40:14 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 11:40:24 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2023-01-30 11:41:25 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2023-01-30 11:43:07 +0100 | <Profpatsch> | akegalj: The biggest issue you can expect from Haskell libraries is A) DDoS via space leaks and B) not a lot of eyes on some of the code, even sometimes very deep in the library stack |
| 2023-01-30 11:43:39 +0100 | <Profpatsch> | This is mitigated somewhat by the fact that attackers usually don’t optimize for Haskell (unless it’s a targeted attack but then you have other problems) |
| 2023-01-30 11:44:11 +0100 | <Profpatsch> | I’d expect Haskell crypto to hold up somewhat, due to the fact that nobody targets it |
| 2023-01-30 11:44:12 +0100 | <razetime> | I'm trying to load a file into ghci from this project: https://github.com/diku-dk/futhark (src/Language/Futhark/Query.hs), but it complains that the imported modules are not in the search files. How do I tell it which modules to load? |
| 2023-01-30 11:44:27 +0100 | <merijn> | Profpatsch: That's a DoS, not DDoS :p |
| 2023-01-30 11:44:30 +0100 | <Profpatsch> | yes |
| 2023-01-30 11:44:37 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 252 seconds) |
| 2023-01-30 11:44:42 +0100 | <Profpatsch> | A single machine probably is enough to crash 80% of the Haskell webservices out there :P |
| 2023-01-30 11:44:45 +0100 | <tomsmeding> | razetime: have you tried `cabal repl`? |
| 2023-01-30 11:44:56 +0100 | <razetime> | i will try that |
| 2023-01-30 11:45:14 +0100 | <tomsmeding> | razetime: `cabal repl` is the thing that starts ghci with all of the relevant modules in its search path |
| 2023-01-30 11:45:28 +0100 | <merijn> | Profpatsch: Well, matter, that DDoS relies on distribution to run a target out of bandwidth. Exploiting a space leak to blow up memory consumption is just "denial of service" :p |
| 2023-01-30 11:45:30 +0100 | <tomsmeding> | razetime: use `:m *Language.Futhark.Query` afterwards to switch focus into that module |
| 2023-01-30 11:45:32 +0100 | <razetime> | i see, thanks. Will ask if I have any more doubts |
| 2023-01-30 11:45:54 +0100 | <tomsmeding> | razetime: see also https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html#ghci-module-cmd |
| 2023-01-30 11:45:55 +0100 | <Profpatsch> | akegalj: don’t let that dissuade you though, Haskell is still one of the best languages for writing web services out there |
| 2023-01-30 11:46:10 +0100 | <Profpatsch> | And issues are gonna be solved in time and with enough industry adoption |
| 2023-01-30 11:46:29 +0100 | <Profpatsch> | It has a lot less bugs than anything nodejs I’d expect |
| 2023-01-30 11:46:47 +0100 | razetime | (~Thunderbi@117.193.5.58) (Read error: Connection reset by peer) |
| 2023-01-30 11:47:01 +0100 | razetime | (~Thunderbi@117.193.5.58) |
| 2023-01-30 11:47:27 +0100 | <razetime> | sorry tomsmeding, cabal repl ate all my ram and crashed my computer :') |
| 2023-01-30 11:47:36 +0100 | <razetime> | so it got disconnected |
| 2023-01-30 11:47:38 +0100 | <tomsmeding> | 😂 |
| 2023-01-30 11:47:43 +0100 | <tomsmeding> | wat |
| 2023-01-30 11:48:01 +0100 | <razetime> | futhark build is pretty heavy on the resources, since it's a language compiler |
| 2023-01-30 11:48:04 +0100 | <Profpatsch> | akegalj: For a recent security issue that has been found and fixed, look at the Aeson Map/KeyMap migration. |
| 2023-01-30 11:48:11 +0100 | <tomsmeding> | razetime: ah right, might want to try `cabal build -j1` before |
| 2023-01-30 11:48:33 +0100 | <tomsmeding> | the -j1 makes it use one parallel compiler unit only, which of course also reduces memory consumption |
| 2023-01-30 11:48:52 +0100 | <razetime> | i already did a cabal build. it seems to be doing something different for cabal repl |
| 2023-01-30 11:49:01 +0100 | <razetime> | does cabal repl -j1 work? |
| 2023-01-30 11:49:24 +0100 | <razetime> | yeah it's in the help |
| 2023-01-30 11:49:35 +0100 | <Profpatsch> | razetime: you migth want to set up https://profpatsch.de/notes/preventing-oom :) |
| 2023-01-30 11:49:58 +0100 | <maerwald> | Profpatsch: fixed after years and pushing the maintainers to actually do it |
| 2023-01-30 11:50:02 +0100 | <tomsmeding> | nah if you already built, then that -j1 is doing the wrong thing I think |
| 2023-01-30 11:50:04 +0100 | <maerwald> | convincing them it's an actual problem |
| 2023-01-30 11:50:14 +0100 | <maerwald> | it's embarrassing |
| 2023-01-30 11:50:25 +0100 | <Profpatsch> | maerwald: well are they paid to do it? :) |
| 2023-01-30 11:50:33 +0100 | <maerwald> | Idc |
| 2023-01-30 11:50:41 +0100 | <Profpatsch> | e.g. random 1.2 only happened cause the people working on it were doing so fulltime |
| 2023-01-30 11:50:57 +0100 | <razetime> | Profpatsch: neat, i'll install it |
| 2023-01-30 11:51:00 +0100 | <Profpatsch> | It took some … mailing list drama to convince the maintainers to unblock |
| 2023-01-30 11:51:06 +0100 | <Profpatsch> | but then it went through just fine |
| 2023-01-30 11:51:10 +0100 | <maerwald> | Profpatsch: not sure I like the new random |
| 2023-01-30 11:51:21 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-01-30 11:51:25 +0100 | <Profpatsch> | maerwald: maybe the interface is not the best, but you gotta work with what you got |
| 2023-01-30 11:51:26 +0100 | <maerwald> | and I don't think resources were blocking the aeson fix |
| 2023-01-30 11:51:30 +0100 | <maerwald> | more like attitude |
| 2023-01-30 11:53:21 +0100 | <maerwald> | I have a lot of understanding for the "I'm an unpaid maintainer" lot... I'm one myself |
| 2023-01-30 11:53:38 +0100 | <maerwald> | but when it's about security, I have low tolerance |
| 2023-01-30 11:54:18 +0100 | <maerwald> | if you lack understanding, get out of the way... if you need resources to fix a security issue, speak up and inform the community |
| 2023-01-30 11:54:28 +0100 | <Profpatsch> | agreed |
| 2023-01-30 11:54:54 +0100 | <Profpatsch> | (I don’t mainain any critical infra in my spare time tho) |
| 2023-01-30 11:57:10 +0100 | <Profpatsch> | Different topic; |
| 2023-01-30 11:57:25 +0100 | <Profpatsch> | I have a [Foo] where each foo has a [Bar] |
| 2023-01-30 11:57:38 +0100 | <Profpatsch> | And I want to do some batched I/O for all of the Bars |
| 2023-01-30 11:57:56 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2023-01-30 11:57:56 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2023-01-30 11:57:56 +0100 | haritz | (~hrtz@user/haritz) |
| 2023-01-30 11:58:08 +0100 | <Profpatsch> | And the result should be a [Baz] where Baz is a Foo with the Bar replaced by the result of the batched IO |
| 2023-01-30 11:58:24 +0100 | <Profpatsch> | But how do I do that while keeping track of which Bar belonged to which Foo |
| 2023-01-30 11:58:53 +0100 | <akegalj> | Profpatsch: by no means I think haskell is bad, its my main tool for most problems. I was just wondering when I saw cve list why haskell isn't listed there. |
| 2023-01-30 11:58:56 +0100 | <Profpatsch> | I guess I could just go via list indexes but that fees a bit meh |
| 2023-01-30 11:59:19 +0100 | <tomsmeding> | Profpatsch: what structure can your "batched IO" procedure take |
| 2023-01-30 11:59:35 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2023-01-30 12:00:03 +0100 | <Profpatsch> | tomsmeding: Well it just takes a list of Bars |
| 2023-01-30 12:00:11 +0100 | <Profpatsch> | and returns a list of results |
| 2023-01-30 12:00:15 +0100 | <tomsmeding> | Profpatsch: are Foo and Baz related by types somehow? Like Foo ~ Cheese Bar, Baz ~ Cheese ProcessedBar |
| 2023-01-30 12:00:29 +0100 | xff0x | (~xff0x@ai081074.d.east.v6connect.net) |
| 2023-01-30 12:00:45 +0100 | <Profpatsch> | tomsmeding: I … could make it that way* |
| 2023-01-30 12:00:54 +0100 | <Profpatsch> | But I don’t want to overcomplicate this hrm |
| 2023-01-30 12:01:09 +0100 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2023-01-30 12:01:21 +0100 | <tomsmeding> | if so, then perhaps Cheese could be Traversable, and then your batched IO thing could take a Traversable instead of a list |
| 2023-01-30 12:01:23 +0100 | <Profpatsch> | You know what, I think I’m gonna do an overapproximation, this code has to go away soon anyway |
| 2023-01-30 12:01:33 +0100 | <tomsmeding> | you can make a list of traversables a traversable |
| 2023-01-30 12:01:59 +0100 | <tomsmeding> | then modulo wrapping, the processing becomes `traverse process` :) |
| 2023-01-30 12:02:21 +0100 | <tomsmeding> | uh, no, just `process`, sorry |
| 2023-01-30 12:02:21 +0100 | <Profpatsch> | tomsmeding: My I/O has to serialize into a list anyway, since I’m contacting a database |
| 2023-01-30 12:02:25 +0100 | <tomsmeding> | but that kind of thing |
| 2023-01-30 12:02:28 +0100 | <tomsmeding> | ah |
| 2023-01-30 12:02:30 +0100 | <Profpatsch> | so that just moves the problem into `process` :) |
| 2023-01-30 12:03:50 +0100 | <tomsmeding> | I mean one could make an `f :: Traversable f => f a -> ([a], [b] -> f b)` |
| 2023-01-30 12:04:08 +0100 | <tomsmeding> | no indices involved in f |
| 2023-01-30 12:04:17 +0100 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb2 - https://znc.in) |
| 2023-01-30 12:08:30 +0100 | haritz | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) |
| 2023-01-30 12:08:31 +0100 | haritz | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) (Changing host) |
| 2023-01-30 12:08:31 +0100 | haritz | (~hrtz@user/haritz) |
| 2023-01-30 12:08:32 +0100 | haritz | (~hrtz@user/haritz) (Remote host closed the connection) |
| 2023-01-30 12:10:11 +0100 | <jackdk> | Profpatsch: use a traversal to focus on all the `Bar`s across all the `Foo`s, use `partsOf` on it to turn it into a "lens" over lists? |
| 2023-01-30 12:11:22 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2023-01-30 12:11:22 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2023-01-30 12:11:22 +0100 | haritz | (~hrtz@user/haritz) |
| 2023-01-30 12:11:23 +0100 | haritz | (~hrtz@user/haritz) (Remote host closed the connection) |
| 2023-01-30 12:11:27 +0100 | tomsmeding | suspects that my 'f' is basically partsOf |
| 2023-01-30 12:11:32 +0100 | tomsmeding | doesn't know lenses |
| 2023-01-30 12:11:54 +0100 | <Profpatsch> | jackdk: does it recover the structure even after >>=ing the resulting list through some IO? |
| 2023-01-30 12:12:09 +0100 | <jackdk> | I'm noodling with a scratch buffer, standby |
| 2023-01-30 12:12:34 +0100 | <Profpatsch> | We don’t use lens here, but this is intruiging nonetheless |
| 2023-01-30 12:12:53 +0100 | <Profpatsch> | > Note: You should really try to maintain the invariant of the number of children in the list. |
| 2023-01-30 12:12:55 +0100 | <lambdabot> | <hint>:1:55: error: parse error on input ‘of’ |
| 2023-01-30 12:13:01 +0100 | <Profpatsch> | Ah, that would hint towards it |
| 2023-01-30 12:13:16 +0100 | <tomsmeding> | Profpatsch: https://paste.tomsmeding.com/2DKZ49Cx |
| 2023-01-30 12:13:37 +0100 | <tomsmeding> | oh ignore the tsilFromList, I don't use that |
| 2023-01-30 12:14:43 +0100 | <tomsmeding> | using execState first and evalState afterwards certainly feels lensy |
| 2023-01-30 12:16:44 +0100 | <Profpatsch> | Looks like partsOf really does the trick if your IO action retains the list length |
| 2023-01-30 12:17:09 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2023-01-30 12:17:10 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2023-01-30 12:17:10 +0100 | haritz | (~hrtz@user/haritz) |
| 2023-01-30 12:18:21 +0100 | haritz | (~hrtz@user/haritz) (Remote host closed the connection) |
| 2023-01-30 12:18:47 +0100 | CiaoSen | (~Jura@p200300c9573284002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2023-01-30 12:19:30 +0100 | <Profpatsch> | It seems to use https://twanvl.nl/blog/haskell/non-regular1 internally |
| 2023-01-30 12:19:37 +0100 | <Profpatsch> | (The “Bazaar” thing) |
| 2023-01-30 12:20:15 +0100 | <jackdk> | Profpatsch: Have to use unsafePartsOf because we are changing types: https://www.irccloud.com/pastebin/HgYfkiew/ReplaceTheBars.hs |
| 2023-01-30 12:20:49 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2023-01-30 12:21:55 +0100 | <Profpatsch> | jackdk: p cool |
| 2023-01-30 12:22:01 +0100 | <Axman6> | % :t partsOf template |
| 2023-01-30 12:22:01 +0100 | <yahb2> | <interactive>:1:1: error: Variable not in scope: partsOf :: t0 -> t ; ; <interactive>:1:9: error: Variable not in scope: template |
| 2023-01-30 12:22:18 +0100 | <Axman6> | % import Control.Lens |
| 2023-01-30 12:22:18 +0100 | <yahb2> | <no location info>: error: ; Could not find module ‘Control.Lens’ ; It is not a module in the current program, or in any known package. |
| 2023-01-30 12:22:20 +0100 | <tomsmeding> | sorry no lens :p |
| 2023-01-30 12:22:24 +0100 | <tomsmeding> | only boot packages currently |
| 2023-01-30 12:22:27 +0100 | <Axman6> | D: |
| 2023-01-30 12:22:37 +0100 | <tomsmeding> | :t partsOf template |
| 2023-01-30 12:22:39 +0100 | <lambdabot> | (Functor f, Data t, Typeable a) => LensLike f t t [a] [a] |
| 2023-01-30 12:22:45 +0100 | <tomsmeding> | lambdabot got yo' back |
| 2023-01-30 12:23:56 +0100 | <Axman6> | partsOf template is the magic incantation to find all the a's anywhere within a given t and let you mess with the |
| 2023-01-30 12:24:00 +0100 | <Axman6> | m |
| 2023-01-30 12:24:05 +0100 | <Axman6> | <3 tomsmeding |
| 2023-01-30 12:26:08 +0100 | Guest75 | (~Guest75@178.141.149.12) (Ping timeout: 260 seconds) |
| 2023-01-30 12:27:39 +0100 | teo | (~teo@user/teo) |
| 2023-01-30 12:27:49 +0100 | <Profpatsch> | lens would be awesome if it weren’t so impossible to use in any team |
| 2023-01-30 12:27:56 +0100 | <Profpatsch> | It’s a bit like call/cc |
| 2023-01-30 12:28:14 +0100 | <Profpatsch> | okay in small doses, but def not in a codebase that should be maintainable |
| 2023-01-30 12:28:29 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 12:28:42 +0100 | <jackdk> | I don't understand the BazaarT stuff but I would seriously consider working out what unsafePartsOf is doing and reinventing that; if `Foo` is `Traversable` then your "optic" to find all the `a`s is `traverse . traverse`, you have `(&)` from `Data.Function` in `base`, and `(%%~) = id` |
| 2023-01-30 12:29:25 +0100 | <Profpatsch> | jackdk: I think it boils down to what tomsmeding posted |
| 2023-01-30 12:29:29 +0100 | <Profpatsch> | Just a lot more generalized |
| 2023-01-30 12:30:52 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-01-30 12:30:57 +0100 | <jackdk> | Profpatsch: I think you're right; his `foo` function looks a lot like a deepified uniplate-esque thing |
| 2023-01-30 12:31:21 +0100 | <Profpatsch> | the simplified type of Bazaar is (a -> f b) -> f t |
| 2023-01-30 12:35:24 +0100 | <jackdk> | $WORK's solution to the lens thing is to a) not go too far beyond get/set and even fooOf functions unless you have a good reason, and b) get everyone to read Optics by Example |
| 2023-01-30 12:35:58 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2023-01-30 12:36:19 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 252 seconds) |
| 2023-01-30 12:40:59 +0100 | <tomsmeding> | Axman6: don't forget to |
| 2023-01-30 12:41:00 +0100 | <tomsmeding> | @botsnack |
| 2023-01-30 12:41:00 +0100 | <lambdabot> | :) |
| 2023-01-30 12:41:17 +0100 | <k> | @botsnack |
| 2023-01-30 12:41:18 +0100 | <lambdabot> | :) |
| 2023-01-30 12:47:02 +0100 | <tomsmeding> | Profpatsch: I was overcomplicating things https://paste.tomsmeding.com/bfWxC3Dd |
| 2023-01-30 12:49:55 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2023-01-30 12:49:56 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2023-01-30 12:49:56 +0100 | haritz | (~hrtz@user/haritz) |
| 2023-01-30 12:50:16 +0100 | gaff | (~gaff@49.207.230.13) |
| 2023-01-30 12:52:08 +0100 | <Profpatsch> | tomsmeding: Ah pretty cool, to unflatten the result you just pass the suffix of the list through the traversal |
| 2023-01-30 12:52:11 +0100 | <Profpatsch> | Makes sense yeah! |
| 2023-01-30 12:52:18 +0100 | <Profpatsch> | Super intuitive as well |
| 2023-01-30 12:53:36 +0100 | <tomsmeding> | I've written code like this on specific data types before but only now realised that it can be generalised to any Traversable :) |
| 2023-01-30 12:54:18 +0100 | <Profpatsch> | yeah super cool |
| 2023-01-30 12:54:41 +0100 | <gaff> | i am using vim with haskell language server. on completions from imports, i see a pop up that shows the type and a link to the haddock html documentation, but i am not able to navigate to the documentation link in vim. is there any way this can be done? |
| 2023-01-30 12:55:57 +0100 | <tomsmeding> | gaff: try typing 'gx' with the cursor on the url |
| 2023-01-30 12:56:07 +0100 | <tomsmeding> | (source: https://stackoverflow.com/questions/9458294/open-url-under-cursor-in-vim-with-browser ) |
| 2023-01-30 12:56:15 +0100 | <Profpatsch> | tomsmeding: jackdk now I also understand why you need unsafePartsOf, because partsOf will re-insert the original value if the result is not long enough |
| 2023-01-30 12:56:22 +0100 | <Profpatsch> | so the types of the output and input have to be the same |
| 2023-01-30 12:56:41 +0100 | <tomsmeding> | yeah I spotted that in the partsOf docs :) |
| 2023-01-30 12:56:50 +0100 | <gaff> | https://mmhaskell.com/blog/2022/9/29/using-haskell-in-vim-the-basics has a screenshot of the typical autocomplete screen i see |
| 2023-01-30 12:57:44 +0100 | <tomsmeding> | Profpatsch: so that 'unsafe' is precisely the 'error' in my code :) |
| 2023-01-30 12:57:48 +0100 | <Profpatsch> | exactly |
| 2023-01-30 12:57:59 +0100 | <gaff> | tomsmeding: the problem is that it is a pop up coming from coc-vim, and there is no way to navigate that pop up to reach the url |
| 2023-01-30 12:58:08 +0100 | <tomsmeding> | ah |
| 2023-01-30 12:58:20 +0100 | <tomsmeding> | (my nvim lsp client does have navigable popups) |
| 2023-01-30 12:58:48 +0100 | <gaff> | tomsmeding: you use neo vim? |
| 2023-01-30 12:59:04 +0100 | <tomsmeding> | sounds like something to bring up on the coc issue tracker as a feature request |
| 2023-01-30 12:59:07 +0100 | <tomsmeding> | yeah |
| 2023-01-30 12:59:12 +0100 | <gaff> | ok |
| 2023-01-30 12:59:19 +0100 | <gaff> | i am using vim |
| 2023-01-30 13:00:17 +0100 | <gaff> | well, i thought the haskell language server people who set this up may be knowing about it, because this pop up is something they created |
| 2023-01-30 13:00:24 +0100 | <tomsmeding> | no |
| 2023-01-30 13:00:30 +0100 | <tomsmeding> | the text in it is something they created |
| 2023-01-30 13:00:41 +0100 | <tomsmeding> | the popup itself is how coc decides to display those messages |
| 2023-01-30 13:00:53 +0100 | <gaff> | ok |
| 2023-01-30 13:01:29 +0100 | Buliarous | (~gypsydang@46.232.210.139) (Ping timeout: 260 seconds) |
| 2023-01-30 13:03:01 +0100 | Buliarous | (~gypsydang@46.232.210.139) |
| 2023-01-30 13:05:34 +0100 | gaff | (~gaff@49.207.230.13) (Ping timeout: 260 seconds) |
| 2023-01-30 13:08:50 +0100 | gaff | (~gaff@49.207.232.105) |
| 2023-01-30 13:09:36 +0100 | elkcl | (~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) (Remote host closed the connection) |
| 2023-01-30 13:09:37 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 13:10:01 +0100 | <gaff> | tomsmeding: sorry i got disconnected. question: in nvim, you are able to navigate to the link for the documentation and open it? |
| 2023-01-30 13:10:46 +0100 | oldfashionedcow | (~Rahul_San@user/oldfashionedcow) |
| 2023-01-30 13:13:27 +0100 | jumper149 | (~jumper149@base.felixspringer.xyz) |
| 2023-01-30 13:14:05 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 260 seconds) |
| 2023-01-30 13:15:24 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-01-30 13:31:46 +0100 | gaff | (~gaff@49.207.232.105) (Quit: Bye ...) |
| 2023-01-30 13:37:45 +0100 | <tomsmeding> | @tell gaff Yes but that's because my nvim lsp client allows changing focus to the popup and treating it as a read-only buffer |
| 2023-01-30 13:37:45 +0100 | <lambdabot> | Consider it noted. |
| 2023-01-30 13:38:56 +0100 | razetime | (~Thunderbi@117.193.5.58) (Remote host closed the connection) |
| 2023-01-30 13:43:07 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 13:44:08 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2023-01-30 13:46:45 +0100 | califax | (~califax@user/califx) |
| 2023-01-30 13:47:27 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 248 seconds) |
| 2023-01-30 13:50:04 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-01-30 13:53:12 +0100 | akegalj | (~akegalj@93-138-129-164.adsl.net.t-com.hr) (Quit: leaving) |
| 2023-01-30 14:03:56 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Read error: Connection reset by peer) |
| 2023-01-30 14:07:37 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-01-30 14:09:02 +0100 | CiaoSen | (~Jura@p200300c9573284002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2023-01-30 14:09:21 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2023-01-30 14:09:50 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2023-01-30 14:14:06 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-01-30 14:14:08 +0100 | troydm | (~troydm@user/troydm) (Ping timeout: 248 seconds) |
| 2023-01-30 14:14:57 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:8095:1260:6fef:5d26) (Ping timeout: 252 seconds) |
| 2023-01-30 14:15:43 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2023-01-30 14:16:07 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-01-30 14:17:12 +0100 | tremon | (~tremon@83-85-213-108.cable.dynamic.v4.ziggo.nl) |
| 2023-01-30 14:30:25 +0100 | Guest86 | (~Guest86@2001:16a2:4222:d000:2df4:2526:36aa:1e0d) |
| 2023-01-30 14:31:21 +0100 | Guest86 | (~Guest86@2001:16a2:4222:d000:2df4:2526:36aa:1e0d) (Client Quit) |
| 2023-01-30 14:37:05 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2023-01-30 14:40:59 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 252 seconds) |
| 2023-01-30 14:43:04 +0100 | jero98772 | (~jero98772@2800:484:1d80:d8ce:9815:cfda:3661:17bb) |
| 2023-01-30 14:45:20 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2023-01-30 14:59:28 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 248 seconds) |
| 2023-01-30 15:03:49 +0100 | akegalj | (~akegalj@222-217.dsl.iskon.hr) |
| 2023-01-30 15:06:44 +0100 | thegeekinside | (~thegeekin@189.180.66.244) |
| 2023-01-30 15:11:09 +0100 | thongpv | (~thongpv87@14.179.159.25) |
| 2023-01-30 15:11:45 +0100 | thongpv | (~thongpv87@14.179.159.25) (Remote host closed the connection) |
| 2023-01-30 15:12:28 +0100 | thongpv | (~thongpv87@14.179.159.25) |
| 2023-01-30 15:13:12 +0100 | thongpv | (~thongpv87@14.179.159.25) (Remote host closed the connection) |
| 2023-01-30 15:14:14 +0100 | thongpv | (~thongpv87@14.179.159.25) |
| 2023-01-30 15:14:33 +0100 | kurbus | (~kurbus@user/kurbus) |
| 2023-01-30 15:15:03 +0100 | thongpv | (~thongpv87@14.179.159.25) (Remote host closed the connection) |
| 2023-01-30 15:15:28 +0100 | thongpv | (~thongpv87@14.179.159.25) |
| 2023-01-30 15:16:26 +0100 | thongpv | (~thongpv87@14.179.159.25) (Remote host closed the connection) |
| 2023-01-30 15:18:24 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:6f34:bf9c:ac6f:4344) |
| 2023-01-30 15:21:08 +0100 | kurbus | (~kurbus@user/kurbus) (Ping timeout: 260 seconds) |
| 2023-01-30 15:25:37 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-01-30 15:26:45 +0100 | kurbus | (~kurbus@user/kurbus) |
| 2023-01-30 15:27:35 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-01-30 15:32:13 +0100 | thongpv | (~thongpv87@2402:9d80:3f4:1510:9f76:2d33:c304:1848) |
| 2023-01-30 15:32:14 +0100 | <yin> | tomsmeding: is there a keybinding to focus navigation on the popup? i think i do it by keeping `K` pressed but am not sure if that's intended behaviour |
| 2023-01-30 15:35:57 +0100 | cheesecake | (~cheesecak@2600:6c4a:7c7f:ec9b:9cb2:b42f:48ab:b49b) (Quit: Client closed) |
| 2023-01-30 15:39:12 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-01-30 15:48:47 +0100 | Angelz | (Angelz@user/angelz) (Ping timeout: 264 seconds) |
| 2023-01-30 15:51:33 +0100 | Hammdist | (~Hammdist@67.169.114.135) |
| 2023-01-30 15:51:38 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2023-01-30 15:52:19 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2023-01-30 15:52:48 +0100 | <Hammdist> | I'm trying to write a program that interfaces with GHC library. To get a Var name, I figure I have to case on Id in the https://hackage.haskell.org/package/ghc-9.4.4/docs/src/GHC.Types.Var.html#Var type. However I get Not in scope: data constructor ‘Id’. any ideas? |
| 2023-01-30 15:53:23 +0100 | <Hammdist> | I have tried import GHC.Types.Var but it didn't fix anything |
| 2023-01-30 15:54:50 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-01-30 15:55:20 +0100 | <lortabac> | Hammdist: IIRC the constructors are not exported but you can use 'varName' |
| 2023-01-30 15:55:34 +0100 | <lortabac> | https://hackage.haskell.org/package/ghc-9.4.4/docs/GHC-Types-Var.html#v:varName |
| 2023-01-30 15:57:15 +0100 | <Hammdist> | ah thanks -- will give that a go |
| 2023-01-30 15:59:02 +0100 | thongpv | (~thongpv87@2402:9d80:3f4:1510:9f76:2d33:c304:1848) (Ping timeout: 255 seconds) |
| 2023-01-30 15:59:55 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2023-01-30 16:01:20 +0100 | CiaoSen | (~Jura@p200300c9573284002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2023-01-30 16:01:58 +0100 | kurbus | (~kurbus@user/kurbus) (Ping timeout: 260 seconds) |
| 2023-01-30 16:02:06 +0100 | rekahsoft | (~rekahsoft@bras-base-orllon1122w-grc-05-174-88-194-86.dsl.bell.ca) |
| 2023-01-30 16:02:09 +0100 | rekahsoft | (~rekahsoft@bras-base-orllon1122w-grc-05-174-88-194-86.dsl.bell.ca) (Remote host closed the connection) |
| 2023-01-30 16:02:53 +0100 | rekahsoft | (~rekahsoft@bras-base-orllon1122w-grc-05-174-88-194-86.dsl.bell.ca) |
| 2023-01-30 16:04:37 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) |
| 2023-01-30 16:06:20 +0100 | <segfaultfizzbuzz> | is there a list of the "characteristics of code" somewhere? for example, code may have: memory safety, totality, bounds checking/correctness, -- i would like to continue or "complete" this list |
| 2023-01-30 16:10:44 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-01-30 16:11:42 +0100 | merijn | (~merijn@86.86.29.250) |
| 2023-01-30 16:13:10 +0100 | <Hammdist> | memory safety isn't a property of code, it's a property of the programming language |
| 2023-01-30 16:13:21 +0100 | kurbus | (~kurbus@user/kurbus) |
| 2023-01-30 16:13:28 +0100 | <Hammdist> | correctness is a property of the code |
| 2023-01-30 16:13:41 +0100 | <segfaultfizzbuzz> | or should we say it is a property of the binary which gets generated...? |
| 2023-01-30 16:14:28 +0100 | <Hammdist> | it would be hard to define memory safety for a binary. a correct binary could do a lot of dodgy things that are perfectly safe in its context |
| 2023-01-30 16:14:32 +0100 | <segfaultfizzbuzz> | presumably unless the programming language is "stiff" there will always be a way to say "this function can do unsafe things" |
| 2023-01-30 16:15:00 +0100 | CiaoSen | (~Jura@p200300c9573284002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2023-01-30 16:15:24 +0100 | <segfaultfizzbuzz> | so the real criteria here would be something like "program written in lang X without using unsafe" |
| 2023-01-30 16:16:11 +0100 | <segfaultfizzbuzz> | i think languages are/can be designed to enforce characteristics of code, so there will probably always be an overlap here |
| 2023-01-30 16:16:19 +0100 | merijn | (~merijn@86.86.29.250) (Ping timeout: 252 seconds) |
| 2023-01-30 16:16:45 +0100 | shriekingnoise | (~shrieking@186.137.175.87) |
| 2023-01-30 16:16:48 +0100 | Angelz | (Angelz@Angelz.oddprotocol.org) |
| 2023-01-30 16:16:55 +0100 | <segfaultfizzbuzz> | probably what happens is someone writes code in some language, people run into lots of bugs, and finally someone gets pissed off and promotes that bug type into some kind of formal invariant which can be enforced at the language level |
| 2023-01-30 16:17:53 +0100 | <segfaultfizzbuzz> | for example languages don't have "choice of unit (e.g. meters kilometers etc) declaration/safety" today, but it would be reasonable to require such a thing |
| 2023-01-30 16:24:08 +0100 | kurbus | (~kurbus@user/kurbus) (Ping timeout: 260 seconds) |
| 2023-01-30 16:30:11 +0100 | <kuribas> | Hammdist: "correctness" doesn't exist. |
| 2023-01-30 16:30:15 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-01-30 16:30:33 +0100 | <kuribas> | It's a meaningless word that people like throwing around. |
| 2023-01-30 16:30:39 +0100 | <segfaultfizzbuzz> | kuribas: right, but we can list desirable characteristics |
| 2023-01-30 16:31:03 +0100 | <segfaultfizzbuzz> | and perhaps we can say that if we choose good and sufficiently orthogonal characteristics then then program is likely to be better as it meets more of the characteristics |
| 2023-01-30 16:31:43 +0100 | <kuribas> | segfaultfizzbuzz: a much more meaningful term is "consistency". I'd like my program to be consistent. |
| 2023-01-30 16:32:06 +0100 | <segfaultfizzbuzz> | well these things, whatever they are called, are externally enforced i think? |
| 2023-01-30 16:32:24 +0100 | <kuribas> | you mean by tooling? |
| 2023-01-30 16:32:39 +0100 | <kuribas> | Tooling can verify these properties. |
| 2023-01-30 16:32:47 +0100 | <segfaultfizzbuzz> | language, tooling, abstract constructs, rules, and maybe heuristics of programming which are not enforced today |
| 2023-01-30 16:33:25 +0100 | <kuribas> | A program can be consistent in a dynamic language, but it is going to be hard to verify the claim. |
| 2023-01-30 16:33:41 +0100 | <segfaultfizzbuzz> | can you define consistency? |
| 2023-01-30 16:34:06 +0100 | <segfaultfizzbuzz> | the term doesn't look right to me because consistency is something which, in my mind, ought to be detectable (such as by the program itself) |
| 2023-01-30 16:34:29 +0100 | <segfaultfizzbuzz> | but i am interested in all characteristics, including characteristics which the program itself can't know to enforce |
| 2023-01-30 16:34:56 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 248 seconds) |
| 2023-01-30 16:35:22 +0100 | <akegalj> | I would like to test function `foo :: IO ()` which reads some input from stdin and outputs somthing to stdout. How to do this simply ? Is there some wrapper `run :: [Text] -> IO Text` that will echo some Text to foo and return stdout back. I see shelly package can be used to model such behaviour, but I wonder is there something simpler maybe in base to use to achieve this? |
| 2023-01-30 16:35:47 +0100 | <earthy> | segfaultfizzbuzz: you may want to look at F#, which does have units of measure, or Frinklang which is built around the concept of physically correct units. Furthermore, you may want to look into dependently typed programming languages such as Idris |
| 2023-01-30 16:35:52 +0100 | <geekosaur> | the program can't ensure self-consistency because it can't know the problem it's solving and therefore what counts as consistent within the bounds of that problem. this is one reason external tests exist |
| 2023-01-30 16:36:30 +0100 | <kuribas> | segfaultfizzbuzz: it means different parts of the program have the same notions of data or behaviour. |
| 2023-01-30 16:36:50 +0100 | <geekosaur> | this is also why typeclasses in Haskell don';t have built-in consistency checks; you need a stronger language such as Idris to express them |
| 2023-01-30 16:37:04 +0100 | <segfaultfizzbuzz> | earthy: these are relevant but don't directly address the question,... dependent typing i think is a method/capability for enforcing code invariants at compile time but does not itself describe what should be enforced |
| 2023-01-30 16:37:33 +0100 | <earthy> | and there's Eiffel as well, with its contracts. |
| 2023-01-30 16:37:35 +0100 | <segfaultfizzbuzz> | geekosaur: re: can't ensure self-consistency, right |
| 2023-01-30 16:37:47 +0100 | <geekosaur> | segfaultfizzbuzz, it can express invariants in the type system that a language like Haskell or especially Python can't |
| 2023-01-30 16:37:58 +0100 | <segfaultfizzbuzz> | yes i understand that |
| 2023-01-30 16:38:12 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2023-01-30 16:38:20 +0100 | <segfaultfizzbuzz> | but my question is what are (typically fairly universal) desirable invariants |
| 2023-01-30 16:38:30 +0100 | <earthy> | segfaultfizzbuzz: then I think you must be clearer as to what you try to state; I do not think I understand |
| 2023-01-30 16:38:32 +0100 | <kuribas> | segfaultfizzbuzz: I think he means encoding laws in the typeclass. |
| 2023-01-30 16:38:44 +0100 | <segfaultfizzbuzz> | i can repeat my question: |
| 2023-01-30 16:38:51 +0100 | <geekosaur> | again, many of them aren't universal, they;re defined by the problem the program is intended to solve |
| 2023-01-30 16:39:19 +0100 | <earthy> | not even garbage collection is universally beneficial |
| 2023-01-30 16:39:44 +0100 | <segfaultfizzbuzz> | well if you were driving a car which had its system software proven to be memory safe, you would be happier and more relaxed than if it was not, right? |
| 2023-01-30 16:40:00 +0100 | <earthy> | (for e.g. certain classes of hard real time systems you may want purely statically allocated memory) |
| 2023-01-30 16:40:10 +0100 | <segfaultfizzbuzz> | right |
| 2023-01-30 16:40:11 +0100 | <[exa]> | segfaultfizzbuzz: what a relief they now make the cars in javascript! :] |
| 2023-01-30 16:40:13 +0100 | <jean-paul[m]> | That's not universal, though. That's control software for a car. That's very, very specific. |
| 2023-01-30 16:40:27 +0100 | <segfaultfizzbuzz> | [exa]: seriously lol but that's just the ui frontend junk i am pretty sure |
| 2023-01-30 16:40:31 +0100 | <earthy> | hell, one of my cars runs windows :D |
| 2023-01-30 16:41:03 +0100 | <segfaultfizzbuzz> | jean-paul[m]: ok so are you saying that the desired characteristics of code are always highly context dependent? |
| 2023-01-30 16:41:06 +0100 | <earthy> | and yeah, just in the 'media/telephone' junk :) |
| 2023-01-30 16:41:06 +0100 | <[exa]> | segfaultfizzbuzz: I'd say frontend includes the steering wheel. |
| 2023-01-30 16:41:39 +0100 | <jean-paul[m]> | segfaultfizzbuzz: I don't think you can separate "desire" from a context, right. |
| 2023-01-30 16:41:43 +0100 | <segfaultfizzbuzz> | maybe my car example is too strong of a context |
| 2023-01-30 16:41:53 +0100 | <earthy> | I think it may be worthwhile to think about what kinds of guarantees you'd like from your code and get most of them with little work |
| 2023-01-30 16:42:10 +0100 | <earthy> | static typing is one way of getting guarantees |
| 2023-01-30 16:42:17 +0100 | <earthy> | garbage collection another |
| 2023-01-30 16:42:45 +0100 | <segfaultfizzbuzz> | right but *purpose* of garbage collection is to provide memory safety (or, memory safety while limiting programmer effort/likelihood of doing it wrong) |
| 2023-01-30 16:42:57 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 16:43:12 +0100 | kurbus | (~kurbus@user/kurbus) |
| 2023-01-30 16:43:39 +0100 | <segfaultfizzbuzz> | and so my interest is the *purpose*, the *desirable characteristic* (eg memory safety) rather than the *method to accomplish the characteristic* (garbage collection, dynamic types etc) |
| 2023-01-30 16:44:04 +0100 | <segfaultfizzbuzz> | and the question would be what is a reasonably good list of these desirable charcteristics |
| 2023-01-30 16:45:14 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2023-01-30 16:45:14 +0100 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2023-01-30 16:45:18 +0100 | allbery_b | geekosaur |
| 2023-01-30 16:46:07 +0100 | <stefan-_> | purity of (a part of) the program is a nice property |
| 2023-01-30 16:46:24 +0100 | <kuribas> | segfaultfizzbuzz: I find referential transparency one of the most important properties. |
| 2023-01-30 16:46:42 +0100 | <kuribas> | Because it means you can understand a part of the program without the need to understand the whole. |
| 2023-01-30 16:47:03 +0100 | <kuribas> | which is something that clojure is missing, despite trying hard to be functional. |
| 2023-01-30 16:47:07 +0100 | <segfaultfizzbuzz> | ha |
| 2023-01-30 16:47:46 +0100 | <kuribas> | Not being referential transparent means you need to understand a lot to make a small change. Also you need to understand the consequences of that change. |
| 2023-01-30 16:47:59 +0100 | <segfaultfizzbuzz> | another example i only partially understand might be "algebraicity"--for example, using floating point can destroy associativity |
| 2023-01-30 16:48:50 +0100 | <earthy> | segfaultfizzbuzz: you're getting way into what cross-functional requirements do I want to achieve - territory |
| 2023-01-30 16:49:14 +0100 | <segfaultfizzbuzz> | earthy: i would say don't think about actually writing code, think about this stuff like a wish list |
| 2023-01-30 16:49:31 +0100 | <jean-paul[m]> | Referential transparency and algebraicity support the same thing - breaking a problem down so you can solve it in tiny pieces. So, "composability". |
| 2023-01-30 16:49:56 +0100 | <segfaultfizzbuzz> | sure |
| 2023-01-30 16:49:59 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 268 seconds) |
| 2023-01-30 16:54:24 +0100 | kurbus | (~kurbus@user/kurbus) (Quit: Client closed) |
| 2023-01-30 16:55:16 +0100 | <stefan-_> | another useful property is immutability of data structures |
| 2023-01-30 16:55:35 +0100 | <segfaultfizzbuzz> | sure, (which might be part of referential transparency...) |
| 2023-01-30 16:56:10 +0100 | <earthy> | then again, mutability is very powerful for performance... |
| 2023-01-30 16:56:48 +0100 | <kuribas> | earthy: err, I contest that, unless you are in a tight inner loop. |
| 2023-01-30 16:57:01 +0100 | <earthy> | that's the problem really, these things are almost always 'it depends' |
| 2023-01-30 16:57:35 +0100 | <earthy> | kuribas: oh, I prefer my data to be immutable in general, and there's performance gains to be had that way as well |
| 2023-01-30 16:58:03 +0100 | <segfaultfizzbuzz> | performance characteristics are valid characteristics of a program but i am trying to keep them independent as a consideration |
| 2023-01-30 16:58:19 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2023-01-30 16:58:44 +0100 | <segfaultfizzbuzz> | earthy: probably what you mean to say is that "i am willing to sacrifice correctness for speed" which is probably true more often than we would like to admit |
| 2023-01-30 16:58:49 +0100 | <kuribas> | earthy: after a long list of considerations, it may have an impact. But often it's the first thing people mention when talking about FP. |
| 2023-01-30 16:59:52 +0100 | raehik | (~raehik@82.21.176.157) |
| 2023-01-30 16:59:53 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2023-01-30 17:00:07 +0100 | jinsun_ | (~jinsun@user/jinsun) (Quit: You have been kicked for being idle) |
| 2023-01-30 17:00:38 +0100 | <segfaultfizzbuzz> | one thing i'm not sure about is whether "linearity" is a desirable characteristic in many situations,... i kind of think it is |
| 2023-01-30 17:00:41 +0100 | jinsun_ | (~jinsun@user/jinsun) |
| 2023-01-30 17:00:49 +0100 | <segfaultfizzbuzz> | because linearity helps guarantee the absence of resource leaks |
| 2023-01-30 17:02:03 +0100 | califax | (~califax@user/califx) |
| 2023-01-30 17:02:10 +0100 | merijn | (~merijn@86.86.29.250) |
| 2023-01-30 17:02:21 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) |
| 2023-01-30 17:02:35 +0100 | <earthy> | but the purpose is 'no resource leaks' then, isn't it? |
| 2023-01-30 17:03:12 +0100 | <segfaultfizzbuzz> | earthy: sure, |
| 2023-01-30 17:03:29 +0100 | <segfaultfizzbuzz> | i am mentioning the method of achieving the characteristic in passing |
| 2023-01-30 17:03:51 +0100 | <earthy> | which Erlang provides with process trees and let-it-crash |
| 2023-01-30 17:04:33 +0100 | <segfaultfizzbuzz> | earthy: does it though? i'm assuming crashing comes from some kind of process memory size limit, but you could probably open a zillion files or ports in that limit |
| 2023-01-30 17:04:44 +0100 | nerdypepper | (~nerdypepp@user/nerdypepper) |
| 2023-01-30 17:05:13 +0100 | <earthy> | which then get cleaned up by the process reaper |
| 2023-01-30 17:05:15 +0100 | jinsun_ | (~jinsun@user/jinsun) () |
| 2023-01-30 17:05:31 +0100 | <segfaultfizzbuzz> | ok i am not terribly familiar with erlang |
| 2023-01-30 17:06:38 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) (Ping timeout: 246 seconds) |
| 2023-01-30 17:10:07 +0100 | kenran` | (~user@user/kenran) (Remote host closed the connection) |
| 2023-01-30 17:14:29 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 17:14:38 +0100 | <segfaultfizzbuzz> | how does the process reaper know it can kill stuff? |
| 2023-01-30 17:14:59 +0100 | oldfashionedcow | (~Rahul_San@user/oldfashionedcow) (Quit: WeeChat 3.8) |
| 2023-01-30 17:15:00 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:6f34:bf9c:ac6f:4344) (Quit: WeeChat 2.8) |
| 2023-01-30 17:16:30 +0100 | oldfashionedcow | (~Rahul_San@user/oldfashionedcow) |
| 2023-01-30 17:17:15 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2023-01-30 17:18:05 +0100 | dsrt^ | (~dsrt@c-24-30-76-89.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2023-01-30 17:18:40 +0100 | <earthy> | it doesn't. it just kills stuff. :D |
| 2023-01-30 17:18:46 +0100 | <segfaultfizzbuzz> | hahaha |
| 2023-01-30 17:19:10 +0100 | <waleee> | looks like the scheduler does some checks with various signal messages, https://www.erlang.org/doc/reference_manual/processes.html#receiving-signals |
| 2023-01-30 17:19:31 +0100 | <earthy> | but honestly the entire concept of supervision trees and programming the resource behaviour separately from the worker processes is neat and not directly linearized |
| 2023-01-30 17:22:35 +0100 | <segfaultfizzbuzz> | needing to be able to exit the process under supervision at any time makes me nervous |
| 2023-01-30 17:27:23 +0100 | FragByte | (~christian@user/fragbyte) (Quit: Quit) |
| 2023-01-30 17:27:33 +0100 | FragByte | (~christian@user/fragbyte) |
| 2023-01-30 17:34:54 +0100 | <Hammdist> | how do I convert a ByteString to a String? |
| 2023-01-30 17:35:12 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2023-01-30 17:36:37 +0100 | merijn | (~merijn@86.86.29.250) (Ping timeout: 252 seconds) |
| 2023-01-30 17:38:27 +0100 | raehik | (~raehik@82.21.176.157) (Ping timeout: 252 seconds) |
| 2023-01-30 17:38:50 +0100 | <geekosaur> | Data.ByteString.Char8.unpack? |
| 2023-01-30 17:39:14 +0100 | <geekosaur> | (going that direction is safe; the other direction truncates) |
| 2023-01-30 17:39:29 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2023-01-30 17:39:44 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Quit: beteigeuze) |
| 2023-01-30 17:40:12 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2023-01-30 17:42:10 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Client Quit) |
| 2023-01-30 17:42:33 +0100 | troydm | (~troydm@user/troydm) |
| 2023-01-30 17:42:37 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2023-01-30 17:43:12 +0100 | <Hammdist> | in this definition of a case expression: | Case (Expr b) b Type [Alt b] <-- what is the second b for? |
| 2023-01-30 17:44:20 +0100 | kurbus | (~kurbus@user/kurbus) |
| 2023-01-30 17:44:46 +0100 | <[exa]> | Hammdist: where is that from? AST parameters typically mean either extra info (such as location) or binders type (such as variable IDs) |
| 2023-01-30 17:45:06 +0100 | <Hammdist> | it's from https://hackage.haskell.org/package/ghc-9.4.4/docs/src/GHC.Core.html#Expr |
| 2023-01-30 17:45:56 +0100 | <Hammdist> | I don't see any AST information on the other cases |
| 2023-01-30 17:46:18 +0100 | <[exa]> | you can see e.g. that Lam has the `b` (that's the variable that's being bound) |
| 2023-01-30 17:46:40 +0100 | <Hammdist> | sure but all the bindings in a case are in the alternatives |
| 2023-01-30 17:46:51 +0100 | <geekosaur> | not true of case in core |
| 2023-01-30 17:47:05 +0100 | <geekosaur> | core also binds the result of evaluating the expression |
| 2023-01-30 17:47:17 +0100 | <[exa]> | it says up there: The binder gets bound to the value of the scrutinee, and the Expr must be that of all the case alternatives |
| 2023-01-30 17:47:28 +0100 | <[exa]> | `b` is that binder. |
| 2023-01-30 17:47:50 +0100 | <[exa]> | I'm not sure if this has a direct representation in "normal" haskell |
| 2023-01-30 17:48:01 +0100 | <geekosaur> | it doesn't |
| 2023-01-30 17:48:44 +0100 | <Hammdist> | so I must translate it as implying a let binding then |
| 2023-01-30 17:49:01 +0100 | <Hammdist> | let x = expr in case x of ... |
| 2023-01-30 17:49:11 +0100 | <Hammdist> | as x may appear in ...? |
| 2023-01-30 17:49:41 +0100 | <geekosaur> | let !x = expr in … |
| 2023-01-30 17:49:47 +0100 | <geekosaur> | case is strict, let is lazy |
| 2023-01-30 17:50:28 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-01-30 17:50:55 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) (Ping timeout: 260 seconds) |
| 2023-01-30 17:51:03 +0100 | kurbus | (~kurbus@user/kurbus) (Ping timeout: 260 seconds) |
| 2023-01-30 17:51:56 +0100 | glguy_ | glguy |
| 2023-01-30 17:55:29 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2023-01-30 17:59:43 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 252 seconds) |
| 2023-01-30 17:59:56 +0100 | econo | (uid147250@user/econo) |
| 2023-01-30 18:07:31 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2023-01-30 18:10:25 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 260 seconds) |
| 2023-01-30 18:13:49 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2023-01-30 18:18:04 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) |
| 2023-01-30 18:22:09 +0100 | teo | (~teo@user/teo) (Ping timeout: 256 seconds) |
| 2023-01-30 18:23:19 +0100 | werneta | (~werneta@137.79.207.195) |
| 2023-01-30 18:23:43 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) (Ping timeout: 268 seconds) |
| 2023-01-30 18:26:45 +0100 | ddellacosta | (~ddellacos@143.244.47.83) (Ping timeout: 260 seconds) |
| 2023-01-30 18:27:30 +0100 | kurbus | (~kurbus@user/kurbus) |
| 2023-01-30 18:30:11 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-01-30 18:31:03 +0100 | CiaoSen | (~Jura@p200300c9573284002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2023-01-30 18:31:24 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2023-01-30 18:53:02 +0100 | nschoe | (~q@141.101.51.197) (Quit: Switching off) |
| 2023-01-30 18:53:05 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2023-01-30 18:54:23 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) |
| 2023-01-30 18:55:35 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2023-01-30 18:55:55 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2023-01-30 18:57:57 +0100 | zeenk | (~zeenk@2a02:2f04:a014:8700::7fe) (Quit: Konversation terminated!) |
| 2023-01-30 18:58:45 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) (Ping timeout: 252 seconds) |
| 2023-01-30 19:05:59 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-01-30 19:08:09 +0100 | talismanick | (~talismani@2601:200:c181:4c40::1be2) |
| 2023-01-30 19:08:22 +0100 | talismanick | (~talismani@2601:200:c181:4c40::1be2) (Client Quit) |
| 2023-01-30 19:18:40 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-01-30 19:21:58 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-01-30 19:36:03 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2023-01-30 19:36:39 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2023-01-30 19:39:00 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) |
| 2023-01-30 19:39:33 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 255 seconds) |
| 2023-01-30 19:40:35 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) |
| 2023-01-30 19:42:42 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-01-30 19:43:36 +0100 | trev | (~trev@user/trev) (Remote host closed the connection) |
| 2023-01-30 19:49:34 +0100 | opticblast | (~Thunderbi@172.58.84.5) |
| 2023-01-30 19:51:58 +0100 | slack1256 | (~slack1256@181.42.52.81) |
| 2023-01-30 19:53:38 +0100 | turlando | (~turlando@user/turlando) |
| 2023-01-30 19:57:02 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) (Ping timeout: 246 seconds) |
| 2023-01-30 20:00:21 +0100 | opticblast | (~Thunderbi@172.58.84.5) (Ping timeout: 252 seconds) |
| 2023-01-30 20:00:43 +0100 | freeside | (~mengwong@103.252.202.170) (Ping timeout: 252 seconds) |
| 2023-01-30 20:01:37 +0100 | bilegeek | (~bilegeek@2600:1008:b0a9:5822:3cbe:e760:543a:34cb) |
| 2023-01-30 20:07:44 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-01-30 20:11:12 +0100 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb2 - https://znc.in) |
| 2023-01-30 20:13:10 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2023-01-30 20:14:01 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2023-01-30 20:14:01 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2023-01-30 20:14:01 +0100 | haritz | (~hrtz@user/haritz) |
| 2023-01-30 20:16:37 +0100 | ddellacosta | (~ddellacos@static-198-44-136-174.cust.tzulo.com) |
| 2023-01-30 20:17:20 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 248 seconds) |
| 2023-01-30 20:19:19 +0100 | mechap | (~mechap@user/mechap) |
| 2023-01-30 20:20:32 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 248 seconds) |
| 2023-01-30 20:22:34 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2023-01-30 20:25:50 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) (Remote host closed the connection) |
| 2023-01-30 20:27:07 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 252 seconds) |
| 2023-01-30 20:28:12 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) |
| 2023-01-30 20:28:35 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2023-01-30 20:32:59 +0100 | ddellacosta | (~ddellacos@static-198-44-136-174.cust.tzulo.com) (Ping timeout: 252 seconds) |
| 2023-01-30 20:33:59 +0100 | freeside | (~mengwong@103.252.202.170) |
| 2023-01-30 20:35:28 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) (Ping timeout: 248 seconds) |
| 2023-01-30 20:41:20 +0100 | kenran | (~user@user/kenran) |
| 2023-01-30 20:42:29 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2023-01-30 20:43:56 +0100 | oldfashionedcow | (~Rahul_San@user/oldfashionedcow) (Quit: WeeChat 3.8) |
| 2023-01-30 20:44:26 +0100 | oldfashionedcow | (~Rahul_San@user/oldfashionedcow) |
| 2023-01-30 20:45:24 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-01-30 20:46:33 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) |
| 2023-01-30 20:48:26 +0100 | <tomsmeding> | yin: indeed if you press K twice you end up in the popup; whether that's intended behaviour no clue, but it works :) |
| 2023-01-30 20:49:55 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2023-01-30 20:50:40 +0100 | cheater_ | (~Username@user/cheater) |
| 2023-01-30 20:50:57 +0100 | ft | (~ft@p4fc2a257.dip0.t-ipconnect.de) |
| 2023-01-30 20:51:50 +0100 | PepsiLepreux | (~pepsi@iron.vengarl.com) |
| 2023-01-30 20:52:32 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
| 2023-01-30 20:52:35 +0100 | cheater_ | cheater |
| 2023-01-30 20:56:39 +0100 | <yin> | where can i learn about the differences between Haskell2010 and GHC2021 ? |
| 2023-01-30 20:56:52 +0100 | MasseR46 | (~MasseR@2001:bc8:47a0:1521::1) |
| 2023-01-30 20:57:35 +0100 | <yin> | tomsmeding: yeah, it kind of feels buggy but i do it on purpose often |
| 2023-01-30 20:57:52 +0100 | haasn` | (~nand@haasn.dev) |
| 2023-01-30 20:59:17 +0100 | <yushyin> | yin: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html#controlling-extensions |
| 2023-01-30 21:01:27 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-01-30 21:03:06 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-01-30 21:03:26 +0100 | kurbus | test123 |
| 2023-01-30 21:03:30 +0100 | test123 | kurbus |
| 2023-01-30 21:04:28 +0100 | <yin> | ty |
| 2023-01-30 21:04:37 +0100 | <mauke> | what is DoAndIfThenElse? |
| 2023-01-30 21:06:01 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2023-01-30 21:07:00 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2023-01-30 21:09:21 +0100 | <mniip> | mauke, whether a ";" is allowed before an "else" in an if-then-else |
| 2023-01-30 21:09:36 +0100 | Lears | (~Leary]@user/Leary/x-0910699) (Remote host closed the connection) |
| 2023-01-30 21:09:49 +0100 | <mniip> | so that inside a do-block, the if and the else could have the same indentation level (thus inserting a semicolon inbetween) |
| 2023-01-30 21:09:57 +0100 | [Leary] | (~Leary]@user/Leary/x-0910699) |
| 2023-01-30 21:12:13 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) |
| 2023-01-30 21:12:13 +0100 | oldfashionedcow | (~Rahul_San@user/oldfashionedcow) (Quit: WeeChat 3.8) |
| 2023-01-30 21:12:36 +0100 | oldfashionedcow | (~Rahul_San@user/oldfashionedcow) |
| 2023-01-30 21:13:17 +0100 | <segfaultfizzbuzz> | why does the SQL "type system" diverge from the haskell "type system" (or that of other good languages, maybe rust)? |
| 2023-01-30 21:13:58 +0100 | <segfaultfizzbuzz> | for instance i don't think (?) SQL has algebraic data types, and SQL allows you to make types nullable |
| 2023-01-30 21:14:43 +0100 | <geekosaur> | because SQL started out as IBM's SEQUEL II, and was designed for the type systems of COBOL and PL/I |
| 2023-01-30 21:14:54 +0100 | <geekosaur> | in particular this is why numeric types work the way they do |
| 2023-01-30 21:15:11 +0100 | <segfaultfizzbuzz> | wow that's a real answer |
| 2023-01-30 21:15:42 +0100 | <segfaultfizzbuzz> | lol so an ORM is really a cobol compatibility layer? lol |
| 2023-01-30 21:16:16 +0100 | <segfaultfizzbuzz> | so why not drop concrete on sql and greenfield stuff? |
| 2023-01-30 21:16:20 +0100 | <darkling> | IIRC, the NULL also has a purpose in relational algebra (of which SQL is a poor and mangled implementation). |
| 2023-01-30 21:17:09 +0100 | <dsal> | SEQUEL II - The Sequel Sequel. |
| 2023-01-30 21:17:16 +0100 | <segfaultfizzbuzz> | sequel ii - the second one |
| 2023-01-30 21:17:40 +0100 | <kurbus> | sequel ii is also called just 3 |
| 2023-01-30 21:18:01 +0100 | <dsal> | We use persistent which is kind of neat, but also kind of annoying. |
| 2023-01-30 21:18:05 +0100 | <darkling> | ORMs aren't about the COBOL -- they're about trying to map the general structures to each other. You'd have the same problems trying to map anything similarly based on relational algebra into anything using objects. |
| 2023-01-30 21:18:15 +0100 | <monochrom> | In fact since SQL predates Haskell and Rust, I would say that Haskell and Rust diverged from SQL's type system. >:) |
| 2023-01-30 21:18:35 +0100 | <darkling> | OO ideas probably map much more cleanly onto CODASYL-like things... |
| 2023-01-30 21:19:04 +0100 | <geekosaur> | some of us still wish C. J. Date's QUEL had won out over SEQUEL |
| 2023-01-30 21:19:22 +0100 | <geekosaur> | (see original Ingres) |
| 2023-01-30 21:19:34 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-01-30 21:19:35 +0100 | <monochrom> | But clearly generally younger languages have better chances to improve and refine ideas than old languages. |
| 2023-01-30 21:19:40 +0100 | <segfaultfizzbuzz> | i mean, who cares right? |
| 2023-01-30 21:19:54 +0100 | <segfaultfizzbuzz> | start from the best ideas rather than holding up old creaky ones |
| 2023-01-30 21:20:07 +0100 | <EvanR> | You can't teach an old language new tricks. Unless it's C++, which is I guess forever young? |
| 2023-01-30 21:20:07 +0100 | <dsal> | esqueleto at least gives us the ability to reuse fragments of queries. |
| 2023-01-30 21:20:10 +0100 | <darkling> | I really need to get some practice time in with Datalog... |
| 2023-01-30 21:20:15 +0100 | <geekosaur> | not only does it have more rational types, it's a clean implementation of relational calculus instead of an iffy implementation of relational algebra |
| 2023-01-30 21:23:03 +0100 | <monochrom> | Hell, even the idea of polymorphism was very loose and broad and muddled in the 1960s until Strachey proposed that there is a difference between ad hoc and parametric, and even then he gave only a wordy (read: can be bent misinterpreted) definition, we had to wait until Reynolds to figure out a mathematical definition. |
| 2023-01-30 21:23:10 +0100 | <segfaultfizzbuzz> | the most essential concept here i guess is persistence right? |
| 2023-01-30 21:24:13 +0100 | <monochrom> | To be fair, if Strachey didn't die early, probably he could figure out the same mathematical definition eventually. |
| 2023-01-30 21:25:21 +0100 | mechap | (~mechap@user/mechap) (Quit: WeeChat 3.8) |
| 2023-01-30 21:26:43 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2023-01-30 21:27:02 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2023-01-30 21:31:00 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:885e:183b:67ff:4e55) |
| 2023-01-30 21:31:00 +0100 | <dminuoso> | akegalj: I think maerwald's mention of lack of screeing is probably a more important one. While the general memory safety certainly rules out 2/3 of bugs, the general lack of research and publications specifically on other errors is slightly worrying. One particular example is cryptonite, a pure-haskell written family of cryptographic functions, which to my knowledge has not been audited or |
| 2023-01-30 21:31:02 +0100 | <dminuoso> | analyzed for side-channels. |
| 2023-01-30 21:32:09 +0100 | <dminuoso> | I haven't seen research into whether or why Haskell would be more secure. |
| 2023-01-30 21:33:03 +0100 | <dminuoso> | It may even be, that an attitude in which you blindly assume lack of bugs due to memory safety and type safety could introduce additional vectors. |
| 2023-01-30 21:33:31 +0100 | <dminuoso> | A prime example might be `postgresql-simple`, which uses some non-audited adhoc self-written query parameter interpolation rather than relying on the builtin libpq features. |
| 2023-01-30 21:33:54 +0100 | <dminuoso> | Who knows, maybe that library is ripe for SQL injections, in which case a lot of packages have some dangerous attack vectors. |
| 2023-01-30 21:34:58 +0100 | <geekosaur> | iirc there has been research demonstrating that declarative FP languages are vulnerable to side channel attacks in general |
| 2023-01-30 21:35:00 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-01-30 21:35:42 +0100 | <geekosaur> | and it's hard to prevent them because you can't e.g. do nonsense work to ensure a failing case takes the same time as a success case |
| 2023-01-30 21:36:43 +0100 | <monochrom> | Hrm, why is it not code optimization that foils nonsense work, and therefore all performant compilers are vulnerable? |
| 2023-01-30 21:36:51 +0100 | <segfaultfizzbuzz> | geekosaur: i believe it |
| 2023-01-30 21:37:09 +0100 | <dminuoso> | monochrom: In facft it is. |
| 2023-01-30 21:37:17 +0100 | <segfaultfizzbuzz> | security is mostly social acceptability and theatre lol |
| 2023-01-30 21:37:24 +0100 | <geekosaur> | monochrom, in C there are ways to defeat optimization in those cases, or just disable optimization |
| 2023-01-30 21:37:31 +0100 | <dminuoso> | monochrom: Which is why well designed cryptographic libraries in part disable or control optimizations that interfere with certain assumptions in cryptographic algorithms. |
| 2023-01-30 21:37:38 +0100 | <geekosaur> | and yes, this does come up in other languages |
| 2023-01-30 21:37:45 +0100 | <dminuoso> | Some libraries use inline assembly in critical sections to properly control the code |
| 2023-01-30 21:38:28 +0100 | kurbus | (~kurbus@user/kurbus) (Quit: Client closed) |
| 2023-01-30 21:39:43 +0100 | <dminuoso> | for instance intel processors have AES specific instructions that are supposed to have constant-time/constant-power behavior. interestingly, there's some recent data that suggest that intel and arm processors might have a lot more timing dependence on values than users are led to believe |
| 2023-01-30 21:39:45 +0100 | <dminuoso> | https://www.openwall.com/lists/oss-security/2023/01/25/3 |
| 2023-01-30 21:39:56 +0100 | <monochrom> | Along another orthogonal axis, automatic GC introduces a lot of side information. But then this one is not particular to FP either, basically everyone except possibly C and Fortran has it. |
| 2023-01-30 21:39:57 +0100 | <dminuoso> | but GCC would never willingly generate them because they have poor performance |
| 2023-01-30 21:40:20 +0100 | avicenzi | (~avicenzi@2a00:ca8:a1f:b004::c32) (Ping timeout: 246 seconds) |
| 2023-01-30 21:41:40 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2023-01-30 21:41:49 +0100 | <geekosaur> | monochrom, indeed quite a lot of security critical software is written in C or a subset of C++ because of that |
| 2023-01-30 21:42:04 +0100 | <dminuoso> | There's a bunch of languages that let you express cryptographic algorithms for which you can extract some kind of program that will use "provably" correct assembly that has the lack of certain side-effect vectors |
| 2023-01-30 21:43:57 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-01-30 21:44:22 +0100 | <segfaultfizzbuzz> | heh |
| 2023-01-30 21:44:28 +0100 | cods | (~fred@82-65-232-44.subs.proxad.net) (Ping timeout: 265 seconds) |
| 2023-01-30 21:44:40 +0100 | cods | (~fred@82-65-232-44.subs.proxad.net) |
| 2023-01-30 21:44:48 +0100 | <dminuoso> | (under the assumption that the hardware will honor its promites...) |
| 2023-01-30 21:44:51 +0100 | califax | (~califax@user/califx) |
| 2023-01-30 21:45:07 +0100 | <dminuoso> | which intel doesnt have a great track record for. :p |
| 2023-01-30 21:46:35 +0100 | pavonia | (~user@user/siracusa) |
| 2023-01-30 21:47:47 +0100 | danza | (~francesco@151.53.27.222) (Ping timeout: 255 seconds) |
| 2023-01-30 21:50:36 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt: personae.ai-integration.biz) |
| 2023-01-30 21:50:57 +0100 | <dminuoso> | I think HACL* is one of the prominent examples of this |
| 2023-01-30 21:51:17 +0100 | <dminuoso> | Which made its way into Firefox even |
| 2023-01-30 21:51:45 +0100 | <segfaultfizzbuzz> | wao ... yeah timing safety is important but very expensive to ensure,... |
| 2023-01-30 21:53:53 +0100 | <segfaultfizzbuzz> | someone mentioned declarative--where can i find a good discussion of declarative programming |
| 2023-01-30 21:54:20 +0100 | <monochrom> | I have a cunning plan! We should demand random-time instead... >:) |
| 2023-01-30 21:55:01 +0100 | <segfaultfizzbuzz> | monochrom: injecting timing noise is probably a cheap and effective way to get around timing side channel problems |
| 2023-01-30 21:55:04 +0100 | <monochrom> | Very old textbooks that have titles along the line of "principles of programming languages". |
| 2023-01-30 21:55:21 +0100 | <monochrom> | i.e., those who still believe in "paradigms". |
| 2023-01-30 21:55:29 +0100 | <segfaultfizzbuzz> | haha as opposed to? |
| 2023-01-30 21:55:35 +0100 | <segfaultfizzbuzz> | chatgpt? lol |
| 2023-01-30 21:55:56 +0100 | oldfashionedcow | (~Rahul_San@user/oldfashionedcow) (Quit: WeeChat 3.8) |
| 2023-01-30 21:56:18 +0100 | <segfaultfizzbuzz> | i've been thinking lately though that this whole practice of trying to construct invariants is statistically invalid in most circumstances... like if you construct rules for business logic, they will eventually break, even if they are very good and last for a good while |
| 2023-01-30 21:56:23 +0100 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2023-01-30 21:57:09 +0100 | cheater_ | (~Username@user/cheater) |
| 2023-01-30 21:57:44 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:885e:183b:67ff:4e55) (Quit: WeeChat 2.8) |
| 2023-01-30 21:58:04 +0100 | <monochrom> | As opposed to for example what Shriram Krishnamurthi from Brown University proposes about "paradigms mean nothing" and you dissect a language's features and semantics instead. |
| 2023-01-30 21:58:25 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) (Remote host closed the connection) |
| 2023-01-30 21:58:29 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 252 seconds) |
| 2023-01-30 21:58:36 +0100 | cheater_ | cheater |
| 2023-01-30 21:58:55 +0100 | <monochrom> | which I just illustrated earlier. Instead of discussing side channels in "FP", I discuss side channels under super-smart code optimizations, under GC, etc. |
| 2023-01-30 21:59:28 +0100 | <mauke> | random noise just means you need to collect more samples |
| 2023-01-30 21:59:46 +0100 | <segfaultfizzbuzz> | pyret (from shriram) looks pretty 🔥 |
| 2023-01-30 21:59:54 +0100 | <monochrom> | https://cs.brown.edu/courses/csci1730/2012/ is his course I learned from about analysing languages (as opposed to paradigm-classifying). |
| 2023-01-30 22:00:11 +0100 | <mauke> | IIRC one of the old SSL attacks did timing shenanigans over the internet and it still worked |
| 2023-01-30 22:01:23 +0100 | <segfaultfizzbuzz> | monochrom: cool |
| 2023-01-30 22:01:54 +0100 | cheater_ | (~Username@user/cheater) |
| 2023-01-30 22:02:13 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-01-30 22:04:10 +0100 | <mniip> | turn any unknown random distribution into a gaussian with this one weird trick |
| 2023-01-30 22:05:43 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 268 seconds) |
| 2023-01-30 22:05:50 +0100 | cheater_ | cheater |
| 2023-01-30 22:06:03 +0100 | merijn | (~merijn@86.86.29.250) |
| 2023-01-30 22:06:20 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-01-30 22:06:31 +0100 | <segfaultfizzbuzz> | so what should i think about the apparent statistical invalidity of code invariants |
| 2023-01-30 22:07:11 +0100 | <segfaultfizzbuzz> | like, i make a type or a relationship between variables because i believe something is true or does not occur, and then statistically the real world will eventually violate that |
| 2023-01-30 22:07:24 +0100 | <segfaultfizzbuzz> | except in very special and rare cases |
| 2023-01-30 22:09:11 +0100 | <darkling> | Sure, but if your model as originally designed is intended to honour that invariant, then the invariant is a useful validation of the implementation of that model. |
| 2023-01-30 22:09:32 +0100 | <darkling> | If the model becomes invalid, then you need a new invariant and a new implementation that the new invariant can check. |
| 2023-01-30 22:10:17 +0100 | <darkling> | This doesn't mean that you should throw away any invariants or tests just because they might be found to be wrong later (or even that you know they're wrong now). |
| 2023-01-30 22:10:50 +0100 | <darkling> | That's an inevitable problem of the modelling process, and any model of the real world that you build will be incorrect -- but some will be useful. |
| 2023-01-30 22:10:51 +0100 | <segfaultfizzbuzz> | i'm thinking that the whole of programming is predicated on the idea that i can construct invariants which are true |
| 2023-01-30 22:11:05 +0100 | <segfaultfizzbuzz> | but more than likely i can only construct false invariants in almost all circumstances |
| 2023-01-30 22:12:08 +0100 | <segfaultfizzbuzz> | furthermore the stronger the association between the invariants (the stronger my type system, perhaps), the higher the likelihood that these things break irl |
| 2023-01-30 22:12:26 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-01-30 22:12:47 +0100 | <segfaultfizzbuzz> | because then both invariants need to be true, etc |
| 2023-01-30 22:13:30 +0100 | <darkling> | You'll never model perfectly. |
| 2023-01-30 22:13:40 +0100 | <darkling> | All you can do is model *well enough for now*. |
| 2023-01-30 22:14:19 +0100 | <darkling> | "Close enough for government work." |
| 2023-01-30 22:14:26 +0100 | <geekosaur> | luckily, that's good enough or we'd still be swinging from the trees |
| 2023-01-30 22:14:38 +0100 | <darkling> | (Or, tightening the requirement significantly, "close enough for practical purposes") |
| 2023-01-30 22:15:21 +0100 | varoo | (~varoo@122.161.91.19) (Read error: Connection reset by peer) |
| 2023-01-30 22:15:31 +0100 | <segfaultfizzbuzz> | i think part of what i am thinking here is that if you aren't doing something like writing cryptographic code, a language model will kick your ass at programming |
| 2023-01-30 22:17:26 +0100 | <geekosaur> | a "language model" can't do much. a domain model that knows the language might do better — but will have more failure modes, including that you can never be certain that it's using the same model you are (cf. https://www.dropbox.com/s/345iszfohklw0sl/dnn.txt?dl=0) |
| 2023-01-30 22:17:51 +0100 | <geekosaur> | (note also per that essay that the same applies to people!) |
| 2023-01-30 22:18:28 +0100 | <geekosaur> | and introspecting models to ensure they're actually doing the right thing is a major open research problem |
| 2023-01-30 22:19:08 +0100 | <darkling> | In $day_job, one of my hats is "ontologist". Overlapping and inconsistent models of the world are my bread and butter. :) |
| 2023-01-30 22:20:11 +0100 | <darkling> | Well, they will be again when we get to that phase of the project... |
| 2023-01-30 22:20:27 +0100 | <segfaultfizzbuzz> | i mean you can annotate stuff like this all day: https://www.categoricaldata.net/images/shot4.png but then you will encounter (i can't read this diagram so don't take this example literally) a specialist who specializes in one field at one college but in a different field at another college, or somesuch |
| 2023-01-30 22:21:31 +0100 | <darkling> | Yes, and this is where you need to model multiple people's conceptualisations of the field and map between them. |
| 2023-01-30 22:23:27 +0100 | varoo | (~varoo@122.161.91.19) |
| 2023-01-30 22:24:02 +0100 | EvanR | (~EvanR@user/evanr) (Remote host closed the connection) |
| 2023-01-30 22:24:21 +0100 | EvanR | (~EvanR@user/evanr) |
| 2023-01-30 22:24:23 +0100 | varoo | (~varoo@122.161.91.19) (Client Quit) |
| 2023-01-30 22:25:20 +0100 | <darkling> | (Or at least agree on a workable compromise) |
| 2023-01-30 22:28:40 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2023-01-30 22:29:13 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-01-30 22:31:04 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-01-30 22:31:49 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-01-30 22:33:29 +0100 | michalz | (~michalz@185.246.207.197) (Remote host closed the connection) |
| 2023-01-30 22:35:09 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) (Ping timeout: 252 seconds) |
| 2023-01-30 22:35:31 +0100 | king_gs | (~Thunderbi@2806:103e:29:34e5:ecc6:ec8d:1c5b:35a6) |
| 2023-01-30 22:38:24 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 268 seconds) |
| 2023-01-30 22:39:02 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2023-01-30 22:39:29 +0100 | merijn | (~merijn@86.86.29.250) (Ping timeout: 252 seconds) |
| 2023-01-30 22:46:46 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2023-01-30 22:46:49 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 252 seconds) |
| 2023-01-30 22:47:21 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2023-01-30 22:48:04 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2023-01-30 22:48:30 +0100 | qorgi | (~qorgi@141.161.13.57) |
| 2023-01-30 22:55:35 +0100 | foul_owl | (~kerry@193.29.61.202) (Ping timeout: 246 seconds) |
| 2023-01-30 22:55:44 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-01-30 22:57:47 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) |
| 2023-01-30 22:58:55 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) |
| 2023-01-30 23:02:05 +0100 | foul_owl | (~kerry@71.212.143.88) |
| 2023-01-30 23:03:50 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5982:f970:3d14:b25c) (Ping timeout: 260 seconds) |
| 2023-01-30 23:04:14 +0100 | codaraxis | (~codaraxis@user/codaraxis) |
| 2023-01-30 23:06:28 +0100 | bhall | (~brunohall@138.199.22.99) (Ping timeout: 252 seconds) |
| 2023-01-30 23:06:37 +0100 | jumper149 | (~jumper149@base.felixspringer.xyz) (Ping timeout: 252 seconds) |
| 2023-01-30 23:08:32 +0100 | foul_owl | (~kerry@71.212.143.88) (Ping timeout: 248 seconds) |
| 2023-01-30 23:11:53 +0100 | <qorgi> | hw |
| 2023-01-30 23:13:37 +0100 | <geekosaur> | ? |
| 2023-01-30 23:14:24 +0100 | <jackdk> | Hello World? |
| 2023-01-30 23:18:02 +0100 | akegalj | (~akegalj@222-217.dsl.iskon.hr) (Quit: leaving) |
| 2023-01-30 23:18:15 +0100 | foul_owl | (~kerry@157.97.134.62) |
| 2023-01-30 23:20:15 +0100 | king_gs | (~Thunderbi@2806:103e:29:34e5:ecc6:ec8d:1c5b:35a6) (Ping timeout: 248 seconds) |
| 2023-01-30 23:20:59 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) |
| 2023-01-30 23:22:33 +0100 | <qorgi> | y |
| 2023-01-30 23:22:44 +0100 | <jackdk> | ! |
| 2023-01-30 23:23:14 +0100 | <qorgi> | :p |
| 2023-01-30 23:25:19 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) (Ping timeout: 252 seconds) |
| 2023-01-30 23:28:14 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-01-30 23:29:50 +0100 | troydm | (~troydm@user/troydm) (Ping timeout: 246 seconds) |
| 2023-01-30 23:30:48 +0100 | <juri_> | i don't suppose anyone here has done any 3d scanning in haskell? |
| 2023-01-30 23:32:05 +0100 | opticblast | (~Thunderbi@172.58.84.5) |
| 2023-01-30 23:36:14 +0100 | proportions | (~proportio@91.150.188.137) |
| 2023-01-30 23:36:19 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2023-01-30 23:38:16 +0100 | merijn | (~merijn@86.86.29.250) |
| 2023-01-30 23:40:22 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2023-01-30 23:42:55 +0100 | merijn | (~merijn@86.86.29.250) (Ping timeout: 252 seconds) |
| 2023-01-30 23:43:07 +0100 | gmg | (~user@user/gehmehgeh) |
| 2023-01-30 23:43:52 +0100 | qorgi | (~qorgi@141.161.13.57) (Remote host closed the connection) |
| 2023-01-30 23:44:11 +0100 | qorgi | (~qorgi@185.156.46.108) |
| 2023-01-30 23:45:11 +0100 | qorgi | (~qorgi@185.156.46.108) (Remote host closed the connection) |
| 2023-01-30 23:45:29 +0100 | qorgi | (~qorgi@185.156.46.108) |
| 2023-01-30 23:49:48 +0100 | qorgi | (~qorgi@185.156.46.108) (Ping timeout: 260 seconds) |
| 2023-01-30 23:52:58 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2023-01-30 23:53:39 +0100 | segfaultfizzbuzz | (~segfaultf@108.211.201.53) |
| 2023-01-30 23:54:33 +0100 | zeenk | (~zeenk@2a02:2f04:a014:8700::7fe) |
| 2023-01-30 23:55:26 +0100 | merijn | (~merijn@86.86.29.250) |
| 2023-01-30 23:58:56 +0100 | zaquest | (~notzaques@5.130.79.72) |
| 2023-01-30 23:59:47 +0100 | merijn | (~merijn@86.86.29.250) (Ping timeout: 252 seconds) |
