Newest at the top
| 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`) |
| 2024-12-28 21:41:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-12-28 21:40:24 +0100 | <geekosaur> | mm, without some kind of compilation testing framework I don't think this can be done generally |
| 2024-12-28 21:40:11 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-12-28 21:38:37 +0100 | <haskellbridge> | <loonycyborg> maybe turn it into AST with some parser |
| 2024-12-28 21:38:19 +0100 | <hellwolf> | unless there is some neat/smart trick that I am not aware of |
| 2024-12-28 21:38:09 +0100 | <hellwolf> | I am not sure. Regular test framework doesn't seem to cut it |
| 2024-12-28 21:37:50 +0100 | <haskellbridge> | <loonycyborg> in unit tests? |
| 2024-12-28 21:37:30 +0100 | <haskellbridge> | <loonycyborg> testing in what way? |
| 2024-12-28 21:36:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 21:35:51 +0100 | <hellwolf> | I asked this before.. I am gonna ask again... what's the best way of testing a piece of code *cannot* be compiled due to type error. |
| 2024-12-28 21:24:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-28 21:20:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 21:09:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-12-28 21:06:43 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2024-12-28 21:04:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 21:02:31 +0100 | euleritian | (~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) |
| 2024-12-28 21:00:38 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-12-28 21:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-12-28 20:55:42 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 276 seconds) |
| 2024-12-28 20:52:42 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |