<FromGitter>
<nanobowers> Thanks, that works. Downside is that you lose encapsulation in at the file or inside-the-describe level so that if (in my case) there are multiple tests that each define a `setup` function, then they will necessarily need to be renamed or enclosed in a module namespace or whatever.
<FromGitter>
<Blacksmoke16> are some shards that expand upon Spec module to add more features
<FromGitter>
<Blacksmoke16> if you wouldnt mind a dep
<FromGitter>
<nanobowers> i've been trying to keep my deps minimal, but probably should take a look instead of fighting it and possibly delaying the inevitable
guest8035 has quit [Remote host closed the connection]
<FromGitter>
<jrei:matrix.org> @nanobowers: sharing a common immutable setup and variable?
<FromGitter>
<jrei:matrix.org> For the multiple tests that each define a `setup` function. If a set of them need the same one, you can pass a proc to the `assert`, or use the same assert for them
darwillim86d has joined #crystal-lang
hightower4 has joined #crystal-lang
hightower3 has quit [Ping timeout: 265 seconds]
Starfoxxes has quit [Ping timeout: 245 seconds]
Starfoxxes has joined #crystal-lang
notzmv has quit [Read error: Connection reset by peer]
notzmv has joined #crystal-lang
SamantazFox_ is now known as SamantazFox
<FromGitter>
<RespiteSage> Following up from the other day, I'm still getting the arithmetic overflow on raise problem when using `1.2.0-dev [a253018a9] (2021-09-07)`.
<FromGitter>
<Blacksmoke16> it's prob a platform issue tbh
<FromGitter>
<jrei:matrix.org> as I said, try inside docker with OpenSUSE stable
<FromGitter>
<jrei:matrix.org> then Tumbleweed
<FromGitter>
<RespiteSage> Maybe this is what will finally convince me to abandon Tumbleweed for Leap...
<FromGitter>
<Blacksmoke16> Arch 😉
<FromGitter>
<RespiteSage> I'm already so used to OpenSUSE, though... Since this is my work machine, I'd probably switch to Ubuntu or another debian-based OS if I were going to totally switch OSes.
<FromGitter>
<jrei:matrix.org> Personally I don't see much difference
<FromGitter>
<RespiteSage> When I started at the company (my first job) and was given the machine, it had OpenSUSE Leap installed (though to my knowledge nobody else at my company uses the OS), then I accidentally switched it to Tumbleweed, and I've been too stubborn to switch.
<FromGitter>
<jrei:matrix.org> I take the most stable, so Debian :)
<FromGitter>
<RespiteSage> Fair.
<FromGitter>
<RespiteSage> OpenSUSE Tumbleweed is (intentionally) not the most stable, so I should probably give it up.
<FromGitter>
<jrei:matrix.org> I'm on Debian Unstable, which is still ok. I just have to beware of package upgrades, when an app is not yet available and propose me to remove this app, because a newer, incompatible packages is available
<FromGitter>
<RespiteSage> Containerized OpenSUSE Leap works without any issues.
<FromGitter>
<jrei:matrix.org> And tumbleweed?
<FromGitter>
<jrei:matrix.org> *in docker of course
<FromGitter>
<RespiteSage> One sec.
<FromGitter>
<RespiteSage> I get the same arithmetic overflow on the containerized Tumbleweed install.
<FromGitter>
<jrei:matrix.org> Ok, so i don't know how updates work on OpenSuse. We may start from Leap, add thr Tumbleweed repo, then update one crystal system lib dep at a time
<FromGitter>
<jrei:matrix.org> Because clearly the issue comes from a system library.
<FromGitter>
<jrei:matrix.org> `ldd` the crystal binary will show them.
<FromGitter>
<RespiteSage> Yeah.
<FromGitter>
<jrei:matrix.org> We might be hit by the same issue as well in several weeks 😅
<FromGitter>
<RespiteSage> "we"?
<FromGitter>
<RespiteSage> On Debian Unstable?
<FromGitter>
<RespiteSage> `ldd` gives me `not a dynamic executable`.
<FromGitter>
<RespiteSage> I did make sure I wasn't using it on the script.
<FromGitter>
<jrei:matrix.org> Sorry, my bad. Rather do a ldd on the built crystal application binary
<FromGitter>
<RespiteSage> Oh, gotcha.
<FromGitter>
<jrei:matrix.org> On other rolling release distributions, especially Arch. Or maybe the bug only affect OpenSUSE, on how they compiled the library and not the version they use 🤷
<FromGitter>
<jrei:matrix.org> One temporary solution for you is to use an alpine container and build statically linked binaries.
<FromGitter>
<RespiteSage> My current solution is to avoid raising.
<FromGitter>
<RespiteSage> Which is non-ideal, but I'm not doing any time-sensitive Crystal work right now.
<FromGitter>
<jrei:matrix.org> I'm nearly sure it is related to libunwind, static linking on Alpine had this issue
<FromGitter>
<RespiteSage> Yeah, I figured that was what it related to.
<FromGitter>
<jrei:matrix.org> To be 100% sure if I were you I'd just upgrade this library on Leap to Tumbleweed. ⏎ ⏎ Anyway, definitely worth opening an issue
<FromGitter>
<RespiteSage> Should I be seeing `libunwind` in the `ldd` output?
<FromGitter>
<RespiteSage> I don't see it for either OS.
<FromGitter>
<RespiteSage> Is it part of one of the other shared objects, like libc?
<FromGitter>
<jrei:matrix.org> right me too
<FromGitter>
<RespiteSage> Leap has `libevent-2.1.so.6`, while Tumbleweed has `libevent-2.1.so.7`.
<FromGitter>
<RespiteSage> That could be it.
<FromGitter>
<jrei:matrix.org> on debian I have `Depends: gcc, pkg-config, libpcre3-dev, libevent-dev`
<FromGitter>
<RespiteSage> Can you check which libevent version you have?
<FromGitter>
<jrei:matrix.org> not sure if the event loop and exceptions are related, I doubt
<FromGitter>
<RespiteSage> That's fair.
<FromGitter>
<jrei:matrix.org> maybe that's the libc?
<FromGitter>
<RespiteSage> Maybe. There aren't any obvious `ldd` differences other than the `libevent` difference.
<FromGitter>
<jrei:matrix.org> You said compiling crystal and using the built compiler still had the issue
<FromGitter>
<RespiteSage> Yes.
<FromGitter>
<jrei:matrix.org> Can't help more sorry :/ You should open an issue
<FromGitter>
<RespiteSage> Yeah. Thank you.
<FromGitter>
<RespiteSage> Should that go in the main repo or the distribution scripts repo?