Newest at the top
| 2025-01-10 04:39:00 +0100 | monochrom | -o monochrom |
| 2025-01-10 04:38:52 +0100 | <haskellbridge> | <sm> https://github.com/simonmichael/hledger/blob/master/hledger/Hledger/Cli/DocFiles.hs#L47 |
| 2025-01-10 04:38:39 +0100 | rongwey | monochrom (rongwey) |
| 2025-01-10 04:38:39 +0100 | monochrom | +b *!*@user/rongwey |
| 2025-01-10 04:38:35 +0100 | ChanServ | +o monochrom |
| 2025-01-10 04:38:31 +0100 | <rongwey> | Naruto Uzumaki visits Monterrey and meets Governor Samuel Garcia and starts a romantic escapade with him. |
| 2025-01-10 04:38:31 +0100 | <rongwey> | Naruto Has Ninja Sex with Nuevo Leon Governor Samuel Garcia |
| 2025-01-10 04:38:14 +0100 | <rongwey> | https://justpaste.it/Naruto_Makes_Love_Samuel_Garcia |
| 2025-01-10 04:37:53 +0100 | <haskellbridge> | <sm> I use https://hackage.haskell.org/package/file-embed-0.0.16.0/docs/Data-FileEmbed.html#v:embedFileRelative . The type signature is confusing, but basically it evaluates to a bytestring |
| 2025-01-10 04:37:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-10 04:37:08 +0100 | rongwey | (~rongwey@user/rongwey) rongwey |
| 2025-01-10 04:36:25 +0100 | <haskellbridge> | <sm> yes; there's a different api for reading the files. (If you absolutely need them to be in the file system, eg to pass to a legacy app, you can write them out to a temp file at runtime) |
| 2025-01-10 04:36:21 +0100 | philopsos | (~caecilius@user/philopsos) (Ping timeout: 248 seconds) |
| 2025-01-10 04:34:42 +0100 | <sim590> | But, am I gonna have to change my approach of recovering the contents since it's not on the disk anymore? For data-files, I have Paths_mypackage automatic module which resolves paths. How does that play out with your approach? |
| 2025-01-10 04:33:21 +0100 | <haskellbridge> | <sm> yup |
| 2025-01-10 04:33:12 +0100 | <sim590> | Oh, so the files are embeded in the binary? |
| 2025-01-10 04:32:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-10 04:31:18 +0100 | rekahsoft | (~rekahsoft@70.51.99.237) (Ping timeout: 246 seconds) |
| 2025-01-10 04:30:51 +0100 | <haskellbridge> | <sm> (whereas embedding files in your executable makes it more self-contained) |
| 2025-01-10 04:30:06 +0100 | <haskellbridge> | <sm> it's excluded from backups. etc. |
| 2025-01-10 04:29:45 +0100 | <haskellbridge> | <sm> or if you copy the executable to a new machine, the data won't come along |
| 2025-01-10 04:29:00 +0100 | <haskellbridge> | <sm> .cabal/store/ghc-9.4.8/...fcfc097/ is not a very durable place to store essential data. It typically gets wiped when your disk fills up or when you uninstall old ghc versions, then the app breaks |
| 2025-01-10 04:28:04 +0100 | <sim590> | what's the advantage? |
| 2025-01-10 04:26:58 +0100 | rekahsoft | (~rekahsoft@70.51.99.237) rekahsoft |
| 2025-01-10 04:25:20 +0100 | <haskellbridge> | <sm> also data-files is inherently fragile, I think. I prefer file-embed |
| 2025-01-10 04:22:05 +0100 | <geekosaur> | also I think that used to be an error but then someone got the idea that the only errors should be the things preventing a package from being accepted on hackage. there's still some ongoing shakedown about that |
| 2025-01-10 04:22:05 +0100 | sabathan | (~sabathan@acaen-652-1-335-197.w83-115.abo.wanadoo.fr) |
| 2025-01-10 04:21:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-10 04:20:14 +0100 | <geekosaur> | I would file a cabal bug, it should (a) be noisier about such problems, not hide them under cabal check (b) perhaps specifically check for fields like data-files and complain even more loudly |
| 2025-01-10 04:19:16 +0100 | <sim590> | I guess that would need to be an error, yeah because data-files are required at runtime by definition. |
| 2025-01-10 04:19:12 +0100 | <geekosaur> | no, I think |
| 2025-01-10 04:18:00 +0100 | sabathan | (~sabathan@acaen-652-1-335-197.w83-115.abo.wanadoo.fr) (Ping timeout: 246 seconds) |
| 2025-01-10 04:17:30 +0100 | <haskellbridge> | <sm> is there a flag that would have turned that cabal data-files warning into an install error ? |
| 2025-01-10 04:17:14 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-10 04:16:12 +0100 | <geekosaur> | not quite. source-repository is a section. it ended the top level (outside any section) fields, so data-files: was ignored from then on |
| 2025-01-10 04:16:04 +0100 | <haskellbridge> | <sm> that's annoying. Just figured out the same thing |
| 2025-01-10 04:15:50 +0100 | <sim590> | Thanks for help everyone. |
| 2025-01-10 04:15:30 +0100 | <sim590> | That's because I added `source-repository` later in development and I didn't understand that it broke data-files section. |
| 2025-01-10 04:15:30 +0100 | rekahsoft | (~rekahsoft@70.51.99.237) (Ping timeout: 252 seconds) |
| 2025-01-10 04:15:05 +0100 | <geekosaur> | arguably should be default\ |
| 2025-01-10 04:14:56 +0100 | <geekosaur> | had to run cabal chrck to get that |
| 2025-01-10 04:14:43 +0100 | <monochrom> | Like this? "Ignoring trailing fields after sections: "data-files"" |
| 2025-01-10 04:14:39 +0100 | <sim590> | god damn. |
| 2025-01-10 04:14:32 +0100 | <sim590> | That's it |
| 2025-01-10 04:14:12 +0100 | <euouae> | it would be nice if a warning was given about data-files being ignored |
| 2025-01-10 04:14:09 +0100 | <sim590> | Let me see |
| 2025-01-10 04:14:06 +0100 | <sim590> | Hmmm |
| 2025-01-10 04:13:56 +0100 | <geekosaur> | that ended the global fields, so data-files is ignored |
| 2025-01-10 04:13:55 +0100 | <sim590> | This person had the same issue here: https://stackoverflow.com/questions/73258030/cabal-ignoring-trailing-fields-after-sections, but no answers were given. |
| 2025-01-10 04:13:37 +0100 | <geekosaur> | you put data-files after source-repository |