Newest at the top
| 2025-12-11 19:18:46 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-12-11 19:16:10 +0100 | <EvanR> | return to the world |
| 2025-12-11 19:15:58 +0100 | <EvanR> | level 60, you're done |
| 2025-12-11 19:15:27 +0100 | ft | (~ft@p508db844.dip0.t-ipconnect.de) ft |
| 2025-12-11 19:15:06 +0100 | <Rembane> | Finally max level! |
| 2025-12-11 19:14:44 +0100 | <haskellbridge> | <Morj> Sadder still is that I thought I finished learning |
| 2025-12-11 19:14:39 +0100 | <EvanR> | ;_; |
| 2025-12-11 19:14:31 +0100 | <haskellbridge> | <Morj> I've been learning erlang recently, and haven't seen anything about transactional semantics. Sad |
| 2025-12-11 19:12:45 +0100 | <haskellbridge> | <sm> I haven't used erlang, but yes that sounds right, they like to throw something away if it fails |
| 2025-12-11 19:12:01 +0100 | <haskellbridge> | <sm> same principle |
| 2025-12-11 19:11:49 +0100 | <haskellbridge> | <sm> that's running software rather than dev in process, but you know what I mean |
| 2025-12-11 19:11:46 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 19:11:05 +0100 | <haskellbridge> | <sm> I know php is a good example, you get a fresh state every request |
| 2025-12-11 19:10:38 +0100 | <EvanR> | which is not what erlang is usually promoting |
| 2025-12-11 19:10:23 +0100 | <EvanR> | well, transactional semantics are a good way to deal with that assumption |
| 2025-12-11 19:09:21 +0100 | <gentauro> | haskellbridge: that's actually the foundation of Erlang right? We know we are gonna fail at some point, lets add that to the equation. |
| 2025-12-11 19:09:19 +0100 | Square | (~Square4@user/square) (Ping timeout: 240 seconds) |
| 2025-12-11 19:07:18 +0100 | Googulator24 | Googulator |
| 2025-12-11 19:06:55 +0100 | Googulator24 | (~Googulato@87-97-86-146.pool.digikabel.hu) |
| 2025-12-11 19:06:45 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) |
| 2025-12-11 19:06:43 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2025-12-11 19:06:33 +0100 | Googulator24 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 19:05:20 +0100 | <haskellbridge> | <sm> I guess my point is, as we work with computers and tools we are working with very complex state which will never be entirely bug free, sometimes it's more cost effective to try a state reset than to debug what's going wrong |
| 2025-12-11 19:04:09 +0100 | Guest87 | (~Guest87@2405:201:d006:986f:5c73:3a20:69d:7d07) (Quit: Client closed) |
| 2025-12-11 19:03:55 +0100 | <geekosaur> | see `patchelf` |
| 2025-12-11 19:03:47 +0100 | <geekosaur> | in particular, it varies on NixOS |
| 2025-12-11 19:03:37 +0100 | <haskellbridge> | <sm> (not something I would do often, but sometimes the dumb hands-free test is worth doing) |
| 2025-12-11 19:03:27 +0100 | <geekosaur> | leading to confusing error messages because `exec` has no way to pass back precisely what wasn't found |
| 2025-12-11 19:02:56 +0100 | <geekosaur> | if that binary was left over from then, it might do it. "does not exist" can refer not to the binary, but to its ELF "interpreter" whose path might vary on different systems (well, shouldn't these days, but if it was old enough it might) |
| 2025-12-11 19:02:47 +0100 | <haskellbridge> | <sm> sure, but sometimes it's quicker to move some dirs aside and let cabal/stack run in another window while you continue working on things that require thought |
| 2025-12-11 19:01:57 +0100 | <gentauro> | I would rather spend my time producing code ;) |
| 2025-12-11 19:01:40 +0100 | <gentauro> | sm: back in the good old days, I sed gentoo and compiled it all locally. I'm never going back to those days again xD |
| 2025-12-11 19:01:21 +0100 | <sm> | sometimes it's the quickest thing to try |
| 2025-12-11 19:01:10 +0100 | <gentauro> | sm: xD |
| 2025-12-11 19:00:57 +0100 | <sm> | gentauro: great. I guess "nuke things and start over" is our equivalent of "have you tried turning it off and on again" |
| 2025-12-11 19:00:49 +0100 | Googulator24 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 19:00:46 +0100 | Googulator | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 19:00:28 +0100 | <gentauro> | int-e: it sure is. Thx :) |
| 2025-12-11 19:00:20 +0100 | <gentauro> | int-e: and sometimes remove support for old GHC. They do that cos the burden of maintaining all of it. So I do understand. |
| 2025-12-11 19:00:06 +0100 | <int-e> | anyway, it sunds like the issue is solved :) |
| 2025-12-11 18:59:32 +0100 | <int-e> | oh I suppose nix will change library paths all the time |
| 2025-12-11 18:59:01 +0100 | <gentauro> | I guess it happens from time to time on NixOS when I change the main channel (recently moved from 25.05 -> 25.11) |
| 2025-12-11 18:58:44 +0100 | <int-e> | (note that "not found" in an exec-like context doesn't necessarily mean that the executable itself is missing; it can also be a shared library that it depends on) |
| 2025-12-11 18:58:17 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-12-11 18:58:08 +0100 | <gentauro> | geekosaur: yeah, it mentioned `Cabal-simple-…` |
| 2025-12-11 18:57:51 +0100 | kuribas | (~user@2a02:1808:cd:df9d:1dcb:cff3:20e8:95d8) kuribas |
| 2025-12-11 18:57:37 +0100 | <gentauro> | sm: it seems that the cached `Cabal-simple-…` placed in `~/.stack/setup-exe-cache/x86_64-linux-nix` become wacko. I cleansed that folder and now it works. |
| 2025-12-11 18:56:38 +0100 | <geekosaur> | normally it says the program |
| 2025-12-11 18:56:28 +0100 | <sm> | anything at https://github.com/haskell/process/issues/247 ? |
| 2025-12-11 18:55:58 +0100 | int-e | would look for verbosity options or maybe use strace to figure out what program it's trying to execute |