Newest at the top
| 2024-12-28 22:42:52 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-12-28 22:42:50 +0100 | Digitteknohippie | Digit |
| 2024-12-28 22:41:22 +0100 | <hellwolf> | anyways, I think I will give up again on this inquiry, for now. |
| 2024-12-28 22:41:11 +0100 | <hellwolf> | even if I did that, not sure what kind constraint injected could be utilized for testing purpose. |
| 2024-12-28 22:40:05 +0100 | Digit | (~user@user/digit) (Ping timeout: 248 seconds) |
| 2024-12-28 22:39:37 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2024-12-28 22:34:19 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-12-28 22:33:35 +0100 | <haskellbridge> | <hellwolf> probably the good old CPP can help?! |
| 2024-12-28 22:33:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-28 22:28:35 +0100 | euleritian | (~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) |
| 2024-12-28 22:28:16 +0100 | euleritian | (~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) (Ping timeout: 244 seconds) |
| 2024-12-28 22:28:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 22:27:37 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-28 22:25:33 +0100 | Everything | (~Everythin@195.138.86.118) Everything |
| 2024-12-28 22:16:37 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-12-28 22:16:23 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-28 22:13:39 +0100 | euleritian | (~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) |
| 2024-12-28 22:12:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 22:08:12 +0100 | <geekosaur> | although I am assuming you are including thos code into a separate test framework; if this is in a library, you're dead before you start because the library component will fail to compile |
| 2024-12-28 22:07:18 +0100 | <geekosaur> | like I said, don't import (`import … hiding (Assert)`) and write your own |
| 2024-12-28 22:05:14 +0100 | <hellwolf> | since the code doesn't change often, I can live with it by testing only once... |
| 2024-12-28 22:04:48 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-12-28 22:04:13 +0100 | <hellwolf> | this is my poor man's version of testing: commenting-out-method |
| 2024-12-28 22:03:51 +0100 | <hellwolf> | https://paste.tomsmeding.com/IEBO6dOs |
| 2024-12-28 22:02:42 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-12-28 22:01:49 +0100 | <hellwolf> | when I use my own. |
| 2024-12-28 22:01:40 +0100 | <hellwolf> | wait, how can I programatically change the Assertion behavior? |
| 2024-12-28 21:59:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-28 21:55:25 +0100 | <geekosaur> | like, define your own constraint WouldAssert and have your Assert include that context in place of errMsg, then use IfCxt to check for it afterward? |
| 2024-12-28 21:53:14 +0100 | <geekosaur> | but there's no reason you couldn't have it not import the standard Assert and write your own, it's a very simple closed type family as you can see from the link |
| 2024-12-28 21:52:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 21:51:49 +0100 | euleritian | (~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2024-12-28 21:51:48 +0100 | <geekosaur> | https://hackage.haskell.org/package/ghc-internal-9.1201.0/docs/src/GHC.Internal.TypeError.html#Ass… no magic at all |
| 2024-12-28 21:51:05 +0100 | <geekosaur> | `Assert` itself is just a type family |
| 2024-12-28 21:50:55 +0100 | <geekosaur> | sadly I think that's also the harder one |
| 2024-12-28 21:50:36 +0100 | <geekosaur> | actually I think the wizard mode trick is not to replace `Assert`, but `TypeError` |
| 2024-12-28 21:50:05 +0100 | <hellwolf> | say, GHCWillAssert :: Constraint) |
| 2024-12-28 21:49:29 +0100 | <hellwolf> | (for testing in runtime) |
| 2024-12-28 21:49:08 +0100 | <hellwolf> | the magic constraint like HasCallStack, or Typeable which you can have some runtime information? |
| 2024-12-28 21:49:06 +0100 | <geekosaur> | may have to play with the import list for the providing module (is it still in the same module as TypeError or am I misremembering that?) |
| 2024-12-28 21:48:15 +0100 | <geekosaur> | um? just don't import that one, import a different one |
| 2024-12-28 21:47:45 +0100 | <geekosaur> | the real question there is, what possible replacement would let that avoid your test suite itself failing to compile? it's kinda a `undefined`-like situation (type level bottom), isn't it? |
| 2024-12-28 21:47:36 +0100 | <hellwolf> | you are right, the package is compiled with the Assert from base, testing package cannot change that |
| 2024-12-28 21:45:55 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f42bc4ebb891d7561a4.dip0.t-ipconnect.de) |
| 2024-12-28 21:45:51 +0100 | <geekosaur> | compiling that would use whatever `Assert` is in scope, no? it's not like it's a wired-in that requires `NoImplicitPrelude` or `RebindableSyntax` |
| 2024-12-28 21:45:06 +0100 | euleritian | (~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) |
| 2024-12-28 21:44:52 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Ping timeout: 244 seconds) |
| 2024-12-28 21:44:45 +0100 | euleritian | (~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) (Ping timeout: 246 seconds) |
| 2024-12-28 21:43:33 +0100 | <hellwolf> | https://paste.tomsmeding.com/0cTPAGam <-- this is the example. Unless I can swap out the "Assert" for a different implementation during testing, I don't think I can "test" it per se. Is that some sort of advanced module feature that I sometimes hear of? I guess if I really try, I could use cabal mixins to force that. |
| 2024-12-28 21:41:17 +0100 | <geekosaur> | quick and dirty is to shell out to a compiler and see if the `waitForProcess` at the end throws an exception, but you then need to arrange for the test program to use your code (maybe `CPP` and a `#include`) |