Newest at the top
| 2025-11-17 17:18:21 +0100 | <lucabtz> | i thought there is a way to have that |
| 2025-11-17 17:18:10 +0100 | <lucabtz> | while mine looks weird |
| 2025-11-17 17:18:04 +0100 | <merijn> | tomsmeding: :) |
| 2025-11-17 17:18:01 +0100 | <lucabtz> | idk because some people on the bridge in matrix have a proper name |
| 2025-11-17 17:17:59 +0100 | <tomsmeding> | I cannot believe my luck |
| 2025-11-17 17:17:53 +0100 | <tomsmeding> | merijn: it has an install-includes!!!!!! |
| 2025-11-17 17:17:39 +0100 | <merijn> | lucabtz: You don't, afaik? |
| 2025-11-17 17:17:19 +0100 | <lucabtz> | how do you connect a matrix account to a IRC one? |
| 2025-11-17 17:17:00 +0100 | <tomsmeding> | makes sense, thanks! |
| 2025-11-17 17:16:51 +0100 | <merijn> | tomsmeding: At any rate, the answer is basically IFF they include it in install-includes you can, else you're hosed |
| 2025-11-17 17:16:40 +0100 | <tomsmeding> | so I believe my only option is writing a fromListNChecked that does almost the same as fromListN but not quite |
| 2025-11-17 17:16:14 +0100 | <tomsmeding> | possible, but I want a checked fromListN and I can't have that now, because doing a length check before calling V.fromListN forces the entire list and breaks all streaming |
| 2025-11-17 17:15:44 +0100 | <merijn> | tomsmeding: Which doesn't support any kind of error flow |
| 2025-11-17 17:15:35 +0100 | <merijn> | tomsmeding: That behaviour is because those functions seem like they're intended to be use with OverloadedList? |
| 2025-11-17 17:15:23 +0100 | <pounce> | if i do readelf -e /lib64/libtinfo.so.6 | grep VER the library has VERSYM and VERNEED but not VERDEF |
| 2025-11-17 17:15:03 +0100 | <pounce> | Clint: well, libtinfo might not have those versions. but im not an expert on linkers so im not sure |
| 2025-11-17 17:14:45 +0100 | <tomsmeding> | (concretely: the fromListN on vectors just ignores additional elements in the list and returns a shorter vector if the list was too short; I think that's boneheaded behaviour and want an error to be thrown instead) |
| 2025-11-17 17:14:43 +0100 | <merijn> | tomsmeding: https://cabal.readthedocs.io/en/stable/cabal-package-description-file.html#pkg-field-install-inclu… |
| 2025-11-17 17:13:50 +0100 | Zemy | (~Zemy@72.178.108.235) (Ping timeout: 256 seconds) |
| 2025-11-17 17:12:13 +0100 | <tomsmeding> | to be robust against future changes of that header file, I'd ideally like to be able to use their macro definition |
| 2025-11-17 17:11:51 +0100 | <tomsmeding> | and they have a little header file (include/vector.h) that defines PHASE_FUSED as [1], and then they write {-# INLINE PHASE_FUSED foo #-} |
| 2025-11-17 17:11:25 +0100 | <tomsmeding> | merijn: I'm trying to write a new function on `vector` vectors that works with their fusion system |
| 2025-11-17 17:10:54 +0100 | <merijn> | In short: What are you trying to do? |
| 2025-11-17 17:10:50 +0100 | Googulator48 | Googulator |
| 2025-11-17 17:10:45 +0100 | <merijn> | I guess that also depends whether you mean including it in C or including it in Haskell code, I suppose |
| 2025-11-17 17:10:45 +0100 | Googulator48 | (~Googulato@85-238-67-234.pool.digikabel.hu) |
| 2025-11-17 17:10:42 +0100 | Googulator | (~Googulato@2a01-036d-0106-0231-4475-80b4-5cdc-43d6.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-17 17:10:03 +0100 | Zemy_ | (~Zemy@2600:100c:b0a9:8436:1c98:a0ff:fed8:7a71) |
| 2025-11-17 17:09:58 +0100 | <merijn> | What that location is, is distro-dependent |
| 2025-11-17 17:09:48 +0100 | <merijn> | tomsmeding: cabal explicitly supports installing header files in a findable location |
| 2025-11-17 17:09:34 +0100 | <merijn> | tomsmeding: "It Depends (TM)" |
| 2025-11-17 17:09:08 +0100 | <tomsmeding> | is it possible to #include a header file using CPP from a _different_ package? |
| 2025-11-17 17:07:26 +0100 | <Clint> | so haskeline and terminfo require versioned symbols and libtinfo has those symbol versions and it's still complaining? |
| 2025-11-17 17:05:23 +0100 | <pounce> | ghc isn't from the repo |
| 2025-11-17 17:05:10 +0100 | <pounce> | Clint: ghc was built against libtinfo on this machine |
| 2025-11-17 17:01:33 +0100 | <Clint> | presumably you could just rebuild ghc against your libtinfo and it would be happy |
| 2025-11-17 16:47:02 +0100 | <pounce> | which is where the libtinfo.so.6 mentioned comes from |
| 2025-11-17 16:46:28 +0100 | <pounce> | i have ncurses-devel and ncurses-libs and ncurses-compat-libs |
| 2025-11-17 16:44:38 +0100 | <Square2> | missing libtinfo-dev? |
| 2025-11-17 16:44:11 +0100 | <pounce> | but idk how to fix this :/ it's repo managed |
| 2025-11-17 16:43:14 +0100 | <pounce> | the only thing i can gather is it might be missing VERDEF |
| 2025-11-17 16:42:22 +0100 | m1dnight_ | (~m1dnight@d8D861A17.access.telenet.be) (Ping timeout: 256 seconds) |
| 2025-11-17 16:42:04 +0100 | <merijn> | Sounds like the libtinfo shipping with your fedora might just be borked? |
| 2025-11-17 16:41:45 +0100 | <pounce> | merijn: yes, they are |
| 2025-11-17 16:41:39 +0100 | vardhan | (~vardhan@122.172.80.68) (Ping timeout: 265 seconds) |
| 2025-11-17 16:41:38 +0100 | <Square2> | A quick googling seems to yield a bunch of results that are not tied to ghc/haskell. |
| 2025-11-17 16:41:34 +0100 | <merijn> | Those look like linker errors to me |
| 2025-11-17 16:38:50 +0100 | <Square2> | okok |
| 2025-11-17 16:38:42 +0100 | <pounce> | but also using cabal or stack or anything else has the same effect |
| 2025-11-17 16:38:30 +0100 | <pounce> | im specifically writing agda, which does call ghc directly |