ChanServ changed the topic of #crystal-lang to: The Crystal programming language | | Fund Crystal's development: | GH: | Docs: | Gitter:
<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
<FromGitter> <Blacksmoke16> is a bit more of an overhauled spec framework
<FromGitter> <Blacksmoke16> is built on `Spec` module and acts as an alternative DSL
<FromGitter> <Blacksmoke16> and are quite a few others
ur5us has joined #crystal-lang
otoburb has quit [Quit: leaving]
ur5us has quit [Ping timeout: 260 seconds]
guest8035 has joined #crystal-lang
guest8035 has quit [Remote host closed the connection]
<FromGitter> <> @nanobowers: sharing a common immutable setup and variable?
<FromGitter> <> 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> <> as I said, try inside docker with OpenSUSE stable
<FromGitter> <> 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> <> 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> <> 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> <> 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> <> And tumbleweed?
<FromGitter> <> *in docker of course
<FromGitter> <RespiteSage> One sec.
<FromGitter> <RespiteSage> I get the same arithmetic overflow on the containerized Tumbleweed install.
<FromGitter> <> 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> <> Because clearly the issue comes from a system library.
<FromGitter> <> `ldd` the crystal binary will show them.
<FromGitter> <RespiteSage> Yeah.
<FromGitter> <> 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> <> Sorry, my bad. Rather do a ldd on the built crystal application binary
<FromGitter> <RespiteSage> Oh, gotcha.
<FromGitter> <> 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> <> 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> <> 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> <> 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> <> right me too
<FromGitter> <RespiteSage> Leap has ``, while Tumbleweed has ``.
<FromGitter> <RespiteSage> That could be it.
<FromGitter> <> on debian I have `Depends: gcc, pkg-config, libpcre3-dev, libevent-dev`
<FromGitter> <RespiteSage> Can you check which libevent version you have?
<FromGitter> <> not sure if the event loop and exceptions are related, I doubt
<FromGitter> <RespiteSage> That's fair.
<FromGitter> <> maybe that's the libc?
<FromGitter> <RespiteSage> Maybe. There aren't any obvious `ldd` differences other than the `libevent` difference.
<FromGitter> <> You said compiling crystal and using the built compiler still had the issue
<FromGitter> <RespiteSage> Yes.
<FromGitter> <> 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?
<FromGitter> <> The main one
Peter0x41 has joined #crystal-lang
Peter0x44 has quit [Ping timeout: 245 seconds]
ur5us has joined #crystal-lang
hightower4 has quit [Ping timeout: 260 seconds]
hightower2 has joined #crystal-lang
rem has joined #crystal-lang
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #crystal-lang