ChanServ changed the topic of #crystal-lang to: The Crystal programming language | | Fund Crystal's development: | GH: | Docs: | Gitter:
<FromGitter> <Blacksmoke16> can also use `case/in`
<FromGitter> <Blacksmoke16> which wouldn't compile if you introduced a fourth type into the union
straight- has quit [Quit: ZNC 1.8.2 -]
straight-shoota has joined #crystal-lang
ur5us_ has quit [Remote host closed the connection]
ur5us_ has joined #crystal-lang
ur5us_ has quit [Ping timeout: 264 seconds]
<FromGitter> <> Hi, does anyone know if there are any plans of implementing preemption? Right now I don't trust Crystal for building backend as fibers can starve each other
deavmi_ has quit [Read error: Connection reset by peer]
ur5us_ has joined #crystal-lang
<FromGitter> <Blacksmoke16> could prob code it to do that, nothing built in atm tho
<FromGitter> <> Already read #1454 but it's from 2017 and seem like the problem hasn't been addressed for a while
<FromGitter> <> Already read #1454 but it's from 2017 and seems like the problem simply hasn't been addressed later. ⏎ ⏎ PS: Sorry for the weird stuff, I'm new to matrix
<FromGitter> <Blacksmoke16> Probably wouldn't hurt to bump it maybe. But probably not a priority ATM
<FromGitter> <> Right now Windows support is (rightfully) the priority, but still it's weird how whole backend frameworks got created without no one actually noticing the risk
<FromGitter> <Blacksmoke16> Oh?
<FromGitter> <Blacksmoke16> Have you been able to reproduce something related to that?
<FromGitter> <> You mean using a backend framework or simply starving a fiber?
<FromGitter> <Blacksmoke16> Combining the two
<FromGitter> <> No I'm simply teorizing that it would be possible. You can easily starve a fiber, I don't see why this wouldn't apply to the case
<FromGitter> <> You can simply do something stupid in a handler and you're done. Blocked the runtime for an unknown amount of time
<FromGitter> <Blacksmoke16> Solution there is write tests 😉
<FromGitter> <> Done, I've just blocked athena
<FromGitter> <Blacksmoke16> with what code?
<FromGitter> <> I'm trying to send it but this client is weird
<FromGitter> <> Alright, so. When you contact /1 first, the backend won't be able to accept any other request after
<FromGitter> <> if you contact /2 first the backend will just work as expected
<FromGitter> <Blacksmoke16> are you making the requests via opening chrome tabs?
<FromGitter> <Blacksmoke16> each request is handled in its own fiber. The loop would block all requests to `/1`, but other requests would be fine
<FromGitter> <> Both firefox and the cli http tool
<FromGitter> <Blacksmoke16> actually wait
<FromGitter> <> Ok, I'll try waiting. This time with curl
<FromGitter> <Blacksmoke16> naw i think you're right. there's no IO or anything so it would never switch to another fiber
<FromGitter> <Blacksmoke16> but would prob timeout after some period of time
<FromGitter> <Blacksmoke16> however this ofc represents a bug in your code that could be handled via testing no?
<FromGitter> <> Just to be sure I waited and no sign of life
<FromGitter> <> Yeah, you could avoid this via automated testing, but this is still a really huge problem
<FromGitter> <Blacksmoke16> MT would also prevent this
<FromGitter> <Blacksmoke16> until all threads were blocked at least
<FromGitter> <Blacksmoke16> idk, hasn't come up really so might not be that big of an issue :shrug:
<FromGitter> <> Imagine having discovering a new edgecase not covered by tests having your backend bombarded by it until all threads are blocked
<FromGitter> <> Btw is the single client not allowing me to edit messages or is it a matrix thing?
<FromGitter> <Blacksmoke16> not sure, i just use gitter web
<FromGitter> <Blacksmoke16> wonder if there is a place for ameba in this as well. Like warn on cases where an infinite loop could occur
<FromGitter> <> Yes, it was a client problem, I'm on element now
<FromGitter> <> Through testing a good analysis are a small patch on really big hole though
<FromGitter> <Blacksmoke16> can manually do `sleep 0` to somewhat get around this tho
<FromGitter> <Blacksmoke16> as it'll check if other fibers need to execute and switch to them, then eventually get back to that fiber
<FromGitter> <> Yeah, but on Discord some time ago I showed you a case where this wasn't really possible
<FromGitter> <> Here the problem created because I wanted to concurrently handle input and output trough NCurses
<FromGitter> <Blacksmoke16> yea dunno, having it be based on partial C could prob doesn't make it easier either
<FromGitter> <> This is a big problem that should absolutely not be ignored further in a language that calls itself production ready
<FromGitter> <> Imo calling Crystal production ready with this single problem (which is not the only one) is really v-lang level talk
<FromGitter> <Blacksmoke16> :shrug: make a forum thread about this info and see if there's any quick wins
<FromGitter> <> I forgot that Crystal had a forum. Yeah, I think that I'll start a thread
<FromGitter> <Blacksmoke16> some would argue the biggest problem is windows support, or MT not being 100% yet, etc. Doesn't mean it's not production ready
<FromGitter> <> In fact I'm not saying that's it's the biggest problem. I'm saying that it's an incredibly huge problem, yet not the biggest onen
<FromGitter> <Blacksmoke16> maybe less so in some areas, but in the end is just another problem that needs solving
deavmi has joined #crystal-lang
deavmi has quit [Quit: No Ping reply in 180 seconds.]
deavmi has joined #crystal-lang
deavmi_ has joined #crystal-lang
deavmi has quit [Read error: Connection reset by peer]
ur5us_ has quit [Ping timeout: 264 seconds]
<FromGitter> <Dan-Do> I am dealing with that using timeout channel atm
<FromGitter> <wyhaines> I don't think it's really even a problem that needs to be solved. The fact that fibers do not have a pre-emptive scheduler means that one must understand that fact when writing concurrent code, but it's hardly a flaw. Insert a Fiber.yield into the loop, and it is no longer blocking.
<FromGitter> <HertzDevil> soon...?
<FromGitter> <HertzDevil> the asm output is not very useful if i include the prelude
elf_fortrez has joined #crystal-lang
elf_fortrez has quit [Quit: Client closed]
<FromGitter> <HertzDevil> in fact compiling anything with the prelude and `--release` causes a timeout
<FromGitter> <alex-kampa> > can manually do `sleep 0` to somewhat get around this tho ⏎ ⏎ Hi @Blacksmoke16 will "sleep 0 "have the same effect as Fiber.yield ?
<FromGitter> <alex-kampa> @wyhaines you suggested Fiber.yield, what do you think about "sleep 0", what's the difference?
<straight-shoota> It's literally the same: Fiber.yield is implemented as sleep(0)
<FromGitter> <alex-kampa> Ok, so just to be 100% sure, the place to insert this would be as follows: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ Is that correct? []
<straight-shoota> Technically, yes. But it's really not necessary at this location.
<straight-shoota> Yielding a fiber is a tool you would use in a tight loop to give the scheduler an opportunity to change to some other task.
<straight-shoota> But your loop contains I/O operations which already expose such opportunities due to their async implementation
<FromGitter> <alex-kampa> Thanks for the clarification. Yes I noticed that it all works well without putting in the Fiber.yield.
<FromGitter> <rishavs> Hey @straight-shoota how goes the Windows signals work? eagerly awaiting it. 😺
<yxhuvud> straight-shoota: I wouldn't mind moving Scheduler#yield to a event loop dependent place though. I don't know about how it would work on windows but at least for uring it makes no sense to set up a timer instead of using a NOP op.
<yxhuvud> assuming there is even need to emit an op in the first place, which is questionable.
<straight-shoota> rishavs, Windows is not exactly made for signals. We'll probably be able to imitate a few of them, but you shouldn't expect that to work as on posix systems
<straight-shoota> yxhuvud, yeah, that's probably a good idea. Fiber.yield == sleep 0 is an implementation detail of the event loop
<FromGitter> <rishavs> ❤️
<FromGitter> <rishavs> I just want crystal on windows so I can do some gamejams using crsfml ^_^. I am not interested in the networking bits, just hate the effort it requires to set up crystal on windows currently. ⏎ I would be happy if I can just do `scoop install crystal` and the compiler after installation throws a big honking text `Networking is not supported on windows platform`. ⏎ ⏎ Anyway, wanted to thank you and the
<FromGitter> ... rest of the team on picking more big rocks on the windows side of things. []
<FromGitter> <rishavs> Hey folks. I am trying to move away from basic auth on my toy project and wanted to do a sessions + JWT implementation. I plan on hand rolling this to understand the entire auth process (which has always scared me in the past) ⏎ Can you critique my auth strategy and let me know if it makes sense? Sorry if this takes too much screen space. ⏎ ⏎ ```code paste, see link```
<FromGitter> <HertzDevil> does crystal have the capability to distinguish between prelude code and user code in build artifacts
<FromGitter> <HertzDevil> mainly asm and llvm-ir
<yxhuvud> what functions would be part of the prelude?
<FromGitter> <rishavs> Any sneak peak on the 1.10 chagelog?
<FromGitter> <rishavs> Thanks !
<FromGitter> <> hi folks, i'm trying to parse a stream of rather large json objects without any delimiters between them from an IO... is there some sane way to do that
<FromGitter> <> the only way i've found so far would be to use the JSON::PullParser and manually try to parse everything... or maybe going through the stream and counting braces, but that's also error-prone because of escaping
<FromGitter> <Blacksmoke16> can you alter the source to make them at least on unique lines?
<FromGitter> <> unfortunately not, i'm consuming a 3rd party api for streaming events
<FromGitter> <> hmm, lemme double-check that though
<FromGitter> <> ok, i must've made some mistake, it seems a simple gets on the io with a huge buffer works :)
<FromGitter> <> and each_line is even more elegant
<FromGitter> <Blacksmoke16> so they are delimited then?
<FromGitter> <> i tried `IO::Delimited` first, but that was probably wrong
<FromGitter> <> sure looks like there are proper newlines in there, yeah
<FromGitter> <> sorry for the disturbance ^^;
<FromGitter> <HertzDevil> looking at the llvm ir and asm outputs, they do include source locations even without `--debug` which should be enough
<FromGitter> <HertzDevil> because on compiler explorer there should most certainly be only one non-library source file, everything else would be considered "third-party" code
Guest73 has joined #crystal-lang
Guest73 has left #crystal-lang [#crystal-lang]
Guest3876 has joined #crystal-lang
Guest3876 has quit [Client Quit]
<FromGitter> ... block later on. However despite that it still leaves the socket open and listening. I'm assuming it needs to be closed within the `spawn` block but I'm wondering if anyone has some insight on that.
<FromGitter> <aaaScript> Hi everyone. I have a quick question. Has anyone ever had an issue with closing a HTTP::Server's port when it is created in a fiber. I'll try to see if I can come up with some cleaned code but I'm basically creating an having a new HTTP Server listen while in a `spawn` block so that it doesn't block the rest of the program. Then later I'm trying to close it with the `#close` function outside of the `spawn`
<straight-shoota> that should really make no difference
<yxhuvud> just make certain the fiber is actually done with it before closing it in the original fiber
edegaru has joined #crystal-lang
postmodern has joined #crystal-lang
<FromGitter> <aaaScript> Is there a good way to ensure that a a fiber is complete and able to be closed? Since the http server is stuck on listening, I'm not sure of a way to send a close command while it's in that state.
deavmi_ has quit [Ping timeout: 252 seconds]
<straight-shoota> HTTP::Server#close should do
<FromGitter> <aaaScript> Oddly enough using that method doesn't seem to do anything. I'll try to see if I can replicate it in a small block of code for some more context.
<straight-shoota> Well, it tries a graceful shutdown. If any requests are still being processed, they'll continue. Can you check if the close method returns or blocks?
<FromGitter> <> @rishavs: ⏎ ⏎ > I just want crystal on windows so I can do some gamejams using crsfml ^_^. I am not interested in the networking bits, just hate the effort it requires to set up crystal on windows currently. ⏎ ⏎ i have to say, a one-time hurdle that takes up an hour at most doesn't seem reasonable to give up at, considering how big of a followup you're abstaining from.
ur5us_ has joined #crystal-lang
<FromGitter> <aaaScript> > *<straight-shoota>* Well, it tries a graceful shutdown. If any requests are still being processed, they'll continue. Can you check if the close method returns or blocks? ⏎ ⏎ The close method does return, yes.
<FromGitter> <aaaScript> However, the fiber running the listen method still blocks and doesn't let the fiber close.
<straight-shoota> Hm, that's odd. Server#close should close all the listening sockets, so accept on them should fail at that point
<FromGitter> <aaaScript> I think it seems to be extremely specific to my code and the use of Granite since I'm not able to replicate it into a smaller file. I'm creating HTTP::Server objects dynamically based on host/port attributes created from Granite models. I think that is causing some weird issues. I'll try to look into it and report back if I determine anything from it.
edegaru2 has joined #crystal-lang
edegaru3 has joined #crystal-lang
edegaru has quit [Ping timeout: 268 seconds]
edegaru2 has quit [Ping timeout: 252 seconds]
edegaru2 has joined #crystal-lang
edegaru3 has quit [Ping timeout: 252 seconds]
hightower2 has joined #crystal-lang
deavmi has joined #crystal-lang
<FromGitter> <didactic-drunk> @aaaScript 1) Are you using -Dpreview_mt? 2) After `.close` what is the socket listen state? Can you check with `netstat -ln`
hightower2 has quit [Ping timeout: 268 seconds]
edegaru2 has quit [Ping timeout: 252 seconds]
edegaru has joined #crystal-lang
xybre is now known as snowdrop
edegaru has quit [Ping timeout: 265 seconds]
<FromGitter> <aaaScript> I am not. Also after running `netstat` the socket is still in a LISTEN state.