2024/12/28

Newest at the top

2024-12-28 22:34:19 +0100peterbecich(~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 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-12-28 22:28:35 +0100euleritian(~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de)
2024-12-28 22:28:16 +0100euleritian(~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de) (Ping timeout: 244 seconds)
2024-12-28 22:28:13 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-12-28 22:27:37 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-12-28 22:25:33 +0100Everything(~Everythin@195.138.86.118) Everything
2024-12-28 22:16:37 +0100Sgeo(~Sgeo@user/sgeo) Sgeo
2024-12-28 22:16:23 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2024-12-28 22:13:39 +0100euleritian(~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de)
2024-12-28 22:12:00 +0100merijn(~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 +0100JuanDaugherty(~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 +0100peterbecich(~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 +0100merijn(~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 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-12-28 21:51:49 +0100euleritian(~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 +0100acidjnk_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 +0100euleritian(~euleritia@dynamic-176-006-135-074.176.6.pool.telefonica.de)
2024-12-28 21:44:52 +0100JuanDaugherty(~juan@user/JuanDaugherty) (Ping timeout: 244 seconds)
2024-12-28 21:44:45 +0100euleritian(~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 +0100merijn(~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 +0100lisbeths(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