Newest at the top
| 2024-11-06 20:26:03 +0100 | CoolMa7 | (~CoolMa7@95.91.137.87) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2024-11-06 20:25:39 +0100 | <EvanR> | provable |
| 2024-11-06 20:25:39 +0100 | <statusbot6> | Status update: The hackage outage has been traced to a misconfigured zfs snapshot configuration resulting in full disk. This is fixed and hackage is operational again. -- http://status.haskell.org/pages/incident/537c07b0cf1fad5830000093/672bb063281978053cb3d85e |
| 2024-11-06 20:25:25 +0100 | <haskellbridge> | <Morj> Ughh I had a counterexample for consensus but now I think you're right |
| 2024-11-06 20:25:14 +0100 | <Inst> | but the absence of effects besides memory and computation, etc, is just really liberating, as well as a "by default" implementation |
| 2024-11-06 20:25:13 +0100 | <EvanR> | ideally you don't have any for whatever provably reason |
| 2024-11-06 20:24:39 +0100 | <EvanR> | that is basically the consensus, no one should be catching pure errors |
| 2024-11-06 20:24:14 +0100 | <Inst> | iirc clean with uniqueness types |
| 2024-11-06 20:24:13 +0100 | <haskellbridge> | <Morj> It would be ideal if there was a consensus to use errors in pure code like panics in rust, but |
| 2024-11-06 20:24:02 +0100 | <Inst> | 0 `div` 0 |
| 2024-11-06 20:24:00 +0100 | <EvanR> | haskell solved it several ways historically, but that doesn't mean "it's solved" in general, unless haskell is the only pure functional language ever |
| 2024-11-06 20:23:17 +0100 | <Inst> | IO type is nice enough, although you can imagine better alternatives (effects imo should be handled within the language as a feature, not as a product of lambda calculus) |
| 2024-11-06 20:23:13 +0100 | <haskellbridge> | <Morj> Error handling - not really. Exceptions in pure code are a pain if you really want to handle them |
| 2024-11-06 20:22:47 +0100 | <Inst> | but aren't those mostly solved in modern Haskell? |
| 2024-11-06 20:22:18 +0100 | <EvanR> | problems like the awkward squad: I/O, error handling, concurrency, and FFI |
| 2024-11-06 20:22:06 +0100 | <Inst> | not sure whether non-strict can actually include lenient evaluation! |
| 2024-11-06 20:21:58 +0100 | <Inst> | nonstrict, technically |
| 2024-11-06 20:20:51 +0100 | <EvanR> | it was basically necessary because of lazyiness |
| 2024-11-06 20:20:43 +0100 | <EvanR> | that being said purity wasn't an end inof itself |
| 2024-11-06 20:20:23 +0100 | <Inst> | what new problems? |
| 2024-11-06 20:20:12 +0100 | <EvanR> | and creates new ones |
| 2024-11-06 20:19:58 +0100 | <EvanR> | pure or pure-by-default really does solve a lot of things |
| 2024-11-06 20:19:33 +0100 | <Inst> | and to some extent i'm coming to a realization that FP doesn't make sense without pure-by-default |
| 2024-11-06 20:17:52 +0100 | <Inst> | Rust, apparently, only has in-program function types via function pointers, not the functions themselves |
| 2024-11-06 20:17:36 +0100 | <Inst> | just my comment about "purely functional" programming being useful, to eschew the argument, is just that Julia doesn't have function types |
| 2024-11-06 20:16:18 +0100 | sudden | (~cat@user/sudden) sudden |
| 2024-11-06 20:14:38 +0100 | sudden | (~cat@user/sudden) (Ping timeout: 265 seconds) |
| 2024-11-06 20:11:43 +0100 | <haskellbridge> | <sm> related, https://flora.pm/packages/@hackage/githash is good for git info |
| 2024-11-06 20:09:46 +0100 | <haskellbridge> | <Morj> At $job we had a script that when doing releases would read version info from several pacakges and prepare it as a haskell module before build |
| 2024-11-06 20:08:18 +0100 | <haskellbridge> | <Morj> > We provide functionality for reading these numbers from cabal files at both runtime and compile-time :3 |
| 2024-11-06 20:07:14 +0100 | <haskellbridge> | <sm> https://flora.pm/packages/@hackage/package-version I guess |
| 2024-11-06 20:06:00 +0100 | <haskellbridge> | <sm> Yes, there are ways to get the package version, which I forget |
| 2024-11-06 20:04:52 +0100 | <haskellbridge> | <Morj> It is a lot better IMO. Still not ideal sadly. Also I liked the old design more ;] |
| 2024-11-06 20:04:40 +0100 | <haskellbridge> | <sm> setting up a mirror sounds fairly advanced |
| 2024-11-06 20:04:17 +0100 | <haskellbridge> | <sm> Morj: I hear that. stack's manual is a bit better |
| 2024-11-06 20:04:06 +0100 | <haskellbridge> | <Morj> Without reading the source files themselves (at build or run time) - no |
| 2024-11-06 20:01:57 +0100 | ft | (~ft@p4fc2a216.dip0.t-ipconnect.de) ft |
| 2024-11-06 20:01:50 +0100 | <lxsameer> | hey folks, is there any way to get the version number of the project that is set in the cabal file in the haskell code? |
| 2024-11-06 20:00:50 +0100 | <haskellbridge> | <Morj> Anyway, thanks for advice (= |
| 2024-11-06 20:00:30 +0100 | <haskellbridge> | <Morj> Well cabal also has everything in the manual allegedly, but last time it took me a couple of weeks of full-time work to figure out how to set up a mirror |
| 2024-11-06 19:59:53 +0100 | <haskellbridge> | <sm> that is the recommended config these days when using stack with ghcup |
| 2024-11-06 19:59:22 +0100 | <haskellbridge> | <Morj> Now the second part can be solved if I write my own stack-init.. |
| 2024-11-06 19:59:21 +0100 | <haskellbridge> | <sm> all in the manual, don't tell anyone :) |
| 2024-11-06 19:59:09 +0100 | <haskellbridge> | <Morj> Oh cool |
| 2024-11-06 19:58:54 +0100 | <haskellbridge> | <sm> Morj: ~/.stack/config.yaml: install-ghc: false, system-ghc: true |
| 2024-11-06 19:58:34 +0100 | <institor> | i am not using nightly |
| 2024-11-06 19:58:19 +0100 | <haskellbridge> | <Morj> sm I can configure it, but it's silly: when I use a snapshot with a mismatching ghc version, it will try to download it instead of giving an error. And when creating a new project I have to guess which snapshot will work with my system ghc |
| 2024-11-06 19:58:09 +0100 | <institor> | yes sm, `stack setup` is throwing that malformed JSON error |
| 2024-11-06 19:57:55 +0100 | <haskellbridge> | <sm> institor: that's what I saw from stack update, which is about what you'd expect. But did that cause setup to fail ? |
| 2024-11-06 19:57:35 +0100 | <institor> | keep in mind i'm running from a clean docker base image |