<FromGitter>
<HertzDevil> `dst` isn't created with `sync_close: true` so closing it will not affect `mem`
<FromGitter>
<spTorin> Without `close` => Unhandled exception: deflate: buffer error (Compress::Deflate::Error) ⏎ add `rewind` before Reader and it works!
<FromGitter>
<HertzDevil> without `close` you might have to do `dst.flush`
deavmi has quit [Quit: No Ping reply in 180 seconds.]
<FromGitter>
<spTorin> with `dst.flush` => deflate: buffer error
deavmi has joined #crystal-lang
<FromGitter>
<spTorin> with `close` and `mem.rewind` => Ok
<oprypin>
HertzDevil, you might be confusing close operation of IO and close operation of Compress
yxhuvud has quit [Remote host closed the connection]
yxhuvud has joined #crystal-lang
HumanG33k has quit [Ping timeout: 246 seconds]
Human_G33k has joined #crystal-lang
HumanGeek has joined #crystal-lang
Human_G33k has quit [Ping timeout: 260 seconds]
Human_G33k has joined #crystal-lang
HumanGeek has quit [Ping timeout: 240 seconds]
HumanG33k has joined #crystal-lang
HumanGeek has joined #crystal-lang
HumanG33k has quit [Read error: Connection reset by peer]
Human_G33k has quit [Ping timeout: 258 seconds]
Human_G33k has joined #crystal-lang
HumanGeek has quit [Ping timeout: 240 seconds]
Human_G33k has quit [Ping timeout: 240 seconds]
sorcus has quit [Quit: WeeChat 2.9]
sorcus has joined #crystal-lang
<FromGitter>
<aaaScript> @oprypin Do you know if it's possible to leverage `ImGuiContext` from your bindings? I've been trying to see if I can implement a custom menu bar that's locked to the edges of the window and expands when the host window expands. To achieve that I've been taking a look at how it's implemented in the original (https://github.com/ocornut/imgui/blob/master/imgui_widgets.cpp#L6525), here's my attempt for
<oprypin>
aaaScript, it's really difficult to tell which of the functionality is available and which is not
<FromGitter>
<aaaScript> Like for example, in the screenshot above, I made that sub menu with exact coordinates to match my screen. I want to see if there's a way to scale it when resizes are done. Since right now it's pretty locked.
<oprypin>
there's always `g.FontSize` and `g.Style` in the impl code
<oprypin>
but the public api for that is just ImGui.get_font_size and ImGui.get_size
<oprypin>
so you can do *those* things
<oprypin>
for others either you failed to find them or it's not possible with public apis. and i can't really help you because im actually a noob to imgui xD
<FromGitter>
<aaaScript> I'll play with it a bit more and see if I can get something working.
<FromGitter>
<aaaScript> @oprypin I think I actually got it working, I just need to understand what `g` was better. Thanks.
<oprypin>
aaaScript, you can probably get help in imgui's discord :)
<FromGitter>
<aaaScript> Thanks, that makes it more neater.
<FromGitter>
<aaaScript> Now I gotta figure out how to port a file explorer widget.
HumanG33k has joined #crystal-lang
HumanG33k has quit [Excess Flood]
HumanG33k has joined #crystal-lang
HumanG33k has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
<FromGitter>
<lbarasti> @j8r: I've noticed that calling `thread.scheduler.@runnables` from within `Thread.unsafe_each` doesn't seem to collect the full set of fibers - see https://carc.in/#/r/9tg6
HumanG33k has quit [Remote host closed the connection]
<FromGitter>
<lbarasti> maybe there is a different way to access fibers related to a thread?
<FromGitter>
<lbarasti> (I noticed the discrepancy because I was running an application with ~8 fibers, but the snippet would return either 1 or 0 😱
<FromGitter>
<j8r> if you want the main one too, you can get it with `thread.scheduler.@main`
<FromGitter>
<lbarasti> basically, what I'm observing is that depending on which fiber we invoke the thread count in we seem to get different results
<FromGitter>
<Blacksmoke16> And what do you need this for?
<FromGitter>
<lbarasti> @Blacksmoke16 the idea would be to monitor the number of fibers to detect any fiber leak
<FromGitter>
<Blacksmoke16> Given you can spawn millions of them is that really useful?
<FromGitter>
<Blacksmoke16> I'd imagine you'd get a stack overflow if there was just a loop of spawning them
<FromGitter>
<lbarasti> Ok, here is tge use case I have in mind: you have a fairly complex application spawning fibers on demand. You'd assume they do their part and the shut down.
<FromGitter>
<lbarasti> I wiuld find it useful to look at the fiver count pattern to understand whether there is something I've missed
<FromGitter>
<lbarasti> So rather than waiting to get a stack overflow in production, we can simulate the load and volume offline, and keep an eye on any leak
<FromGitter>
<lbarasti> Am I making sense?
<FromGitter>
<Blacksmoke16> fair enough
<FromGitter>
<wyhaines> It makes sense. I have a similar desire for a platform that I'm working on.