Newest at the top
2025-03-26 19:18:13 +0100 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) robobub |
2025-03-26 19:17:30 +0100 | <haskellbridge> | <Morj> Does it install mscrt or does it require it |
2025-03-26 19:17:00 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
2025-03-26 19:14:59 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds) |
2025-03-26 19:14:56 +0100 | sprotte24 | (~sprotte24@p200300d16f097d007520d57df2b917ec.dip0.t-ipconnect.de) |
2025-03-26 19:14:37 +0100 | <EvanR> | dependency manager from microsoft |
2025-03-26 19:10:21 +0100 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
2025-03-26 19:08:03 +0100 | <haskellbridge> | <Bowuigi> vcpkg is probably the most popular solution to the C packaging problem. Never tried it but it shouldn't be too bad |
2025-03-26 19:05:09 +0100 | <haskellbridge> | <Bowuigi> It would free maintainers from doing that, which would be wonderful for everyone because distros would only have to provide binaries or simple build scripts instead of coordinating around poor tooling |
2025-03-26 19:05:00 +0100 | <haskellbridge> | <Morj> One solution is bundling/vendoring. One other solution is using build2. Yet another solution is nix |
2025-03-26 19:04:26 +0100 | <EvanR> | I'm mostly programming in C |
2025-03-26 19:04:13 +0100 | <haskellbridge> | <Morj> Bowuigi: Exactly! And since we're not programming in C (mostly), we can replace those conventions with something better |
2025-03-26 19:04:09 +0100 | <geekosaur> | https://github.com/geekosaur/xmonad.hs/blob/hilfy-2023/xmonad.hs#L127-L128 for example |
2025-03-26 19:04:06 +0100 | <EvanR> | (or any programming language) |
2025-03-26 19:04:00 +0100 | <EvanR> | and if you ask ##c they will say package management for the language would be a terrible idea |
2025-03-26 19:03:46 +0100 | <geekosaur> | you can embed ignored whitespace (and specifically, newlines) in a string by surrounding it with \ |
2025-03-26 19:03:33 +0100 | <haskellbridge> | <Bowuigi> Morj That's because there are a lot of distros with different packaging conventions. The issue there is that C relies too much on distro packaging because it's packaging support is basically nonexistent |
2025-03-26 19:02:40 +0100 | <EvanR> | I'm surprised that CPP even works on haskell |
2025-03-26 19:02:28 +0100 | <haskellbridge> | <Morj> Yeah, I guess my argument got mangled by my hatred of ncurses |
2025-03-26 19:02:14 +0100 | <yin> | geekosaur: what are string gaps? |
2025-03-26 19:01:29 +0100 | <EvanR> | but you seemed to shift from being against third party deps to being for bundling |
2025-03-26 19:01:24 +0100 | ash3en | (~Thunderbi@185.209.196.192) (Ping timeout: 260 seconds) |
2025-03-26 19:01:23 +0100 | <haskellbridge> | There are many projects in git forges where build instructions start with "Install libthis and libthat. You need to figure out how they are named in your distro yourself". This is suboptimal |
2025-03-26 19:01:23 +0100 | <haskellbridge> | <Morj> > what are you even talking about |
2025-03-26 19:01:02 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
2025-03-26 19:00:37 +0100 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
2025-03-26 19:00:34 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
2025-03-26 19:00:21 +0100 | <EvanR> | blindly setting --link-options=-lsqlite what are you even talking about |
2025-03-26 19:00:15 +0100 | <haskellbridge> | <Morj> That's why in my software I bundle both zlib and sqlite |
2025-03-26 18:59:51 +0100 | <EvanR> | every time you rewrite a thing there is costs and risks |
2025-03-26 18:59:51 +0100 | <geekosaur> | doesn't like ticked identifiers, doesn't like MagicHash, doesn't like string gaps (granting that a large chunk of the userbase agrees with it there), etc. |
2025-03-26 18:59:42 +0100 | <haskellbridge> | I agree! I disagree with blindly setting '--link-options=-lsqlite' and praying |
2025-03-26 18:59:42 +0100 | <haskellbridge> | <Morj> > I would rather depend on sqlite than rewrite it |
2025-03-26 18:59:16 +0100 | <geekosaur> | IMO the real problem isn't how we get CPP, it's that we use it at all. it's intended for C, after all, and it's a pretty bad fit for Haskell |
2025-03-26 18:59:15 +0100 | <haskellbridge> | <Morj> Making programs and managing programs seems orthogonal to me. I have nothing against giant or small deps as long as they are on hackage and not in pkg-config |
2025-03-26 18:59:06 +0100 | <EvanR> | also zlib |
2025-03-26 18:59:00 +0100 | <EvanR> | solid stuff |
2025-03-26 18:58:47 +0100 | <EvanR> | I would rather depend on sqlite than rewrite it |
2025-03-26 18:58:43 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
2025-03-26 18:58:31 +0100 | <yin> | Morj: then I would argue that the solution is not to make programs bigger but the opposite: make them smaller and easier to manage |
2025-03-26 18:58:22 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
2025-03-26 18:58:22 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
2025-03-26 18:56:56 +0100 | <geekosaur> | https://github.com/hackage-trustees/malcolm-wallace-universe is the current repo, it seems |
2025-03-26 18:56:51 +0100 | <haskellbridge> | <Morj> Maybe I'm a bit too bought into the idea that the best way to manage dependencies is to get rid of the external ones |
2025-03-26 18:56:30 +0100 | <haskellbridge> | <Morj> I agree |
2025-03-26 18:55:41 +0100 | <yin> | Morj: i see what you mean now. the problem is not having dependencies then, it's how bad we are at managing them |
2025-03-26 18:55:20 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
2025-03-26 18:54:45 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
2025-03-26 18:54:43 +0100 | <haskellbridge> | This one? https://github.com/malcolmwallace/cpphs - empty, but the issue tracker is still there |
2025-03-26 18:54:43 +0100 | <haskellbridge> | <Morj> > as to "wouldn't be hard", ask the cpphs folks about that one 🙂 |