| 2023-02-25 00:10:41 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-02-25 00:11:34 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-02-25 00:12:30 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) |
| 2023-02-25 00:12:40 +0100 | <ncf> | gurkenglas: is composition of Path strictly unital and associative? |
| 2023-02-25 00:13:58 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-02-25 00:14:19 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Remote host closed the connection) |
| 2023-02-25 00:15:06 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-02-25 00:15:55 +0100 | king_gs | (~Thunderbi@187.201.41.239) |
| 2023-02-25 00:16:19 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-02-25 00:16:24 +0100 | <ncf> | i don't see how you build a Dict (Category a) from a forall s t. Path a s t → a s t |
| 2023-02-25 00:16:56 +0100 | <ncf> | i guess you apply it to the paths of length 0 and 2 |
| 2023-02-25 00:17:33 +0100 | <ncf> | and in the other direction you fold |
| 2023-02-25 00:17:36 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Remote host closed the connection) |
| 2023-02-25 00:19:12 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-02-25 00:24:15 +0100 | <ncf> | hmm |
| 2023-02-25 00:24:48 +0100 | <ncf> | it seems weird that one representation is allowed to treat paths of length 3 specially while the other is not |
| 2023-02-25 00:26:19 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2023-02-25 00:28:30 +0100 | <ncf> | i'm not convinced |
| 2023-02-25 00:29:09 +0100 | f-a | (~f-a@151.34.85.212) (Read error: Connection reset by peer) |
| 2023-02-25 00:29:35 +0100 | thegeekinside | (~thegeekin@189.180.66.126) |
| 2023-02-25 00:31:03 +0100 | <gurkenglas> | ncf: consider that there is precisely one Dict (Category (Path a)) for either definition of Category, and it's lawful |
| 2023-02-25 00:33:10 +0100 | f-a | (~f-a@151.34.13.116) |
| 2023-02-25 00:33:38 +0100 | <gurkenglas> | ncf: the usual definition of Category is forall s t. PathsOfLengthZeroOrTwo a s t -> a s t |
| 2023-02-25 00:35:09 +0100 | <gurkenglas> | They are equivalent assuming lawfulness, but not equivalent when not assuming lawfulness |
| 2023-02-25 00:35:14 +0100 | king_gs | (~Thunderbi@187.201.41.239) (Read error: Connection reset by peer) |
| 2023-02-25 00:36:06 +0100 | <gurkenglas> | the fact that assoc/unital fall out of the Paths variant but not the PathsOfLengthZeroOrTwo variant speaks in favor of the Paths variant |
| 2023-02-25 00:36:55 +0100 | vandita | (~vandit@87-97-13-33.pool.digikabel.hu) (Ping timeout: 252 seconds) |
| 2023-02-25 00:37:28 +0100 | king_gs | (~Thunderbi@2806:103e:29:1779:19a5:ca6b:2f79:45e7) |
| 2023-02-25 00:38:01 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 252 seconds) |
| 2023-02-25 00:38:41 +0100 | vandita | (~vandit@92-249-193-153.pool.digikabel.hu) |
| 2023-02-25 00:45:21 +0100 | bilegeek_ | (~bilegeek@255.sub-174-208-231.myvzw.com) |
| 2023-02-25 00:48:05 +0100 | bilegeek | (~bilegeek@2600:1008:b008:ac8:4aba:4b96:274e:f868) (Ping timeout: 260 seconds) |
| 2023-02-25 00:50:34 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-02-25 00:53:36 +0100 | f-a | (~f-a@151.34.13.116) (Read error: Connection reset by peer) |
| 2023-02-25 00:58:11 +0100 | jpds1 | (~jpds@gateway/tor-sasl/jpds) (Quit: WeeChat 3.6) |
| 2023-02-25 00:58:51 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2023-02-25 00:59:13 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-02-25 00:59:44 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2023-02-25 01:00:14 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2023-02-25 01:09:40 +0100 | __monty__ | (~toonn@user/toonn) (Ping timeout: 260 seconds) |
| 2023-02-25 01:12:37 +0100 | mauke_ | (~mauke@user/mauke) |
| 2023-02-25 01:13:32 +0100 | mauke | (~mauke@user/mauke) (Ping timeout: 252 seconds) |
| 2023-02-25 01:13:32 +0100 | mauke_ | mauke |
| 2023-02-25 01:14:38 +0100 | son0p | (~ff@181.136.122.143) |
| 2023-02-25 01:16:05 +0100 | king_gs | (~Thunderbi@2806:103e:29:1779:19a5:ca6b:2f79:45e7) (Ping timeout: 260 seconds) |
| 2023-02-25 01:17:19 +0100 | acidjnk | (~acidjnk@p200300d6e715c440d10b57a0a1d8ddd3.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2023-02-25 01:31:54 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) (Quit: WeeChat 3.7) |
| 2023-02-25 01:33:30 +0100 | freeside | (~mengwong@103.6.151.67) |
| 2023-02-25 01:38:17 +0100 | slack1256 | (~slack1256@186.11.53.84) |
| 2023-02-25 01:38:30 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-02-25 01:38:30 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-02-25 01:38:30 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2023-02-25 01:39:26 +0100 | <ph88> | i am trying to debug this code https://github.com/scrive/pool/blob/0a05714739fc533c9840a8a5cb8bdd07ead57800/src/Data/Pool/Interna… i put trace statements all over https://bpa.st/BYGP4 i don't see it going into the if/else branch .. what else can i do to figure out why the code hangs ? |
| 2023-02-25 01:40:01 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2023-02-25 01:40:23 +0100 | acarrico | (~acarrico@dhcp-68-142-49-163.greenmountainaccess.net) (Quit: Leaving.) |
| 2023-02-25 01:40:31 +0100 | freeside | (~mengwong@103.6.151.67) (Ping timeout: 248 seconds) |
| 2023-02-25 01:42:53 +0100 | dtman34 | (~dtman34@76.156.89.180) (Ping timeout: 252 seconds) |
| 2023-02-25 01:43:07 +0100 | wroathe_ | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-02-25 01:43:41 +0100 | acarrico | (~acarrico@dhcp-68-142-49-163.greenmountainaccess.net) |
| 2023-02-25 01:49:04 +0100 | falafel | (~falafel@2607:fb91:143f:e47f:4560:973b:da2e:e11d) (Ping timeout: 248 seconds) |
| 2023-02-25 01:49:32 +0100 | <geekosaur> | check the value of `pools`? |
| 2023-02-25 01:49:57 +0100 | <geekosaur> | also be aware that `trace` and `traceM` don't happen at the same time so mixing them can produce weird results |
| 2023-02-25 01:50:35 +0100 | <geekosaur> | but from the existing trace I'd say either evaluating `pools` itself or `sizeofSmallArray pools` is hanging for some reason |
| 2023-02-25 01:54:44 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-02-25 01:57:12 +0100 | lbseale | (~quassel@user/ep1ctetus) (Ping timeout: 255 seconds) |
| 2023-02-25 01:58:31 +0100 | dtman34 | (~dtman34@2601:447:d000:93c9:2198:73de:f8ee:642a) |
| 2023-02-25 01:59:58 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2023-02-25 02:01:53 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-02-25 02:02:45 +0100 | gurkenglas | (~gurkengla@dynamic-046-114-178-046.46.114.pool.telefonica.de) (Ping timeout: 260 seconds) |
| 2023-02-25 02:03:25 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 252 seconds) |
| 2023-02-25 02:03:58 +0100 | califax | (~califax@user/califx) |
| 2023-02-25 02:06:54 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-02-25 02:08:45 +0100 | lbseale | (~quassel@user/ep1ctetus) |
| 2023-02-25 02:10:38 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-02-25 02:13:13 +0100 | <ph88> | geekosaur, i tried to refine it more .. https://bpa.st/QURP2 it hangs when i want to Show these types |
| 2023-02-25 02:14:26 +0100 | <geekosaur[m]> | Sounds like they're circularly defined? But I'm on my way to bed |
| 2023-02-25 02:16:45 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-02-25 02:18:53 +0100 | <ph88> | geekosaur[m], good night :) |
| 2023-02-25 02:18:59 +0100 | <[Leary]> | ph88: I would shift my attention to whatever code is constructing the `Pool a` you're examining; that seems to be where the bottom is. |
| 2023-02-25 02:21:07 +0100 | <ph88> | [Leary], that is a smart comment :) |
| 2023-02-25 02:38:42 +0100 | freeside | (~mengwong@103.6.151.67) |
| 2023-02-25 02:40:24 +0100 | mei | (~mei@user/mei) (Ping timeout: 255 seconds) |
| 2023-02-25 02:40:56 +0100 | wroathe_ | (~wroathe@207-153-38-140.fttp.usinternet.com) (Quit: leaving) |
| 2023-02-25 02:43:27 +0100 | freeside | (~mengwong@103.6.151.67) (Ping timeout: 248 seconds) |
| 2023-02-25 02:44:03 +0100 | mei | (~mei@user/mei) |
| 2023-02-25 02:45:03 +0100 | mei | (~mei@user/mei) (Max SendQ exceeded) |
| 2023-02-25 02:47:10 +0100 | razetime | (~Thunderbi@117.193.3.107) |
| 2023-02-25 02:50:29 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-02-25 02:51:54 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-02-25 02:52:59 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2023-02-25 02:53:18 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2023-02-25 02:56:59 +0100 | mei | (~mei@user/mei) |
| 2023-02-25 02:59:27 +0100 | morrow | (~morrow@2a10:8012:11:e637:bd15:e5e9:23f1:af6) |
| 2023-02-25 03:03:43 +0100 | vandita | (~vandit@92-249-193-153.pool.digikabel.hu) (Ping timeout: 246 seconds) |
| 2023-02-25 03:05:46 +0100 | vandita | (~vandit@94-21-55-121.pool.digikabel.hu) |
| 2023-02-25 03:06:09 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-02-25 03:09:38 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-02-25 03:18:08 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds) |
| 2023-02-25 03:21:47 +0100 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection) |
| 2023-02-25 03:22:01 +0100 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) |
| 2023-02-25 03:22:19 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-02-25 03:23:35 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 255 seconds) |
| 2023-02-25 03:32:09 +0100 | razetime1 | (~Thunderbi@117.193.2.47) |
| 2023-02-25 03:33:37 +0100 | mima | (~mmh@212.114.180.173) (Ping timeout: 252 seconds) |
| 2023-02-25 03:34:24 +0100 | razetime | (~Thunderbi@117.193.3.107) (Ping timeout: 255 seconds) |
| 2023-02-25 03:34:25 +0100 | razetime1 | razetime |
| 2023-02-25 03:37:19 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 246 seconds) |
| 2023-02-25 03:38:25 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 252 seconds) |
| 2023-02-25 03:38:48 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-02-25 03:47:18 +0100 | king_gs | (~Thunderbi@187.201.41.239) |
| 2023-02-25 04:00:25 +0100 | freeside | (~mengwong@103.6.151.67) |
| 2023-02-25 04:00:29 +0100 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection) |
| 2023-02-25 04:00:45 +0100 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) |
| 2023-02-25 04:03:41 +0100 | azure_vermilion | (~azure_ver@82.132.235.123) (Ping timeout: 252 seconds) |
| 2023-02-25 04:03:52 +0100 | slack1256 | (~slack1256@186.11.53.84) (Remote host closed the connection) |
| 2023-02-25 04:04:17 +0100 | azure_vermilion | (~azure_ver@82-132-233-24.dab.02.net) |
| 2023-02-25 04:05:00 +0100 | freeside | (~mengwong@103.6.151.67) (Ping timeout: 255 seconds) |
| 2023-02-25 04:08:20 +0100 | jludwig | (~justin@li657-110.members.linode.com) (Quit: ZNC - https://znc.in) |
| 2023-02-25 04:09:31 +0100 | jludwig | (~justin@li657-110.members.linode.com) |
| 2023-02-25 04:13:51 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-02-25 04:23:52 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-02-25 04:25:40 +0100 | tjakway | (~tjakway@cpe-107-184-74-161.socal.res.rr.com) |
| 2023-02-25 04:28:56 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-02-25 04:30:21 +0100 | gastus | (~gastus@5.83.191.19) |
| 2023-02-25 04:33:19 +0100 | gastus_ | (~gastus@185.6.123.134) (Ping timeout: 248 seconds) |
| 2023-02-25 04:34:25 +0100 | king_gs | (~Thunderbi@187.201.41.239) (Read error: Connection reset by peer) |
| 2023-02-25 04:35:39 +0100 | king_gs | (~Thunderbi@2806:103e:29:1779:19a5:ca6b:2f79:45e7) |
| 2023-02-25 04:38:30 +0100 | tjakway | (~tjakway@cpe-107-184-74-161.socal.res.rr.com) (Quit: WeeChat 3.5) |
| 2023-02-25 04:42:04 +0100 | td_ | (~td@i5387092A.versanet.de) (Ping timeout: 246 seconds) |
| 2023-02-25 04:44:11 +0100 | td_ | (~td@i5387090F.versanet.de) |
| 2023-02-25 04:44:23 +0100 | king_gs | (~Thunderbi@2806:103e:29:1779:19a5:ca6b:2f79:45e7) (Ping timeout: 252 seconds) |
| 2023-02-25 04:50:31 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-02-25 04:50:31 +0100 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-02-25 04:50:31 +0100 | finn_elija | FinnElija |
| 2023-02-25 04:51:07 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 248 seconds) |
| 2023-02-25 04:52:08 +0100 | freeside | (~mengwong@103.6.151.67) |
| 2023-02-25 04:53:54 +0100 | razetime1 | (~Thunderbi@117.193.4.254) |
| 2023-02-25 04:54:28 +0100 | morrow | (~morrow@2a10:8012:11:e637:bd15:e5e9:23f1:af6) (Remote host closed the connection) |
| 2023-02-25 04:55:01 +0100 | razetime | (~Thunderbi@117.193.2.47) (Ping timeout: 246 seconds) |
| 2023-02-25 04:55:01 +0100 | razetime1 | razetime |
| 2023-02-25 04:55:31 +0100 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (Quit: Ping timeout (120 seconds)) |
| 2023-02-25 04:55:51 +0100 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) |
| 2023-02-25 04:55:51 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 255 seconds) |
| 2023-02-25 04:58:57 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-02-25 04:59:48 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-02-25 05:12:57 +0100 | razetime | (~Thunderbi@117.193.4.254) (Ping timeout: 255 seconds) |
| 2023-02-25 05:17:02 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-02-25 05:22:42 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2023-02-25 05:33:03 +0100 | vandita | (~vandit@94-21-55-121.pool.digikabel.hu) (Ping timeout: 248 seconds) |
| 2023-02-25 05:34:55 +0100 | vandita | (~vandit@77-234-64-138.pool.digikabel.hu) |
| 2023-02-25 05:36:51 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2023-02-25 05:37:36 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2023-02-25 05:38:56 +0100 | king_gs | (~Thunderbi@187.201.41.239) |
| 2023-02-25 05:47:52 +0100 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Ping timeout: 246 seconds) |
| 2023-02-25 05:48:02 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2023-02-25 05:48:46 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17) (Ping timeout: 252 seconds) |
| 2023-02-25 05:48:59 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) (Remote host closed the connection) |
| 2023-02-25 05:50:45 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 255 seconds) |
| 2023-02-25 05:59:25 +0100 | king_gs | (~Thunderbi@187.201.41.239) (Read error: Connection reset by peer) |
| 2023-02-25 05:59:42 +0100 | king_gs | (~Thunderbi@2806:103e:29:1779:19a5:ca6b:2f79:45e7) |
| 2023-02-25 06:02:02 +0100 | razetime | (~Thunderbi@117.193.4.254) |
| 2023-02-25 06:20:54 +0100 | king_gs | (~Thunderbi@2806:103e:29:1779:19a5:ca6b:2f79:45e7) (Quit: king_gs) |
| 2023-02-25 06:49:29 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) |
| 2023-02-25 06:50:37 +0100 | jinsun | (~jinsun@user/jinsun) (Read error: Connection reset by peer) |
| 2023-02-25 06:53:26 +0100 | jinsun | (~jinsun@user/jinsun) |
| 2023-02-25 06:53:50 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) (Ping timeout: 260 seconds) |
| 2023-02-25 06:57:16 +0100 | man_max | (~man_max@94-43-231-47.dsl.utg.ge) |
| 2023-02-25 06:57:37 +0100 | <man_max> | I need to download a paper from springer proceeding. Do you have an access to download from springer? |
| 2023-02-25 07:03:18 +0100 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Remote host closed the connection) |
| 2023-02-25 07:07:43 +0100 | bliminse | (~bliminse@user/bliminse) |
| 2023-02-25 07:23:27 +0100 | thegeekinside | (~thegeekin@189.180.66.126) (Ping timeout: 255 seconds) |
| 2023-02-25 07:27:18 +0100 | man_max | (~man_max@94-43-231-47.dsl.utg.ge) (Quit: Client closed) |
| 2023-02-25 07:27:19 +0100 | bilegeek_ | (~bilegeek@255.sub-174-208-231.myvzw.com) (Quit: Leaving) |
| 2023-02-25 07:29:38 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds) |
| 2023-02-25 07:40:33 +0100 | inversed | (~inversed@bcdcac82.skybroadband.com) (Ping timeout: 255 seconds) |
| 2023-02-25 07:42:52 +0100 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-02-25 07:49:16 +0100 | zephyr__ | (~irfan@106.214.197.187) |
| 2023-02-25 07:50:32 +0100 | razetime | (~Thunderbi@117.193.4.254) (Remote host closed the connection) |
| 2023-02-25 07:51:21 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 255 seconds) |
| 2023-02-25 07:53:08 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-02-25 07:54:39 +0100 | inversed | (~inversed@bcdcac82.skybroadband.com) |
| 2023-02-25 07:55:17 +0100 | vandita | (~vandit@77-234-64-138.pool.digikabel.hu) (Ping timeout: 255 seconds) |
| 2023-02-25 07:56:56 +0100 | vandita | (~vandit@84-236-122-10.pool.digikabel.hu) |
| 2023-02-25 07:57:08 +0100 | <Inst> | yeah, i'm not sure if this is intended behavior with cabal |
| 2023-02-25 07:57:25 +0100 | <Inst> | apparently, if you use --lib with any package, say, Acme.Dont, you now have a config file, at least on Windows |
| 2023-02-25 07:57:36 +0100 | <Inst> | further non --lib uses of cabal install will install hidden to that config file |
| 2023-02-25 07:57:48 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2023-02-25 07:58:08 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2023-02-25 08:01:50 +0100 | <Inst> | posted to cabal |
| 2023-02-25 08:01:53 +0100 | <Inst> | issues on github |
| 2023-02-25 08:04:02 +0100 | <Inst> | btw, i finally figured out how to teach / learn an idiom of Haskell in 1 week, but it's pretty horrifying, anyone interested? |
| 2023-02-25 08:04:12 +0100 | <zephyr__> | Inst: Sure! |
| 2023-02-25 08:04:20 +0100 | <Inst> | put everything in main |
| 2023-02-25 08:04:30 +0100 | <Inst> | IORef / MVar / TVar |
| 2023-02-25 08:04:41 +0100 | <Inst> | fix to emulate a while loop, for to emulate a for loop |
| 2023-02-25 08:05:13 +0100 | <Inst> | i tried this idiom a bit, as a Pythonic translation of a Python program into Haskell, and it was horrifying / disgusting |
| 2023-02-25 08:05:26 +0100 | <Inst> | but I think anyone can pick up this idiom in the same amount of time they might need to get a minimal grasp of any other language |
| 2023-02-25 08:06:32 +0100 | <zephyr__> | Inst: I see. |
| 2023-02-25 08:06:39 +0100 | <Inst> | it's sort of like curing cancer by shooting the patient |
| 2023-02-25 08:06:57 +0100 | <Inst> | but hey, it's technically doable, we can technically say Haskell can be learned in 1 week, for some definition of Haskell |
| 2023-02-25 08:08:21 +0100 | <zephyr__> | Inst: True. |
| 2023-02-25 08:14:01 +0100 | <Inst> | there is actually a different question of how many "productive" Haskell idioms there are |
| 2023-02-25 08:14:28 +0100 | <Inst> | I think the "everything in main, IORef, simulated while / for" is probably the minimum possible productive Haskell idiom |
| 2023-02-25 08:14:57 +0100 | <Inst> | there's Simple Haskell on top of that, and probably a range of useful / "true" Haskell idioms between "not really Haskell" and Simple Haskell |
| 2023-02-25 08:20:25 +0100 | falafel | (~falafel@2607:fb91:143f:e47f:f2ba:9e36:77ef:5ee6) |
| 2023-02-25 08:25:00 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-02-25 08:30:00 +0100 | trev | (~trev@user/trev) |
| 2023-02-25 08:35:19 +0100 | kenran | (~user@user/kenran) |
| 2023-02-25 08:41:28 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) |
| 2023-02-25 08:48:00 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2023-02-25 08:58:42 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2023-02-25 08:59:02 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2023-02-25 09:02:50 +0100 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 2023-02-25 09:15:49 +0100 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2023-02-25 09:19:49 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) |
| 2023-02-25 09:26:40 +0100 | falafel | (~falafel@2607:fb91:143f:e47f:f2ba:9e36:77ef:5ee6) (Ping timeout: 260 seconds) |
| 2023-02-25 09:28:06 +0100 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 255 seconds) |
| 2023-02-25 09:36:06 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2023-02-25 09:37:22 +0100 | cstml | (~cstml@cpc151611-shef16-2-0-cust313.17-1.cable.virginm.net) |
| 2023-02-25 09:42:27 +0100 | qhong | (~qhong@dn160vrd000d6kpg009l6c0000ep.stanford.edu) (Remote host closed the connection) |
| 2023-02-25 09:44:00 +0100 | qhong | (~qhong@DN160vrd000d6kpg009l6c0000ep.stanford.edu) |
| 2023-02-25 09:45:46 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) (Remote host closed the connection) |
| 2023-02-25 09:51:54 +0100 | acidjnk | (~acidjnk@2003:d6:e715:c416:a957:76b2:4369:5020) |
| 2023-02-25 09:52:50 +0100 | qhong | (~qhong@DN160vrd000d6kpg009l6c0000ep.stanford.edu) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-02-25 09:53:06 +0100 | qhong | (~qhong@rescomp-21-400677.stanford.edu) |
| 2023-02-25 09:53:07 +0100 | qhong | (~qhong@rescomp-21-400677.stanford.edu) (Remote host closed the connection) |
| 2023-02-25 09:53:49 +0100 | qhong | (~qhong@2607:f6d0:d:3533:1:3533:0:1d9) |
| 2023-02-25 09:57:48 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) (Ping timeout: 255 seconds) |
| 2023-02-25 09:58:42 +0100 | cstml | (~cstml@cpc151611-shef16-2-0-cust313.17-1.cable.virginm.net) (Ping timeout: 255 seconds) |
| 2023-02-25 09:59:52 +0100 | vandita | (~vandit@84-236-122-10.pool.digikabel.hu) (Ping timeout: 246 seconds) |
| 2023-02-25 10:01:40 +0100 | vandita | (~vandit@91-83-11-241.pool.digikabel.hu) |
| 2023-02-25 10:05:50 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2023-02-25 10:06:19 +0100 | <maerwald[m]> | I think you need 6 weeks for basic haskell |
| 2023-02-25 10:11:02 +0100 | alecs | (~alecs@31.188.224.180) |
| 2023-02-25 10:13:19 +0100 | alecs | (~alecs@31.188.224.180) (Client Quit) |
| 2023-02-25 10:13:37 +0100 | alecs | (~alecs@31.188.224.180) |
| 2023-02-25 10:14:22 +0100 | alecs | (~alecs@31.188.224.180) (Client Quit) |
| 2023-02-25 10:14:44 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) |
| 2023-02-25 10:15:37 +0100 | alecs | (~alecs@31.188.224.180) |
| 2023-02-25 10:20:12 +0100 | alecs | (~alecs@31.188.224.180) (Client Quit) |
| 2023-02-25 10:20:24 +0100 | alecs | (~alecs@31.188.224.180) |
| 2023-02-25 10:20:30 +0100 | alecs | (~alecs@31.188.224.180) (Client Quit) |
| 2023-02-25 10:20:52 +0100 | alecs | (~alecs@31.188.224.180) |
| 2023-02-25 10:26:25 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-02-25 10:26:32 +0100 | `2jt | (~jtomas@84.78.228.192) |
| 2023-02-25 10:31:10 +0100 | rembo10 | (~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-02-25 10:31:48 +0100 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) |
| 2023-02-25 10:33:21 +0100 | rembo10 | (~rembo10@main.remulis.com) |
| 2023-02-25 10:33:40 +0100 | azure_vermilion | (~azure_ver@82-132-233-24.dab.02.net) (Ping timeout: 252 seconds) |
| 2023-02-25 10:33:59 +0100 | azure_vermilion | (~azure_ver@82-132-233-212.dab.02.net) |
| 2023-02-25 10:34:03 +0100 | phma | (~phma@2001:5b0:2143:86d8:f396:a44:9b48:fdf2) (Read error: Connection reset by peer) |
| 2023-02-25 10:34:59 +0100 | phma | (~phma@2001:5b0:2172:8768:d70b:20eb:9db0:5a75) |
| 2023-02-25 10:46:16 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) |
| 2023-02-25 10:50:35 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) (Ping timeout: 248 seconds) |
| 2023-02-25 10:53:21 +0100 | mima | (~mmh@ppp-212-114-180-20.dynamic.mnet-online.de) |
| 2023-02-25 10:55:03 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-02-25 10:56:55 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2023-02-25 11:11:51 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-02-25 11:12:34 +0100 | gmg | (~user@user/gehmehgeh) |
| 2023-02-25 11:15:37 +0100 | OscarZ | (~oscarz@95.175.104.72) (Quit: Leaving) |
| 2023-02-25 11:27:05 +0100 | Vajb | (~Vajb@2001:999:230:f561:4ee8:ad7f:13ff:9959) (Read error: Connection reset by peer) |
| 2023-02-25 11:27:31 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2023-02-25 11:32:44 +0100 | akegalj | (~akegalj@183-163.dsl.iskon.hr) |
| 2023-02-25 11:43:17 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-02-25 11:49:23 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2023-02-25 11:55:39 +0100 | `2jt | (~jtomas@84.78.228.192) (Ping timeout: 248 seconds) |
| 2023-02-25 11:57:05 +0100 | `2jt | (~jtomas@84.78.228.193) |
| 2023-02-25 11:59:16 +0100 | jtomas | (~jtomas@84.78.228.192) |
| 2023-02-25 12:01:33 +0100 | `2jt | (~jtomas@84.78.228.193) (Ping timeout: 255 seconds) |
| 2023-02-25 12:11:54 +0100 | vandita | (~vandit@91-83-11-241.pool.digikabel.hu) (Ping timeout: 255 seconds) |
| 2023-02-25 12:13:30 +0100 | vandita | (~vandit@80-95-85-49.pool.digikabel.hu) |
| 2023-02-25 12:15:53 +0100 | <[exa]> | Inst: actually that's a pretty reasonable way |
| 2023-02-25 12:16:13 +0100 | <[exa]> | `fix` is a bit of overkill but we have `whileM` right. :D |
| 2023-02-25 12:17:24 +0100 | <[exa]> | the only thing the people need to resolve there to get moreless productive (with problems they can reasonably solve) is explaining that 1] return actually doesn't return 2] when to use <- vs when to use let .. = |
| 2023-02-25 12:18:10 +0100 | jtomas | (~jtomas@84.78.228.192) (Ping timeout: 260 seconds) |
| 2023-02-25 12:18:13 +0100 | <Inst> | also the most important thing to explain is NEVER ACTUALLY CODE IN THIS f- IDIOM |
| 2023-02-25 12:18:23 +0100 | <Inst> | it's disgusting! |
| 2023-02-25 12:19:08 +0100 | <[exa]> | you can't judge, they will still like it |
| 2023-02-25 12:19:12 +0100 | jtomas | (~jtomas@84.78.228.193) |
| 2023-02-25 12:19:20 +0100 | <Inst> | what i've heard is that if you try to teach the explosives to learners |
| 2023-02-25 12:19:22 +0100 | <[exa]> | the disgust comes with knowing how to do stuff better |
| 2023-02-25 12:19:26 +0100 | <Inst> | and to an extent, people like knowing that mutability exists |
| 2023-02-25 12:19:33 +0100 | <Inst> | it'll just roll of their backs |
| 2023-02-25 12:19:42 +0100 | <Inst> | they're not interested, they understand that Haskell is for functional programming |
| 2023-02-25 12:20:28 +0100 | <Inst> | in my experience, they don't actually want to know mutrefs, if they have accumulating parameters, it's enough |
| 2023-02-25 12:21:13 +0100 | <Inst> | if you teach them unsafePerformIO, they'll be like: "well, this is unsafe, isn't it?" |
| 2023-02-25 12:23:10 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2023-02-25 12:23:35 +0100 | <[exa]> | yeah |
| 2023-02-25 12:23:39 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2023-02-25 12:26:11 +0100 | <Inst> | whileM requires IO Bool, which is suboptimal |
| 2023-02-25 12:26:21 +0100 | xff0x | (~xff0x@ai081074.d.east.v6connect.net) (Ping timeout: 268 seconds) |
| 2023-02-25 12:26:23 +0100 | <Inst> | untilM is better if you want it |
| 2023-02-25 12:26:50 +0100 | <Inst> | oh god what, no one cloned the until semantics |
| 2023-02-25 12:27:15 +0100 | <Inst> | fix is great, though, because it gives you an opportunity to introduce recursion and laziness, as in, how the hell does x = f x workS/ |
| 2023-02-25 12:27:46 +0100 | xff0x | (~xff0x@178.255.149.135) |
| 2023-02-25 12:29:31 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2023-02-25 12:30:31 +0100 | gmg | (~user@user/gehmehgeh) |
| 2023-02-25 12:34:30 +0100 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Ping timeout: 260 seconds) |
| 2023-02-25 12:38:49 +0100 | <zephyr__> | Inst: Perl has had `until` for long. |
| 2023-02-25 12:40:39 +0100 | <mc47> | Hi folks! I'm trying to model a smart refresh system of values that only get recalculated when their dependencies change. They type that I came up with is basically { compute :: Context -> a, dependencies :: Set Dependency} |
| 2023-02-25 12:41:28 +0100 | <mc47> | The applicative instance is straightforward (merge the dependencies), but I don't think there's a reasonable way to implement a monad instance |
| 2023-02-25 12:41:40 +0100 | <mc47> | Right? Just wanted to check my intuition |
| 2023-02-25 12:43:59 +0100 | xff0x | (~xff0x@178.255.149.135) (Ping timeout: 248 seconds) |
| 2023-02-25 12:44:01 +0100 | jtomas | (~jtomas@84.78.228.193) (Ping timeout: 246 seconds) |
| 2023-02-25 12:45:54 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2023-02-25 12:46:03 +0100 | xff0x | (~xff0x@ai081074.d.east.v6connect.net) |
| 2023-02-25 12:48:35 +0100 | Vajb | (~Vajb@2001:999:230:f561:4ee8:ad7f:13ff:9959) |
| 2023-02-25 12:52:25 +0100 | __monty__ | (~toonn@user/toonn) |
| 2023-02-25 13:05:04 +0100 | tubogram44 | (~tubogram@user/tubogram) (Quit: See ya later!) |
| 2023-02-25 13:05:12 +0100 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 2023-02-25 13:06:43 +0100 | akegalj | (~akegalj@183-163.dsl.iskon.hr) (Quit: leaving) |
| 2023-02-25 13:08:21 +0100 | tubogram44 | (~tubogram@user/tubogram) |
| 2023-02-25 13:13:15 +0100 | <[Leary]> | mc47: Sounds like Incremental Computing. This is a matter of ongoing research where even the state of the art approaches (e.g. Adapton) are honestly not great; I don't recommend sinking time into your own design unless it's for fun. |
| 2023-02-25 13:14:13 +0100 | <geekosaur> | sounds like a spreadsheet to me 🙂 |
| 2023-02-25 13:14:40 +0100 | <[Leary]> | Yeah, spreadsheets are a classic usecase for IC. |
| 2023-02-25 13:17:54 +0100 | <mc47> | I didn't expect this to be a matter of ongoing research... Thanks for the pointer [Leary] |
| 2023-02-25 13:17:58 +0100 | <mc47> | [Leary]: Huh, interesting. I mean I have an applicative-based design that works for my purposes. The "bottom" computation nodes are their own dependencies, computations are composed with <*>. |
| 2023-02-25 13:19:47 +0100 | <mc47> | However, the refresh logic is ad-hoc: I create a map from dependencies to final computations, and trigger a refresh when the dependencies change |
| 2023-02-25 13:20:10 +0100 | <mc47> | geekosaur: very similar to a spreadsheet ;) trying to replace them actually |
| 2023-02-25 13:20:26 +0100 | jtomas | (~jtomas@84.78.228.192) |
| 2023-02-25 13:21:09 +0100 | GoldsteinQ | (~goldstein@goldstein.rs) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-02-25 13:21:45 +0100 | acidjnk | (~acidjnk@2003:d6:e715:c416:a957:76b2:4369:5020) (Ping timeout: 252 seconds) |
| 2023-02-25 13:21:59 +0100 | GoldsteinQ | (~goldstein@goldstein.rs) |
| 2023-02-25 13:22:01 +0100 | <Franciman> | hi mc47, maybe you can get some ideas from FRP |
| 2023-02-25 13:22:28 +0100 | <Franciman> | or from virtual dom technologies in react and the likes which compute the minimal set of changes to propagate |
| 2023-02-25 13:23:15 +0100 | `2jt | (~jtomas@84.78.228.192) |
| 2023-02-25 13:24:46 +0100 | <mc47> | Thanks for the pointer Franciman |
| 2023-02-25 13:25:03 +0100 | jtomas | (~jtomas@84.78.228.192) (Ping timeout: 248 seconds) |
| 2023-02-25 13:26:57 +0100 | <Franciman> | i'm not sure, but i think that implementing a monad instance means losing static control over what happens at the previous stages of your refresh system |
| 2023-02-25 13:27:32 +0100 | <Franciman> | so you can't be sure what >>= will pass over, and could end up solving an halting problem? Not sure, again :P |
| 2023-02-25 13:30:24 +0100 | <[Leary]> | mc47: This <https://gist.github.com/LSLeary/da963da122946d981b4b143cbcf3dd73> is a small Haskell implementation based on Magnus Carlsson's functional pearl on the topic, with further inspiration from the Adapton paper. Perhaps it (or details contained within) will be of use to you, though I can't guarantee performance or usability. |
| 2023-02-25 13:31:27 +0100 | ubert | (~Thunderbi@p548c8a3b.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2023-02-25 13:31:59 +0100 | ubert | (~Thunderbi@p200300ecdf1f1e05ddce163a973cd7f5.dip0.t-ipconnect.de) |
| 2023-02-25 13:33:22 +0100 | <mc47> | Franciman: that's exactly my intuition. I can't know what >>= will give me back until I run it, which means it's not particularly useful. |
| 2023-02-25 13:33:56 +0100 | <Franciman> | arrows could help a bit in preprocessing things |
| 2023-02-25 13:34:59 +0100 | <mc47> | [Leary] that was quick! Thanks a lot, I'll definitely check it out. I don't care about performance or usability at this point since what I've written fulfills the requirements (and is in TypeScript...). I was just curious and intrigued by the problem |
| 2023-02-25 13:35:53 +0100 | <[Leary]> | Note that `Adaptive` in this implementation /does/ have Monad. The necessary trick is to observe dependencies as they're used and update deps/revdeps accordingly. |
| 2023-02-25 13:36:41 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-02-25 13:38:26 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-02-25 13:42:37 +0100 | <mc47> | I guess I have some reading to do :D |
| 2023-02-25 13:44:02 +0100 | cheater_ | (~Username@user/cheater) |
| 2023-02-25 13:46:51 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
| 2023-02-25 13:46:58 +0100 | cheater_ | cheater |
| 2023-02-25 13:47:09 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
| 2023-02-25 13:50:29 +0100 | GuestW16 | (~GuestW16@46.146.247.46) |
| 2023-02-25 13:54:29 +0100 | <[exa]> | mc47: this sounds a bit like propagators, but these are more like for constraint solving and managing uncertainty |
| 2023-02-25 13:57:39 +0100 | <mc47> | [exa]: thanks for another pointer :D :D |
| 2023-02-25 13:59:38 +0100 | <[exa]> | mc47: I literally saw some pretty reasonable slides a few days ago, more related to prolog actually |
| 2023-02-25 14:00:41 +0100 | <[exa]> | but yeah it's more for constraint solvers where you don't really know how many constraints are going to get spawned |
| 2023-02-25 14:01:09 +0100 | <[exa]> | in your case I guess any topology-conserving update scheme will do |
| 2023-02-25 14:02:33 +0100 | <[exa]> | btw IIRC there's some super-cool super-complicated online algorithm for quickly detecting new strongly connected components (aka uncomputable cycles) after dependency graph updates (the benefit is that you don't need to run the whole the scc everytime again), that might help I guess |
| 2023-02-25 14:03:43 +0100 | ubert | (~Thunderbi@p200300ecdf1f1e05ddce163a973cd7f5.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2023-02-25 14:03:46 +0100 | <mc47> | Yes, I think what I've written will be enough for the next two or three years, and any improvement will be more on the "software-engineery" side |
| 2023-02-25 14:03:56 +0100 | ub | (~Thunderbi@p548c8a3b.dip0.t-ipconnect.de) |
| 2023-02-25 14:04:10 +0100 | <mc47> | All of this is for my own enjoyment :D I like thinking about these problems |
| 2023-02-25 14:06:13 +0100 | ub | ubert |
| 2023-02-25 14:07:10 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-02-25 14:07:55 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-02-25 14:10:56 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 248 seconds) |
| 2023-02-25 14:16:31 +0100 | `2jt | (~jtomas@84.78.228.192) (Remote host closed the connection) |
| 2023-02-25 14:16:50 +0100 | `2jt | (~jtomas@84.78.228.192) |
| 2023-02-25 14:18:37 +0100 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 252 seconds) |
| 2023-02-25 14:20:59 +0100 | nattiestnate | (~nate@202.138.250.13) |
| 2023-02-25 14:28:04 +0100 | alecs | (~alecs@31.188.224.180) (Quit: WeeChat 3.8) |
| 2023-02-25 14:34:13 +0100 | jtza8 | (~user@165.255.63.244) |
| 2023-02-25 14:47:29 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-02-25 14:48:30 +0100 | shapr | (~user@144.163.19.233) (Ping timeout: 255 seconds) |
| 2023-02-25 14:49:17 +0100 | GuestW16 | (~GuestW16@46.146.247.46) (Quit: Client closed) |
| 2023-02-25 14:49:50 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) |
| 2023-02-25 14:54:30 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) (Ping timeout: 260 seconds) |
| 2023-02-25 15:16:11 +0100 | Midjak | (~Midjak@82.66.147.146) |
| 2023-02-25 15:27:43 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 248 seconds) |
| 2023-02-25 15:28:33 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:c1fe:7ebc:3299:29d5) |
| 2023-02-25 15:29:18 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-02-25 15:42:10 +0100 | notzmv | (~zmv@user/notzmv) |
| 2023-02-25 15:43:57 +0100 | <ph88> | does someone recognize this kind of code ? https://bpa.st/DPGZ2 i suspect it used to work on GHC release 9.0.2 but no longer works on ghc 9.2.6 |
| 2023-02-25 15:44:39 +0100 | <ph88> | This is taken from here https://github.com/biocad/hasbolt-extras/blob/master/src/Database/Bolt/Extras/DSL/Typed/Instances.… |
| 2023-02-25 15:46:05 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-02-25 15:47:04 +0100 | `2jt | (~jtomas@84.78.228.192) (Remote host closed the connection) |
| 2023-02-25 15:47:23 +0100 | `2jt | (~jtomas@84.78.228.192) |
| 2023-02-25 15:48:00 +0100 | <jtza8> | I've spent an afternoon comming to the conclusion that what I thought should be a sum type, ends up being two very different types, in that there don't seem to be any significant functions that would be defined for both of them. Is this a usual part of the Haskell learning experience? (Or was I just being thick?) |
| 2023-02-25 15:48:41 +0100 | Guest2517 | (~Guest25@103.15.228.66) |
| 2023-02-25 15:49:08 +0100 | <geekosaur> | ph88, that looks like missing `PolyKinds` |
| 2023-02-25 15:49:41 +0100 | <geekosaur> | jtza8, designing types rationally is part of learning, yes |
| 2023-02-25 15:50:01 +0100 | <geekosaur> | the rules you'd follow for other languages don't necessarily work here |
| 2023-02-25 15:50:34 +0100 | <jtza8> | It was a good learning experience though. Still too much OOP in me. |
| 2023-02-25 15:56:06 +0100 | kmein | (~weechat@static.173.83.99.88.clients.your-server.de) (Quit: ciao kakao) |
| 2023-02-25 15:56:20 +0100 | <ph88> | geekosaur, i added PolyKinds also i forgot to post second error https://bpa.st/V6GRU |
| 2023-02-25 15:56:23 +0100 | kmein | (~weechat@static.173.83.99.88.clients.your-server.de) |
| 2023-02-25 15:59:16 +0100 | <geekosaur> | more context helps. they're explicitly of kind `Type` so can't be of kind `'Bool` |
| 2023-02-25 15:59:43 +0100 | <geekosaur> | unless this code was misusing `Type` from back before `NoStarIsType` |
| 2023-02-25 16:00:16 +0100 | fr33domlover | (~fr33domlo@towards.vision) (Remote host closed the connection) |
| 2023-02-25 16:00:48 +0100 | <ph88> | geekosaur, i also don't know (not my library) .. i will comment out the Assert then for the moment |
| 2023-02-25 16:03:04 +0100 | acidjnk | (~acidjnk@2003:d6:e715:c416:a957:76b2:4369:5020) |
| 2023-02-25 16:03:31 +0100 | `2jt | (~jtomas@84.78.228.192) (Read error: Connection reset by peer) |
| 2023-02-25 16:04:09 +0100 | o-90 | (~o-90@gateway/tor-sasl/o-90) |
| 2023-02-25 16:05:33 +0100 | `2jt | (~jtomas@84.78.228.192) |
| 2023-02-25 16:05:51 +0100 | `2jt | (~jtomas@84.78.228.192) (Read error: Connection reset by peer) |
| 2023-02-25 16:06:00 +0100 | o-90 | (~o-90@gateway/tor-sasl/o-90) (Client Quit) |
| 2023-02-25 16:06:58 +0100 | `2jt | (~jtomas@84.78.228.192) |
| 2023-02-25 16:09:09 +0100 | `2jt | (~jtomas@84.78.228.192) (Remote host closed the connection) |
| 2023-02-25 16:09:22 +0100 | `2jt | (~jtomas@84.78.228.192) |
| 2023-02-25 16:09:39 +0100 | `2jt | (~jtomas@84.78.228.192) (Read error: Connection reset by peer) |
| 2023-02-25 16:09:53 +0100 | <Guest2517> | Hey everyone! I'm new to Haskell and open-source but quite excited about Summer of Haskell! I might be a bit late but can anyone direct me to how to get started? |
| 2023-02-25 16:10:14 +0100 | mjs2600 | (~mjs2600@24.91.3.49) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-02-25 16:11:38 +0100 | `2jt | (~jtomas@84.78.228.192) |
| 2023-02-25 16:11:43 +0100 | <hpc> | https://www.haskell.org/get-started/ |
| 2023-02-25 16:11:57 +0100 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 2023-02-25 16:12:18 +0100 | <hpc> | ^ is a nice easy way to get set up |
| 2023-02-25 16:13:53 +0100 | <geekosaur> | ph88, actually I misread that and can't tell for certain because the definition of Assert is missing, but ghc is very certain that it should have kind Type in both those places. which looks wrong, so I wonder if Assert is misdeclared or itself is in a module without PolyKinds (but that too seems weird, seems like it should be explicitly Bool not polymorphic) |
| 2023-02-25 16:14:05 +0100 | <geekosaur> | but without being able to see Assert I can't tell for certain |
| 2023-02-25 16:14:37 +0100 | <ph88> | geekosaur, i think the definition of Assert is here https://hackage.haskell.org/package/base-4.17.0.0/docs/GHC-TypeError.html#t:Assert |
| 2023-02-25 16:16:35 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2023-02-25 16:16:39 +0100 | <geekosaur> | okay, maybe its type changed at some point, because that definition indeed doesn't match the usage |
| 2023-02-25 16:17:11 +0100 | <[Leary]> | It doesn't match the error either. |
| 2023-02-25 16:19:47 +0100 | `2jt | (~jtomas@84.78.228.192) (Quit: Leaving) |
| 2023-02-25 16:22:23 +0100 | ddellacosta | (~ddellacos@146.70.166.100) (Ping timeout: 264 seconds) |
| 2023-02-25 16:23:46 +0100 | <geekosaur> | true, the error says `Type` but base's `Assert` wants a `TypeError` |
| 2023-02-25 16:24:03 +0100 | <geekosaur> | and a `Bool` matches neither |
| 2023-02-25 16:24:18 +0100 | <geekosaur> | (promoted) |
| 2023-02-25 16:25:46 +0100 | <eldritchcookie[m> | i want to get all the exports of a module with template haskell currently the only way to do that is to parse the module, assuming i were able to modify the template haskell package to support this would i need to pass this by a GHC proposal or something similar ? |
| 2023-02-25 16:27:34 +0100 | <geekosaur> | hypothetically you have an already parsed AST if you are doing things like e.g. Data.QuickCheck.All does |
| 2023-02-25 16:28:15 +0100 | <geekosaur> | I have a nasty suspicion that traversing that AST is either difficult or wildly incompatible between ghc versions at that point, though |
| 2023-02-25 16:31:08 +0100 | <eldritchcookie[m> | quickchecksallProperties is defined as... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/343b3015b91dfc56754b2a6afe10f6587938…>) |
| 2023-02-25 16:32:31 +0100 | <geekosaur> | yes, but it's parsing to get names and then querying the AST for their definitions |
| 2023-02-25 16:32:44 +0100 | <geekosaur> | you should be able to walk the AST if you can query it |
| 2023-02-25 16:34:27 +0100 | <eldritchcookie[m> | yeah but GHC obvously has the names of all the exports of a module i should just have to ask not reparse again |
| 2023-02-25 16:34:39 +0100 | <geekosaur> | exactly |
| 2023-02-25 16:35:00 +0100 | <geekosaur> | which is why I suspect there's an additional complication somewhere |
| 2023-02-25 16:36:17 +0100 | <geekosaur> | like, I know there was a major chaneg when the AST was redone with TTG |
| 2023-02-25 16:36:45 +0100 | <geekosaur> | but that should be long since over and you shouldn't need to worry about pre-TTG versions of ghc |
| 2023-02-25 16:37:57 +0100 | <geekosaur> | anothyer big change when everything became Located bvut again you shouldn't need to worry at this point |
| 2023-02-25 16:38:17 +0100 | <geekosaur> | so I womder what else might be changing between versions to make this hard |
| 2023-02-25 16:39:12 +0100 | ubert | (~Thunderbi@p548c8a3b.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2023-02-25 16:40:11 +0100 | <eldritchcookie[m> | wait qReifyModule is defined as |
| 2023-02-25 16:40:11 +0100 | <eldritchcookie[m> | ```haskell |
| 2023-02-25 16:40:11 +0100 | <eldritchcookie[m> | instance Quasi Q where |
| 2023-02-25 16:40:30 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-02-25 16:40:52 +0100 | <eldritchcookie[m> | qReifyModule = reifyModule |
| 2023-02-25 16:41:15 +0100 | <eldritchcookie[m> | reifyModule :: Module -> Q ModuleInfo |
| 2023-02-25 16:41:15 +0100 | <eldritchcookie[m> | reifyModule m = Q (qReifyModule m) |
| 2023-02-25 16:41:22 +0100 | <eldritchcookie[m> | the hell? |
| 2023-02-25 16:41:44 +0100 | ubert | (~Thunderbi@p548c9fde.dip0.t-ipconnect.de) |
| 2023-02-25 16:41:47 +0100 | <eldritchcookie[m> | is reifyModule a Primop ? |
| 2023-02-25 16:42:36 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-02-25 16:45:57 +0100 | ddellacosta | (~ddellacos@146.70.165.159) |
| 2023-02-25 16:47:55 +0100 | <geekosaur> | no, I think you're confusing a top level definition that came from the compiler guts with an instance definition for Q |
| 2023-02-25 16:49:01 +0100 | <geekosaur> | also it has occurred to me that QuickCheck is old enough to have lived through all the AST changes I mentioned, so they went with something simple and dependable, then everyone else copied them because it worked |
| 2023-02-25 16:49:31 +0100 | <geekosaur> | and for anything more direct you'll have to (a) ask in #ghc (b) hope the AST doesn't go through another major change |
| 2023-02-25 16:52:20 +0100 | CiaoSen | (~Jura@p200300c9570460002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2023-02-25 16:52:44 +0100 | accord | (uid568320@id-568320.hampstead.irccloud.com) |
| 2023-02-25 16:53:02 +0100 | <geekosaur> | iirc there are two Q instances: one for IO, one for pure. some things are stubbed out in the pure version |
| 2023-02-25 16:53:57 +0100 | <ph88> | Could anyone help me to figure out why my program hangs when i call `show` on a value ? https://bpa.st/PFBFQ |
| 2023-02-25 16:54:46 +0100 | bgs | (~bgs@212.85.160.171) |
| 2023-02-25 16:55:12 +0100 | <ph88> | actually let me make a new paste .. |
| 2023-02-25 16:55:34 +0100 | CiaoSen | (~Jura@p200300c9570460002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Client Quit) |
| 2023-02-25 16:55:34 +0100 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
| 2023-02-25 16:55:42 +0100 | <geekosaur> | missing Connection definition |
| 2023-02-25 16:55:47 +0100 | <geekosaur> | can't tell |
| 2023-02-25 16:55:49 +0100 | gentauro | (~gentauro@user/gentauro) |
| 2023-02-25 16:55:57 +0100 | <geekosaur> | everything else about pipe looks okay |
| 2023-02-25 16:56:46 +0100 | <eldritchcookie[m> | the ConnectionWithTimeout doesn't call show on Connection so it shouldn't matter |
| 2023-02-25 16:56:56 +0100 | <ph88> | geekosaur, thanks for looking, i'll try to debug it as far as i can. Maybe in a bit i have a better example |
| 2023-02-25 16:57:26 +0100 | <hpc> | what happens if you show only specific parts of the value? |
| 2023-02-25 16:57:38 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2023-02-25 16:58:18 +0100 | <hpc> | also what happens if you don't show, but just evaluate? |
| 2023-02-25 16:59:17 +0100 | mima | (~mmh@ppp-212-114-180-20.dynamic.mnet-online.de) () |
| 2023-02-25 17:01:39 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-02-25 17:02:50 +0100 | azure_vermilion | (~azure_ver@82-132-233-212.dab.02.net) (Ping timeout: 260 seconds) |
| 2023-02-25 17:02:59 +0100 | <segfaultfizzbuzz> | i was considering trying to learn to understand assembly so i looked up the riscv specification expecting it to be simple, and my eyes were watering after a few pages. is there a simple and complete ISA which is worth learning? i was eyeing the 6502... |
| 2023-02-25 17:03:01 +0100 | azure_vermilion | (~azure_ver@82-132-232-181.dab.02.net) |
| 2023-02-25 17:03:57 +0100 | <geekosaur> | z80? |
| 2023-02-25 17:04:32 +0100 | <geekosaur> | 6502 is simple-ish but a bit strange, like various things assuming page 2 ($0200-$02ff) is stack |
| 2023-02-25 17:04:52 +0100 | <hpc> | the ben eater youtube channel makes a computer out of breadboard stuff, and it includes making its own instruction set |
| 2023-02-25 17:04:58 +0100 | <geekosaur> | (and god help you if you overflow it) |
| 2023-02-25 17:05:06 +0100 | <segfaultfizzbuzz> | yeah i meant to clarify, i would be looking for "simple and sufficiently modern",... i don't want to chase ideas which are no longer relevant |
| 2023-02-25 17:05:08 +0100 | <hpc> | it's beyond minimal, but you get to see all the logic that goes into it |
| 2023-02-25 17:05:21 +0100 | <hpc> | and how it turns into microcode, how that microcode gets executed, etc |
| 2023-02-25 17:05:35 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-02-25 17:05:57 +0100 | <geekosaur> | z80's still pretty relevant, it's used for embedded stuff still |
| 2023-02-25 17:06:17 +0100 | <geekosaur> | and it's modern enough that x86 took stuff from it |
| 2023-02-25 17:06:40 +0100 | <segfaultfizzbuzz> | ok i guess i will look at the z80 then |
| 2023-02-25 17:06:50 +0100 | <segfaultfizzbuzz> | hopefully the ISA is less than 50 pages...? |
| 2023-02-25 17:06:57 +0100 | <geekosaur> | yes |
| 2023-02-25 17:07:22 +0100 | <segfaultfizzbuzz> | i don't understand how people can keep these multi-hundred page documents in their heads, let alone understand how stuff on one page interacts with stuff on another |
| 2023-02-25 17:07:41 +0100 | <geekosaur> | it's even smaller if you get a reference that doesn't split out instructions that are really the same thing but with register bits split out for some weird reason like the first z80 asm reference I owned |
| 2023-02-25 17:08:17 +0100 | <ph88> | geekosaur, i found it eventually ... i created bottom by calling functions recursively in ReaderT implementation. Thanks for having a look on the paste |
| 2023-02-25 17:08:25 +0100 | <segfaultfizzbuzz> | i guess there is no toy minimalist ISA? |
| 2023-02-25 17:11:30 +0100 | CiaoSen | (~Jura@p200300c9570460002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2023-02-25 17:13:53 +0100 | <segfaultfizzbuzz> | haha this advertisement for the z80 says it has a "instruction speed of 1.6 microseconds" |
| 2023-02-25 17:14:50 +0100 | <geekosaur> | I didn't say it was fast |
| 2023-02-25 17:15:15 +0100 | <geekosaur> | although I think there are 4MHz versions these days (the original was 1MHz) |
| 2023-02-25 17:15:35 +0100 | <segfaultfizzbuzz> | i am looking at the registers, and this has an 8 bit accumulator and a 16 bit accumulator... this is already needlessly complicated |
| 2023-02-25 17:15:44 +0100 | <geekosaur> | the simple architectures are all dead |
| 2023-02-25 17:16:17 +0100 | <segfaultfizzbuzz> | so if i try to simplify the registers here: https://en.wikipedia.org/wiki/Zilog_Z80 |
| 2023-02-25 17:16:23 +0100 | <geekosaur> | AF BC DE HL |
| 2023-02-25 17:17:07 +0100 | <darkling> | If you're looking for something simple, ARM2/ARM3 is great. |
| 2023-02-25 17:18:14 +0100 | <darkling> | RiscOS (available for the Raspberry Pi) even has an assembler built into its BASIC. |
| 2023-02-25 17:20:35 +0100 | <segfaultfizzbuzz> | do the z80 registers define the complete state of the CPU? or is there state elsewhere? |
| 2023-02-25 17:21:19 +0100 | <geekosaur> | complete state if you include the flags register which is paired with the 8-bit accumulator |
| 2023-02-25 17:21:20 +0100 | <darkling> | There's other state, but that's not generally accessible or even particularly helpful. |
| 2023-02-25 17:21:45 +0100 | <geekosaur> | (there's a PUSH AF instruction) |
| 2023-02-25 17:21:56 +0100 | <segfaultfizzbuzz> | geekosaur: yeah if you see the wikipedia entry, the "status" register is listed, which has the CPU flags |
| 2023-02-25 17:22:28 +0100 | <geekosaur> | I'm not looking at wikipedia, I'm remembering form when I spent a couple years doing z80 assembly |
| 2023-02-25 17:22:48 +0100 | <darkling> | There's also IX and IY for the offset instructions, and a purely internal I that holds the current instructions. |
| 2023-02-25 17:23:06 +0100 | <segfaultfizzbuzz> | can i ignore the distinction between main and alternate registers? |
| 2023-02-25 17:23:08 +0100 | ell | (~ellie@user/ellie) (Quit: Ping timeout (120 seconds)) |
| 2023-02-25 17:23:13 +0100 | <geekosaur> | z80 is an upgraded Intel 8080 that made it a true 8/16 bit CPU instead of an 8-bit CPU with a glorified 16 bit register |
| 2023-02-25 17:23:24 +0100 | <darkling> | Oh, and a complete set of shadow registers that you can swap for the current ones with the EXX instruction. |
| 2023-02-25 17:23:45 +0100 | <segfaultfizzbuzz> | darkling: ok so wikipedia doesn't list these "shadow" registers then? |
| 2023-02-25 17:23:59 +0100 | <segfaultfizzbuzz> | darkling: oh the "alternate" registers are the "shadow" registers |
| 2023-02-25 17:24:10 +0100 | <geekosaur> | that's the "alternate" regs you were talking about |
| 2023-02-25 17:24:13 +0100 | <darkling> | Yaeh, I 've rpobably used the wrong name for them. |
| 2023-02-25 17:24:27 +0100 | <darkling> | Hmm. My typing's terrible today. |
| 2023-02-25 17:25:34 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-02-25 17:25:51 +0100 | <segfaultfizzbuzz> | i don't think i understand the index registers |
| 2023-02-25 17:26:43 +0100 | <segfaultfizzbuzz> | i guess the instructions, perhaps for physical logic design reasons, restrict which registers operations can read from or write to? |
| 2023-02-25 17:27:05 +0100 | <darkling> | Where you can do an operation with (HL) (i.e. read data from the address pointed to by HL), you can also do that operation with (IX+n) or (IY+n) |
| 2023-02-25 17:27:13 +0100 | <segfaultfizzbuzz> | "The index registers, IX and IY, were intended as flexible 16-bit pointers, enhancing the ability to manipulate memory, stack frames and data structures." |
| 2023-02-25 17:27:34 +0100 | <darkling> | They're a lot slower, because it's got to read the n value from the byte after the opcode, and there's a prefix, and it's got to do the addition. |
| 2023-02-25 17:28:37 +0100 | <darkling> | Imagine you've got a data structure with several elements in it. You can point to the start of the structure with IX, and then access all the elements of the structure as (IX+n), without having to manually add and subtract on the pointer. |
| 2023-02-25 17:28:43 +0100 | <int-e> | segfaultfizzbuzz: You could use them as the base of a C struct, with direct addressing mode for fields (within ~128 bytes either way) |
| 2023-02-25 17:29:38 +0100 | <segfaultfizzbuzz> | so IX/IY about not having to do lots of loads and adds, basically--increase memory locality |
| 2023-02-25 17:29:52 +0100 | <segfaultfizzbuzz> | but it is an optimization rather than something "fundamental" |
| 2023-02-25 17:30:01 +0100 | <int-e> | nobody cared about memory locality at that time |
| 2023-02-25 17:30:08 +0100 | <segfaultfizzbuzz> | haha ok |
| 2023-02-25 17:30:10 +0100 | <int-e> | there were no caches |
| 2023-02-25 17:30:46 +0100 | <darkling> | It's not even much of an optimisation -- the instructions are large (3-4 bytes, IIRC) and slow (21 clock cycles). |
| 2023-02-25 17:30:49 +0100 | <int-e> | But RAM was also rather fast if you measured access speed in clock cycles. |
| 2023-02-25 17:30:58 +0100 | <segfaultfizzbuzz> | https://clrhome.org/table/ ay this is too much |
| 2023-02-25 17:31:22 +0100 | <darkling> | To be fair, that's writing out all of the combinations of all the instructions. |
| 2023-02-25 17:31:33 +0100 | <int-e> | Not 100s of cycles to access RAM when all caches are missed which is the reality now. |
| 2023-02-25 17:31:42 +0100 | <segfaultfizzbuzz> | are (opcode, register) pairs restricted? |
| 2023-02-25 17:31:45 +0100 | <darkling> | It's a bit simpler if you just look at the types of instructions (but still pretty complicated). |
| 2023-02-25 17:32:15 +0100 | <darkling> | This is a reasonable reference: https://wiki.specnext.dev/Extended_Z80_instruction_set |
| 2023-02-25 17:32:45 +0100 | <darkling> | (It's got some extra instructions that the original Z80 never had, but those are noted) |
| 2023-02-25 17:32:46 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:c1fe:7ebc:3299:29d5) (Ping timeout: 246 seconds) |
| 2023-02-25 17:33:46 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2023-02-25 17:33:48 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17) |
| 2023-02-25 17:33:59 +0100 | <int-e> | so plenty of special purpose registers |
| 2023-02-25 17:34:04 +0100 | <segfaultfizzbuzz> | does the z80 "reduce" the state every cycle? that is to say, can an instruction from the past have a delayed effect? |
| 2023-02-25 17:34:20 +0100 | <geekosaur> | nope |
| 2023-02-25 17:34:39 +0100 | <geekosaur> | it predates caches, delay slots, and the like |
| 2023-02-25 17:34:40 +0100 | <segfaultfizzbuzz> | so the z80 state at t+1 is strictly determined by the opcode, and there is only one opcode |
| 2023-02-25 17:34:41 +0100 | <int-e> | maybe, with external hardware ;) |
| 2023-02-25 17:35:39 +0100 | <darkling> | I'd still recommend ARM instead of Z80. For example: https://www.chiark.greenend.org.uk/~theom/riscos/docs/ARM3-datasheet_ARM-Family-Data-Manual-VLSI.pdf |
| 2023-02-25 17:35:55 +0100 | vandita | (~vandit@80-95-85-49.pool.digikabel.hu) (Ping timeout: 268 seconds) |
| 2023-02-25 17:36:10 +0100 | <segfaultfizzbuzz> | so i am looking at the LD part of this specnext website--i see things like LD HL nn, LD IXY nn, etc-- so this means that there are restrictions on how the LD instruction can pair with registers (and more generally this applies to other opcodes as well)? |
| 2023-02-25 17:36:11 +0100 | <darkling> | The list of instructions is on page 1-11, and the full description of the instructions is from 3-13 onwards. |
| 2023-02-25 17:36:41 +0100 | <darkling> | (Up to 3-43) |
| 2023-02-25 17:37:13 +0100 | <darkling> | The rest you don't really need to know. |
| 2023-02-25 17:37:29 +0100 | vandita | (~vandit@178.164.206.90) |
| 2023-02-25 17:37:55 +0100 | <darkling> | It's a much more orthogonal design than the Z80, so you don't need to worry about restrictions on which registers can be used together in which instructions. |
| 2023-02-25 17:38:21 +0100 | <darkling> | (Having 32 bits per instruction makes it much easier to do that than the Z80's 8 bits per instruction). |
| 2023-02-25 17:38:39 +0100 | <geekosaur> | yeh, I didn't claim Z80 was well designed. was better than the 8080 though |
| 2023-02-25 17:38:45 +0100 | <int-e> | segfaultfizzbuzz: Yes there are some restrictions like that. Though in this case, there's also an instruction for loading BC/DE/HL/SP; the difference is that the IXY one is slower. |
| 2023-02-25 17:38:46 +0100 | <darkling> | :) |
| 2023-02-25 17:39:14 +0100 | <geekosaur> | then the 8085 stole stuff from it, then the 8086/8088 stole more, but still not really orthogonal (and still not enough registers…) |
| 2023-02-25 17:40:38 +0100 | <int-e> | I think orthogonality only really took root when we started using compilers for peformance critical code. |
| 2023-02-25 17:40:51 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 255 seconds) |
| 2023-02-25 17:41:00 +0100 | <darkling> | I think the 6502 ISA was fairly nicely orthogonal. I don't know a huge amount about it, though. |
| 2023-02-25 17:41:02 +0100 | <int-e> | Because register allocation is hard enough even when they're all interchangeable. |
| 2023-02-25 17:41:32 +0100 | <int-e> | I may be looking at this through an x86 lens though. |
| 2023-02-25 17:41:43 +0100 | <geekosaur> | there was little to know about it. A, X, Y regs (and a stack pointer that was 8 bits because the top bits were wired to $02) |
| 2023-02-25 17:42:17 +0100 | <geekosaur> | pages 0, 1, 2 were special (although I forget was special about $01 now) |
| 2023-02-25 17:43:10 +0100 | <geekosaur> | oh, and X and Y weren't very orthogonal really, either to A or each other |
| 2023-02-25 17:43:25 +0100 | <geekosaur> | weirdass addressing modes |
| 2023-02-25 17:44:07 +0100 | <darkling> | Wasn't there an addressing mode that allowed you treat the first 256 bytes of RAM effectively as registers? |
| 2023-02-25 17:44:09 +0100 | <geekosaur> | maybe you're thinking 6800 (A, B, X)? |
| 2023-02-25 17:44:37 +0100 | <darkling> | No, I've never looked at the 6800/680x0 family. |
| 2023-02-25 17:45:50 +0100 | <darkling> | Mostly old ARMs and Z80 and a little bit of x86, and I've read some docs on Connection Machines, the Transputer, and the PDP8. |
| 2023-02-25 17:46:02 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-02-25 17:46:32 +0100 | <segfaultfizzbuzz> | darkling: i think here i would ask again about the full state of the CPU--i suppose this is an ARM2 cpu? |
| 2023-02-25 17:46:46 +0100 | <geekosaur> | "In order to make up somewhat for the lack of registers, the 6502 included a zero-page addressing mode that uses one address byte in the instruction instead of the two needed to address the full 64 KB of memory. This provides fast access to the first 256 bytes of RAM by using shorter instructions." |
| 2023-02-25 17:46:47 +0100 | <darkling> | The thing I linked to was the ARM3. Very similar, though. |
| 2023-02-25 17:46:51 +0100 | <segfaultfizzbuzz> | so R0 through R15 define the full state? |
| 2023-02-25 17:47:00 +0100 | <darkling> | segfaultfizzbuzz: Yes. |
| 2023-02-25 17:47:06 +0100 | <geekosaur> | like I said, first 3 pages were special |
| 2023-02-25 17:47:07 +0100 | <darkling> | geekosaur: That's the thing I was thinking of. |
| 2023-02-25 17:47:22 +0100 | <geekosaur> | I think $01 was used for indexing? |
| 2023-02-25 17:47:25 +0100 | <int-e> | geekosaur: Looks like page 1 is/was for stack. page 2 is for memory-mapped IO? |
| 2023-02-25 17:47:39 +0100 | <geekosaur> | mm, maybe I'm misremembering |
| 2023-02-25 17:47:40 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-02-25 17:48:00 +0100 | <geekosaur> | yeh, looks like $01 not $02 |
| 2023-02-25 17:48:04 +0100 | <segfaultfizzbuzz> | darkling: and again like the z80, cpu state at clock t+1 is determined entirely by the opcode from clock t ? |
| 2023-02-25 17:48:12 +0100 | kimiamania | (~65804703@user/kimiamania) (Quit: Ping timeout (120 seconds)) |
| 2023-02-25 17:48:29 +0100 | <darkling> | Yes. |
| 2023-02-25 17:49:13 +0100 | <segfaultfizzbuzz> | lol "high level constructs like for, while, and proc" |
| 2023-02-25 17:49:25 +0100 | econo | (uid147250@user/econo) |
| 2023-02-25 17:49:35 +0100 | <int-e> | Well, there's external factors... RAM (if you're reading from memory) or interrupts... |
| 2023-02-25 17:49:56 +0100 | <int-e> | segfaultfizzbuzz: what's so funny about that |
| 2023-02-25 17:50:01 +0100 | <int-e> | :) |
| 2023-02-25 17:50:36 +0100 | <geekosaur> | welcome to 1970 |
| 2023-02-25 17:50:50 +0100 | kimiamania | (~65804703@user/kimiamania) |
| 2023-02-25 17:51:08 +0100 | <segfaultfizzbuzz> | int-e: but RAM can only touch CPU state via the load instruction, i think (?) |
| 2023-02-25 17:51:23 +0100 | <segfaultfizzbuzz> | interrupts i definitely do not understand |
| 2023-02-25 17:52:09 +0100 | <darkling> | Interrupts are basically "something outside the CPU wants attention". There's usually a special line on the hardware that you change to tell the CPU about that, |
| 2023-02-25 17:52:37 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) |
| 2023-02-25 17:53:02 +0100 | <darkling> | and then it'll usually do something like push the current PC onto the stack and jump to a special location, where you can put code that works out what the request was and what to do about it. |
| 2023-02-25 17:53:15 +0100 | <int-e> | And the CPU will save a bit of state (the instruction pointer as the bare minimum) and transfer control to an interrupt service routine (often at a fixed address those days) |
| 2023-02-25 17:53:43 +0100 | <int-e> | . o O ( stereo ) |
| 2023-02-25 17:53:47 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-02-25 17:53:48 +0100 | <darkling> | On the early ARMs, it replaced about half the registers with a special set, put the original PC into LR and jumped to 0x08 (I think). |
| 2023-02-25 17:54:40 +0100 | <int-e> | oh yeah you can have a shadow register set just for interrupt handling |
| 2023-02-25 17:54:45 +0100 | <int-e> | as a way of preserving state |
| 2023-02-25 17:54:50 +0100 | <darkling> | Then you return from IRQ mode by copying LR back to PC (which on the ARM 2 & ARM 3 would also set the CPU flags, changing the mode from IRQ back to the original USR) |
| 2023-02-25 17:56:08 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2023-02-25 17:56:34 +0100 | <darkling> | Most of the time, you don't need to know about interrupts, unless you're writing an operating system. |
| 2023-02-25 17:56:57 +0100 | <darkling> | (Or something that interacts with the hardware outside the CPU/RAM system) |
| 2023-02-25 17:57:15 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) (Ping timeout: 248 seconds) |
| 2023-02-25 17:58:00 +0100 | <segfaultfizzbuzz> | location always refers to RAM, and special location means a specific RAM address? |
| 2023-02-25 17:58:40 +0100 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 2023-02-25 17:58:46 +0100 | <darkling> | Well, a specific instruction, which on most modern machines is RAM, yes. |
| 2023-02-25 17:59:06 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-02-25 17:59:52 +0100 | <darkling> | On the ZX Spectrum, for example, the first 8KiB of the address space was ROM, and the rest (8KiB or 48 KiB, depending onthe machine) was RAM. |
| 2023-02-25 18:01:49 +0100 | nattiestnate | (~nate@202.138.250.13) (Quit: WeeChat 3.8) |
| 2023-02-25 18:02:36 +0100 | <darkling> | On the Acorn Archimedes (ARM-based), the ROM with the OS in it was mapped into the address space a bit higher, and the first page of address space was RAM (usually full of interrupt-handling code) |
| 2023-02-25 18:03:40 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 268 seconds) |
| 2023-02-25 18:03:46 +0100 | zephyr__ | (~irfan@106.214.197.187) (Quit: leaving) |
| 2023-02-25 18:07:38 +0100 | zmt01 | (~zmt00@user/zmt00) |
| 2023-02-25 18:09:20 +0100 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 260 seconds) |
| 2023-02-25 18:09:36 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-02-25 18:11:03 +0100 | <cdsmith> | Anyone have a quick example of using GHC Generics with a container (of kind Type -> Type)? |
| 2023-02-25 18:12:59 +0100 | morrow | (~morrow@2a10:8012:11:e637:5553:520d:7730:7240) |
| 2023-02-25 18:14:16 +0100 | <ph88> | when i Show a bytestring how should i interpret something like this ? "\179\DLE\208x" are those escaping backslashes ? |
| 2023-02-25 18:15:41 +0100 | <[exa]> | yeah these are likely non-ascii bytes |
| 2023-02-25 18:16:10 +0100 | <[exa]> | if you're sure the bytestring should contain eg. utf8, it's best to decode it and show as normal string/text |
| 2023-02-25 18:17:59 +0100 | <ph88> | [exa], it's actually binary data ... perhaps there is a handy function to encode it to hex ? 00 FF 01 etc |
| 2023-02-25 18:18:03 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-02-25 18:19:34 +0100 | <monochrom> | You can unpack to get [Word8]. Then its show gives you decimal numbers. |
| 2023-02-25 18:20:22 +0100 | <[exa]> | `base16` package could help too |
| 2023-02-25 18:21:41 +0100 | <[exa]> | ah wait there's https://hackage.haskell.org/package/bytestring-0.11.4.0/docs/Data-ByteString-Builder.html#v:byteSt… |
| 2023-02-25 18:23:10 +0100 | zmt00 | (~zmt00@user/zmt00) |
| 2023-02-25 18:25:18 +0100 | zmt01 | (~zmt00@user/zmt00) (Ping timeout: 255 seconds) |
| 2023-02-25 18:25:42 +0100 | CiaoSen | (~Jura@p200300c9570460002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2023-02-25 18:26:05 +0100 | zmt00 | (~zmt00@user/zmt00) (Remote host closed the connection) |
| 2023-02-25 18:35:51 +0100 | caryhartline | (~caryhartl@2603:8080:6c00:6c01:7463:7a75:4b5e:bddd) |
| 2023-02-25 18:36:21 +0100 | CiaoSen | (~Jura@2003:c9:5704:6000:2a3a:4dff:fe84:dbd5) |
| 2023-02-25 18:39:27 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-02-25 18:44:15 +0100 | coot | (~coot@213.134.171.3) |
| 2023-02-25 18:44:36 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2023-02-25 18:51:12 +0100 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (Quit: The Lounge - https://thelounge.chat) |
| 2023-02-25 18:55:06 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 255 seconds) |
| 2023-02-25 18:56:53 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2023-02-25 19:08:29 +0100 | ddellacosta | (~ddellacos@146.70.165.159) (Ping timeout: 255 seconds) |
| 2023-02-25 19:11:16 +0100 | gurkenglas | (~gurkengla@dynamic-046-114-176-132.46.114.pool.telefonica.de) |
| 2023-02-25 19:12:23 +0100 | accord | (uid568320@id-568320.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-02-25 19:14:29 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2023-02-25 19:19:53 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) |
| 2023-02-25 19:22:05 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2023-02-25 19:22:33 +0100 | CiaoSen | (~Jura@2003:c9:5704:6000:2a3a:4dff:fe84:dbd5) (Ping timeout: 252 seconds) |
| 2023-02-25 19:30:38 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-02-25 19:30:51 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-02-25 19:31:24 +0100 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2023-02-25 19:36:45 +0100 | caryhartline | (~caryhartl@2603:8080:6c00:6c01:7463:7a75:4b5e:bddd) (Quit: caryhartline) |
| 2023-02-25 19:40:13 +0100 | morrow | (~morrow@2a10:8012:11:e637:5553:520d:7730:7240) (Ping timeout: 260 seconds) |
| 2023-02-25 19:44:10 +0100 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
| 2023-02-25 19:45:07 +0100 | fr33domlover | (~fr33domlo@towards.vision) |
| 2023-02-25 19:47:43 +0100 | biberu | (~biberu@user/biberu) |
| 2023-02-25 19:49:07 +0100 | telser_ | (~quassel@user/telser) (Ping timeout: 268 seconds) |
| 2023-02-25 19:50:01 +0100 | telser | (~quassel@user/telser) |
| 2023-02-25 19:53:07 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 246 seconds) |
| 2023-02-25 19:57:02 +0100 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-02-25 19:58:07 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-02-25 19:59:13 +0100 | jtza8 | (~user@165.255.63.244) (Remote host closed the connection) |
| 2023-02-25 19:59:32 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) (Remote host closed the connection) |
| 2023-02-25 20:00:04 +0100 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 2023-02-25 20:06:46 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-02-25 20:07:31 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-02-25 20:08:47 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-02-25 20:11:08 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 255 seconds) |
| 2023-02-25 20:11:16 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:90d2:49e4:6637:422e) |
| 2023-02-25 20:11:57 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-02-25 20:11:59 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2023-02-25 20:12:55 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-02-25 20:14:53 +0100 | accord | (uid568320@id-568320.hampstead.irccloud.com) |
| 2023-02-25 20:17:15 +0100 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 2023-02-25 20:18:40 +0100 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 2023-02-25 20:21:56 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2023-02-25 20:24:32 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-02-25 20:24:59 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 255 seconds) |
| 2023-02-25 20:28:03 +0100 | Guest2517 | (~Guest25@103.15.228.66) (Ping timeout: 260 seconds) |
| 2023-02-25 20:31:14 +0100 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) |
| 2023-02-25 20:31:24 +0100 | ddellacosta | (~ddellacos@146.70.171.100) |
| 2023-02-25 20:36:01 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-02-25 20:41:46 +0100 | mei | (~mei@user/mei) (Quit: mei) |
| 2023-02-25 20:43:46 +0100 | mei | (~mei@user/mei) |
| 2023-02-25 20:52:47 +0100 | wroathe | (~wroathe@50.205.197.50) |
| 2023-02-25 20:52:48 +0100 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2023-02-25 20:52:48 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2023-02-25 21:00:19 +0100 | emmanuelux_ | (~emmanuelu@user/emmanuelux) |
| 2023-02-25 21:00:35 +0100 | CiaoSen | (~Jura@p200300c9570460002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2023-02-25 21:03:23 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Ping timeout: 252 seconds) |
| 2023-02-25 21:21:21 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-02-25 21:22:28 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-02-25 21:23:26 +0100 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2023-02-25 21:28:18 +0100 | <Artem[m]> | Is there a way to get a list of identifiers imported by the current module from some other one? I want to clean up imports a bit, and many modules in the project import Foo while Foo is simply a bunch of reexports from Foo.Bar, Foo.Baz, etc. I wont to replace imports of Foo to more fine grained imports of Foo.Bar etc. For that I need to know what Foo-identifiers are in use, then I can see which of Foo.Bars i need to import |
| 2023-02-25 21:28:18 +0100 | <Artem[m]> | instead of Foo. |
| 2023-02-25 21:31:48 +0100 | <geekosaur> | if you don't have an import list and it's not qualified then -Wmissing-import-lists will tell you all the identifiers so imported |
| 2023-02-25 21:32:13 +0100 | <geekosaur> | I don't think you can get it if you have it imported qualified. (the opposite case is an error) |
| 2023-02-25 21:34:02 +0100 | <c_wraith> | should HLS have that sort of functionality? It's clearly related to jump-to-definition |
| 2023-02-25 21:34:17 +0100 | <geekosaur> | HLS does and the warning I cited is where it gets it |
| 2023-02-25 21:36:40 +0100 | <geekosaur> | hm, I guess "error" is overspeaking a bit, no qualification and import list means the import list must be complete or you get undefined symbol errors |
| 2023-02-25 21:36:49 +0100 | <mauke> | can't you just remove the import and see which identifiers become errors? |
| 2023-02-25 21:37:00 +0100 | <geekosaur> | or that, yes |
| 2023-02-25 21:38:46 +0100 | <geekosaur> | what you can't tell is which of the imports in the other module it came from, because that information is completely lost when re-exported |
| 2023-02-25 21:39:31 +0100 | <mauke> | you can't have everything. (where would you put it?) |
| 2023-02-25 21:39:35 +0100 | <geekosaur> | (some of that is because it's difficult to get the linker to handle it, but also consider how `import … as X` interacts) |
| 2023-02-25 21:41:09 +0100 | Lycurgus | (~juan@user/Lycurgus) (Ping timeout: 255 seconds) |
| 2023-02-25 21:41:21 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-02-25 21:42:38 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-02-25 21:44:18 +0100 | wroathe | (~wroathe@user/wroathe) (Quit: leaving) |
| 2023-02-25 21:59:51 +0100 | Monster196883 | (~hp@2409:4064:4e98:40db:c950:2a30:5b3c:75a3) |
| 2023-02-25 22:04:53 +0100 | Guest69 | (~Guest69@109.237.26.33) |
| 2023-02-25 22:05:11 +0100 | <Artem[m]> | brilliant, thanks everyone for the suggestions |
| 2023-02-25 22:05:43 +0100 | Guest69 | (~Guest69@109.237.26.33) (Client Quit) |
| 2023-02-25 22:05:53 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2023-02-25 22:06:12 +0100 | <Artem[m]> | yeah, attributing those identifiers to the more specific modules was a bonus point, but I didn't count on it... |
| 2023-02-25 22:08:34 +0100 | <Artem[m]> | and yes, I'm told HLS has something called "refine imports" that does exactly that. I wish I could use HLS superpowers in scripts... |
| 2023-02-25 22:11:17 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-02-25 22:20:25 +0100 | cstml | (~cstml@cpc151611-shef16-2-0-cust313.17-1.cable.virginm.net) |
| 2023-02-25 22:26:28 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 252 seconds) |
| 2023-02-25 22:27:38 +0100 | mechap | (~mechap@user/mechap) |
| 2023-02-25 22:31:15 +0100 | Monster196883 | (~hp@2409:4064:4e98:40db:c950:2a30:5b3c:75a3) (Ping timeout: 260 seconds) |
| 2023-02-25 22:31:59 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-02-25 22:33:04 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 252 seconds) |
| 2023-02-25 22:33:59 +0100 | mechap | (~mechap@user/mechap) |
| 2023-02-25 22:34:51 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-02-25 22:39:17 +0100 | dcoutts_ | (~duncan@cpc69403-oxfd27-2-0-cust285.4-3.cable.virginm.net) |
| 2023-02-25 22:39:32 +0100 | cheater_ | (~Username@user/cheater) |
| 2023-02-25 22:42:14 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
| 2023-02-25 22:42:18 +0100 | cheater_ | cheater |
| 2023-02-25 22:48:32 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 255 seconds) |
| 2023-02-25 22:50:33 +0100 | cstml | (~cstml@cpc151611-shef16-2-0-cust313.17-1.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2023-02-25 22:51:19 +0100 | trev | (~trev@user/trev) (Remote host closed the connection) |
| 2023-02-25 22:51:29 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-02-25 22:55:53 +0100 | <sm> | me too |
| 2023-02-25 22:57:35 +0100 | <segfaultfizzbuzz> | if i have a pure function which maps say, 8 bytes to 8 bytes, is it true that such a function can require more than 8 bytes of memory (during execution, if it is allowed to mutate the input memory), or can the function always be restricted to never use more than the input? |
| 2023-02-25 22:58:29 +0100 | bgs | (~bgs@212.85.160.171) (Remote host closed the connection) |
| 2023-02-25 22:58:51 +0100 | <segfaultfizzbuzz> | i feel like *requiring more than 8 bytes |
| 2023-02-25 22:59:13 +0100 | <segfaultfizzbuzz> | during the intermediary computation would violate the pidgeonhole principle |
| 2023-02-25 22:59:37 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-02-25 23:02:29 +0100 | <mauke> | does code count as memory? |
| 2023-02-25 23:02:36 +0100 | <segfaultfizzbuzz> | no code is free |
| 2023-02-25 23:03:09 +0100 | <segfaultfizzbuzz> | and it's pure so there is no IO or other weird stuff |
| 2023-02-25 23:03:39 +0100 | <mauke> | if input == 0 then ... else if input == 1 then ... else if input == 2 then ... |
| 2023-02-25 23:03:54 +0100 | manwithluck | (~manwithlu@194.177.28.192) (Remote host closed the connection) |
| 2023-02-25 23:05:20 +0100 | <segfaultfizzbuzz> | ay one day i will write a formal definition of a "non-intrinsic pathological counterexample"... so in this case, |
| 2023-02-25 23:06:06 +0100 | <segfaultfizzbuzz> | maybe i can fix the definition by saying that the code cannot be "enormous" in size, or maybe i can say that the code cannot branch |
| 2023-02-25 23:07:33 +0100 | <monochrom> | Or perhaps investigate the trade off between code size and space cost. |
| 2023-02-25 23:08:48 +0100 | <mauke> | fromEnum (x == 0) * r0 + fromEnum (x == 1) * r1 + fromEnum (x == 2) * r2 + ... |
| 2023-02-25 23:08:50 +0100 | <mauke> | branchless |
| 2023-02-25 23:11:11 +0100 | CiaoSen | (~Jura@p200300c9570460002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2023-02-25 23:11:17 +0100 | manwithluck | (~manwithlu@194.177.28.192) |
| 2023-02-25 23:11:26 +0100 | <segfaultfizzbuzz> | i think i will go with the defintion here that the function must be branch-free/always execute the same code path |
| 2023-02-25 23:11:39 +0100 | <segfaultfizzbuzz> | so you can only define a fixed sequence of operations |
| 2023-02-25 23:12:03 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Remote host closed the connection) |
| 2023-02-25 23:12:11 +0100 | <jackdk> | mauke's example qualifies |
| 2023-02-25 23:12:17 +0100 | <monochrom> | What is your model of computing anyway? Turing machines? Game of Life? |
| 2023-02-25 23:12:46 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-02-25 23:12:50 +0100 | CiaoSen | (~Jura@2003:c9:570e:9100:2a3a:4dff:fe84:dbd5) |
| 2023-02-25 23:12:52 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-02-25 23:13:05 +0100 | <monochrom> | What you think of as well-defined notions such as "branch free" are actually meaningless unless you first pick a model of computing. |
| 2023-02-25 23:13:58 +0100 | <monochrom> | For example there is no such thing as "code path" in the two models I mentioned. |
| 2023-02-25 23:15:01 +0100 | <monochrom> | This is why what I said about trade off between code size and space cost is a much more robust approach. |
| 2023-02-25 23:15:17 +0100 | kadobanana | (~mud@user/kadoban) (Quit: quit) |
| 2023-02-25 23:17:03 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
| 2023-02-25 23:18:21 +0100 | mud | (~mud@user/kadoban) |
| 2023-02-25 23:18:46 +0100 | tubogram44 | (~tubogram@user/tubogram) (Ping timeout: 246 seconds) |
| 2023-02-25 23:19:53 +0100 | abhixec | (~abhinav@c-67-169-139-16.hsd1.ca.comcast.net) (Read error: Connection reset by peer) |
| 2023-02-25 23:20:40 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 246 seconds) |
| 2023-02-25 23:20:49 +0100 | dcoutts_ | (~duncan@cpc69403-oxfd27-2-0-cust285.4-3.cable.virginm.net) (Remote host closed the connection) |
| 2023-02-25 23:21:11 +0100 | dcoutts_ | (~duncan@cpc69403-oxfd27-2-0-cust285.4-3.cable.virginm.net) |
| 2023-02-25 23:21:20 +0100 | cstml | (~cstml@cpc151611-shef16-2-0-cust313.17-1.cable.virginm.net) |
| 2023-02-25 23:21:54 +0100 | mvk | (~mvk@2607:fea8:5caa:ac00::fa57) |
| 2023-02-25 23:23:03 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-02-25 23:25:11 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-02-25 23:26:17 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-02-25 23:27:04 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-02-25 23:27:35 +0100 | manwithluck | (~manwithlu@194.177.28.192) (Quit: ZNC - https://znc.in) |
| 2023-02-25 23:27:48 +0100 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 255 seconds) |
| 2023-02-25 23:28:16 +0100 | <segfaultfizzbuzz> | hmm so i can't just have a bunch of logic gates...? it's a deterministic mapping so i don't understand what a "model of computing" would be... |
| 2023-02-25 23:28:50 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-02-25 23:29:37 +0100 | manwithluck | (~manwithlu@194.177.28.192) |
| 2023-02-25 23:32:49 +0100 | <monochrom> | Then "a bunch of logic gates" is your model of computing. |
| 2023-02-25 23:33:05 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2023-02-25 23:33:15 +0100 | azure_vermilion | (~azure_ver@82-132-232-181.dab.02.net) (Ping timeout: 246 seconds) |
| 2023-02-25 23:33:50 +0100 | azure_vermilion | (~azure_ver@82-132-234-53.dab.02.net) |
| 2023-02-25 23:33:54 +0100 | wroathe | (~wroathe@50.205.197.50) |
| 2023-02-25 23:33:54 +0100 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2023-02-25 23:33:54 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2023-02-25 23:33:58 +0100 | <monochrom> | "a bunch of logic gates" is also a straightforward translation of both of mauke's programs, one of which you [mis]labelled as "branching". |
| 2023-02-25 23:34:29 +0100 | <monochrom> | So arguably "a bunch of logic gates but it has to be branch free" is actually self-contradictory. |
| 2023-02-25 23:35:27 +0100 | manwithluck | (~manwithlu@194.177.28.192) (Ping timeout: 268 seconds) |
| 2023-02-25 23:35:38 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-02-25 23:36:00 +0100 | <monochrom> | This is why it's bad idea to do moving goalposts. |
| 2023-02-25 23:36:03 +0100 | <darkling> | But you don't get recursion or loops with linear logic, so it's a poor model of computing (but practically good enough if your function domain is finite and small enough). |
| 2023-02-25 23:36:05 +0100 | <segfaultfizzbuzz> | well if i had an addition operation, that isn't considered a branch (i don't think?) but it would use logic gates... |
| 2023-02-25 23:37:41 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2023-02-25 23:37:58 +0100 | <monochrom> | "x==0" is just a comparator (logic gates!). "if then else" is just a two-way demultiplexer (logic gates!). |
| 2023-02-25 23:39:07 +0100 | <segfaultfizzbuzz> | i think that i understand here: all we care about is the mapping, and so you may as well start off thinking about the *largest* encoding, which would be a complete table from inputs to outputs |
| 2023-02-25 23:39:18 +0100 | <segfaultfizzbuzz> | and the "model of computing" is merely a practical method for compressing or encoding that table |
| 2023-02-25 23:40:00 +0100 | <segfaultfizzbuzz> | so if extra memory beyond the 8 bytes turns out to be useful for making a more compact representation of the table, then it is useful |
| 2023-02-25 23:40:25 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-02-25 23:41:54 +0100 | <segfaultfizzbuzz> | i don't want to do moving goalposts, the issue is that my original question overlooked the fact that the code can be of arbitrary size and therefore encode a lookup table for the results |
| 2023-02-25 23:45:07 +0100 | random-jellyfish | (~random-je@user/random-jellyfish) |
| 2023-02-25 23:46:11 +0100 | <[exa]> | segfaultfizzbuzz: btw the closest distinction to your original problem that I recall are the limited turing machines, they have a nice spot in chomsky hierarchy capturing type-1 languages |
| 2023-02-25 23:46:22 +0100 | manwithluck | (~manwithlu@194.177.28.192) |
| 2023-02-25 23:46:56 +0100 | <monochrom> | Is that the one about context-sensitive languages? |
| 2023-02-25 23:47:07 +0100 | <[exa]> | yeah, with the noncontracting grammars |
| 2023-02-25 23:47:37 +0100 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 246 seconds) |
| 2023-02-25 23:47:49 +0100 | <[exa]> | ah nvm they pingtimeouted |
| 2023-02-25 23:48:29 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2023-02-25 23:50:13 +0100 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2023-02-25 23:50:46 +0100 | tan00kee | (~paul@pauloliver.dev) |
| 2023-02-25 23:50:48 +0100 | <monochrom> | I bet code size + space code >= log_2 (how many functions from 8 bytes to 8 bytes) |
| 2023-02-25 23:51:15 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-02-25 23:51:16 +0100 | <monochrom> | err s/space code/space size/ |
| 2023-02-25 23:51:30 +0100 | hnOsmium0001 | (uid453710@user/hnOsmium0001) (Quit: Connection closed for inactivity) |
| 2023-02-25 23:52:42 +0100 | manwithluck | (~manwithlu@194.177.28.192) (Ping timeout: 268 seconds) |
| 2023-02-25 23:52:55 +0100 | <[exa]> | I wouldn't like to bet there, you can encode really ugly stuff in these functions |
| 2023-02-25 23:52:56 +0100 | <monochrom> | No, that flies in the face of constant functions. |
| 2023-02-25 23:53:19 +0100 | cstml | (~cstml@cpc151611-shef16-2-0-cust313.17-1.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2023-02-25 23:54:02 +0100 | <[exa]> | like, split the 64 bits to 3 pieces, compute ackermann function on that, and return the first 64 bits |
| 2023-02-25 23:54:27 +0100 | <[exa]> | (or middle 64 bits, so that we're sufficiently evil) |
| 2023-02-25 23:56:28 +0100 | <[exa]> | with that I guess the full lookup table might be an good, economical option |
| 2023-02-25 23:57:02 +0100 | <[exa]> | *a |
| 2023-02-25 23:58:04 +0100 | Sciencentistguy9 | (~sciencent@hacksoc/ordinary-member) |
| 2023-02-25 23:58:37 +0100 | <monochrom> | The mid-square method was not a very good PRNG. But perhaps this mid-ack method is better. >:) |
| 2023-02-25 23:59:40 +0100 | <darkling> | You might need a time machine to ensure a decent throughput. :) |