Logs: freenode/#haskell
| 2020-09-21 12:32:10 | <dminuoso> | My head kept thinking of this type alias as a newtype for so long, after 15 minutes in disbelief it didn't click. |
| 2020-09-21 12:32:12 | <dminuoso> | Thanks. |
| 2020-09-21 12:32:14 | <ski> | what's `SpecWith' ? |
| 2020-09-21 12:32:29 | <dminuoso> | type SpecWith a = SpecM a () |
| 2020-09-21 12:32:47 | <Cale> | (It doesn't matter for this question, it turns out) |
| 2020-09-21 12:33:05 | <ski> | (yea, i know. just wondering) |
| 2020-09-21 12:33:28 | <dminuoso> | This I think is a good example of why type aliases can be annoying. |
| 2020-09-21 12:33:30 | × | sQVe quits (~sQVe@unaffiliated/sqve) (Client Quit) |
| 2020-09-21 12:33:41 | <Cale> | Yeah, pretty much |
| 2020-09-21 12:33:56 | <Cale> | It would be clearer without the synonym |
| 2020-09-21 12:34:09 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-09-21 12:34:25 | × | p8m quits (p8m@gateway/vpn/protonvpn/p8m) (Ping timeout: 264 seconds) |
| 2020-09-21 12:34:43 | → | sQVe joins (~sQVe@unaffiliated/sqve) |
| 2020-09-21 12:34:55 | <ski> | aroundWith . flip . (runContT .) :: (b -> ContT () IO a) -> (SpecWith a -> SpecWith b) -- then |
| 2020-09-21 12:35:03 | → | p8m joins (p8m@gateway/vpn/protonvpn/p8m) |
| 2020-09-21 12:35:33 | × | Kaivo quits (~Kaivo@104-200-86-99.mc.derytele.com) (Quit: WeeChat 2.9) |
| 2020-09-21 12:36:02 | → | cybercraft joins (~Cybercraf@194.78.58.3) |
| 2020-09-21 12:37:58 | × | sQVe quits (~sQVe@unaffiliated/sqve) (Client Quit) |
| 2020-09-21 12:38:48 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 260 seconds) |
| 2020-09-21 12:39:14 | → | gmt joins (~gmt@pool-71-105-108-44.nycmny.fios.verizon.net) |
| 2020-09-21 12:40:04 | ← | iqubic` parts (~user@2601:602:9500:4870:ecd4:9584:1de:8f2d) ("ERC (IRC client for Emacs 28.0.50)") |
| 2020-09-21 12:40:28 | hackage | signable-haskell-protoc 0.1 - Signable instances protoc compiler plugin. https://hackage.haskell.org/package/signable-haskell-protoc-0.1 (coingaming) |
| 2020-09-21 12:41:05 | × | xerox_ quits (~xerox@unaffiliated/xerox) (Ping timeout: 240 seconds) |
| 2020-09-21 12:43:30 | → | argent0 joins (~argent0@168.227.97.4) |
| 2020-09-21 12:46:24 | × | rprije quits (~rprije@27.143.220.203.dial.dynamic.acc01-myal-dub.comindico.com.au) (Ping timeout: 260 seconds) |
| 2020-09-21 12:47:27 | → | thir joins (~thir@p200300f27f0fc600ed2222922a5678d5.dip0.t-ipconnect.de) |
| 2020-09-21 12:48:11 | → | tronical joins (~tronical@185.244.214.216) |
| 2020-09-21 12:50:21 | → | drbean joins (~drbean@TC210-63-209-62.static.apol.com.tw) |
| 2020-09-21 12:50:38 | → | xerox_ joins (~xerox@unaffiliated/xerox) |
| 2020-09-21 12:51:57 | × | thir quits (~thir@p200300f27f0fc600ed2222922a5678d5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2020-09-21 12:52:19 | <siraben> | What should I do when stack fails to find a version of GHC that works? |
| 2020-09-21 12:52:29 | <siraben> | Why wouldn't it have found a version that worked in the past? |
| 2020-09-21 12:52:41 | × | Kaiepi quits (~Kaiepi@nwcsnbsc03w-47-55-157-9.dhcp-dynamic.fibreop.nb.bellaliant.net) (Read error: Connection reset by peer) |
| 2020-09-21 12:55:00 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-09-21 12:56:28 | <merijn> | siraben: It doesn't look for a GHC version, the snapshot specifies the GHC version |
| 2020-09-21 12:56:45 | × | rihards quits (~rihards@balticom-142-78-50.balticom.lv) (Quit: rihards) |
| 2020-09-21 12:57:05 | × | gmt quits (~gmt@pool-71-105-108-44.nycmny.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2020-09-21 12:57:09 | <merijn> | So if you stack setup uses lts 11.8 (or whatever, I don't use stack) that defines which GHC you get and if that one doesn't work, well, fix your project >.> |
| 2020-09-21 12:57:13 | <siraben> | Running stack init in a repository like https://github.com/jozefg/pcf/ seems to fail |
| 2020-09-21 12:57:41 | <siraben> | log: http://ix.io/2yhR |
| 2020-09-21 12:58:13 | <merijn> | I'm assuming "stack init" just picks the latest LTS snapshot or something |
| 2020-09-21 12:58:41 | <merijn> | I doubt it does anything smart |
| 2020-09-21 12:59:13 | <siraben> | Is that log not showing it going through older LTS snapshots to find one that has all the deps? |
| 2020-09-21 12:59:24 | <merijn> | ok, something smarter than I expected, but still doomed to fail |
| 2020-09-21 12:59:34 | <siraben> | How should I fix it? |
| 2020-09-21 12:59:38 | <merijn> | siraben: Eh, why would you assume a snapshot that has all the dependencies exists? |
| 2020-09-21 12:59:54 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 272 seconds) |
| 2020-09-21 13:00:02 | <siraben> | merijn: presumably this project built at some moment in time |
| 2020-09-21 13:00:07 | <merijn> | That seems...naively optimistic, especially given the lat change to that package predates the existence of stack |
| 2020-09-21 13:00:32 | <siraben> | Ok, I see why, because it predates stack. |
| 2020-09-21 13:00:36 | <merijn> | oh, wait, no, there's more recent changes |
| 2020-09-21 13:00:47 | <merijn> | Still, I'd assume the author uses cabal-install |
| 2020-09-21 13:01:09 | <siraben> | Well, cabal build doesn't work either. |
| 2020-09-21 13:01:18 | <siraben> | After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, language-c, c-dsl, pcf |
| 2020-09-21 13:01:28 | <merijn> | What's the rest of the error, though? |
| 2020-09-21 13:01:47 | <siraben> | http://ix.io/2yhU |
| 2020-09-21 13:02:08 | <merijn> | Right |
| 2020-09-21 13:02:15 | <siraben> | stack wasn't around in 2015? |
| 2020-09-21 13:02:46 | <siraben> | Ok, so building projects older than stack seems to be slightly more involved. |
| 2020-09-21 13:02:47 | <merijn> | siraben: That error is pointing out that it (transitively) depends on language-c==0.4.* |
| 2020-09-21 13:03:02 | <merijn> | siraben: Which requires (conflict: language-c |
| 2020-09-21 13:03:03 | <merijn> | +/-separatesyb +/-splitbase => base<4.11) |
| 2020-09-21 13:03:16 | <merijn> | So your GHC is to new |
| 2020-09-21 13:03:38 | <merijn> | You could (optimistically) try "cabal build --allow-newer" which may work |
| 2020-09-21 13:03:42 | <siraben> | Ok, so should I use a nix-shell with an older version of GHC then? |
| 2020-09-21 13:04:37 | <merijn> | siraben: base 4.11 is GHC 8.4 it seems: https://wiki.haskell.org/Base_package |
| 2020-09-21 13:05:53 | × | polyrain quits (~polyrain@2001:8003:e501:6901:1d0:1c96:3b88:7bde) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2020-09-21 13:06:42 | → | polyrain joins (~polyrain@2001:8003:e501:6901:1d0:1c96:3b88:7bde) |
| 2020-09-21 13:06:42 | × | polyrain quits (~polyrain@2001:8003:e501:6901:1d0:1c96:3b88:7bde) (Client Quit) |
| 2020-09-21 13:07:26 | <siraben> | merijn: Running cabal build --allow-newer now |
| 2020-09-21 13:08:04 | <cheater> | what's a word for an exercise that's very repetitive, and you learn by doing a lot of it? like when you have a full page of stuff like 1x5 = __, 7x4 = __, and so on |
| 2020-09-21 13:08:41 | <siraben> | cheater: rote |
| 2020-09-21 13:08:48 | <siraben> | rote learning, that is |
| 2020-09-21 13:10:13 | <cheater> | someone else suggested that too. rote learning is the method with which you learn from this. but what about the problem itself that's on the problem sheet? |
| 2020-09-21 13:10:37 | → | acarrico joins (~acarrico@dhcp-68-142-39-249.greenmountainaccess.net) |
| 2020-09-21 13:10:37 | → | darjeeling_ joins (~darjeelin@122.245.219.58) |
| 2020-09-21 13:10:50 | → | hyperisco joins (~hyperisco@d192-186-117-226.static.comm.cgocable.net) |
| 2020-09-21 13:11:29 | <int-e> | boring, trite, routine |
| 2020-09-21 13:12:31 | <int-e> | (and wrong channel) |
| 2020-09-21 13:15:37 | <siraben> | merijn: with allow-never it seems to get all the dependencies, however how it's complaining about Pcf.hs which is the source file |
| 2020-09-21 13:15:43 | <siraben> | newer* |
| 2020-09-21 13:15:47 | → | bahamas joins (~lucian@188.24.181.166) |
| 2020-09-21 13:15:47 | × | bahamas quits (~lucian@188.24.181.166) (Changing host) |
| 2020-09-21 13:15:47 | → | bahamas joins (~lucian@unaffiliated/bahamas) |
| 2020-09-21 13:15:48 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-09-21 13:16:10 | <siraben> | http://ix.io/2yhY |
| 2020-09-21 13:16:36 | <siraben> | Could I use nix to go back to GHC 8.4 with the packages there? |
| 2020-09-21 13:16:46 | <merijn> | Probably a change in the dependencies or something |
| 2020-09-21 13:16:55 | → | basil joins (~basil@host-87-26-187-41.business.telecomitalia.it) |
| 2020-09-21 13:17:19 | basil | is now known as Guest18536 |
| 2020-09-21 13:17:44 | × | Guest18536 quits (~basil@host-87-26-187-41.business.telecomitalia.it) (Client Quit) |
| 2020-09-21 13:18:58 | <siraben> | Hm, what's the easiest way to get it to build then? |
| 2020-09-21 13:19:04 | <siraben> | These are not libraries I'm very familiar with. |
| 2020-09-21 13:19:23 | <Cheery> | A question.. Lets say you had de-bruijn syntax, eg. λλ1, how would you represent let-expressions? |
| 2020-09-21 13:19:37 | <Cheery> | and letrec syntax? |
| 2020-09-21 13:20:01 | <Cheery> | let x = ... in, if we dropped the variable here, how would you adjust the syntax? How about the case expression? |
| 2020-09-21 13:20:15 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 260 seconds) |
| 2020-09-21 13:20:49 | × | bahamas quits (~lucian@unaffiliated/bahamas) (Ping timeout: 260 seconds) |
| 2020-09-21 13:21:36 | <ggole> | Indices require rewriting of the scope of a binding when you remove that binding |
| 2020-09-21 13:22:12 | <ggole> | Wait, did you mean removing the name and using an index? |
All times are in UTC.