| 2023-04-24 00:04:53 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2023-04-24 00:06:01 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-24 00:06:34 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2023-04-24 00:08:35 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::3) (Ping timeout: 264 seconds) |
| 2023-04-24 00:12:29 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds) |
| 2023-04-24 00:12:32 +0200 | MQ-17J | (~MQ-17J@104.28.216.165) |
| 2023-04-24 00:12:36 +0200 | MQ-17J | (~MQ-17J@104.28.216.165) (Client Quit) |
| 2023-04-24 00:13:25 +0200 | opticblast | (~Thunderbi@172.58.85.88) (Ping timeout: 240 seconds) |
| 2023-04-24 00:13:27 +0200 | MQ-17J | (~MQ-17J@104.28.216.166) |
| 2023-04-24 00:13:35 +0200 | MQ-17J | (~MQ-17J@104.28.216.166) (Client Quit) |
| 2023-04-24 00:18:42 +0200 | mcglk | (~mcglk@131.191.19.145) (Read error: Connection reset by peer) |
| 2023-04-24 00:20:18 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::3) |
| 2023-04-24 00:20:20 +0200 | michalz | (~michalz@185.246.207.217) (Remote host closed the connection) |
| 2023-04-24 00:21:12 +0200 | mcglk | (~mcglk@131.191.19.145) |
| 2023-04-24 00:22:19 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2023-04-24 00:31:40 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2023-04-24 00:36:37 +0200 | emmanuelux_ | (~emmanuelu@user/emmanuelux) (Ping timeout: 276 seconds) |
| 2023-04-24 00:45:41 +0200 | mcglk | (~mcglk@131.191.19.145) (Quit: (seeya)) |
| 2023-04-24 00:46:21 +0200 | gurkenglas | (~gurkengla@46.114.178.101) (Ping timeout: 265 seconds) |
| 2023-04-24 00:46:42 +0200 | a6a45081-2b83 | (~aditya@2600:1700:8fd0:3660::48) (Remote host closed the connection) |
| 2023-04-24 00:48:10 +0200 | gurkenglas | (~gurkengla@dynamic-089-204-139-194.89.204.139.pool.telefonica.de) |
| 2023-04-24 00:51:15 +0200 | opticblast | (~Thunderbi@172.58.85.88) |
| 2023-04-24 01:01:26 +0200 | falafel | (~falafel@2603:8000:d700:115c:12f7:bd7:ccb3:ed19) |
| 2023-04-24 01:02:19 +0200 | Me-me | (~Me-me@146.102.215.218.dyn.iprimus.net.au) |
| 2023-04-24 01:03:41 +0200 | Me-me | (~Me-me@146.102.215.218.dyn.iprimus.net.au) (Changing host) |
| 2023-04-24 01:03:41 +0200 | Me-me | (~Me-me@user/me-me) |
| 2023-04-24 01:08:07 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) (Quit: Leaving) |
| 2023-04-24 01:09:42 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2023-04-24 01:09:56 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-24 01:12:43 +0200 | mcglk | (~mcglk@131.191.19.145) |
| 2023-04-24 01:13:08 +0200 | foul_owl | (~kerry@94.140.8.139) |
| 2023-04-24 01:14:09 +0200 | ddellacosta | (~ddellacos@143.244.47.84) (Ping timeout: 255 seconds) |
| 2023-04-24 01:15:25 +0200 | acidjnk | (~acidjnk@p54ad56b7.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2023-04-24 01:18:47 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::3) (Ping timeout: 264 seconds) |
| 2023-04-24 01:26:56 +0200 | xff0x | (~xff0x@ai098135.d.east.v6connect.net) (Quit: xff0x) |
| 2023-04-24 01:29:45 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2023-04-24 01:30:08 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::3) |
| 2023-04-24 01:31:43 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::7fe) (Quit: Konversation terminated!) |
| 2023-04-24 01:31:50 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2023-04-24 01:45:42 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-24 01:45:55 +0200 | mauke_ | (~mauke@user/mauke) |
| 2023-04-24 01:47:27 +0200 | mauke | (~mauke@user/mauke) (Ping timeout: 255 seconds) |
| 2023-04-24 01:47:28 +0200 | mauke_ | mauke |
| 2023-04-24 01:47:45 +0200 | unit73e | (~emanuel@2001:818:e8dd:7c00:656:e5ff:fe72:9d36) (Remote host closed the connection) |
| 2023-04-24 01:50:25 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2023-04-24 01:51:02 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-04-24 01:53:19 +0200 | gurkenglas | (~gurkengla@dynamic-089-204-139-194.89.204.139.pool.telefonica.de) (Ping timeout: 276 seconds) |
| 2023-04-24 02:07:30 +0200 | pierrot | (~pi@user/pierrot) (Quit: ZNC 1.8.2 - http://znc.in) |
| 2023-04-24 02:07:45 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds) |
| 2023-04-24 02:09:53 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-04-24 02:10:44 +0200 | pierrot | (~pi@user/pierrot) |
| 2023-04-24 02:19:08 +0200 | xff0x | (~xff0x@2405:6580:b080:900:1d02:138:10dc:9535) |
| 2023-04-24 02:23:00 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 255 seconds) |
| 2023-04-24 02:33:39 +0200 | falafel | (~falafel@2603:8000:d700:115c:12f7:bd7:ccb3:ed19) (Ping timeout: 265 seconds) |
| 2023-04-24 02:47:59 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-24 02:51:53 +0200 | eggplantade | (~Eggplanta@104.55.37.220) |
| 2023-04-24 02:52:19 +0200 | falafel | (~falafel@2603-8000-d700-115c-bab8-bca3-28db-3e6a.res6.spectrum.com) |
| 2023-04-24 02:52:42 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds) |
| 2023-04-24 02:56:22 +0200 | eggplantade | (~Eggplanta@104.55.37.220) (Ping timeout: 265 seconds) |
| 2023-04-24 03:08:52 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-04-24 03:10:35 +0200 | falafel | (~falafel@2603-8000-d700-115c-bab8-bca3-28db-3e6a.res6.spectrum.com) (Ping timeout: 260 seconds) |
| 2023-04-24 03:10:54 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-04-24 03:16:05 +0200 | cheater | (~Username@user/cheater) (Quit: Going offline, see ya! (www.adiirc.com)) |
| 2023-04-24 03:17:01 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-04-24 03:23:01 +0200 | bilegeek_ | (~bilegeek@2600:1008:b02e:ea76:eada:d06b:de7e:6cef) |
| 2023-04-24 03:26:00 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2023-04-24 03:28:41 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 255 seconds) |
| 2023-04-24 03:30:26 +0200 | wroathe | (~wroathe@user/wroathe) (Quit: Reconnecting) |
| 2023-04-24 03:30:40 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-04-24 03:30:40 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-04-24 03:30:40 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-04-24 03:53:02 +0200 | cheater | (~Username@user/cheater) |
| 2023-04-24 03:54:04 +0200 | cheater | (~Username@user/cheater) (Client Quit) |
| 2023-04-24 04:01:34 +0200 | haritz | (~hrtz@user/haritz) (Read error: Connection reset by peer) |
| 2023-04-24 04:02:46 +0200 | rburkholder | (~blurb@96.45.2.121) (Remote host closed the connection) |
| 2023-04-24 04:03:18 +0200 | rburkholder | (~blurb@96.45.2.121) |
| 2023-04-24 04:04:30 +0200 | accord | (uid568320@id-568320.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-04-24 04:04:36 +0200 | rburkholder | (~blurb@96.45.2.121) (Max SendQ exceeded) |
| 2023-04-24 04:05:09 +0200 | rburkholder | (~blurb@96.45.2.121) |
| 2023-04-24 04:05:45 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2023-04-24 04:05:45 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2023-04-24 04:05:45 +0200 | haritz | (~hrtz@user/haritz) |
| 2023-04-24 04:12:21 +0200 | cheater | (~Username@user/cheater) |
| 2023-04-24 04:12:39 +0200 | xff0x | (~xff0x@2405:6580:b080:900:1d02:138:10dc:9535) (Ping timeout: 260 seconds) |
| 2023-04-24 04:14:04 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-24 04:22:38 +0200 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) |
| 2023-04-24 04:27:05 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2023-04-24 04:41:25 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-24 04:43:19 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2023-04-24 04:48:49 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 276 seconds) |
| 2023-04-24 04:54:50 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-04-24 04:54:50 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-04-24 04:54:50 +0200 | finn_elija | FinnElija |
| 2023-04-24 04:54:58 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-04-24 04:59:52 +0200 | td_ | (~td@i5387093F.versanet.de) (Ping timeout: 276 seconds) |
| 2023-04-24 05:01:00 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2023-04-24 05:01:18 +0200 | td_ | (~td@i53870912.versanet.de) |
| 2023-04-24 05:09:05 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2023-04-24 05:09:52 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2023-04-24 05:19:44 +0200 | jargon | (~jargon@174-22-213-236.phnx.qwest.net) |
| 2023-04-24 05:24:22 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-04-24 05:30:40 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 248 seconds) |
| 2023-04-24 05:30:46 +0200 | <probie> | If I call `imap` with a strict function over a `Vector Word8` from Data.Vector.Storable, should I expect GHC to generate similar code to a naive for loop written in a language like C or Fortran (ignoring the code to allocate the destination Vector)? |
| 2023-04-24 05:32:58 +0200 | <probie> | (and assuming the function is inlined) |
| 2023-04-24 05:33:01 +0200 | <c_wraith> | in general, you can assume the higher-order functions behave that way, yes |
| 2023-04-24 05:34:51 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-04-24 05:35:38 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-04-24 05:37:52 +0200 | <probie> | I guess the easiest thing to do would just be to compare it myself. Is there an easy way to see what assembly GHC generates for a function (or module)? Historically I've just called objdump on the produced executable, but navigating that isn't ideal. |
| 2023-04-24 05:41:31 +0200 | rf | (~rf@2605:59c8:1604:2210:6e18:f30:3bf:df23) (Ping timeout: 248 seconds) |
| 2023-04-24 05:44:09 +0200 | <probie> | I couldn't find an answer for a specific function, but it'll do the entire module if you pass it `-S` |
| 2023-04-24 05:47:21 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-24 05:50:39 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 260 seconds) |
| 2023-04-24 05:52:15 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 255 seconds) |
| 2023-04-24 05:54:35 +0200 | {-d0t-} | (~q_q@user/-d0t-/x-7915216) |
| 2023-04-24 05:54:41 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-04-24 05:58:06 +0200 | ddellacosta | (~ddellacos@146.70.168.100) |
| 2023-04-24 06:02:53 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-24 06:06:25 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2023-04-24 06:08:19 +0200 | msavoritias | (cb716af6b3@irc.cheogram.com) (Ping timeout: 252 seconds) |
| 2023-04-24 06:09:22 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Remote host closed the connection) |
| 2023-04-24 06:10:04 +0200 | opticblast | (~Thunderbi@172.58.85.88) (Ping timeout: 276 seconds) |
| 2023-04-24 06:13:53 +0200 | euandreh | (~Thunderbi@189.6.18.7) |
| 2023-04-24 06:13:54 +0200 | jargon | (~jargon@174-22-213-236.phnx.qwest.net) (Remote host closed the connection) |
| 2023-04-24 06:14:28 +0200 | slack1256 | (~slack1256@181.42.40.58) |
| 2023-04-24 06:15:56 +0200 | <slack1256> | Is it possible to use yampa with GTK without replicating a bunch of info between the two systems? |
| 2023-04-24 06:16:49 +0200 | <slack1256> | Most of the example of yampa that I see, draw the whole screen at the end of the step function. That is OK for games or html stuff. But for GTK, seems more complicated as it has its own event loop. |
| 2023-04-24 06:17:01 +0200 | Sgeo_ | (~Sgeo@user/sgeo) |
| 2023-04-24 06:17:33 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-04-24 06:17:34 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Remote host closed the connection) |
| 2023-04-24 06:18:08 +0200 | euandreh | (~Thunderbi@189.6.18.7) |
| 2023-04-24 06:33:55 +0200 | vglfr | (~vglfr@37.73.65.155) |
| 2023-04-24 06:34:25 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-04-24 06:36:43 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 276 seconds) |
| 2023-04-24 06:39:21 +0200 | bgs | (~bgs@212.85.160.171) |
| 2023-04-24 06:41:38 +0200 | PHO` | (~pho@akari.cielonegro.org) (Ping timeout: 265 seconds) |
| 2023-04-24 06:41:51 +0200 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2023-04-24 06:42:32 +0200 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2023-04-24 06:44:07 +0200 | dontdieych | (~alarm@132.226.169.184) (Quit: WeeChat 3.8) |
| 2023-04-24 06:49:11 +0200 | opticblast | (~Thunderbi@172.58.85.88) |
| 2023-04-24 06:54:48 +0200 | {-d0t-} | (~q_q@user/-d0t-/x-7915216) (Quit: Konversation terminated!) |
| 2023-04-24 06:55:22 +0200 | kmein | (~weechat@user/kmein) (Quit: ciao kakao) |
| 2023-04-24 06:55:59 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::3) (Remote host closed the connection) |
| 2023-04-24 06:56:02 +0200 | kmein | (~weechat@user/kmein) |
| 2023-04-24 06:56:50 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Quit: quit) |
| 2023-04-24 06:57:16 +0200 | tr_ev | (~trev@user/trev) |
| 2023-04-24 06:58:05 +0200 | opticblast | (~Thunderbi@172.58.85.88) (Ping timeout: 240 seconds) |
| 2023-04-24 07:03:33 +0200 | nek0 | (~nek0@2a01:4f8:222:2b41::12) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-24 07:07:27 +0200 | slack1256 | (~slack1256@181.42.40.58) (Ping timeout: 250 seconds) |
| 2023-04-24 07:13:29 +0200 | bilegeek_ | (~bilegeek@2600:1008:b02e:ea76:eada:d06b:de7e:6cef) (Quit: Leaving) |
| 2023-04-24 07:14:34 +0200 | aeroplane | (~user@user/aeroplane) |
| 2023-04-24 07:17:43 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-04-24 07:19:50 +0200 | tr_ev | trev |
| 2023-04-24 07:23:20 +0200 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-04-24 07:24:44 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-04-24 07:25:49 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-04-24 07:28:32 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-04-24 07:29:41 +0200 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) |
| 2023-04-24 07:40:34 +0200 | planplan | (~planplan@88.147.153.79) |
| 2023-04-24 07:41:20 +0200 | planplan | (~planplan@88.147.153.79) (Client Quit) |
| 2023-04-24 07:44:59 +0200 | Sgeo | (~Sgeo@user/sgeo) (Quit: Leaving) |
| 2023-04-24 07:46:54 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-04-24 07:50:15 +0200 | michalz | (~michalz@185.246.207.221) |
| 2023-04-24 07:54:43 +0200 | msavoritias | (cb716af6b3@irc.cheogram.com) |
| 2023-04-24 07:55:45 +0200 | hgolden_ | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2023-04-24 07:58:05 +0200 | tabemann_ | (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) |
| 2023-04-24 07:58:22 +0200 | rs | (~rs@p200300cf072e68ea6b29732cbdb21e80.dip0.t-ipconnect.de) |
| 2023-04-24 07:58:37 +0200 | drdo0 | (~drdo@bl14-14-164.dsl.telepac.pt) |
| 2023-04-24 07:58:37 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2023-04-24 07:58:37 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Ping timeout: 255 seconds) |
| 2023-04-24 07:58:37 +0200 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 255 seconds) |
| 2023-04-24 07:58:37 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 255 seconds) |
| 2023-04-24 07:58:37 +0200 | tabemann__ | (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) (Remote host closed the connection) |
| 2023-04-24 07:58:37 +0200 | drdo | (~drdo@bl14-14-164.dsl.telepac.pt) (Quit: Ping timeout (120 seconds)) |
| 2023-04-24 07:58:37 +0200 | drdo0 | drdo |
| 2023-04-24 07:58:46 +0200 | rs | Guest6213 |
| 2023-04-24 07:58:50 +0200 | m5zs7k_ | (aquares@web10.mydevil.net) |
| 2023-04-24 07:59:43 +0200 | euandreh | (~Thunderbi@189.6.18.7) |
| 2023-04-24 08:01:04 +0200 | werneta_ | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-04-24 08:02:46 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 249 seconds) |
| 2023-04-24 08:06:21 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Ping timeout: 255 seconds) |
| 2023-04-24 08:07:46 +0200 | bgs | (~bgs@212.85.160.171) (Remote host closed the connection) |
| 2023-04-24 08:07:54 +0200 | m5zs7k_ | m5zs7k |
| 2023-04-24 08:33:21 +0200 | merijn | (~merijn@86.86.29.250) |
| 2023-04-24 08:41:55 +0200 | vglfr | (~vglfr@37.73.65.155) (Read error: Connection reset by peer) |
| 2023-04-24 09:01:37 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:a82:d46a:c173:974c) |
| 2023-04-24 09:02:37 +0200 | gurkenglas | (~gurkengla@dynamic-089-204-139-194.89.204.139.pool.telefonica.de) |
| 2023-04-24 09:08:03 +0200 | merijn | (~merijn@86.86.29.250) (Ping timeout: 265 seconds) |
| 2023-04-24 09:09:45 +0200 | dh97 | (~dh97@2405:201:d02b:48f3:d9ee:cb54:6fa0:b6ac) |
| 2023-04-24 09:11:31 +0200 | PHO` | (~pho@akari.cielonegro.org) |
| 2023-04-24 09:13:52 +0200 | acidjnk | (~acidjnk@p200300d6e715c483143575a405c4d32c.dip0.t-ipconnect.de) |
| 2023-04-24 09:17:51 +0200 | dh97 | (~dh97@2405:201:d02b:48f3:d9ee:cb54:6fa0:b6ac) (Quit: Quit) |
| 2023-04-24 09:21:30 +0200 | trev | (~trev@user/trev) (Ping timeout: 255 seconds) |
| 2023-04-24 09:21:47 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2023-04-24 09:24:17 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2023-04-24 09:26:36 +0200 | shriekingnoise | (~shrieking@186.137.175.87) (Ping timeout: 264 seconds) |
| 2023-04-24 09:29:04 +0200 | euandreh | (~Thunderbi@189.6.18.7) |
| 2023-04-24 09:42:13 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-24 09:48:45 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-04-24 09:48:51 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-24 09:53:33 +0200 | gehmehgeh | gmg |
| 2023-04-24 09:53:54 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 255 seconds) |
| 2023-04-24 09:56:24 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-04-24 09:57:49 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-04-24 10:01:52 +0200 | <tomsmeding> | probie: won't you see the individual function in the assembly if you {-# NOINLINE #-} the function? |
| 2023-04-24 10:02:27 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 255 seconds) |
| 2023-04-24 10:04:13 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 2023-04-24 10:06:05 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-04-24 10:06:41 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-04-24 10:08:19 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-04-24 10:08:42 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-04-24 10:12:00 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::7fe) |
| 2023-04-24 10:13:38 +0200 | <probie> | tomsmeding yes that will work, I was just hoping there some magical `--show-me-the-assembly-for "Module.function"` which prevented it from being inlined and would also print just the `_info` part |
| 2023-04-24 10:13:46 +0200 | <probie> | s/there some/there was some/ |
| 2023-04-24 10:14:05 +0200 | <tomsmeding> | ¯\_(ツ)_/¯ |
| 2023-04-24 10:14:31 +0200 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2023-04-24 10:14:50 +0200 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2023-04-24 10:18:02 +0200 | <merijn> | probie: There's some RTS debug tools for walking and dumping info tables, iirc |
| 2023-04-24 10:18:30 +0200 | titibandit | (~titibandi@user/titibandit) |
| 2023-04-24 10:22:56 +0200 | trev | (~trev@user/trev) |
| 2023-04-24 10:27:05 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-04-24 10:30:41 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2023-04-24 10:40:18 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2023-04-24 10:41:47 +0200 | <probie> | merijn: I think you may mean something else by "info table" than I mean by "the `_info` part". `SomeModule_someFunction_info` is (at least with the default GHC backend) the label that will appear in the assembly where the actual instructions start for `someFunction` from module `SomeModule`. |
| 2023-04-24 10:42:32 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-04-24 10:42:40 +0200 | <merijn> | probie: That *sounds* like the info table, which afaik every function, value, and thunk has |
| 2023-04-24 10:42:54 +0200 | <merijn> | but you'll probably get more useful comments in #ghc |
| 2023-04-24 10:43:19 +0200 | nschoe | (~q@82.65.202.30) |
| 2023-04-24 10:46:53 +0200 | tok | (~user@user/tok) |
| 2023-04-24 10:50:18 +0200 | c0c0 | (~coco@212-51-146-137.fiber7.init7.net) |
| 2023-04-24 10:52:59 +0200 | titibandit | (~titibandi@user/titibandit) (Remote host closed the connection) |
| 2023-04-24 10:55:00 +0200 | euav | (~euav@195.135.254.99) |
| 2023-04-24 10:57:32 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-d11e-aa70-1ef3-2bb0.rev.sfr.net) |
| 2023-04-24 11:05:22 +0200 | euav | (~euav@195.135.254.99) (Remote host closed the connection) |
| 2023-04-24 11:06:08 +0200 | kenran | (~user@user/kenran) |
| 2023-04-24 11:08:43 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-24 11:09:18 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 252 seconds) |
| 2023-04-24 11:10:35 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2023-04-24 11:15:43 +0200 | ft | (~ft@p4fc2a88b.dip0.t-ipconnect.de) (Quit: leaving) |
| 2023-04-24 11:17:35 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 255 seconds) |
| 2023-04-24 11:19:39 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2023-04-24 11:21:03 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-04-24 11:21:57 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-24 11:23:45 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2023-04-24 11:24:25 +0200 | kenran | (~user@user/kenran) (Ping timeout: 240 seconds) |
| 2023-04-24 11:24:59 +0200 | __monty__ | (~toonn@user/toonn) |
| 2023-04-24 11:25:35 +0200 | <dminuoso> | I have a bunch of worker threads that process requests. A request can be of type "start" or "update", and they have some user identifier attached to them. In my situation the initial start is almost always followed up by an update immediately afterwards. There's now a race condition where sometimes a worker thread will process the update first. |
| 2023-04-24 11:25:55 +0200 | <dminuoso> | However, I must also cater for the reality that an initial `start` might have been missed (I consider such records orphan records) |
| 2023-04-24 11:27:05 +0200 | <dminuoso> | How can I sensibly avoid generating orphan records in the general case? My most naive attempt would be to consistently add a threadDelay whenever I get an update record, but given that update records is almost everything I ever process, this stupidly delays their processing |
| 2023-04-24 11:28:02 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-04-24 11:28:11 +0200 | <dminuoso> | Another idea Ive been playing with is to just consider them orphan records that get "adopted" if a start message arrives within seconds, but that creates synchronization problems. |
| 2023-04-24 11:28:24 +0200 | juri_ | (~juri@84-19-175-179.pool.ovpn.com) (Ping timeout: 255 seconds) |
| 2023-04-24 11:29:29 +0200 | <dminuoso> | Or is using an STM `TVar (Set UserIdentifier)` as a poor mans associative MVar a good idea to avoid concurrent processing (such that I can |
| 2023-04-24 11:29:39 +0200 | <dminuoso> | safely do an adoption process? |
| 2023-04-24 11:31:31 +0200 | <__monty__> | Does start *need* to be a separate request? Or could you have the first update request implicitly imply start? |
| 2023-04-24 11:31:44 +0200 | JScript | (~JScript@144.48.39.180) (Ping timeout: 248 seconds) |
| 2023-04-24 11:33:36 +0200 | juri_ | (~juri@84-19-175-179.pool.ovpn.com) |
| 2023-04-24 11:34:23 +0200 | <dminuoso> | __monty__: Yes, its out of my control |
| 2023-04-24 11:35:39 +0200 | <mauke> | start must block updates of the same entity |
| 2023-04-24 11:36:02 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::7fe) (Remote host closed the connection) |
| 2023-04-24 11:36:18 +0200 | <mauke> | but wouldn't concurrent updates of the same entity race against each other, too? |
| 2023-04-24 11:36:31 +0200 | <dminuoso> | mauke: a block wont help if the update is processed first. |
| 2023-04-24 11:36:47 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::fba) |
| 2023-04-24 11:36:50 +0200 | <dminuoso> | Due to timing and some batching involved, in about 0,1% of the cases an update is indeed processed first |
| 2023-04-24 11:37:36 +0200 | <mauke> | that's rather my point: don't process updates first |
| 2023-04-24 11:38:16 +0200 | <dminuoso> | Maybe I thought about it wrong. So the reality is, because this is an unreliable network I must in principle allow for a start to not occur. |
| 2023-04-24 11:38:21 +0200 | <dminuoso> | So I cant just block until I see a start |
| 2023-04-24 11:38:24 +0200 | <chreekat> | can 'start' be reformulated as a kind of 'update'? |
| 2023-04-24 11:39:07 +0200 | <mauke> | if you don't see a start, don't block |
| 2023-04-24 11:39:32 +0200 | <mauke> | I mean, are these messages ordered or not? |
| 2023-04-24 11:42:32 +0200 | <dminuoso> | mauke: If an update arrives not even a millisecond after the a start, and you're working with multiple concurrent workers, then you have a race condition. |
| 2023-04-24 11:43:18 +0200 | <mauke> | only if you hand out updates indiscriminately |
| 2023-04-24 11:43:24 +0200 | eggplantade | (~Eggplanta@104.55.37.220) |
| 2023-04-24 11:43:36 +0200 | vglfr | (~vglfr@37.73.65.155) |
| 2023-04-24 11:44:08 +0200 | vglfr | (~vglfr@37.73.65.155) (Read error: Connection reset by peer) |
| 2023-04-24 11:44:10 +0200 | <dminuoso> | As mentioned earlier, a start is necessarily almost always followed by an update |
| 2023-04-24 11:45:08 +0200 | <mauke> | what kind of uncontrollable event loop is this? |
| 2023-04-24 11:45:41 +0200 | <dminuoso> | This is RADIUS messages. As per standard, Start and Interim-Update are different messages |
| 2023-04-24 11:45:57 +0200 | <mauke> | the nature of the messages doesn't really matter |
| 2023-04-24 11:46:15 +0200 | <dminuoso> | Im just saying its external networking equipment |
| 2023-04-24 11:46:45 +0200 | <mauke> | the point is that you shouldn't start processing updates until all outstanding starts are done for the same entity |
| 2023-04-24 11:46:57 +0200 | phma | (phma@2001:5b0:2143:c788:d2b8:a200:d590:bdcb) (Read error: Connection reset by peer) |
| 2023-04-24 11:46:57 +0200 | <mauke> | (and probably all outstanding updates, too) |
| 2023-04-24 11:47:07 +0200 | <dminuoso> | I dont know whether there's outstanding starts |
| 2023-04-24 11:47:12 +0200 | <mauke> | why not? |
| 2023-04-24 11:47:25 +0200 | <dminuoso> | If the worker thread processing the update is just lucky to get CPU time first |
| 2023-04-24 11:47:39 +0200 | <dminuoso> | Then I might not even have come to the point where I know whether or not a start message is in the queue |
| 2023-04-24 11:47:53 +0200 | <mauke> | <mauke> only if you hand out updates indiscriminately |
| 2023-04-24 11:48:02 +0200 | eggplantade | (~Eggplanta@104.55.37.220) (Ping timeout: 265 seconds) |
| 2023-04-24 11:48:04 +0200 | <mauke> | don't let worker threads start processing random messages out of order |
| 2023-04-24 11:48:10 +0200 | phma | (~phma@67.44.208.196) |
| 2023-04-24 11:49:07 +0200 | <dminuoso> | Okay I see your point. |
| 2023-04-24 11:49:24 +0200 | <dminuoso> | So I guess I could have a smarter ingress queue that perhaps have some blocking logic to it. |
| 2023-04-24 11:50:02 +0200 | <mauke> | or a separate queue per user or something |
| 2023-04-24 11:51:06 +0200 | <mauke> | I'm not familiar with RADIUS, but I would assume it doesn't make sense to process interim updates out of order, either |
| 2023-04-24 11:55:47 +0200 | titibandit | (~titibandi@user/titibandit) |
| 2023-04-24 12:08:43 +0200 | vpan | (~0@mail.elitnet.lt) |
| 2023-04-24 12:11:48 +0200 | jpds4 | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2023-04-24 12:12:14 +0200 | <dminuoso> | mauke: Okay so thats subtly more complicated, but we can assume an interim update to fire only once an hour. |
| 2023-04-24 12:12:19 +0200 | jpds4 | (~jpds@gateway/tor-sasl/jpds) |
| 2023-04-24 12:13:25 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 240 seconds) |
| 2023-04-24 12:13:34 +0200 | <dminuoso> | mauke: So the per-user queue bit is interesting, but that opens up a potential space leak (say if something cause a flood of start messages with random user identifiers) |
| 2023-04-24 12:13:48 +0200 | <dminuoso> | At least for a naive implementation |
| 2023-04-24 12:14:42 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2023-04-24 12:14:49 +0200 | <mauke> | https://en.wikipedia.org/wiki/SYN_flood :-D |
| 2023-04-24 12:15:16 +0200 | <dminuoso> | Right, something along those lines. |
| 2023-04-24 12:16:32 +0200 | <dminuoso> | Although, perhaps I dont need to worry about space leaks much. |
| 2023-04-24 12:17:02 +0200 | <dminuoso> | If I maintain something like `Map UserIdentifier ThreadId` as a map of currently running threads |
| 2023-04-24 12:17:15 +0200 | JScript | (~JScript@144.48.39.182) |
| 2023-04-24 12:17:17 +0200 | JScript | (~JScript@144.48.39.182) (Max SendQ exceeded) |
| 2023-04-24 12:17:30 +0200 | <dminuoso> | And merely keep a backlog of requests that cant currently be scheduled |
| 2023-04-24 12:17:34 +0200 | <dminuoso> | Then the space leak disappears |
| 2023-04-24 12:18:11 +0200 | <dminuoso> | Of course then we get into scheduling. |
| 2023-04-24 12:18:37 +0200 | <dminuoso> | It's interesting how vastly different and complicated concurrency is. |
| 2023-04-24 12:19:13 +0200 | JScript | (~JScript@144.48.39.182) |
| 2023-04-24 12:23:23 +0200 | titibandit | (~titibandi@user/titibandit) (Quit: leaving) |
| 2023-04-24 12:25:14 +0200 | Guest6229 | (~thibaut@sunp.ient.rwth-aachen.de) |
| 2023-04-24 12:25:28 +0200 | nek0 | (~nek0@2a01:4f8:222:2b41::12) |
| 2023-04-24 12:26:24 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2023-04-24 12:26:30 +0200 | <dminuoso> | mauke: Implementation-wise it will be vastly more simple to blindly spawn threads and use a blocking action - because it's essentially impossible to have more than `1 start + 1 update` concurrently |
| 2023-04-24 12:26:43 +0200 | <dminuoso> | So blocking will give me that ordering for that special case. |
| 2023-04-24 12:28:58 +0200 | Square2 | (~Square4@user/square) |
| 2023-04-24 12:33:38 +0200 | Guest6229 | (~thibaut@sunp.ient.rwth-aachen.de) (Quit: leaving) |
| 2023-04-24 12:36:34 +0200 | titiband1t | (~titibandi@user/titibandit) |
| 2023-04-24 12:38:36 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 255 seconds) |
| 2023-04-24 12:39:18 +0200 | oljenkins | (~philipp@p5dec4bb3.dip0.t-ipconnect.de) |
| 2023-04-24 12:42:52 +0200 | tremon | (~tremon@83.80.159.219) |
| 2023-04-24 12:47:52 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 276 seconds) |
| 2023-04-24 12:50:19 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2023-04-24 12:55:10 +0200 | Barfolomew | (~Barfolome@2a0a-a546-a8e-1-c27c-c014-a0d8-fcc3.ipv6dyn.netcologne.de) |
| 2023-04-24 13:16:45 +0200 | mei | (~mei@user/mei) (Ping timeout: 240 seconds) |
| 2023-04-24 13:20:59 +0200 | mei | (~mei@user/mei) |
| 2023-04-24 13:21:04 +0200 | witcher | (~witcher@wiredspace.de) (Remote host closed the connection) |
| 2023-04-24 13:21:36 +0200 | witcher | (~witcher@wiredspace.de) |
| 2023-04-24 13:24:28 +0200 | acidjnk | (~acidjnk@p200300d6e715c483143575a405c4d32c.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2023-04-24 13:25:03 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-24 13:27:08 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2023-04-24 13:27:09 +0200 | jpds4 | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2023-04-24 13:27:44 +0200 | jpds4 | (~jpds@gateway/tor-sasl/jpds) |
| 2023-04-24 13:28:55 +0200 | xff0x | (~xff0x@2405:6580:b080:900:23bd:4b23:18bc:5cdf) |
| 2023-04-24 13:33:54 +0200 | Barfolomew | (~Barfolome@2a0a-a546-a8e-1-c27c-c014-a0d8-fcc3.ipv6dyn.netcologne.de) (Quit: Barfolomew) |
| 2023-04-24 13:37:16 +0200 | LambdaDuck | (~anka@ksit.fixme.fi) (Ping timeout: 276 seconds) |
| 2023-04-24 13:37:20 +0200 | jimki | (~jmaki@gazorpazorp.fixme.fi) (Ping timeout: 260 seconds) |
| 2023-04-24 13:39:16 +0200 | nschoe | (~q@82.65.202.30) (Quit: Switching off) |
| 2023-04-24 13:39:36 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2023-04-24 13:44:32 +0200 | polyphem | (~rod@2a02:810d:840:8754:1b97:4da6:419e:bd10) |
| 2023-04-24 13:45:23 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-04-24 13:47:27 +0200 | <jean-paul[m]> | are there clamped types already defined somewhere I could get at them? |
| 2023-04-24 13:48:59 +0200 | <geekosaur> | "clamped"? |
| 2023-04-24 13:49:21 +0200 | witcher | (~witcher@wiredspace.de) (Remote host closed the connection) |
| 2023-04-24 13:49:52 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 248 seconds) |
| 2023-04-24 13:50:04 +0200 | witcher | (~witcher@wiredspace.de) |
| 2023-04-24 13:50:14 +0200 | <jean-paul[m]> | Types that stick to their min/max bound on overflow |
| 2023-04-24 13:50:23 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-24 13:50:24 +0200 | <geekosaur> | nope |
| 2023-04-24 13:51:29 +0200 | <dminuoso> | jean-paul[m]: Curious, whats the use case for such types? |
| 2023-04-24 13:51:49 +0200 | <geekosaur> | (I think that makes them dependent types) |
| 2023-04-24 13:52:07 +0200 | <dminuoso> | geekosaur: Why would it? |
| 2023-04-24 13:52:30 +0200 | <dminuoso> | It would only if they got promoted to larger types on overflow |
| 2023-04-24 13:52:47 +0200 | <merijn> | dminuoso: Lots of physics and graphics problems |
| 2023-04-24 13:52:48 +0200 | <geekosaur> | typechecker may have to prove that extra code to clamp it doesn't have to be emitted? |
| 2023-04-24 13:53:09 +0200 | <geekosaur> | that, or every operation needs extra codegen to do the clamping |
| 2023-04-24 13:53:19 +0200 | <dminuoso> | I see, I was thinking of the latter. |
| 2023-04-24 13:53:21 +0200 | <geekosaur> | (and some will anyway) |
| 2023-04-24 13:53:23 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2023-04-24 13:53:32 +0200 | <dminuoso> | Are there x86 instructions for such clamping behavior? |
| 2023-04-24 13:53:40 +0200 | <jean-paul[m]> | I can imagine ClampedInt low high being a dependent type, but I think it's simpler if you just have ClampedIntFromLowToHigh (ie, the bounds are not parameters, they're just intrinsic to the type) |
| 2023-04-24 13:53:58 +0200 | <jean-paul[m]> | A float clamped between 0 and 1 is used in graphics a lot |
| 2023-04-24 13:54:12 +0200 | <jean-paul[m]> | (which is basically what I'm doing) |
| 2023-04-24 13:54:32 +0200 | <dminuoso> | jean-paul[m]: Do clamping AMD64 instructions exist for the mathematical operations you're thinking of? |
| 2023-04-24 13:54:38 +0200 | <dminuoso> | Or would they require branching? |
| 2023-04-24 13:54:48 +0200 | <jean-paul[m]> | I have no idea :) |
| 2023-04-24 13:55:24 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 264 seconds) |
| 2023-04-24 13:55:27 +0200 | <jean-paul[m]> | my interest is mainly at the programming level ... can I arrange my code more neatly with such a type, does it make sense to have a Num instance for them, etc |
| 2023-04-24 13:56:10 +0200 | <dminuoso> | Oh I was merely wondering if those existed, whether they might be exposed as primops already, |
| 2023-04-24 13:56:32 +0200 | <jean-paul[m]> | I have never really ventured down to that level |
| 2023-04-24 13:56:52 +0200 | <dminuoso> | Interesting, so it seems the efficient way is cmp + cmov |
| 2023-04-24 13:57:34 +0200 | <dminuoso> | Presumably cmov just induces a data dependency, so I guess it will bypass branch predictors entirely |
| 2023-04-24 13:58:33 +0200 | <dminuoso> | I guess a highly efficient implementation would require custom primops then |
| 2023-04-24 13:58:55 +0200 | <dminuoso> | merijn: where does this appear in physics? |
| 2023-04-24 14:01:25 +0200 | <merijn> | dminuoso: Computational physics I meant, the kindas 2d/3d convolution stuff for, like, heat transfer, where you have grid boundaries |
| 2023-04-24 14:02:03 +0200 | <probie> | I think you can do this in arm without introducing branching via the conditional ops (not that many people are during numerically intense stuff on arm) |
| 2023-04-24 14:08:54 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) |
| 2023-04-24 14:09:57 +0200 | <fbytez> | What's the equivalent of c's `argv[0]`? |
| 2023-04-24 14:10:59 +0200 | <dminuoso> | getProgName |
| 2023-04-24 14:11:33 +0200 | <dminuoso> | fbytez: Be sure to read the haddock details about it. |
| 2023-04-24 14:11:44 +0200 | <fbytez> | Thankyou. |
| 2023-04-24 14:11:44 +0200 | <dminuoso> | There's some subtle potentially relevant portability issues with it. |
| 2023-04-24 14:12:12 +0200 | <merijn> | dminuoso: Are there? (as in, more so than in C?) |
| 2023-04-24 14:12:26 +0200 | <geekosaur> | https://downloads.haskell.org/ghc/9.2.5/docs/html/libraries/base-4.16.4.0/System-Environment.html#… |
| 2023-04-24 14:12:32 +0200 | geekosaur | slow |
| 2023-04-24 14:12:45 +0200 | <dminuoso> | merijn: That's a good point, actually |
| 2023-04-24 14:13:05 +0200 | <geekosaur> | afaik they're the same as in C |
| 2023-04-24 14:14:25 +0200 | <fbytez> | However, this is hard-to-impossible to implement on some non-Unix OSes, so instead, for maximum portability, we just return the leafname of the program as invoked. Even then there are some differences between platforms: on Windows, for example, a program invoked as foo is probably really FOO.EXE, and that is what getProgName will return. |
| 2023-04-24 14:14:36 +0200 | <dminuoso> | Yeah I just browsed the RTS |
| 2023-04-24 14:14:37 +0200 | <fbytez> | ^ what is meant by "leafname"? basename? |
| 2023-04-24 14:15:00 +0200 | <dminuoso> | fbytez: Consider you might have invoked C:/foo/bar.exe |
| 2023-04-24 14:15:07 +0200 | <dminuoso> | or worse |
| 2023-04-24 14:15:12 +0200 | <dminuoso> | C:/foo/bar |
| 2023-04-24 14:15:18 +0200 | <dminuoso> | What would you expect? |
| 2023-04-24 14:15:28 +0200 | <dminuoso> | C:/foo/bar, C:/foo/bar.exe, bar, bar.exe? |
| 2023-04-24 14:17:04 +0200 | polyphem | (~rod@2a02:810d:840:8754:1b97:4da6:419e:bd10) (Ping timeout: 248 seconds) |
| 2023-04-24 14:17:23 +0200 | <dminuoso> | `for example, a program invoked as foo is probably really FOO.EXE, and that is what getProgName will return.` |
| 2023-04-24 14:17:30 +0200 | <dminuoso> | Curiously the rts code doesnt look like it would do that. |
| 2023-04-24 14:17:47 +0200 | <dminuoso> | But I dont know. Maybe the windows loader will inject that .EXE |
| 2023-04-24 14:17:48 +0200 | <geekosaur> | I think some of that is Windows itself |
| 2023-04-24 14:17:52 +0200 | <dminuoso> | oh okay |
| 2023-04-24 14:17:58 +0200 | <fbytez> | I don't use Windows, but on Linux I'd expect /foo/bar to be /foo/bar |
| 2023-04-24 14:18:00 +0200 | <dminuoso> | The rts code definitely strips any directory information |
| 2023-04-24 14:18:02 +0200 | <geekosaur> | also the upcasing |
| 2023-04-24 14:18:03 +0200 | <dminuoso> | fbytez: nope |
| 2023-04-24 14:18:06 +0200 | <dminuoso> | fbytez: it would produce `bar` |
| 2023-04-24 14:18:12 +0200 | <fbytez> | Right, thanks. |
| 2023-04-24 14:18:28 +0200 | <geekosaur> | and drive letters aren't necessarily accurate by the time getProgName is called |
| 2023-04-24 14:18:32 +0200 | <dminuoso> | fbytez: and on windows C:\foo\bar would produce bar.EXE |
| 2023-04-24 14:18:36 +0200 | <geekosaur> | I mean, even DOS 2.11 had SUBST |
| 2023-04-24 14:19:08 +0200 | oljenkins | (~philipp@p5dec4bb3.dip0.t-ipconnect.de) (Quit: Lost terminal) |
| 2023-04-24 14:19:41 +0200 | <dminuoso> | Though if your Haskell program is required to have DOS 2.11 compatibility, I think you have different problems than getProgName. |
| 2023-04-24 14:19:53 +0200 | <dminuoso> | It wouldn't be my primary concern. :-) |
| 2023-04-24 14:20:07 +0200 | <geekosaur> | my point was more that they've aleways had a dynamic aspect |
| 2023-04-24 14:20:15 +0200 | <dminuoso> | Right. |
| 2023-04-24 14:20:19 +0200 | <dminuoso> | I guess the same holds true in linux too |
| 2023-04-24 14:20:35 +0200 | <dminuoso> | Since by the time you call getProgName, there could have been any number of bind mounts or unmounts. |
| 2023-04-24 14:21:38 +0200 | <dminuoso> | And I suppose you get into toc tou race as well, since the executable could have been renamed by the time getProgName is called |
| 2023-04-24 14:21:49 +0200 | <dminuoso> | s/toc tou/another toc tou/ |
| 2023-04-24 14:22:53 +0200 | <geekosaur> | yep. so it's strongly recommended you not rely on argv[0] / getProgName for anything important |
| 2023-04-24 14:23:09 +0200 | <merijn> | Ah...filesystem operation...so easy, until you think about things |
| 2023-04-24 14:23:19 +0200 | <merijn> | Then it's TOCTOU races as far as the eye can see |
| 2023-04-24 14:24:12 +0200 | <dminuoso> | merijn: Im had some real love with S3 recently, which doesnt even imbue you with things that let you *think* you can solve them. |
| 2023-04-24 14:24:28 +0200 | <dminuoso> | On one hand its frustrating, because you're forced to do TOC TOU checks with obvious huge latencies. |
| 2023-04-24 14:24:54 +0200 | <merijn> | dminuoso: I think the (scrapped) idea of giving Windows Vista a proper transactional filesystem woulda been brilliant |
| 2023-04-24 14:24:57 +0200 | <merijn> | sadly that never happened |
| 2023-04-24 14:25:43 +0200 | <merijn> | Could've been really cool |
| 2023-04-24 14:25:56 +0200 | <[exa]> | merijn: it was just another flock frontend as far as I recall, no? |
| 2023-04-24 14:26:35 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 255 seconds) |
| 2023-04-24 14:26:42 +0200 | <[exa]> | as in, I don't recall that a properly journaled ntfs replacement would ever be in sight |
| 2023-04-24 14:26:50 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2023-04-24 14:37:24 +0200 | <mauke> | https://en.wikipedia.org/wiki/WinFS |
| 2023-04-24 14:44:23 +0200 | <merijn> | [exa]: That's the one I was thinking off |
| 2023-04-24 14:49:22 +0200 | <dminuoso> | Is there a newtype that conceptually descripes an existential `exists e. Hashable a, Eq a *> e`? |
| 2023-04-24 14:49:37 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.8) |
| 2023-04-24 14:50:02 +0200 | <dminuoso> | Or maybe a typeclass?> |
| 2023-04-24 14:51:55 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-24 14:53:20 +0200 | <[exa]> | mauke merijn: thx |
| 2023-04-24 14:53:45 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2023-04-24 14:58:59 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2023-04-24 15:06:21 +0200 | tok | (~user@user/tok) (Remote host closed the connection) |
| 2023-04-24 15:11:20 +0200 | acidjnk | (~acidjnk@p200300d6e715c4838c5446d0fdde46cd.dip0.t-ipconnect.de) |
| 2023-04-24 15:16:11 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::3) |
| 2023-04-24 15:18:39 +0200 | motherfsck | (~motherfsc@user/motherfsck) |
| 2023-04-24 15:21:31 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2023-04-24 15:22:23 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 255 seconds) |
| 2023-04-24 15:23:12 +0200 | gurkenglas | (~gurkengla@dynamic-089-204-139-194.89.204.139.pool.telefonica.de) (Ping timeout: 248 seconds) |
| 2023-04-24 15:26:50 +0200 | chele | (~chele@user/chele) |
| 2023-04-24 15:29:39 +0200 | <dminuoso> | mauke: Mmm, the more I try and think how to implement a queuing, it's not very satisfactory. |
| 2023-04-24 15:30:08 +0200 | <dminuoso> | Given that I might be getting thousands of requests per second in some situations, I want proper scalability in terms of stm retries. |
| 2023-04-24 15:30:49 +0200 | <dminuoso> | That being said https://hackage.haskell.org/package/ttrie is a pretty nifty thing, but it takes some effort verifying its internals |
| 2023-04-24 15:32:08 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2023-04-24 15:34:00 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
| 2023-04-24 15:35:24 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-04-24 15:35:25 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-04-24 15:35:25 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-04-24 15:36:09 +0200 | Digit | (~user@user/digit) |
| 2023-04-24 15:39:33 +0200 | Me-me | (~Me-me@user/me-me) (Quit: Something has gone terribly, terribly wrong, that being that I'm not here any more.) |
| 2023-04-24 15:46:52 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-04-24 15:47:36 +0200 | JScript | (~JScript@144.48.39.182) (Ping timeout: 255 seconds) |
| 2023-04-24 15:49:24 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 255 seconds) |
| 2023-04-24 15:51:30 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 260 seconds) |
| 2023-04-24 15:57:19 +0200 | oljenkins | (~philipp@p5dec4bb3.dip0.t-ipconnect.de) |
| 2023-04-24 15:58:22 +0200 | yurideabreu | (~yurideabr@189.6.27.58) |
| 2023-04-24 15:58:51 +0200 | MajorBiscuit | (~MajorBisc@145.94.190.155) |
| 2023-04-24 16:01:12 +0200 | vglfr | (~vglfr@37.73.65.155) |
| 2023-04-24 16:04:41 +0200 | o-90 | (~o-90@gateway/tor-sasl/o-90) |
| 2023-04-24 16:06:42 +0200 | xff0x | (~xff0x@2405:6580:b080:900:23bd:4b23:18bc:5cdf) (Quit: xff0x) |
| 2023-04-24 16:07:37 +0200 | ystael | (~ystael@user/ystael) |
| 2023-04-24 16:09:35 +0200 | <c_wraith> | ok, so... I've been thinking about the difficulty I was seeing in getting ghci to <<loop>> yesterday, and I have a hypothesis. Only a major GC will detect loops in the threaded runtime, and sometime in recent years major GCs have been set to return early if there haven't been enough allocations to escape the nursery since the last major gc |
| 2023-04-24 16:10:52 +0200 | rf | (~rf@2605:59c8:1604:2210:5de6:62f6:20ef:34c8) |
| 2023-04-24 16:11:06 +0200 | <c_wraith> | that still doesn't feel complete, but it would explain a lot of it. |
| 2023-04-24 16:12:42 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9b3e:353e:43c8:742e) |
| 2023-04-24 16:19:05 +0200 | o-90 | (~o-90@gateway/tor-sasl/o-90) (Ping timeout: 255 seconds) |
| 2023-04-24 16:24:46 +0200 | oljenkins | (~philipp@p5dec4bb3.dip0.t-ipconnect.de) (Quit: leaving) |
| 2023-04-24 16:25:20 +0200 | oljenkins | (~philipp@p5dec4bb3.dip0.t-ipconnect.de) |
| 2023-04-24 16:27:45 +0200 | vglfr | (~vglfr@37.73.65.155) (Ping timeout: 240 seconds) |
| 2023-04-24 16:29:57 +0200 | shriekingnoise | (~shrieking@186.137.175.87) |
| 2023-04-24 16:31:23 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2023-04-24 16:35:15 +0200 | Guest26 | (~Guest26@85.249.45.137) |
| 2023-04-24 16:44:17 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:a82:d46a:c173:974c) (Quit: WeeChat 2.8) |
| 2023-04-24 16:48:01 +0200 | Vq | (~vq@90-230-208-28-no77.tbcn.telia.com) (Ping timeout: 240 seconds) |
| 2023-04-24 16:50:15 +0200 | Vq | (~vq@90-230-208-28-no77.tbcn.telia.com) |
| 2023-04-24 16:52:28 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-04-24 16:56:00 +0200 | yurideabreu | (~yurideabr@189.6.27.58) (Ping timeout: 255 seconds) |
| 2023-04-24 16:57:13 +0200 | Thilastiko | (~user@user/Thilastiko) |
| 2023-04-24 16:59:45 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-d11e-aa70-1ef3-2bb0.rev.sfr.net) (Remote host closed the connection) |
| 2023-04-24 17:00:08 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-04-24 17:02:24 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2023-04-24 17:18:55 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Ping timeout: 276 seconds) |
| 2023-04-24 17:20:12 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2023-04-24 17:22:23 +0200 | Inst | (~Inst@2601:6c4:4081:54f0:45f7:243a:3f7e:8aff) |
| 2023-04-24 17:22:52 +0200 | ddellacosta | (~ddellacos@146.70.168.100) (Quit: WeeChat 3.8) |
| 2023-04-24 17:24:56 +0200 | yurideabreu | (~yurideabr@189.6.27.58) |
| 2023-04-24 17:31:25 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 240 seconds) |
| 2023-04-24 17:33:45 +0200 | michalz | (~michalz@185.246.207.221) (Ping timeout: 240 seconds) |
| 2023-04-24 17:38:55 +0200 | Square2 | Square |
| 2023-04-24 17:39:25 +0200 | fcortesi | (~fcortesi@2001:470:69fc:105::f3a9) |
| 2023-04-24 17:41:01 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds) |
| 2023-04-24 17:41:05 +0200 | michalz | (~michalz@185.246.207.215) |
| 2023-04-24 17:42:13 +0200 | cheater | (~Username@user/cheater) |
| 2023-04-24 17:44:01 +0200 | MajorBiscuit | (~MajorBisc@145.94.190.155) (Ping timeout: 250 seconds) |
| 2023-04-24 17:44:03 +0200 | dh97 | (~tanmoydas@2405:201:d02b:48f3:b4d9:7afc:ebd0:3f47) |
| 2023-04-24 17:44:21 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Quit: WeeChat 3.8) |
| 2023-04-24 17:45:42 +0200 | michalz | (~michalz@185.246.207.215) (Ping timeout: 265 seconds) |
| 2023-04-24 17:51:01 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 240 seconds) |
| 2023-04-24 17:51:53 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-24 17:53:30 +0200 | michalz | (~michalz@185.246.207.201) |
| 2023-04-24 17:53:44 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-d11e-aa70-1ef3-2bb0.rev.sfr.net) |
| 2023-04-24 17:54:34 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-04-24 17:55:48 +0200 | dh97 | (~tanmoydas@2405:201:d02b:48f3:b4d9:7afc:ebd0:3f47) (Ping timeout: 246 seconds) |
| 2023-04-24 17:56:45 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 255 seconds) |
| 2023-04-24 17:58:48 +0200 | vpan | (~0@mail.elitnet.lt) (Quit: Leaving.) |
| 2023-04-24 17:59:59 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-04-24 18:00:07 +0200 | cdsmith | (~cdsmithma@2001:470:69fc:105::284) (Quit: You have been kicked for being idle) |
| 2023-04-24 18:03:12 +0200 | michalz | (~michalz@185.246.207.201) (Ping timeout: 264 seconds) |
| 2023-04-24 18:04:24 +0200 | Square | (~Square4@user/square) (Ping timeout: 255 seconds) |
| 2023-04-24 18:09:15 +0200 | xiliuya | (~xiliuya@user/xiliuya) |
| 2023-04-24 18:11:14 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2023-04-24 18:12:57 +0200 | vglfr | (~vglfr@88.155.117.69) |
| 2023-04-24 18:13:49 +0200 | werneta_ | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2023-04-24 18:15:17 +0200 | gurkenglas | (~gurkengla@dynamic-089-204-139-194.89.204.139.pool.telefonica.de) |
| 2023-04-24 18:16:27 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2023-04-24 18:16:35 +0200 | pavonia | (~user@user/siracusa) |
| 2023-04-24 18:28:21 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2023-04-24 18:30:46 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2023-04-24 18:35:13 +0200 | acidjnk | (~acidjnk@p200300d6e715c4838c5446d0fdde46cd.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2023-04-24 18:35:15 +0200 | econo | (uid147250@user/econo) |
| 2023-04-24 18:39:57 +0200 | Vq | (~vq@90-230-208-28-no77.tbcn.telia.com) (Ping timeout: 255 seconds) |
| 2023-04-24 18:43:09 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::fba) (Quit: Konversation terminated!) |
| 2023-04-24 18:44:20 +0200 | acidjnk | (~acidjnk@p200300d6e715c48345effc14b913dd3f.dip0.t-ipconnect.de) |
| 2023-04-24 18:51:48 +0200 | Vq | (~vq@90-227-195-9-no77.tbcn.telia.com) |
| 2023-04-24 18:58:20 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-04-24 18:59:24 +0200 | Guest79 | (~Guest79@dynamic-077-191-182-080.77.191.pool.telefonica.de) |
| 2023-04-24 19:00:41 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-04-24 19:01:38 +0200 | <fbytez> | Have I written the following idiomatically? |
| 2023-04-24 19:01:44 +0200 | <fbytez> | let r = filter (\c -> not (isSpace c || isControl c)) string |
| 2023-04-24 19:02:29 +0200 | <int-e> | @pl \c -> not (isSpace c || isControl c) |
| 2023-04-24 19:02:29 +0200 | <lambdabot> | not . liftM2 (||) isSpace isControl |
| 2023-04-24 19:02:42 +0200 | <int-e> | sheer beauty |
| 2023-04-24 19:03:21 +0200 | <int-e> | :t not . ((||) <$> isSpace <*> isControl) |
| 2023-04-24 19:03:22 +0200 | <lambdabot> | Char -> Bool |
| 2023-04-24 19:03:28 +0200 | <int-e> | I'd leave it as is. |
| 2023-04-24 19:03:29 +0200 | <Guest79> | Is there any completely portable development environment for haskell (everything needed in one folder)? |
| 2023-04-24 19:03:51 +0200 | <fbytez> | int-e, as I did or as your first example? |
| 2023-04-24 19:04:17 +0200 | <int-e> | fbytez: the way you wrote it |
| 2023-04-24 19:04:23 +0200 | ryantrinkle | (~ryantrink@140.174.255.47) (Read error: Connection reset by peer) |
| 2023-04-24 19:04:28 +0200 | <fbytez> | Thanks for taking a look. |
| 2023-04-24 19:04:31 +0200 | <mauke> | fbytez: looks good to me |
| 2023-04-24 19:05:49 +0200 | <int-e> | there's also [c | c <- string, not (isSpace c || isControl c)] with it's own flavor |
| 2023-04-24 19:06:19 +0200 | <int-e> | but if you use `filter` it'll still basically work if you later switch to Text, for example. |
| 2023-04-24 19:13:07 +0200 | Guest7979 | (~Guest79@dynamic-077-191-182-080.77.191.pool.telefonica.de) |
| 2023-04-24 19:13:18 +0200 | Guest7979 | (~Guest79@dynamic-077-191-182-080.77.191.pool.telefonica.de) (Client Quit) |
| 2023-04-24 19:14:22 +0200 | Guest79 | (~Guest79@dynamic-077-191-182-080.77.191.pool.telefonica.de) (Quit: Client closed) |
| 2023-04-24 19:14:43 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-04-24 19:15:16 +0200 | ubert | (~Thunderbi@p548c9793.dip0.t-ipconnect.de) |
| 2023-04-24 19:16:28 +0200 | vglfr | (~vglfr@88.155.117.69) (Ping timeout: 252 seconds) |
| 2023-04-24 19:19:04 +0200 | MajorBiscuit | (~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a) |
| 2023-04-24 19:19:31 +0200 | ryantrinkle | (~ryantrink@140.174.240.199) |
| 2023-04-24 19:22:57 +0200 | acidjnk | (~acidjnk@p200300d6e715c48345effc14b913dd3f.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-04-24 19:24:35 +0200 | acidjnk | (~acidjnk@p200300d6e715c4837c197c2288c4bb55.dip0.t-ipconnect.de) |
| 2023-04-24 19:25:43 +0200 | kimiamania | (~65804703@user/kimiamania) (Quit: PegeLinux) |
| 2023-04-24 19:26:51 +0200 | MajorBiscuit | (~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a) (Ping timeout: 260 seconds) |
| 2023-04-24 19:27:18 +0200 | kimiamania | (~65804703@user/kimiamania) |
| 2023-04-24 19:28:19 +0200 | hanabi | (~hanabi@dhcp-077-251-039-086.chello.nl) |
| 2023-04-24 19:29:11 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) (Remote host closed the connection) |
| 2023-04-24 19:31:22 +0200 | Guest26 | (~Guest26@85.249.45.137) (Quit: Connection closed) |
| 2023-04-24 19:39:47 +0200 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-24 19:45:12 +0200 | gurkenglas | (~gurkengla@dynamic-089-204-139-194.89.204.139.pool.telefonica.de) (Ping timeout: 264 seconds) |
| 2023-04-24 19:48:02 +0200 | Digitteknohippie | (~user@user/digit) |
| 2023-04-24 19:49:25 +0200 | Digit | (~user@user/digit) (Ping timeout: 240 seconds) |
| 2023-04-24 19:49:27 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) (Read error: Connection reset by peer) |
| 2023-04-24 19:50:37 +0200 | Goodbye_Vincent | (cyvahl@198.244.205.143) |
| 2023-04-24 19:51:20 +0200 | Guest6213 | (~rs@p200300cf072e68ea6b29732cbdb21e80.dip0.t-ipconnect.de) (Quit: Client closed) |
| 2023-04-24 19:55:10 +0200 | <sm> | Guest79: no, I think an online environment like code.world/haskell or repl.it would probably be the closest |
| 2023-04-24 19:55:29 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-04-24 19:55:41 +0200 | <sm[i]> | argh, did it again |
| 2023-04-24 19:56:03 +0200 | <sm[i]> | those speedy Guests |
| 2023-04-24 19:57:29 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-04-24 19:57:45 +0200 | Digitteknohippie | (~user@user/digit) (Ping timeout: 240 seconds) |
| 2023-04-24 20:08:07 +0200 | yurideabreu_ | (~yurideabr@189.6.27.58) |
| 2023-04-24 20:08:34 +0200 | yurideabreu | (~yurideabr@189.6.27.58) (Ping timeout: 276 seconds) |
| 2023-04-24 20:09:01 +0200 | michalz | (~michalz@185.246.207.221) |
| 2023-04-24 20:12:39 +0200 | yurideabreu_ | (~yurideabr@189.6.27.58) (Ping timeout: 250 seconds) |
| 2023-04-24 20:12:44 +0200 | <bionade24> | Do you also see those <haskell> tags on this page? https://wiki.haskell.org/How_to_get_rid_of_IO Those should be fields, shouldn't they? |
| 2023-04-24 20:14:48 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) |
| 2023-04-24 20:15:54 +0200 | <tomsmeding> | I get the feeling that the haskell wiki css is kinda broken |
| 2023-04-24 20:15:59 +0200 | <int-e> | if you look at the source it says :<haskell>, then a line of Haskell code, and the </haskell>... is there a markup dialog that works like this for code blocks? |
| 2023-04-24 20:16:00 +0200 | <tomsmeding> | pages that looked fine before have the same issue |
| 2023-04-24 20:16:10 +0200 | <tomsmeding> | e.g. https://wiki.haskell.org/State_Monad |
| 2023-04-24 20:17:11 +0200 | <sm> | I have a feeling hgolden upgraded the wiki and was/is working on fixing |
| 2023-04-24 20:17:47 +0200 | Digit | (~user@user/digit) |
| 2023-04-24 20:17:48 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-04-24 20:18:13 +0200 | <int-e> | or was there a custom plugin for making <haskell>...</haskell> work that is now absent or broken |
| 2023-04-24 20:19:00 +0200 | <int-e> | would #haskell-infrastructure care about this? |
| 2023-04-24 20:21:56 +0200 | hanabi_ | (~hanabi@dhcp-077-251-039-086.chello.nl) |
| 2023-04-24 20:22:18 +0200 | hanabi | (~hanabi@dhcp-077-251-039-086.chello.nl) (Read error: Connection reset by peer) |
| 2023-04-24 20:22:30 +0200 | xiliuya | (~xiliuya@user/xiliuya) (Quit: bye~) |
| 2023-04-24 20:26:22 +0200 | <monochrom> | There is always a custom plugin for <haskell> and I think <hask> (difference: block vs inline). |
| 2023-04-24 20:26:53 +0200 | Goodbye_Vincent | (cyvahl@198.244.205.143) (Remote host closed the connection) |
| 2023-04-24 20:27:07 +0200 | <monochrom> | And it has always been toggling between working and not working. |
| 2023-04-24 20:27:35 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) |
| 2023-04-24 20:27:51 +0200 | <monochrom> | <code> and <pre> always work. |
| 2023-04-24 20:30:19 +0200 | <monochrom> | Unpopular opinion: Get it to work before get it to look fancy. If <haskell> buys you colours at the price of being broken every 5 years, I say KISS and use <code> or <pre>. |
| 2023-04-24 20:30:42 +0200 | <tomsmeding> | every 5 years could've been worse |
| 2023-04-24 20:31:12 +0200 | <tomsmeding> | my university uses MS Teams, and that breaks every few weeks |
| 2023-04-24 20:31:17 +0200 | <tomsmeding> | in various interesting ways |
| 2023-04-24 20:34:53 +0200 | cassiopea | (~cassiopea@user/cassiopea) (Remote host closed the connection) |
| 2023-04-24 20:39:14 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-04-24 20:41:03 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-04-24 20:48:12 +0200 | hueso_ | (~root@user/hueso) |
| 2023-04-24 20:48:39 +0200 | hueso | (~root@user/hueso) (Read error: Connection reset by peer) |
| 2023-04-24 20:50:16 +0200 | gehmehgeh | gmg |
| 2023-04-24 20:52:01 +0200 | <bionade24> | int-e: Did you or someone else report this in #haskell-infra ? I don't want this to be forgotten again. |
| 2023-04-24 20:52:40 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2023-04-24 20:53:36 +0200 | int-e | didn't |
| 2023-04-24 21:00:02 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-04-24 21:04:28 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) (Remote host closed the connection) |
| 2023-04-24 21:04:40 +0200 | <fbytez> | Is there a standard function / operator that curries functions in reverse order to `.`? |
| 2023-04-24 21:04:47 +0200 | msavoritias | (cb716af6b3@irc.cheogram.com) (Ping timeout: 246 seconds) |
| 2023-04-24 21:05:00 +0200 | img | (~img@user/img) |
| 2023-04-24 21:05:08 +0200 | polykernel[m] | (~polykerne@user/polykernel) (Quit: issued !quit command) |
| 2023-04-24 21:05:11 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) |
| 2023-04-24 21:05:18 +0200 | <tomsmeding> | :t (>>>) |
| 2023-04-24 21:05:20 +0200 | <lambdabot> | forall k (cat :: k -> k -> *) (a :: k) (b :: k) (c :: k). Category cat => cat a b -> cat b c -> cat a c |
| 2023-04-24 21:05:26 +0200 | <tomsmeding> | :t (>>>) @(->) |
| 2023-04-24 21:05:27 +0200 | <lambdabot> | error: parse error on input ‘->’ |
| 2023-04-24 21:05:34 +0200 | <tomsmeding> | % :set -XTypeApplications |
| 2023-04-24 21:05:34 +0200 | <yahb2> | <no output> |
| 2023-04-24 21:05:39 +0200 | <fbytez> | Is it in prelude? |
| 2023-04-24 21:05:43 +0200 | <tomsmeding> | % :t (Control.Category.>>>) @(->) |
| 2023-04-24 21:05:43 +0200 | <yahb2> | (Control.Category.>>>) @(->) ; :: Control.Category.Category (->) => (a -> b) -> (b -> c) -> a -> c |
| 2023-04-24 21:05:51 +0200 | <tomsmeding> | no, it's there |
| 2023-04-24 21:05:58 +0200 | <fbytez> | Right, thanks very much. |
| 2023-04-24 21:06:22 +0200 | <tomsmeding> | % :t (Control.Category.<<<) @(->) -- fbytez this is just (.) with a different name |
| 2023-04-24 21:06:22 +0200 | <yahb2> | (Control.Category.<<<) @(->) -- fbytez this is just (.) with a different name ; :: Control.Category.Category (->) => (b -> c) -> (a -> b) -> a -> c |
| 2023-04-24 21:06:31 +0200 | <tomsmeding> | lol double mention, sorry |
| 2023-04-24 21:06:50 +0200 | <fbytez> | No problem at all. |
| 2023-04-24 21:10:50 +0200 | <fbytez> | What am I doing here? Needs some form of quoting? -- `import Control.Category (>>>)` |
| 2023-04-24 21:10:58 +0200 | rburkholder | (~blurb@96.45.2.121) (Ping timeout: 276 seconds) |
| 2023-04-24 21:11:00 +0200 | <fbytez> | *doing wrong |
| 2023-04-24 21:11:59 +0200 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) |
| 2023-04-24 21:14:18 +0200 | <fbytez> | error: parse error on input ‘>>>’ |
| 2023-04-24 21:16:51 +0200 | <jean-paul[m]> | you need more () |
| 2023-04-24 21:17:00 +0200 | <jean-paul[m]> | the outer set of ( ) introduces your import list |
| 2023-04-24 21:17:30 +0200 | <jean-paul[m]> | then a set of ( ) around >>> lets you identify the thing-with-a-funny-name |
| 2023-04-24 21:18:05 +0200 | <jean-paul[m]> | like if you wanted to refer to >>> as a value, you would `x = (>>>)`, not `x = >>>` |
| 2023-04-24 21:18:10 +0200 | <fbytez> | Because of it being an infix operator? |
| 2023-04-24 21:18:10 +0200 | Square2 | (~Square4@user/square) |
| 2023-04-24 21:19:16 +0200 | <jean-paul[m]> | Actually I'm not sure what the essential cause is, maybe someone else can enlighten us |
| 2023-04-24 21:19:32 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-04-24 21:19:48 +0200 | unit73e | (~emanuel@2001:818:e8dd:7c00:656:e5ff:fe72:9d36) |
| 2023-04-24 21:22:19 +0200 | <geekosaur> | it turns an infix operator into a prefix function |
| 2023-04-24 21:22:36 +0200 | <geekosaur> | conversely `` turns a prefix function into an infix operator |
| 2023-04-24 21:23:10 +0200 | <unit73e> | I just found out that haddock has SVG like this one here: https://hackage.haskell.org/package/active-0.2.0.17/docs/Data-Active.html#g:7 |
| 2023-04-24 21:23:13 +0200 | <unit73e> | very neat imo |
| 2023-04-24 21:26:34 +0200 | polykernel[m] | (~polykerne@user/polykernel) |
| 2023-04-24 21:27:15 +0200 | polykernel[m] | (~polykerne@user/polykernel) () |
| 2023-04-24 21:30:51 +0200 | opticblast | (~Thunderbi@172.58.85.88) |
| 2023-04-24 21:38:58 +0200 | nehsou^ | (~nehsou@c-76-105-96-13.hsd1.ga.comcast.net) |
| 2023-04-24 21:40:56 +0200 | ft | (~ft@p4fc2a88b.dip0.t-ipconnect.de) |
| 2023-04-24 21:42:03 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) (Remote host closed the connection) |
| 2023-04-24 21:42:32 +0200 | aeroplane | (~user@user/aeroplane) (Ping timeout: 252 seconds) |
| 2023-04-24 21:42:46 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) |
| 2023-04-24 21:43:20 +0200 | <fbytez> | Thanks, jean-paul[m] and geekosaur. |
| 2023-04-24 21:43:36 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2023-04-24 21:45:06 +0200 | zer0bitz_ | (~zer0bitz@2001:2003:f443:d600:d2a:4f3:eccf:87eb) |
| 2023-04-24 21:45:49 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2023-04-24 21:46:15 +0200 | zer0bitz | (~zer0bitz@dsl-hkibng32-54f843-214.dhcp.inet.fi) (Ping timeout: 255 seconds) |
| 2023-04-24 21:49:59 +0200 | Square2 | Square |
| 2023-04-24 21:53:30 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-24 21:55:20 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-04-24 21:56:18 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-04-24 21:56:33 +0200 | opticblast | (~Thunderbi@172.58.85.88) (Remote host closed the connection) |
| 2023-04-24 21:57:06 +0200 | opticblast | (~june@172.58.85.88) |
| 2023-04-24 21:58:08 +0200 | opticblast | (~june@172.58.85.88) () |
| 2023-04-24 21:58:18 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2023-04-24 21:59:35 +0200 | opticblast | (~june@172.58.85.88) |
| 2023-04-24 22:00:33 +0200 | opticblast | (~june@172.58.85.88) (Client Quit) |
| 2023-04-24 22:04:44 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-04-24 22:08:56 +0200 | jlwoodwa | (~june@172.58.85.88) |
| 2023-04-24 22:09:28 +0200 | jlwoodwa | (~june@172.58.85.88) (Client Quit) |
| 2023-04-24 22:09:35 +0200 | son0p | (~ff@181.136.122.143) |
| 2023-04-24 22:09:50 +0200 | jlwoodwa | (~june@172.58.85.88) |
| 2023-04-24 22:19:39 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) (Remote host closed the connection) |
| 2023-04-24 22:20:20 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) |
| 2023-04-24 22:21:01 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-04-24 22:23:21 +0200 | jlwoodwa | (~june@172.58.85.88) (Quit: leaving) |
| 2023-04-24 22:24:14 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-04-24 22:24:21 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-d11e-aa70-1ef3-2bb0.rev.sfr.net) (Remote host closed the connection) |
| 2023-04-24 22:27:35 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2023-04-24 22:28:00 +0200 | Thilastiko | (~user@user/Thilastiko) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2023-04-24 22:28:41 +0200 | Guest7 | (~Guest7@2001:a62:19ac:e601:62bf:be94:859d:59bd) |
| 2023-04-24 22:29:00 +0200 | Guest7 | (~Guest7@2001:a62:19ac:e601:62bf:be94:859d:59bd) (Client Quit) |
| 2023-04-24 22:33:52 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-04-24 22:33:52 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-04-24 22:33:52 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-04-24 22:46:31 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 276 seconds) |
| 2023-04-24 22:47:18 +0200 | tosyl | (~user@103.206.114.87) |
| 2023-04-24 22:48:36 +0200 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-04-24 22:49:30 +0200 | coot | (~coot@213.134.170.228) |
| 2023-04-24 22:51:17 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::fba) |
| 2023-04-24 22:56:48 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-04-24 22:58:38 +0200 | tosyl | (~user@103.206.114.87) (Quit: ##french) |
| 2023-04-24 22:58:39 +0200 | pyook | (~puke@user/puke) |
| 2023-04-24 23:00:39 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) (Remote host closed the connection) |
| 2023-04-24 23:01:21 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) |
| 2023-04-24 23:01:27 +0200 | yurideabreu_ | (~yurideabr@189.6.27.58) |
| 2023-04-24 23:01:28 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 276 seconds) |
| 2023-04-24 23:04:05 +0200 | tosyl | (~user@103.206.114.114) |
| 2023-04-24 23:07:25 +0200 | pyook | (~puke@user/puke) (Ping timeout: 240 seconds) |
| 2023-04-24 23:10:02 +0200 | accord | (uid568320@id-568320.hampstead.irccloud.com) |
| 2023-04-24 23:17:03 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-04-24 23:28:08 +0200 | <fbytez> | If anyone is interested, the following is a simple irc privmsg binary, which is what you've been helping me with: https://paste.tomsmeding.com/blh01bZQ |
| 2023-04-24 23:30:45 +0200 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection) |
| 2023-04-24 23:33:54 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-d11e-aa70-1ef3-2bb0.rev.sfr.net) |
| 2023-04-24 23:41:54 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) (Read error: Connection reset by peer) |
| 2023-04-24 23:42:36 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) |
| 2023-04-24 23:56:15 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |