2025/03/26

Newest at the top

2025-03-26 19:18:13 +0100robobub(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 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds)
2025-03-26 19:14:59 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds)
2025-03-26 19:14:56 +0100sprotte24(~sprotte24@p200300d16f097d007520d57df2b917ec.dip0.t-ipconnect.de)
2025-03-26 19:14:37 +0100 <EvanR> dependency manager from microsoft
2025-03-26 19:10:21 +0100robobub(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 +0100ash3en(~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 +0100ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2025-03-26 19:00:37 +0100Chai-T-Rex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2025-03-26 19:00:34 +0100wootehfoot(~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 +0100alfiee(~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 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-03-26 18:58:22 +0100Unicorn_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 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2025-03-26 18:54:45 +0100jmcantrell(~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 🙂