05:05 <SamantazFox> Blacksmoke16: Ok, thanks!

05:06 <SamantazFox> rjnienaber: Ah, yes, indeed, I want to keep the backtrace, as this will be given to the end user if something fails!

05:10 <FromGitter> <Blacksmoke16> id also suggest using that `cause` exception property

05:10 <FromGitter> <Blacksmoke16> then you can keep a reference to the original exception

05:18 <SamantazFox> Noted, ty :)

12:17 <FromGitter> <ym418_twitter> Two independent specs seem to interfere. Does someone tell me why? ⏎ I have two specs below: ⏎ ⏎ 1) spec/domain/c*v*e/id_spec.cr ⏎ 2) spec/domain/c*w*e/id_spec.cr ... [https://gitter.im/crystal-lang/crystal?at=6356823ccd9a8436d1304ba2]

20:56 <FromGitter> <moe:busyloop.net> brrr, i really hope crystal adds `throws` at some point

21:45 <SamantazFox> https://github.com/iv-org/invidious/issues/3352

21:46 <SamantazFox> Is it only me, or there is an offset between the function name and the filename in the exception backtrace?

21:55 <FromGitter> <Blacksmoke16> afaik in some cases the trace may be a bit wonky due to inlining and stuff

22:00 <SamantazFox> inlining ?

22:01 <FromGitter> <Blacksmoke16> like if you do something like

22:02 <FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=63570b67cf41c67a5cc7ff15]

22:02 <FromGitter> <Blacksmoke16> LLVM could change the method calls into essentially just `pp 1 + 2`

22:03 <SamantazFox> Ah, I see

22:04 <SamantazFox> Btw, is there something to see what's fed to LLVM?

22:05 <SamantazFox> or at least some code pretty late in the compilation (e.g after ECR and macros being expanded)?

22:05 <SamantazFox> That would be really cool to debug

22:07 <FromGitter> <Blacksmoke16> you can see what LLVM sees

22:07 <FromGitter> <Blacksmoke16> `--emit [asm|obj|llvm-bc|llvm-ir] Comma separated list of types of output for the compiler to emit`

22:10 <SamantazFox> Cool! Ty!

22:13 <FromGitter> <Blacksmoke16> https://godbolt.org/z/qcYfGjEYW this site is also pretty cool

22:13 <FromGitter> <Blacksmoke16> can see in this example it basically reduces the whole program to a single value of `13`

22:14 <SamantazFox> mmh, *nods*

22:15 <SamantazFox> Though, figuring out some of the bugs I'm getting is gonna be harder than expected lol

22:16 <SamantazFox> I'm betting on `--release` to be broken again

22:16 <FromGitter> <Blacksmoke16> my understanding is `--release --no-debug` is what makes it hard

22:16 <FromGitter> <Blacksmoke16> a release build with `--debug` should be able to rebuild the trace id think?

22:17 <SamantazFox> it indeed builds a trace (See the error I've linked above)

22:17 <SamantazFox> but the error doesn't make sense, as the function where this error happens have enforced data types

22:18 <SamantazFox> I can't reproduce without `--release`, so I'm compiling again and we'll see

22:19 <SamantazFox> (Why do I always encounter weird edge cases, lol)

22:19 <FromGitter> <Blacksmoke16> crazy complex code? :P

22:20 <FromGitter> <Blacksmoke16> if i had to guess, that error is due to the underlying `JSON::Any`containing an array and not a hash as it expects

22:21 <FromGitter> <Blacksmoke16> er well thats exactly what is happening, but the question is why

22:21 <SamantazFox> crazy complex code? :P <- yeaaaah <_<

22:22 <SamantazFox> Also handling and trasversing large unknown data structures is hard

22:27 <SamantazFox> Ok, managed to get it to work in release mode!

22:27 <SamantazFox> I've retrieved the source structure for analysis.

22:47 <FromGitter> <Blacksmoke16> Nice one!

22:58 <SamantazFox> Damn it, the whole data structure changed D:

22:58 <SamantazFox> Welp, I'm good to start over :c

23:19 <FromGitter> <Blacksmoke16> That would do it