| 2024-07-31 00:01:36 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-07-31 00:03:07 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-31 00:03:22 +0200 | zero | yin |
| 2024-07-31 00:03:42 +0200 | <yin> | i made a pretty |
| 2024-07-31 00:04:00 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-31 00:04:00 +0200 | <yin> | > take 7 $ iterate (recip . succ) 1 :: [Rational] |
| 2024-07-31 00:04:01 +0200 | <lambdabot> | [1 % 1,1 % 2,2 % 3,3 % 5,5 % 8,8 % 13,13 % 21] |
| 2024-07-31 00:04:37 +0200 | <xerox> | quite |
| 2024-07-31 00:05:19 +0200 | <yin> | i call it the phi bonacci sequence |
| 2024-07-31 00:07:11 +0200 | <yin> | i got the idea from the c |
| 2024-07-31 00:07:37 +0200 | <ncf> | nice |
| 2024-07-31 00:07:52 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Ping timeout: 272 seconds) |
| 2024-07-31 00:08:03 +0200 | <yin> | *continued fraction expansion of phi |
| 2024-07-31 00:08:37 +0200 | <yin> | it approximates phi as the list goes on |
| 2024-07-31 00:09:30 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-07-31 00:09:52 +0200 | <yin> | (recip . succ) being (\x -> 1 / (1 + x)) |
| 2024-07-31 00:12:56 +0200 | MadeleineSydney | (~Thunderbi@c-71-229-185-228.hsd1.co.comcast.net) (Quit: MadeleineSydney) |
| 2024-07-31 00:13:14 +0200 | MadeleineSydney | (~Thunderbi@c-71-229-185-228.hsd1.co.comcast.net) |
| 2024-07-31 00:13:42 +0200 | <monochrom> | Yeah that is beautiful :) |
| 2024-07-31 00:14:32 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 00:17:12 +0200 | AlexNoo_ | (~AlexNoo@94.233.241.125) |
| 2024-07-31 00:18:14 +0200 | AlexZenon | (~alzenon@94.233.241.102) (Ping timeout: 260 seconds) |
| 2024-07-31 00:18:38 +0200 | AlexNoo | (~AlexNoo@94.233.241.102) (Ping timeout: 265 seconds) |
| 2024-07-31 00:18:50 +0200 | AlexNoo_ | AlexNoo |
| 2024-07-31 00:19:10 +0200 | pavonia | (~user@user/siracusa) |
| 2024-07-31 00:22:38 +0200 | AlexNoo_ | (~AlexNoo@94.233.241.125) |
| 2024-07-31 00:23:04 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2024-07-31 00:23:50 +0200 | AlexNoo | (~AlexNoo@94.233.241.125) (Ping timeout: 255 seconds) |
| 2024-07-31 00:24:31 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-07-31 00:24:34 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 00:24:44 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-31 00:24:46 +0200 | Square2 | (~Square@user/square) |
| 2024-07-31 00:24:48 +0200 | AlexNoo_ | AlexNoo |
| 2024-07-31 00:27:16 +0200 | <yin> | haskell makes it nice to look at |
| 2024-07-31 00:31:45 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 276 seconds) |
| 2024-07-31 00:34:38 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 00:39:39 +0200 | Midjak | (~MarciZ@82.66.147.146) |
| 2024-07-31 00:46:08 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 00:51:01 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb663100542eb9ff72dc.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2024-07-31 00:53:33 +0200 | <int-e> | > fix ((1:) . (>>= sequence [id, recip] . succ)) :: [Rational] |
| 2024-07-31 00:53:35 +0200 | <lambdabot> | [1 % 1,2 % 1,1 % 2,3 % 1,1 % 3,3 % 2,2 % 3,4 % 1,1 % 4,4 % 3,3 % 4,5 % 2,2 %... |
| 2024-07-31 00:53:45 +0200 | AlexZenon | (~alzenon@94.233.241.125) |
| 2024-07-31 00:59:56 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Quit: Lost terminal) |
| 2024-07-31 01:04:16 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-31 01:04:19 +0200 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2024-07-31 01:05:41 +0200 | gawen | (~gawen@user/gawen) |
| 2024-07-31 01:05:50 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-07-31 01:08:19 +0200 | harveypwca | (~harveypwc@2601:246:d080:b40:1889:d9bf:2dd8:b288) (Quit: Leaving) |
| 2024-07-31 01:08:32 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Ping timeout: 252 seconds) |
| 2024-07-31 01:23:15 +0200 | ZharMeny | (~user@user/ZharMeny) (Quit: This space was intentionally left blank.) |
| 2024-07-31 01:32:34 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-07-31 01:32:47 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-07-31 01:34:39 +0200 | Square3 | (~Square4@user/square) |
| 2024-07-31 01:34:59 +0200 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2024-07-31 01:37:34 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 260 seconds) |
| 2024-07-31 01:37:38 +0200 | Square2 | (~Square@user/square) (Ping timeout: 255 seconds) |
| 2024-07-31 01:38:37 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-07-31 01:50:06 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-07-31 01:54:37 +0200 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
| 2024-07-31 01:54:56 +0200 | gentauro | (~gentauro@user/gentauro) |
| 2024-07-31 01:56:37 +0200 | Rodney- | (~Rodney@90.201.223.82) (Ping timeout: 248 seconds) |
| 2024-07-31 01:59:54 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2024-07-31 02:10:59 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2024-07-31 02:11:38 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-07-31 02:19:32 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-31 02:22:48 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-07-31 02:28:24 +0200 | tt1231097832 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) |
| 2024-07-31 02:29:51 +0200 | tt123109783 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Ping timeout: 252 seconds) |
| 2024-07-31 02:29:53 +0200 | tt1231097832 | tt123109783 |
| 2024-07-31 02:35:31 +0200 | wryish | (~wryish@2605:4c40:119:efa3:0:727d:19eb:1) (Ping timeout: 264 seconds) |
| 2024-07-31 02:36:37 +0200 | <Axman6> | raehik: RE: using Integer, remember that Integer is defined as something like data Integer = Small !Int | Large !Sign !Natural, so for 99% of cases you will be using an Int (this is one of the things that's lead to Haskell implementations of the functions found in GMP being faster in many cases, because there's much less bookkeeping) |
| 2024-07-31 02:43:19 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-31 02:43:47 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 255 seconds) |
| 2024-07-31 02:44:00 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-31 02:44:14 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds) |
| 2024-07-31 02:44:49 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 260 seconds) |
| 2024-07-31 02:44:58 +0200 | euleritian | (~euleritia@dynamic-176-006-133-039.176.6.pool.telefonica.de) |
| 2024-07-31 02:45:51 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) |
| 2024-07-31 02:48:16 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 02:49:03 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 02:49:11 +0200 | wryish | (~wryish@2605:4c40:119:efa3:0:727d:19eb:1) |
| 2024-07-31 02:52:07 +0200 | sp1ff | (~user@c-73-11-70-111.hsd1.wa.comcast.net) (Read error: Connection reset by peer) |
| 2024-07-31 02:52:22 +0200 | sp1ff | (~user@c-73-11-70-111.hsd1.wa.comcast.net) |
| 2024-07-31 02:56:41 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 265 seconds) |
| 2024-07-31 02:57:26 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-07-31 02:59:24 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-07-31 03:04:02 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 255 seconds) |
| 2024-07-31 03:05:27 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2024-07-31 03:11:59 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-07-31 03:12:18 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 276 seconds) |
| 2024-07-31 03:12:38 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 265 seconds) |
| 2024-07-31 03:24:55 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 03:25:04 +0200 | <raehik> | Axman6: yeah thanks, that's something I know but haven't rly internalized |
| 2024-07-31 03:30:20 +0200 | <c_wraith> | Unlike Int, though, Integer doesn't unpack into registers nicely with good use patterns |
| 2024-07-31 03:30:54 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2024-07-31 03:32:00 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2024-07-31 03:32:37 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 03:38:52 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 03:40:31 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 03:48:08 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 255 seconds) |
| 2024-07-31 03:48:40 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-31 03:55:14 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9e38:497d:6793:e966) (Ping timeout: 272 seconds) |
| 2024-07-31 04:01:22 +0200 | <Axman6> | Not that that's going to matter much in the context of file IO |
| 2024-07-31 04:03:00 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 276 seconds) |
| 2024-07-31 04:04:30 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-07-31 04:08:33 +0200 | nadja | (~dequbed@banana-new.kilobyte22.de) (Ping timeout: 252 seconds) |
| 2024-07-31 04:08:49 +0200 | td_ | (~td@i53870934.versanet.de) (Ping timeout: 260 seconds) |
| 2024-07-31 04:08:51 +0200 | nadja | (~dequbed@banana-new.kilobyte22.de) |
| 2024-07-31 04:10:15 +0200 | td_ | (~td@i53870916.versanet.de) |
| 2024-07-31 04:14:44 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 04:22:09 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2024-07-31 04:25:31 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 04:30:29 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-79-84.fiber.dynamic.sonic.net) |
| 2024-07-31 04:30:55 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 04:43:32 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2024-07-31 04:44:46 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 04:45:49 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-07-31 04:46:22 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2024-07-31 04:51:01 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2024-07-31 04:52:25 +0200 | spew | (~spew@201.141.102.132) |
| 2024-07-31 04:54:17 +0200 | spew_ | (~spew@201.141.102.132) |
| 2024-07-31 04:55:15 +0200 | spew | (~spew@201.141.102.132) (Killed (NickServ (GHOST command used by spew_))) |
| 2024-07-31 04:55:21 +0200 | spew_ | spew |
| 2024-07-31 05:04:50 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 05:07:35 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-79-84.fiber.dynamic.sonic.net) (Remote host closed the connection) |
| 2024-07-31 05:10:10 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-31 05:10:54 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 05:12:21 +0200 | aforemny_ | (~aforemny@2001:9e8:6cfe:4d00:6761:b6ac:73fc:a888) (Ping timeout: 252 seconds) |
| 2024-07-31 05:12:45 +0200 | aforemny | (~aforemny@2001:9e8:6ce0:2100:2fa7:a1ac:c8c:437) |
| 2024-07-31 05:14:28 +0200 | hayk | (~hayk@141.136.90.108) (Quit: hayk) |
| 2024-07-31 05:14:31 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 05:17:08 +0200 | tabaqui | (~root@87.200.123.114) (Ping timeout: 252 seconds) |
| 2024-07-31 05:21:09 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2024-07-31 05:21:11 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-07-31 05:29:00 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-07-31 05:32:05 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-07-31 05:36:33 +0200 | dolio | (~dolio@130.44.140.168) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-07-31 05:40:00 +0200 | dolio | (~dolio@130.44.140.168) |
| 2024-07-31 05:44:48 +0200 | dolio | (~dolio@130.44.140.168) (Client Quit) |
| 2024-07-31 05:46:37 +0200 | hayk | (~hayk@141.136.90.108) |
| 2024-07-31 05:47:37 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-07-31 05:49:58 +0200 | dolio | (~dolio@130.44.140.168) |
| 2024-07-31 05:51:11 +0200 | hayk | (~hayk@141.136.90.108) (Quit: hayk) |
| 2024-07-31 05:52:49 +0200 | tt123109783 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Ping timeout: 248 seconds) |
| 2024-07-31 06:01:17 +0200 | spew | (~spew@201.141.102.132) (Read error: Connection reset by peer) |
| 2024-07-31 06:06:14 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-31 06:08:44 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 06:13:46 +0200 | spew | (~spew@201.141.102.132) |
| 2024-07-31 06:14:49 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2024-07-31 06:16:09 +0200 | spew | (~spew@201.141.102.132) (Client Quit) |
| 2024-07-31 06:30:02 +0200 | euleritian | (~euleritia@dynamic-176-006-133-039.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-31 06:30:19 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-31 06:37:02 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-07-31 06:37:23 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-07-31 06:56:53 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 248 seconds) |
| 2024-07-31 06:57:07 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-31 07:02:22 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-07-31 07:16:30 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 07:25:09 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 276 seconds) |
| 2024-07-31 07:30:04 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-07-31 07:44:07 +0200 | Kryder | (~Kryder@90.201.223.82) |
| 2024-07-31 07:53:20 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-07-31 07:53:36 +0200 | euleritian | (~euleritia@dynamic-176-006-141-095.176.6.pool.telefonica.de) |
| 2024-07-31 07:56:52 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) (Quit: on the move) |
| 2024-07-31 07:57:48 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-07-31 08:06:08 +0200 | CiaoSen | (~Jura@2a05:5800:2d3:d800:e6b9:7aff:fe80:3d03) |
| 2024-07-31 08:15:21 +0200 | euleritian | (~euleritia@dynamic-176-006-141-095.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-31 08:16:31 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 08:17:44 +0200 | yobson_ | (~yobson@mail.jotron.com) |
| 2024-07-31 08:18:34 +0200 | euleritian | (~euleritia@dynamic-176-006-141-095.176.6.pool.telefonica.de) |
| 2024-07-31 08:22:16 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (Quit: ZNC - https://znc.in) |
| 2024-07-31 08:23:59 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) |
| 2024-07-31 08:24:36 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 08:26:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-31 08:42:30 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 08:45:08 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb37989a4326b80d30bf.dip0.t-ipconnect.de) |
| 2024-07-31 08:47:26 +0200 | michalz | (~michalz@185.246.207.203) |
| 2024-07-31 08:49:02 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 265 seconds) |
| 2024-07-31 08:50:05 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Ping timeout: 255 seconds) |
| 2024-07-31 09:06:09 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-07-31 09:06:31 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 09:10:17 +0200 | vgtw | (~vgtw@user/vgtw) (Quit: ZNC - https://znc.in) |
| 2024-07-31 09:14:58 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2024-07-31 09:16:30 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 09:19:27 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-31 09:20:46 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-07-31 09:21:12 +0200 | pieguy128_ | (~pieguy128@65.93.192.80) |
| 2024-07-31 09:21:15 +0200 | pieguy128 | (~pieguy128@bras-base-mtrlpq5031w-grc-45-67-70-24-166.dsl.bell.ca) (Ping timeout: 252 seconds) |
| 2024-07-31 09:22:29 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-07-31 09:25:11 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 255 seconds) |
| 2024-07-31 09:25:41 +0200 | MadeleineSydney | (~Thunderbi@c-71-229-185-228.hsd1.co.comcast.net) (Remote host closed the connection) |
| 2024-07-31 09:29:16 +0200 | euleritian | (~euleritia@dynamic-176-006-141-095.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-31 09:30:02 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-31 09:37:41 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) |
| 2024-07-31 09:37:44 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) (Max SendQ exceeded) |
| 2024-07-31 09:38:24 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3218-c520-d177-6cba-1578-0ee5.rev.sfr.net) |
| 2024-07-31 09:38:57 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) |
| 2024-07-31 09:39:02 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) (Max SendQ exceeded) |
| 2024-07-31 09:40:19 +0200 | john2 | (~john@203.94.52.182) |
| 2024-07-31 09:41:19 +0200 | john2 | (~john@203.94.52.182) (Quit: WeeChat 4.0.5) |
| 2024-07-31 09:43:03 +0200 | danse-118 | (~danse-nr3@user/danse-nr3) |
| 2024-07-31 09:43:21 +0200 | john2 | (~john@2406:5a00:241a:5600:28be:5350:975b:80b7) |
| 2024-07-31 09:43:23 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) (Read error: Connection reset by peer) |
| 2024-07-31 09:44:04 +0200 | john2 | (~john@2406:5a00:241a:5600:28be:5350:975b:80b7) (Client Quit) |
| 2024-07-31 09:50:45 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 09:55:31 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 244 seconds) |
| 2024-07-31 09:56:11 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-07-31 10:02:45 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 10:05:42 +0200 | <kuribas> | sbcl lisp automatically does upscaling of integers, so they are small integer by default, but are converted to big integer on overflow. |
| 2024-07-31 10:05:59 +0200 | <kuribas> | It's quite performant. But I think ghc doesn't do that. |
| 2024-07-31 10:07:12 +0200 | <Hecate> | nor should it, because the behaviour is also quite different with check arithmetic |
| 2024-07-31 10:07:17 +0200 | <Hecate> | *checked |
| 2024-07-31 10:08:39 +0200 | chele | (~chele@user/chele) |
| 2024-07-31 10:09:07 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 264 seconds) |
| 2024-07-31 10:09:47 +0200 | <kuribas> | I mean, Integer could do something like that to make it more efficient when the values are small. |
| 2024-07-31 10:11:31 +0200 | <kuribas> | Rather than always dispatching to GMP, to have special logic and generate optimal assembly. |
| 2024-07-31 10:12:31 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 10:13:48 +0200 | <kuribas> | In which case you would only need Int in an inner loop, where it really matters. |
| 2024-07-31 10:15:43 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-07-31 10:16:41 +0200 | ft | (~ft@p3e9bc4e7.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-07-31 10:16:58 +0200 | <kuribas> | I used to be sceptical, but some testing shows that SBCL is similar to GHC in performance (with explicit annotations). |
| 2024-07-31 10:18:54 +0200 | <JuanDaugherty> | it's the default free lisp but you can't rely on just it |
| 2024-07-31 10:19:19 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 264 seconds) |
| 2024-07-31 10:20:02 +0200 | <JuanDaugherty> | a lot of stuff the compiles uncomplainingly in ACL, LW or whatever wont even in sbcl |
| 2024-07-31 10:20:11 +0200 | <JuanDaugherty> | *that compiles |
| 2024-07-31 10:20:36 +0200 | <JuanDaugherty> | cl is not like hs in this regard |
| 2024-07-31 10:21:52 +0200 | <JuanDaugherty> | insofar as one overdominating implementation |
| 2024-07-31 10:22:23 +0200 | <kuribas> | What do you mean? SBCL should be compliant with the clisp spec. But different lisp flavours have often incompatible features. |
| 2024-07-31 10:22:26 +0200 | <kuribas> | Like scheme. |
| 2024-07-31 10:22:31 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 10:22:57 +0200 | <JuanDaugherty> | the cl spec is a moving target |
| 2024-07-31 10:23:29 +0200 | <JuanDaugherty> | i used cmucl until it forked into sbcl |
| 2024-07-31 10:24:05 +0200 | <JuanDaugherty> | youd think it would converge to basically unchanging thing but somehow that isnt the case |
| 2024-07-31 10:24:24 +0200 | <JuanDaugherty> | after almost 20 y |
| 2024-07-31 10:25:13 +0200 | <JuanDaugherty> | it's my default cl, still not same situation as with ghc |
| 2024-07-31 10:25:32 +0200 | <kuribas> | Well, I dont' care that much about CLISP, other than being a nice historical artifact. I used to work in a codebases that was full of undocumented DSLs and macros, pretty hard to get into for anyone but the guy who wrote it. |
| 2024-07-31 10:25:56 +0200 | <JuanDaugherty> | you've confused clisp |
| 2024-07-31 10:26:15 +0200 | <JuanDaugherty> | it's a different lineage and isnt a spec or the basis of one |
| 2024-07-31 10:26:34 +0200 | <kuribas> | common-lisp |
| 2024-07-31 10:26:41 +0200 | <kuribas> | the language, not the implementation. |
| 2024-07-31 10:27:20 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-07-31 10:27:20 +0200 | <JuanDaugherty> | ok, cl, common lisp would be the usage, for the obvious reason of collision with the implementation |
| 2024-07-31 10:27:40 +0200 | <JuanDaugherty> | the spec is ansi lisp |
| 2024-07-31 10:27:50 +0200 | <kuribas> | Well, this software was basically its own language on top of lisp. |
| 2024-07-31 10:28:21 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2024-07-31 10:29:12 +0200 | <danse-118> | to be fair also haskell can get quite far with undocumented stuff. And if you argue that types are documentation by themselves, one could reply any implementation is |
| 2024-07-31 10:30:23 +0200 | <kuribas> | Yeah, I find haskell is more restistant to making large undocumented programs. Lisp makes it easy. |
| 2024-07-31 10:30:26 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 255 seconds) |
| 2024-07-31 10:30:50 +0200 | <danse-118> | i just argued the opposite |
| 2024-07-31 10:31:25 +0200 | <kuribas> | I rather take an undocumented haskell program than an undocumented lisp (or other dynamic language) one. |
| 2024-07-31 10:31:59 +0200 | <danse-118> | can agree with that, but it's quite subjective |
| 2024-07-31 10:32:04 +0200 | danse-118 | (~danse-nr3@user/danse-nr3) (Quit: on the move) |
| 2024-07-31 10:32:21 +0200 | Square3 | (~Square4@user/square) (Ping timeout: 276 seconds) |
| 2024-07-31 10:32:34 +0200 | <kuribas> | I find that in dynamic languages, people don't try to understand the code, they just run it in the REPL or in the debugger, and try to see how it behaves. |
| 2024-07-31 10:32:46 +0200 | <kuribas> | It's a different philosophy. |
| 2024-07-31 10:33:15 +0200 | <Franciman> | it's the same in haskell |
| 2024-07-31 10:33:32 +0200 | <Franciman> | but in haskell it is much harder to get the code to execute lol |
| 2024-07-31 10:33:55 +0200 | <Lears> | People (including myself) do a variant of that in Haskell to. I often just write the simplest code that I know will compile, and write the next-simplest compiling program if the previous didn't do what I wanted. |
| 2024-07-31 10:34:03 +0200 | <Lears> | too* |
| 2024-07-31 10:34:41 +0200 | <kuribas> | I prefer modular code, where the types give already a lot of information. |
| 2024-07-31 10:36:20 +0200 | <kuribas> | But true, lispy languages have the best REPLs. |
| 2024-07-31 10:36:57 +0200 | Square3 | (~Square4@user/square) |
| 2024-07-31 10:38:04 +0200 | <kuribas> | Lears: I find writing new code with a dynamic language, reasonably easy. It gets hard when you need to refactor or change existing code. Especially when you didn't write it. |
| 2024-07-31 10:39:25 +0200 | <kuribas> | Lears: I really enjoy typed hole driven programming. I don't even have to write the whole program, just leave parts as holes that are boring but tedious. |
| 2024-07-31 10:39:46 +0200 | <kuribas> | I only fill it when I am happy with the structure. |
| 2024-07-31 10:41:46 +0200 | <kuribas> | It's just a different style of programming. |
| 2024-07-31 10:42:17 +0200 | <kuribas> | In lisp or (dynamic) python, you write your code and as you write it test in the REPL or use unit tests. |
| 2024-07-31 10:43:02 +0200 | <kuribas> | As in haskell, I write is much as I can, then do a small test in the REPL (or some unit tests if it the logic is complicated). |
| 2024-07-31 10:44:07 +0200 | JuanDaugherty | ftr: https://en.wikipedia.org/wiki/CLISP not to be confused with the lineage of cl that descends from kyoto lisp, the c based lisps as a genre |
| 2024-07-31 10:44:30 +0200 | <kuribas> | right |
| 2024-07-31 10:45:02 +0200 | Square3 | (~Square4@user/square) (Ping timeout: 265 seconds) |
| 2024-07-31 10:45:12 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-31 10:45:40 +0200 | john2 | (~john@2406:5a00:241a:5600:bd8e:6941:a113:3361) |
| 2024-07-31 10:46:09 +0200 | Guest|36 | (~Guest|36@103.200.86.240) |
| 2024-07-31 10:46:19 +0200 | Guest|36 | (~Guest|36@103.200.86.240) (Client Quit) |
| 2024-07-31 10:46:34 +0200 | <kuribas> | I think that the need for full unit test coverage on what is mostly CRUD and light data processing, just comes from the frailty of dynamic languages. |
| 2024-07-31 10:47:27 +0200 | <kuribas> | For example, in clojure I can have a typo that changes the logic, but may not even trigger a runtime error. |
| 2024-07-31 10:47:48 +0200 | <kuribas> | like (:foo_bar mydata), instead of (:foo-bar mydata). |
| 2024-07-31 10:48:08 +0200 | <kuribas> | If the first field doesn't exist, it will always return nil. |
| 2024-07-31 10:49:01 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-07-31 10:49:38 +0200 | <kuribas> | I had weird and confusing error messages from misplacing a paren. |
| 2024-07-31 10:51:27 +0200 | <lisbeths> | do you folks know if the z combinator works in python? |
| 2024-07-31 10:53:21 +0200 | <kuribas> | lisbeths: why wouldn't it? |
| 2024-07-31 10:53:47 +0200 | <lisbeths> | I am trying to implement factorial in pure lambda calculus in python but I keep reaching the recursion limit on even the lowest integer input |
| 2024-07-31 10:54:10 +0200 | <danse-nr3> | maybe there is some library for trampoline |
| 2024-07-31 10:54:12 +0200 | <kuribas> | right, python and recursion don't go so well together. |
| 2024-07-31 10:54:21 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-07-31 10:54:31 +0200 | <danse-nr3> | https://pypi.org/project/trampoline/ |
| 2024-07-31 10:54:40 +0200 | <kuribas> | > Increasing the recursion limit: Python has a default maximum recursion depth of 1000. If a function exceeds this limit, it can be increased using the sys. setrecursionlimit(n) function |
| 2024-07-31 10:54:42 +0200 | <lambdabot> | <hint>:1:46: error: parse error on input ‘default’ |
| 2024-07-31 10:55:29 +0200 | <kuribas> | https://docs.python.org/3/library/sys.html#sys.setrecursionlimit |
| 2024-07-31 10:56:12 +0200 | <danse-nr3> | increasing the limit may not be a great idea if they keep pushing on the stack |
| 2024-07-31 10:56:45 +0200 | <kuribas> | This is not production code, right? |
| 2024-07-31 10:57:18 +0200 | john2 | synchromesh |
| 2024-07-31 10:57:30 +0200 | <kuribas> | You could write an interpreter in python that doesn't use the stack for recursion. |
| 2024-07-31 10:57:47 +0200 | <danse-nr3> | i mean what's wrong with the link above kuribas? |
| 2024-07-31 10:58:08 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-07-31 10:59:12 +0200 | <kuribas> | danse-nr3: nothing, I haven't looked at it... |
| 2024-07-31 10:59:19 +0200 | euleritian | (~euleritia@dynamic-176-006-141-095.176.6.pool.telefonica.de) |
| 2024-07-31 10:59:45 +0200 | <kuribas> | but yeah, something like that. |
| 2024-07-31 11:01:39 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-31 11:07:16 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-07-31 11:07:53 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Ping timeout: 245 seconds) |
| 2024-07-31 11:08:07 +0200 | euleritian | (~euleritia@dynamic-176-006-141-095.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-31 11:08:16 +0200 | <bwe> | newtype Decimal' = Decimal -- I am defining Decimal' to define instances for Decimal; however it requires some argument, why? |
| 2024-07-31 11:08:25 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-31 11:08:51 +0200 | <kuribas> | newtypes are wrappers, here you don't wrap anything. |
| 2024-07-31 11:09:05 +0200 | <kuribas> | wrappers at type level, and runtime there is no wrapping. |
| 2024-07-31 11:09:19 +0200 | <bwe> | my issue is if I do `newtype Decimal' a = Decimal a`, I need to supply `a` which I don't have. |
| 2024-07-31 11:09:31 +0200 | <kuribas> | bwe: maybe you want "newtype Decimal' = Decimal' Decimal"? |
| 2024-07-31 11:11:36 +0200 | <danse-nr3> | :t Decimal |
| 2024-07-31 11:11:37 +0200 | <lambdabot> | error: |
| 2024-07-31 11:11:37 +0200 | <lambdabot> | • Data constructor not in scope: Decimal |
| 2024-07-31 11:11:38 +0200 | <lambdabot> | • Perhaps you meant variable ‘decimal’ (imported from Numeric.Lens) |
| 2024-07-31 11:12:00 +0200 | <danse-nr3> | hoogle Decimal |
| 2024-07-31 11:12:23 +0200 | <danse-nr3> | uff i'd better not |
| 2024-07-31 11:16:06 +0200 | <lisbeths> | if I was to take arbitrary lambda expressions and write a compiler that compiled from those lambda expressions to some assembly language, is there a strategy to do that and it would it have any advantage over interpreted lambdas? |
| 2024-07-31 11:16:22 +0200 | <lisbeths> | If you are talking about any arbitrary lambda I am not sure it actually (can) be compiled |
| 2024-07-31 11:16:30 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 11:16:42 +0200 | zetef | (~quassel@2a02:2f00:5202:1200:3fa2:e908:b522:fa2f) |
| 2024-07-31 11:16:45 +0200 | zetef | (~quassel@2a02:2f00:5202:1200:3fa2:e908:b522:fa2f) (Client Quit) |
| 2024-07-31 11:19:13 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-07-31 11:20:03 +0200 | <bwe> | kuribas: that's actually what I want |
| 2024-07-31 11:21:21 +0200 | <kuribas> | lisbeths: sure, you could generate python AST, and then use numba to make optimal assembly. But at that point, is python really the right language? |
| 2024-07-31 11:21:47 +0200 | <lisbeths> | well the python people are telling me I should not use python to encode the lambdas |
| 2024-07-31 11:22:13 +0200 | <kuribas> | lisbeths: but what is the goal, is this just a toy interpreter? |
| 2024-07-31 11:22:28 +0200 | <lisbeths> | I am trying to develop an easieness oriented programming language |
| 2024-07-31 11:23:09 +0200 | <kuribas> | well, you're on #haskell, I'd say haskell is the better language to make an interpreter or compiler. |
| 2024-07-31 11:23:30 +0200 | <kuribas> | First make an interpreter for your language so you know it works, and you can adjust the semantics. |
| 2024-07-31 11:23:45 +0200 | <kuribas> | Write an optimal compiler when you're happy with it. |
| 2024-07-31 11:24:02 +0200 | <kuribas> | And when your user base > 1 :) |
| 2024-07-31 11:25:19 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 264 seconds) |
| 2024-07-31 11:25:27 +0200 | <kuribas> | lisbeths: but focus first on designing your language, have a working prototype that can get people interested. |
| 2024-07-31 11:26:21 +0200 | <kuribas> | lisbeths: python is already slow and interpreted. If you write another interpreter in it, it will be slow squared. |
| 2024-07-31 11:26:58 +0200 | <Lears> | Ultra-hack: secretly transpile your simple language into Haskell and invoke ghc |
| 2024-07-31 11:27:06 +0200 | <lisbeths> | the design of the language is complete |
| 2024-07-31 11:27:14 +0200 | <lisbeths> | making the an interpreter for it isnt an issue |
| 2024-07-31 11:27:22 +0200 | <lisbeths> | it is the idea of compiling a lambda that confuses me |
| 2024-07-31 11:27:54 +0200 | <kuribas> | lisbeths: you have a working interpreter? |
| 2024-07-31 11:28:17 +0200 | <lisbeths> | yes in python but the z combinator doesnt work on it |
| 2024-07-31 11:28:55 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 252 seconds) |
| 2024-07-31 11:29:14 +0200 | <kuribas> | yeah, what Leary says :) |
| 2024-07-31 11:30:27 +0200 | <lisbeths> | unfortunately ghc is too large for what I want |
| 2024-07-31 11:30:34 +0200 | <lisbeths> | thanks though I think my questions ahve been answered |
| 2024-07-31 11:30:48 +0200 | <kuribas> | lisbeths: you don't need to ship GHC |
| 2024-07-31 11:30:58 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-07-31 11:31:06 +0200 | <lisbeths> | perhaps not |
| 2024-07-31 11:31:10 +0200 | <kuribas> | If you write an interpreter, chances are the executable is smaller than the python executable. |
| 2024-07-31 11:31:26 +0200 | <kuribas> | You could put it in a docker image. |
| 2024-07-31 11:32:23 +0200 | <lisbeths> | I think I'm gonna use binary lambda calculus as the interpreter |
| 2024-07-31 11:37:27 +0200 | <kuribas> | I would just increase recursion depth and don't worry about it. |
| 2024-07-31 11:37:58 +0200 | <kuribas> | Worry about efficiency when your language has adopters. |
| 2024-07-31 11:39:40 +0200 | <lisbeths> | the python folks have assured me it isnt good to do deep lambdas in python so I have given up on that |
| 2024-07-31 11:40:39 +0200 | <lisbeths> | my target has got to be a very memory and filesize efficient binary that takes a lambda from stdin, interprets it, and prints the result ot stdout, kind of like binary lambda calculus or sector lisp. but haskell could do that too |
| 2024-07-31 11:40:57 +0200 | <lisbeths> | has to be under 1 meg |
| 2024-07-31 11:41:21 +0200 | <kuribas> | Yeah, if the goal is efficiency, then forget Python. |
| 2024-07-31 11:41:40 +0200 | <lisbeths> | the goal is not efficiency in terms of speed performance |
| 2024-07-31 11:41:49 +0200 | <kuribas> | memory? |
| 2024-07-31 11:41:59 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2024-07-31 11:42:14 +0200 | <lisbeths> | if we get into my design constraints its gonna be a very long off topic discussion |
| 2024-07-31 11:42:24 +0200 | gehmehgeh | gmg |
| 2024-07-31 11:42:44 +0200 | <lisbeths> | ideally it will be under 64 kilobytes in filesize |
| 2024-07-31 11:42:46 +0200 | <kuribas> | lisbeths: yeah :) You should pick what are the most familiar with. But you are in #haskell, so I would assume you are familiar with haskell? |
| 2024-07-31 11:42:57 +0200 | <lisbeths> | sorry my original question was about lambdas |
| 2024-07-31 11:43:14 +0200 | <kuribas> | lisbeths: In that case neither Python nor haskell. Maybe C or rust? |
| 2024-07-31 11:43:54 +0200 | <lisbeths> | I am envisioning a kind of a SIMD in fortran :) |
| 2024-07-31 11:44:18 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) |
| 2024-07-31 11:44:20 +0200 | <kuribas> | SIMD isn't going to help a lot with lambda calculus. |
| 2024-07-31 11:44:25 +0200 | <lisbeths> | y |
| 2024-07-31 11:45:23 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 245 seconds) |
| 2024-07-31 11:46:10 +0200 | euleritian | (~euleritia@dynamic-176-006-141-095.176.6.pool.telefonica.de) |
| 2024-07-31 11:46:31 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 11:51:55 +0200 | <kuribas> | lisbeths: https://github.com/catseye/minischeme (52kb) |
| 2024-07-31 11:52:27 +0200 | <lisbeths> | ty I will review that |
| 2024-07-31 11:54:29 +0200 | hljhcjwzzh | (~anton@m90-131-33-112.cust.tele2.lt) |
| 2024-07-31 11:54:58 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 11:55:56 +0200 | <kuribas> | lisbeths: this one is 47k (stripped) https://github.com/jiribenes/scheme |
| 2024-07-31 11:56:18 +0200 | <lisbeths> | one constraint is I need it to be able to fill its memory container |
| 2024-07-31 11:56:49 +0200 | <kuribas> | What does that mean? |
| 2024-07-31 11:57:08 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) (Quit: Leaving) |
| 2024-07-31 11:57:27 +0200 | <lisbeths> | I want to use 64 terrabytes of swap for lambdas if the user asks for it |
| 2024-07-31 11:58:18 +0200 | <kuribas> | You have to try it. |
| 2024-07-31 11:59:43 +0200 | <kuribas> | But these requirements are quite wild. Who makes them? |
| 2024-07-31 12:00:19 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3218-c520-d177-6cba-1578-0ee5.rev.sfr.net) (Remote host closed the connection) |
| 2024-07-31 12:00:44 +0200 | <lisbeths> | These design constraints are decided by a committee of 1 |
| 2024-07-31 12:01:03 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3218-c520-d177-6cba-1578-0ee5.rev.sfr.net) |
| 2024-07-31 12:08:10 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 252 seconds) |
| 2024-07-31 12:09:15 +0200 | <kuribas> | In that case I would try to find some harder constraints to make your life a pain ;-) |
| 2024-07-31 12:15:06 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-31 12:15:54 +0200 | CiaoSen | (~Jura@2a05:5800:2d3:d800:e6b9:7aff:fe80:3d03) (Ping timeout: 260 seconds) |
| 2024-07-31 12:18:31 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 12:19:24 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Ping timeout: 260 seconds) |
| 2024-07-31 12:21:08 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2) |
| 2024-07-31 12:32:44 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 12:46:35 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 12:46:45 +0200 | Guest|71 | (~Guest|71@88-165-143-97.subs.proxad.net) |
| 2024-07-31 12:54:50 +0200 | lucyy | (228ee8f0ce@user/lucyy) |
| 2024-07-31 12:55:31 +0200 | ZharMeny | (~user@user/ZharMeny) |
| 2024-07-31 12:56:05 +0200 | xff0x | (~xff0x@2405:6580:b080:900:bf97:1fa8:4185:9e6) |
| 2024-07-31 12:56:56 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 13:00:17 +0200 | CiaoSen | (~Jura@2a05:5800:2d3:d800:e6b9:7aff:fe80:3d03) |
| 2024-07-31 13:00:25 +0200 | tabaqui | (~root@87.200.123.114) |
| 2024-07-31 13:00:32 +0200 | Guest|71 | (~Guest|71@88-165-143-97.subs.proxad.net) (Quit: Connection closed) |
| 2024-07-31 13:07:52 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) (Quit: lunch time) |
| 2024-07-31 13:08:07 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-07-31 13:16:35 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 13:23:18 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 276 seconds) |
| 2024-07-31 13:32:12 +0200 | tabaqui | (~root@87.200.123.114) (Ping timeout: 272 seconds) |
| 2024-07-31 13:34:28 +0200 | hljhcjwzzh | (~anton@m90-131-33-112.cust.tele2.lt) (Read error: Connection reset by peer) |
| 2024-07-31 13:36:37 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 13:39:03 +0200 | hljhcjwzzh | (~anton@m90-131-45-211.cust.tele2.lt) |
| 2024-07-31 13:41:38 +0200 | kuribas` | (~user@d51529C17.access.telenet.be) |
| 2024-07-31 13:42:30 +0200 | kuribas | (~user@ptr-17d51emnm92g51m299m.18120a2.ip6.access.telenet.be) (Ping timeout: 252 seconds) |
| 2024-07-31 13:45:11 +0200 | hayk | (~hayk@141.136.90.108) |
| 2024-07-31 13:45:15 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 13:52:24 +0200 | hljhcjwzzh | (~anton@m90-131-45-211.cust.tele2.lt) (Ping timeout: 252 seconds) |
| 2024-07-31 14:03:18 +0200 | euleritian | (~euleritia@dynamic-176-006-141-095.176.6.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2024-07-31 14:07:41 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2024-07-31 14:12:30 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3218-c520-d177-6cba-1578-0ee5.rev.sfr.net) (Remote host closed the connection) |
| 2024-07-31 14:17:58 +0200 | yobson_ | (~yobson@mail.jotron.com) (Quit: Leaving...) |
| 2024-07-31 14:20:23 +0200 | alexherbo2 | (~alexherbo@2a02-8440-330e-0e0a-60e8-33b1-b3f8-3bce.rev.sfr.net) |
| 2024-07-31 14:26:30 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-07-31 14:27:35 +0200 | hayk | (~hayk@141.136.90.108) (Ping timeout: 255 seconds) |
| 2024-07-31 14:31:47 +0200 | hayk | (~hayk@141.136.90.108) |
| 2024-07-31 14:33:36 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-07-31 14:36:45 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 14:45:12 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 14:46:44 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 14:53:06 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2024-07-31 14:54:39 +0200 | hayk | (~hayk@141.136.90.108) (Quit: hayk) |
| 2024-07-31 14:56:25 +0200 | euleritian | (~euleritia@dynamic-176-000-161-036.176.0.pool.telefonica.de) |
| 2024-07-31 14:59:01 +0200 | hayk | (~hayk@141.136.90.108) |
| 2024-07-31 15:03:19 +0200 | euleritian | (~euleritia@dynamic-176-000-161-036.176.0.pool.telefonica.de) (Ping timeout: 260 seconds) |
| 2024-07-31 15:03:21 +0200 | califax_ | (~califax@user/califx) |
| 2024-07-31 15:03:30 +0200 | euleritian | (~euleritia@dynamic-176-002-077-099.176.2.pool.telefonica.de) |
| 2024-07-31 15:03:41 +0200 | califax | (~califax@user/califx) (Ping timeout: 260 seconds) |
| 2024-07-31 15:03:50 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-07-31 15:04:38 +0200 | califax_ | califax |
| 2024-07-31 15:06:07 +0200 | CiaoSen | (~Jura@2a05:5800:2d3:d800:e6b9:7aff:fe80:3d03) (Ping timeout: 264 seconds) |
| 2024-07-31 15:17:38 +0200 | euleritian | (~euleritia@dynamic-176-002-077-099.176.2.pool.telefonica.de) (Ping timeout: 265 seconds) |
| 2024-07-31 15:18:32 +0200 | euleritian | (~euleritia@dynamic-176-004-145-017.176.4.pool.telefonica.de) |
| 2024-07-31 15:37:18 +0200 | alexherbo2 | (~alexherbo@2a02-8440-330e-0e0a-60e8-33b1-b3f8-3bce.rev.sfr.net) (Remote host closed the connection) |
| 2024-07-31 15:43:01 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) () |
| 2024-07-31 15:48:26 +0200 | euleritian | (~euleritia@dynamic-176-004-145-017.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-31 15:48:44 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-31 15:51:37 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-79-84.fiber.dynamic.sonic.net) |
| 2024-07-31 15:51:58 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 15:57:21 +0200 | falafel | (~falafel@2a0c:5a84:e301:4d01::5c13) |
| 2024-07-31 15:59:29 +0200 | alexherbo2 | (~alexherbo@2a02-8440-330e-0e0a-60e8-33b1-b3f8-3bce.rev.sfr.net) |
| 2024-07-31 16:02:45 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-07-31 16:05:11 +0200 | alexherbo2 | (~alexherbo@2a02-8440-330e-0e0a-60e8-33b1-b3f8-3bce.rev.sfr.net) (Remote host closed the connection) |
| 2024-07-31 16:08:38 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) |
| 2024-07-31 16:10:11 +0200 | nate_b | (~u0_a123@pool-72-74-69-99.bstnma.fios.verizon.net) () |
| 2024-07-31 16:16:31 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-07-31 16:19:07 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-07-31 16:19:43 +0200 | <haskellbridge> | <Bowuigi> lisbeths You could try compiling to combinators if you want to reduce size. Oleg Kiselyov's Eta-optimized algorithm seems to give smaller expressions than the input itself |
| 2024-07-31 16:19:55 +0200 | ystael | (~ystael@user/ystael) |
| 2024-07-31 16:21:51 +0200 | <haskellbridge> | <Bowuigi> Inlining is optional as well, shouldn't be too hard to serialize expressions, then paste them one after the other and then make an index on the header so you can quickly get each definition |
| 2024-07-31 16:23:58 +0200 | <haskellbridge> | <Bowuigi> Haven't tried mixing it with SIMD or any other big optimization method yet, but the gains should be decent, a lot of the combinators can be parallelized without issues |
| 2024-07-31 16:25:02 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 16:27:51 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-31 16:35:03 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-07-31 16:39:32 +0200 | chessai | (sid225296@id-225296.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-31 16:49:34 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-07-31 16:55:19 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-31 16:56:34 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-31 16:58:10 +0200 | synchromesh | (~john@2406:5a00:241a:5600:bd8e:6941:a113:3361) (Read error: Connection reset by peer) |
| 2024-07-31 16:59:44 +0200 | john2 | (~john@2406:5a00:241a:5600:bd8e:6941:a113:3361) |
| 2024-07-31 17:02:48 +0200 | john4 | (~john@203.94.52.182) |
| 2024-07-31 17:02:57 +0200 | billchenchina- | (~billchenc@210.110.131.49) |
| 2024-07-31 17:05:04 +0200 | john2 | (~john@2406:5a00:241a:5600:bd8e:6941:a113:3361) (Ping timeout: 260 seconds) |
| 2024-07-31 17:05:13 +0200 | billchenchina- | (~billchenc@210.110.131.49) (Client Quit) |
| 2024-07-31 17:08:31 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 17:09:04 +0200 | jerg | (~jerg@2001:a61:2553:4500::bb0) |
| 2024-07-31 17:09:06 +0200 | jerg | (~jerg@2001:a61:2553:4500::bb0) (Remote host closed the connection) |
| 2024-07-31 17:15:33 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3200-de93-9920-774e-e427-67e7.rev.sfr.net) |
| 2024-07-31 17:19:24 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2) |
| 2024-07-31 17:20:10 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 17:20:53 +0200 | falafel | (~falafel@2a0c:5a84:e301:4d01::5c13) (Ping timeout: 244 seconds) |
| 2024-07-31 17:21:22 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) (Read error: Connection reset by peer) |
| 2024-07-31 17:22:38 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Read error: Connection reset by peer) |
| 2024-07-31 17:22:55 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-07-31 17:23:12 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) |
| 2024-07-31 17:23:57 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) |
| 2024-07-31 17:24:37 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-31 17:26:36 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 17:29:58 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 245 seconds) |
| 2024-07-31 17:30:49 +0200 | euleritian | (~euleritia@dynamic-176-004-145-017.176.4.pool.telefonica.de) |
| 2024-07-31 17:32:37 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 248 seconds) |
| 2024-07-31 17:33:01 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-07-31 17:38:01 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 17:41:59 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3200-de93-9920-774e-e427-67e7.rev.sfr.net) (Remote host closed the connection) |
| 2024-07-31 17:42:56 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 17:44:28 +0200 | rvalue- | (~rvalue@user/rvalue) |
| 2024-07-31 17:45:15 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 276 seconds) |
| 2024-07-31 17:48:37 +0200 | rvalue- | rvalue |
| 2024-07-31 17:54:00 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 17:58:17 +0200 | dans76272 | (~danse-nr3@user/danse-nr3) |
| 2024-07-31 17:58:41 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 17:58:59 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) (Read error: Connection reset by peer) |
| 2024-07-31 18:00:10 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-31 18:00:44 +0200 | michalz_ | (~michalz@185.246.207.222) |
| 2024-07-31 18:02:22 +0200 | michalz | (~michalz@185.246.207.203) (Ping timeout: 252 seconds) |
| 2024-07-31 18:02:37 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit) |
| 2024-07-31 18:10:28 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 18:12:59 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) (Quit: oo_miguel) |
| 2024-07-31 18:17:56 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 18:21:40 +0200 | tabaqui | (~root@87.200.123.114) |
| 2024-07-31 18:22:54 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2024-07-31 18:23:52 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2024-07-31 18:24:38 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) |
| 2024-07-31 18:27:02 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-31 18:29:22 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 18:32:11 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) |
| 2024-07-31 18:36:01 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 18:37:01 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-31 18:42:25 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-07-31 18:46:17 +0200 | skyesoss | (~Thunderbi@128.135.204.35) |
| 2024-07-31 18:48:00 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 18:48:51 +0200 | euleritian | (~euleritia@dynamic-176-004-145-017.176.4.pool.telefonica.de) (Ping timeout: 265 seconds) |
| 2024-07-31 18:50:17 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-07-31 18:52:00 +0200 | kuribas` | (~user@d51529C17.access.telenet.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2024-07-31 18:54:14 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-07-31 18:54:41 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 18:59:45 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 19:00:38 +0200 | dans76272 | (~danse-nr3@user/danse-nr3) (Quit: off) |
| 2024-07-31 19:01:53 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2024-07-31 19:04:39 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2024-07-31 19:05:46 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 19:11:41 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-07-31 19:16:51 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 19:21:50 +0200 | ft | (~ft@p3e9bc4e7.dip0.t-ipconnect.de) |
| 2024-07-31 19:22:41 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 19:23:30 +0200 | Midjak | (~MarciZ@82.66.147.146) |
| 2024-07-31 19:23:34 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) (Quit: oo_miguel) |
| 2024-07-31 19:23:41 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 255 seconds) |
| 2024-07-31 19:28:46 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-31 19:32:43 +0200 | spew | (~spew@201.141.102.132) |
| 2024-07-31 19:33:41 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-31 19:34:24 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 19:35:30 +0200 | spew | (~spew@201.141.102.132) (Client Quit) |
| 2024-07-31 19:40:46 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 19:40:48 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 272 seconds) |
| 2024-07-31 19:43:28 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-07-31 19:46:38 +0200 | spew | (~spew@201.141.102.132) |
| 2024-07-31 19:53:24 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 20:03:07 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-07-31 20:07:01 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 20:12:11 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-07-31 20:19:04 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 20:24:31 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 20:31:45 +0200 | hayk | (~hayk@141.136.90.108) (Quit: hayk) |
| 2024-07-31 20:36:26 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 20:42:01 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 20:42:04 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 260 seconds) |
| 2024-07-31 20:42:17 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-31 20:42:28 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 245 seconds) |
| 2024-07-31 20:46:52 +0200 | hayk | (~hayk@141.136.90.108) |
| 2024-07-31 20:47:21 +0200 | <constxd> | hey bros |
| 2024-07-31 20:48:17 +0200 | <constxd> | what is like the canonical example where @ in a pattern is useful |
| 2024-07-31 20:48:33 +0200 | <constxd> | like something that's really simple with @ but would be a bit awkward to write without it |
| 2024-07-31 20:50:01 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-07-31 20:50:14 +0200 | <monochrom> | bstInsert x t@(Node left key right) | x == key = t |
| 2024-07-31 20:50:28 +0200 | <dolio> | tails [] = |
| 2024-07-31 20:50:31 +0200 | <dolio> | Oops. |
| 2024-07-31 20:50:55 +0200 | <dolio> | @src tails |
| 2024-07-31 20:50:55 +0200 | <lambdabot> | tails [] = [[]] |
| 2024-07-31 20:50:55 +0200 | <lambdabot> | tails xxs@(_:xs) = xxs : tails xs |
| 2024-07-31 20:52:03 +0200 | hayk | (~hayk@141.136.90.108) (Ping timeout: 252 seconds) |
| 2024-07-31 20:52:05 +0200 | <constxd> | nice those are both pretty good |
| 2024-07-31 20:52:06 +0200 | <constxd> | thanks |
| 2024-07-31 20:53:54 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 20:59:18 +0200 | spew | (~spew@201.141.102.132) (Quit: spew) |
| 2024-07-31 20:59:31 +0200 | spew | (~spew@201.141.102.132) |
| 2024-07-31 21:00:06 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 21:01:19 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 21:07:41 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 21:21:34 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 21:24:26 +0200 | <EvanR> | any time you want to refer to the very thing you pattern matched, and don't want to reconstruct it long hand. Which is error prone anyway |
| 2024-07-31 21:25:04 +0200 | <EvanR> | a case of literal don't repeat yourself |
| 2024-07-31 21:27:31 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 21:29:51 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-31 21:37:39 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 21:38:58 +0200 | <jle`> | i sometimes act as if it can help with sharing too |
| 2024-07-31 21:39:11 +0200 | <jle`> | but i feel like ghc is smart enough to do it automatically |
| 2024-07-31 21:39:33 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 248 seconds) |
| 2024-07-31 21:39:39 +0200 | <EvanR> | haha yeah |
| 2024-07-31 21:43:51 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 21:51:27 +0200 | alexherbo2 | (~alexherbo@2a02-8440-321c-755c-19f5-1a66-63b5-46f3.rev.sfr.net) |
| 2024-07-31 21:54:18 +0200 | <probie> | GHC is "smart enough" to do it automatically, but chooses not to, trusting the programmer |
| 2024-07-31 21:54:30 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-07-31 21:55:06 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) |
| 2024-07-31 21:55:53 +0200 | <probie> | Just like it won't rewrite `f 0 = 1; f n = f (n-1) + f (n-1)` to `f 0 = 1; f n = let x = f (n-1) in x + x` |
| 2024-07-31 21:56:10 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 21:59:10 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-31 22:01:21 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 22:02:17 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 22:03:20 +0200 | <monochrom> | But it rewrites to 2 * f (n-1) under "f :: Int -> Int" and -O. https://play.haskell.org/saved/Ln5njJhL |
| 2024-07-31 22:04:36 +0200 | <monochrom> | Ever since https://mail.haskell.org/pipermail/haskell-cafe/2013-April/107775.html , I have learned the hard way that whenever I plan to claim "GHC won't optimize this" I must try it first. |
| 2024-07-31 22:05:23 +0200 | <monochrom> | Also whenever I claim "GHC will optimize this". GHC always does the opposite of what you think. OK, what I think. |
| 2024-07-31 22:07:15 +0200 | Square | (~Square@user/square) |
| 2024-07-31 22:08:42 +0200 | <mauke> | "I am saying that if a task uses both the predicates and the extraction functions, then it is much clearer and simpler to use pattern matching." <- even if it is just predicates, pattern matching isn't any more cumbersome |
| 2024-07-31 22:08:56 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 22:09:33 +0200 | <mauke> | if isNothing mx then "nada" else "it is something" vs. case mx of Nothing -> "nada"; Just{} -> "it is something" |
| 2024-07-31 22:09:51 +0200 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) (Quit: WeeChat 4.3.3) |
| 2024-07-31 22:11:19 +0200 | <mauke> | > (\case (:){} -> False; _ -> True) [1,2,3] |
| 2024-07-31 22:11:20 +0200 | <lambdabot> | False |
| 2024-07-31 22:11:31 +0200 | mulk | (~mulk@p5b112b2e.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2024-07-31 22:11:38 +0200 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) |
| 2024-07-31 22:12:31 +0200 | michalz_ | (~michalz@185.246.207.222) (Remote host closed the connection) |
| 2024-07-31 22:19:06 +0200 | <probie> | monochrom: Perhaps that should be "I must try it _at the point in time I'm claiming it_" |
| 2024-07-31 22:20:59 +0200 | mulk | (~mulk@p5b112b2e.dip0.t-ipconnect.de) |
| 2024-07-31 22:22:10 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 22:23:06 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-31 22:25:17 +0200 | <probie> | Ah right, I see what's going on. GHC's behaviour hasn't changed per se, it's just that monomorphising it to `Int` (or presumably anything else which is just a constructor wrapping an unboxed type) allows the rewrite |
| 2024-07-31 22:28:11 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 22:33:28 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds) |
| 2024-07-31 22:36:12 +0200 | benkard | (~mulk@p5b112b2e.dip0.t-ipconnect.de) |
| 2024-07-31 22:36:34 +0200 | mulk | (~mulk@p5b112b2e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2024-07-31 22:36:34 +0200 | benkard | mulk |
| 2024-07-31 22:40:00 +0200 | hayk | (~hayk@141.136.90.108) |
| 2024-07-31 22:40:12 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 22:40:18 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 252 seconds) |
| 2024-07-31 22:41:19 +0200 | euleritian | (~euleritia@dynamic-176-000-149-067.176.0.pool.telefonica.de) |
| 2024-07-31 22:46:51 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 260 seconds) |
| 2024-07-31 22:47:38 +0200 | euleritian | (~euleritia@dynamic-176-000-149-067.176.0.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-31 22:48:54 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-31 22:49:17 +0200 | alexherbo2 | (~alexherbo@2a02-8440-321c-755c-19f5-1a66-63b5-46f3.rev.sfr.net) (Remote host closed the connection) |
| 2024-07-31 22:50:27 +0200 | alexherbo2 | (~alexherbo@2a02-8440-321c-755c-a137-bc25-9803-4558.rev.sfr.net) |
| 2024-07-31 22:51:22 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-07-31 22:52:19 +0200 | <monochrom> | I'm actually a bit surprised that it does this to Int but not Integer. |
| 2024-07-31 22:52:53 +0200 | <monochrom> | For polymorphic (Num a =>) I would understand being conservative. |
| 2024-07-31 22:54:00 +0200 | alexherbo2 | (~alexherbo@2a02-8440-321c-755c-a137-bc25-9803-4558.rev.sfr.net) (Remote host closed the connection) |
| 2024-07-31 22:54:34 +0200 | <monochrom> | And yeah GHC keeps changing, so you have to re-try every time >:) |
| 2024-07-31 22:55:15 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-07-31 22:55:34 +0200 | <monochrom> | We already know that, for example, the strength reduction from "mod x 7" to "x * magic number" is showing up in new GHC versions. |
| 2024-07-31 22:55:55 +0200 | <spew> | Hello, I'm trying to `cabal install glirc` but the compile step is failing because it seems that warnings are being treated as errors in the C compiler. |
| 2024-07-31 22:56:23 +0200 | <spew> | for example "/tmp/ghc153147_0/ghc_220.c:15:160: error: warning: return discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] |
| 2024-07-31 22:56:53 +0200 | <spew> | fuller log is here: https://gist.github.com/spewspews/ebd212bc82603a1d697855c991573830 |
| 2024-07-31 22:57:43 +0200 | <spew> | is there a way to specify compiler flags or does someone know where I need to configure this? |
| 2024-07-31 22:58:38 +0200 | <mauke> | that's HsOpenSSL, not glirc |
| 2024-07-31 22:59:33 +0200 | <mauke> | https://github.com/haskell-cryptography/HsOpenSSL/issues/93 |
| 2024-07-31 22:59:53 +0200 | <spew> | thank you! |
| 2024-07-31 23:03:17 +0200 | <glguy> | spew: I need to make an HsOpenSSL PR, but I have a branch up one sec |
| 2024-07-31 23:03:32 +0200 | <glguy> | https://github.com/glguy/HsOpenSSL/tree/glguy/pointer-fixes |
| 2024-07-31 23:04:48 +0200 | <spew> | glguy: I appreciate it very much |
| 2024-07-31 23:05:44 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-07-31 23:11:59 +0200 | <mauke> | am annoyed that ConstPtr does not represent a const pointer |
| 2024-07-31 23:12:46 +0200 | <mauke> | or as the documentation calls it, "A pointer with the C const qualifier", which it is not |
| 2024-07-31 23:13:43 +0200 | <mauke> | also, capi is lucky that no API actually uses volatile qualifiers |
| 2024-07-31 23:13:47 +0200 | <glguy> | mauke: because the qualifier is on the type pointed to and not the pointer itself? |
| 2024-07-31 23:13:54 +0200 | <mauke> | right |
| 2024-07-31 23:14:14 +0200 | <mauke> | "a pointer with the const qualifier" in C syntax would be *const |
| 2024-07-31 23:17:32 +0200 | pavonia | (~user@user/siracusa) |
| 2024-07-31 23:21:27 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-31 23:24:18 +0200 | <glguy> | spew: I'm making HsOpenSSL a submodule to work around it being broken until a new released goes out https://github.com/glguy/irc-core/pull/122 |
| 2024-07-31 23:24:25 +0200 | tcard | (~tcard@2400:4051:5801:7500:1e90:74c3:2754:ce8a) (Quit: Leaving) |
| 2024-07-31 23:24:31 +0200 | <monochrom> | :( :) |
| 2024-07-31 23:25:28 +0200 | <glguy> | Good OpenSSL bindings are hard to come by. My other client has its own binding to avoid stuff like this |
| 2024-07-31 23:25:40 +0200 | <spew> | glguy: thanks, I subscribed to the PR |
| 2024-07-31 23:25:46 +0200 | <spew> | what's the other cilent? |
| 2024-07-31 23:26:33 +0200 | starburst | (~starburst@2601:602:480:9390::707d) |
| 2024-07-31 23:26:47 +0200 | <glguy> | https://github.com/glguy/snowcone - it's more of an automation host and server administration dashboard |
| 2024-07-31 23:27:43 +0200 | <glguy> | I sometimes use it as my actual chat client, but it's not really targetted at that usecase |
| 2024-07-31 23:32:12 +0200 | tcard | (~tcard@p4324234-ipxg22901hodogaya.kanagawa.ocn.ne.jp) |
| 2024-07-31 23:39:20 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 265 seconds) |
| 2024-07-31 23:41:09 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-07-31 23:44:48 +0200 | euleritian | (~euleritia@dynamic-176-000-149-067.176.0.pool.telefonica.de) |
| 2024-07-31 23:44:52 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Quit: Lost terminal) |
| 2024-07-31 23:51:38 +0200 | euleritian | (~euleritia@dynamic-176-000-149-067.176.0.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-31 23:51:56 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-31 23:53:14 +0200 | <yin> | "a functor is a structure preserving map between objects in different categories, and between their associated morphisms" can anyone give me an example in Haskell of a Functor and what 2 different categories might be? |
| 2024-07-31 23:54:11 +0200 | <EvanR> | Functor is between Hask and Hask |
| 2024-07-31 23:54:18 +0200 | <mauke> | haskell Functors are endofunctors in that they map between the same category |
| 2024-07-31 23:54:25 +0200 | <mauke> | (which might not actually be a category) |
| 2024-07-31 23:54:37 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-31 23:54:41 +0200 | <yin> | ok that's not confusing at all |
| 2024-07-31 23:54:46 +0200 | <mauke> | yes |
| 2024-07-31 23:54:47 +0200 | <EvanR> | the bad news is they're not different categories, the good news is they're not even categories |
| 2024-07-31 23:54:53 +0200 | <mauke> | haha |
| 2024-07-31 23:55:10 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-31 23:55:37 +0200 | <mauke> | but assuming Hask exists, the objects in it are Haskell types |
| 2024-07-31 23:55:45 +0200 | <mauke> | and the morphisms are functions |
| 2024-07-31 23:55:48 +0200 | <EvanR> | :k Maybe |
| 2024-07-31 23:55:49 +0200 | <lambdabot> | * -> * |
| 2024-07-31 23:56:02 +0200 | <EvanR> | :t fmap @Maybe |
| 2024-07-31 23:56:03 +0200 | <lambdabot> | error: |
| 2024-07-31 23:56:04 +0200 | <lambdabot> | Pattern syntax in expression context: fmap@Maybe |
| 2024-07-31 23:56:04 +0200 | <lambdabot> | Did you mean to enable TypeApplications? |
| 2024-07-31 23:56:08 +0200 | <EvanR> | yes |
| 2024-07-31 23:56:16 +0200 | <mauke> | a Haskell Functor turns types into (other) types and functions into (other) functions |
| 2024-07-31 23:56:50 +0200 | <mauke> | Maybe is a functor because it turns a type T into another type Maybe T |
| 2024-07-31 23:57:14 +0200 | <mauke> | the mapping of functions is done with fmap :: (a -> b) -> (Maybe a -> Maybe b) |
| 2024-07-31 23:57:24 +0200 | falafel | (~falafel@188.26.220.220) |
| 2024-07-31 23:57:25 +0200 | <EvanR> | (a -> b) -> (Maybe a -> Maybe b) |
| 2024-07-31 23:57:44 +0200 | <yin> | that makes sense |
| 2024-07-31 23:57:57 +0200 | <yin> | but since when are we doubting Hask's existence? |
| 2024-07-31 23:58:13 +0200 | <EvanR> | it's morally a category |
| 2024-07-31 23:58:17 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-07-31 23:58:18 +0200 | <monochrom> | I don't doubt it. |
| 2024-07-31 23:58:23 +0200 | <EvanR> | by fast and loose reasoning |
| 2024-07-31 23:58:50 +0200 | <mauke> | IIRC it's because we have no semantics and no equality |
| 2024-07-31 23:59:07 +0200 | <monochrom> | My impression is that no one has bothered to sit down and write down all the detailed definitions so people are conservative and say we don't have it. |