<FromGitter>
<TheLonelyGhost> @BlaXpirit also, how soon does it seem like we'll get parallelism? Ruby has been saying it for years but you can't really get past the GIL on MRI.
<BlaXpirit>
TheLonelyGhost, i dunno, core devs seem to be working on it. there's no such roadblock like GIL but who knows what may happen
<BlaXpirit>
it'll be a big undertaking, a lot of code will need to be updated to expect parallelism
<BlaXpirit>
on the other hand much code was modelled to prevent the need to update it for parallelism
<FromGitter>
<TheLonelyGhost> @raydf will check it out. Thanks!
<FromGitter>
<TheLonelyGhost> Yeah, I figured there'd be something else in the way instead of the GIL. I'm curious how Rust did parallelism and seeing if we can draw from that?
<FromGitter>
<raydf> @BlaXpirit , thanks, it looks very stable.
<BlaXpirit>
TheLonelyGhost, Rust fixes everything by being extremely strict. doesnt apply usually
<BlaXpirit>
if you want an analogy, Crystal will be similar to Go
<BlaXpirit>
johnjansen, uhh main monitoring is exception catching in each fiber, and systemd can restart the whole app if it crashes but it really doesnt because just individual fibers crash :(
<FromGitter>
<TheLonelyGhost> Yes, but I figured many people were already looking into Go and it's not based on LLVM, if memory serves. Even if it's a dead end, I'm curious about how they handle a lot of the similar problems we're facing with Crystal. Even if certain core philosophies differ, the macroscopic path to get there might be similar.
<BlaXpirit>
TheLonelyGhost, we don't even know if there are problems per se. it might be just a matter of time
<BlaXpirit>
i'm sure the devs have studied what Go does and it's a relatively good approach
<BlaXpirit>
namely, usually you should not have shared memory but use queue-like structures for communication between different fibers
djellemah has quit [Ping timeout: 260 seconds]
* FromGitter
* TheLonelyGhost shrugs
<FromGitter>
<TheLonelyGhost> Fair point
<FromGitter>
<johnjansen> oh @BlaXpirit sorry (i didnt mean in your code), more like monit, bluepill or the like
<FromGitter>
<raydf> In some commits of the branch it looks like the channels are already thread safe :).
<FromGitter>
<johnjansen> @BlaXpirit i need to read what people write :-) systemd was the answer, sorry
<FromGitter>
<TheLonelyGhost> @raydf interesting... Now I'm definitely going to have to check it out! 😊
<BlaXpirit>
i was worried, but it's actually freenode that really lags right now. my bot receives and sends messages in a timely manner but sometimes i see your messages a minute later all bunched up
<FromGitter>
<raydf> I haven't tried it yet :). based on history of crystal development as indicator, i believe multithreading should be initially supported in around 1-3 months, this is only speculations from me :).
<FromGitter>
<raydf> After that i'm sure we'll find a lot of bugs in std libs.
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/vP2BM
<crystal-gh>
crystal/master 1119f02 Ary Borenszweig: Compiler: restrict else parr of an if with ||. Fixes #3266. Fixes #3412
soveran has joined #crystal-lang
<crystal-gh>
[crystal] asterite closed pull request #3414: fix gets call with delimiter exactly at limit (master...io_gets) https://git.io/vPgyk
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/vP203
<crystal-gh>
crystal/master 56cff37 Ary Borenszweig: GC.stats: remove internal properties not exposed by boehm. Related to #3405
soveran has quit [Ping timeout: 265 seconds]
snsei_ has quit [Remote host closed the connection]
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
<RX14>
BlaXpirit, i'm pretty sure 1 fiber crashing doesn't crash the whole executable usually
pawnbox has quit [Remote host closed the connection]
soveran has quit [Remote host closed the connection]
djellemah has joined #crystal-lang
<FromGitter>
<johnjansen> @raydf i thought he was saying that he wanted it to
<FromGitter>
<johnjansen> although i think this is a candidate for better error handling
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
<BlaXpirit>
RX14, yes, and that's what sucks
<BlaXpirit>
there are like 5 different unrelated exceptions that can happen at that point
<RX14>
what do you mean?
<BlaXpirit>
uh this is specific to my application (well any application that uses SSL sockets)
<BlaXpirit>
there can be timeouts, io exceptions, ssl exceptions
<BlaXpirit>
decoding exceptions
soveran has quit [Remote host closed the connection]
<BlaXpirit>
you name it. fun times
<BlaXpirit>
yeah who am i kidding
<RX14>
yes, surely the correct solution is to either exit or retry when you raise
<BlaXpirit>
did i really expect `@socket.try &.close` to never raise an exception :D
<BlaXpirit>
of course it can timeout, cuz why not
pawnbox has joined #crystal-lang
<RX14>
exceptions happen, if you don't handle them then it's kinda your fault
<BlaXpirit>
i had 2 layers of exception handling, apparently need a 3rd one
<FromGitter>
<johnjansen> @BlaXpirit i think you are swallowing the timeout error anyway … you only raise it if timeout=true and you reset it to false on every iteration
<FromGitter>
<johnjansen> i think
<RX14>
surely if run is in the main fiber, raising in it will exit the program?
<BlaXpirit>
probably
<RX14>
if it's not, then i always use rescue in a loop
soveran has joined #crystal-lang
soveran has quit [Remote host closed the connection]