Newest at the top
| 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 |
| 2024-12-28 20:52:23 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2024-12-28 20:51:20 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 20:48:46 +0100 | ljdarj1 | ljdarj |
| 2024-12-28 20:48:46 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2024-12-28 20:46:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 20:46:40 +0100 | prsteele | (~prsteele@pool-173-48-172-223.bstnma.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2024-12-28 20:45:54 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-12-28 20:37:11 +0100 | euleritian | (~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) (Ping timeout: 244 seconds) |
| 2024-12-28 20:33:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-28 20:32:54 +0100 | euleritian | (~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) |
| 2024-12-28 20:31:53 +0100 | tabemann | (~tabemann@2600:1700:7990:24e0:439f:78fd:a524:27e2) tabemann |
| 2024-12-28 20:31:31 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-12-28 20:30:34 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Client Quit) |
| 2024-12-28 20:29:56 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |