Logs: liberachat/#haskell
| 2021-06-14 15:32:39 | <DigitalKiwi> | (tbh i'm not ok either but pretty sure people knew that lol) |
| 2021-06-14 15:32:56 | <shapr> | I think I'll try the VELDT getting started repo today after work. |
| 2021-06-14 15:32:57 | Obo | hugs DigitalKiwi |
| 2021-06-14 15:33:01 | shapr | hugs DigitalKiwi |
| 2021-06-14 15:33:04 | <shapr> | hugs are good |
| 2021-06-14 15:33:04 | <tomsmeding> | lambdabot is also quite ok if you feed it a snack |
| 2021-06-14 15:33:05 | × | iamarpandey quits (~iamarpand@110.235.238.174) (Client Quit) |
| 2021-06-14 15:33:08 | <tomsmeding> | @botsnack |
| 2021-06-14 15:33:08 | <shapr> | @botsnack |
| 2021-06-14 15:33:09 | <lambdabot> | :) |
| 2021-06-14 15:33:09 | <lambdabot> | :) |
| 2021-06-14 15:33:11 | <shapr> | yay! |
| 2021-06-14 15:33:12 | <tomsmeding> | :D |
| 2021-06-14 15:33:22 | × | fishfinger quits (~fishfinge@cpc68330-cdif16-2-0-cust557.5-1.cable.virginm.net) (Read error: Connection reset by peer) |
| 2021-06-14 15:33:29 | <shapr> | so this will be my fun after work: https://github.com/standardsemiconductor/VELDT-getting-started |
| 2021-06-14 15:33:30 | × | ddellacosta quits (~ddellacos@86.106.121.230) (Ping timeout: 244 seconds) |
| 2021-06-14 15:33:31 | <DigitalKiwi> | OH NO I HAVE BEEN HUGGED |
| 2021-06-14 15:33:32 | × | jmcarthur quits (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) (Client Quit) |
| 2021-06-14 15:33:35 | → | fishfinger joins (~fishfinge@cpc68330-cdif16-2-0-cust557.5-1.cable.virginm.net) |
| 2021-06-14 15:34:03 | <tomsmeding> | https://xkcd.com/2419/ |
| 2021-06-14 15:34:54 | <DigitalKiwi> | shapr: is this the hearing aid project |
| 2021-06-14 15:35:17 | → | jmcarthur joins (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) |
| 2021-06-14 15:35:49 | → | hemlock joins (~hemlock@wsip-70-163-92-141.tu.ok.cox.net) |
| 2021-06-14 15:36:11 | <tomsmeding> | shapr: that cabal.project template contains a comment that I find disturbing |
| 2021-06-14 15:36:15 | <tomsmeding> | "'large-tuples' generates tuple instances for various classes up to the GHC imposed maximum of 62 elements. This severely slows down compiling Clash, and triggers Template Haskell bugs on Windows. Hence, we disable it by default. This will be the default for Clash >=1.4." |
| 2021-06-14 15:36:32 | <tomsmeding> | in particular the "Template Haskell bugs on Windows" |
| 2021-06-14 15:36:43 | <DigitalKiwi> | https://hackage.haskell.org/package/arduino-copilot i have one of these blink on an uno |
| 2021-06-14 15:36:48 | <shapr> | DigitalKiwi: nah, I haven't picked up the hearing aid project in awhile, but that's a good reminder. |
| 2021-06-14 15:36:55 | <tomsmeding> | why would having large tuples bring problems on a particular operating system only |
| 2021-06-14 15:37:02 | × | jmcarthur quits (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) (Client Quit) |
| 2021-06-14 15:37:44 | <shapr> | I don't know, but it sounds like an adventure I would rather not have today. |
| 2021-06-14 15:39:20 | <[exa]> | tomsmeding: any program may trigger halting problem unexplainability, but windows loves doing it |
| 2021-06-14 15:41:12 | <shapr> | DigitalKiwi: I mostly want to get comfy writing FPGA code. If I reach that, I have some ideas for speeding up FPGA place and route that probably won't work, but will be fun to read about. |
| 2021-06-14 15:42:05 | <shapr> | I still find it strange that I haven't found any FPGA bitstreams used to speed up FPGA development. Seems like that should exist. |
| 2021-06-14 15:47:22 | <DigitalKiwi> | probably does exist somewhere proprietary |
| 2021-06-14 15:47:29 | × | nschoe quits (~quassel@2a04:cec0:10b8:624e:c4a3:2667:fa41:694c) (Read error: Connection reset by peer) |
| 2021-06-14 15:48:22 | → | degraafk joins (sid71464@id-71464.tooting.irccloud.com) |
| 2021-06-14 15:49:56 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 272 seconds) |
| 2021-06-14 15:51:02 | → | Bartosz joins (~textual@24.35.90.211) |
| 2021-06-14 15:51:18 | → | nschoe joins (~quassel@178.251.84.79) |
| 2021-06-14 15:51:57 | <nshepperd2> | one source of potential os-specific large-tuple bugs i can imagine is deforestation/inlining leading to allocating lots of registers |
| 2021-06-14 15:53:26 | → | fef joins (~thedawn@user/thedawn) |
| 2021-06-14 15:54:07 | <[exa]> | nshepperd2: like that some certain OS would break register contents? |
| 2021-06-14 15:54:15 | <[exa]> | that sounds pretty harsh |
| 2021-06-14 15:54:48 | <tomsmeding> | and that also sounds like a bug that should manifest in a lot of other places, if true |
| 2021-06-14 15:57:00 | <nshepperd2> | i don't know |
| 2021-06-14 15:57:38 | <geekosaur> | I'm under the impression Windows has a very different notion of things like caller-saves registers and registers used to access DLL data than Unix-derived systems |
| 2021-06-14 15:57:42 | <nshepperd2> | the thing about bugs is that something has to go wrong |
| 2021-06-14 15:58:42 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:b9b1:9fc2:289f:a533) (Remote host closed the connection) |
| 2021-06-14 15:59:19 | → | hnOsmium0001 joins (uid453710@id-453710.stonehaven.irccloud.com) |
| 2021-06-14 15:59:42 | <geekosaur> | that said, I find it difficult to believe that TH is related to registers since on the one hand TH itself is bytecode and on the other what it generates is too high level to involve registers |
| 2021-06-14 16:00:00 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-06-14 16:00:24 | <geekosaur> | unless they're bytecode-linking to objects in other packages, but that one should show up in lots of other packages on Windows |
| 2021-06-14 16:00:39 | <DigitalKiwi> | i find a lot of bugs so it's quite possible i'm meeting your quota too |
| 2021-06-14 16:00:58 | <nshepperd2> | huh, i thought TH used to be compiled to object code and dynamically loaded into ghc? |
| 2021-06-14 16:01:06 | → | lbseale joins (~lbseale@user/ep1ctetus) |
| 2021-06-14 16:01:09 | → | ddellacosta joins (~ddellacos@89.45.224.125) |
| 2021-06-14 16:01:30 | <geekosaur> | bytecode is a large part of why TH is so slow |
| 2021-06-14 16:03:37 | → | fizbin joins (~fizbin@2601:8a:4080:1280:8c7e:5b3f:79d6:ec26) |
| 2021-06-14 16:03:40 | × | bfrk quits (~bfrk@200116b8451b0900bae0ed5ddd267e3d.dip.versatel-1u1.de) (Ping timeout: 244 seconds) |
| 2021-06-14 16:04:25 | × | hemlock quits (~hemlock@wsip-70-163-92-141.tu.ok.cox.net) (Read error: Connection reset by peer) |
| 2021-06-14 16:04:59 | × | wonko quits (~wjc@62.115.229.50) (Ping timeout: 268 seconds) |
| 2021-06-14 16:05:13 | × | ddellacosta quits (~ddellacos@89.45.224.125) (Ping timeout: 244 seconds) |
| 2021-06-14 16:06:09 | × | jumper149 quits (~jumper149@80.240.31.34) (Quit: WeeChat 3.1) |
| 2021-06-14 16:07:05 | × | NanoC quits (~NanoCoast@p200300e127264d001d3a04d52b588e67.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2021-06-14 16:07:30 | × | chomwitt quits (~Pitsikoko@2a02:587:dc02:b00:98b0:cd42:bd6f:8295) (Ping timeout: 264 seconds) |
| 2021-06-14 16:08:45 | → | xprlgjf joins (~gavin@60.27.93.209.dyn.plus.net) |
| 2021-06-14 16:09:18 | × | yd502 quits (~yd502@2409:891e:320:209e:f07d:9f0f:e489:cc37) (Ping timeout: 268 seconds) |
| 2021-06-14 16:09:40 | × | dunkeln quits (~dunkeln@94.129.65.28) (Ping timeout: 244 seconds) |
| 2021-06-14 16:09:55 | → | hemlock joins (~hemlock@2607:fb90:96f5:984c:fcd7:c5eb:b752:8ad5) |
| 2021-06-14 16:09:56 | <kuribas> | is there a library that can read a record subset from a superset? |
| 2021-06-14 16:10:02 | <kuribas> | using generics? |
| 2021-06-14 16:10:23 | × | fishfinger quits (~fishfinge@cpc68330-cdif16-2-0-cust557.5-1.cable.virginm.net) (Ping timeout: 244 seconds) |
| 2021-06-14 16:11:14 | <[exa]> | kuribas: we did something similar with surgery, but not sure if that's desirable for simple usecases |
| 2021-06-14 16:11:41 | → | fishfinger joins (~fishfinge@cpc68330-cdif16-2-0-cust557.5-1.cable.virginm.net) |
| 2021-06-14 16:12:08 | <[exa]> | (the package is `generic-data-surgery`) |
| 2021-06-14 16:12:09 | → | tzh joins (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2021-06-14 16:12:30 | <kuribas> | it would save me a moderate amount of boilerplate |
| 2021-06-14 16:12:42 | <kuribas> | Currently I am abusing RecordWildCards for it :) |
| 2021-06-14 16:12:45 | × | Bartosz quits (~textual@24.35.90.211) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-06-14 16:13:13 | <kuribas> | [exa]: that library looks complicated |
| 2021-06-14 16:13:24 | → | Bartosz joins (~textual@24.35.90.211) |
| 2021-06-14 16:13:49 | → | amahl joins (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) |
| 2021-06-14 16:14:19 | <[exa]> | kuribas: it's not that bad, the use usually reduces to a simple scheme like `fromOR . removeSomeFields . toOR` |
| 2021-06-14 16:14:21 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2021-06-14 16:14:36 | → | tinco joins (~tinco@tinco.nl) |
| 2021-06-14 16:15:14 | <kuribas> | maybe I'll roll my own with generics-eot |
| 2021-06-14 16:15:38 | → | lbseale_ joins (~lbseale@user/ep1ctetus) |
| 2021-06-14 16:15:40 | <kuribas> | oh, that's not powerful enough |
| 2021-06-14 16:16:04 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-06-14 16:16:39 | <[exa]> | like, I was sold just the name of the operating room for types |
| 2021-06-14 16:16:46 | <[exa]> | and it worked, so I left it there :D |
| 2021-06-14 16:16:46 | <kuribas> | yeah :) |
| 2021-06-14 16:17:02 | <kuribas> | [exa]: by do I need to manually remove fields? |
| 2021-06-14 16:17:06 | <kuribas> | or can it detect them? |
| 2021-06-14 16:17:10 | × | fishfinger quits (~fishfinge@cpc68330-cdif16-2-0-cust557.5-1.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2021-06-14 16:17:46 | <[exa]> | not sure, we had datatypes with `id` that were falling out of some database adaptor (likely selda) and we were removing the `id` and some other db-specific stuff |
| 2021-06-14 16:18:02 | <kuribas> | yeah, that's my usecase as well |
| 2021-06-14 16:18:19 | <[exa]> | I'm not sure if you can do "everything except these fields" |
| 2021-06-14 16:18:36 | × | amahl quits (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) (Remote host closed the connection) |
All times are in UTC.