00:53 < bridge> [ddnet] Is there any work with threads in teeworlds code? 00:53 < bridge> [ddnet] Is there any work with threads in teeworlds(ddnet) code? 00:55 < bridge> [ddnet] Yes 00:57 < bridge> [ddnet] what is your bug? 00:57 < bridge> [ddnet] std::thread should work just fine 00:58 < bridge> [ddnet] (or the more tee-ish engine jobs which should be used if possible) 00:58 < bridge> [ddnet] Its not 00:58 < bridge> [ddnet] or thread_init_and_detach xD 00:58 < bridge> [ddnet] oh yeah we do have an abstraction around threads too 00:58 < bridge> [ddnet] I use std::thread t1(*my void function*) and it gives me error 00:59 < bridge> [ddnet] Since none of us here have telepathic abilities we can't really diagnose from just "error" 😄 00:59 < bridge> [ddnet] u cannot just run a function from a class 00:59 < bridge> [ddnet] u need to bind this then 01:00 < bridge> [ddnet] or use a static function and call it from there 01:00 < bridge> [ddnet] std::bind(&Class::Func, this) 01:00 < bridge> [ddnet] should work 01:00 < bridge> [ddnet] :Alzheimer: 01:00 < bridge> [ddnet] Thx 01:00 < bridge> [ddnet] I will test it tmrw 01:04 < bridge> [ddnet] c++11 is nicer way imo xd 01:04 < bridge> [ddnet] I'd disagree since I'm a fan of using only one set of abstractions, but to each their own 01:05 < bridge> [ddnet] What do you think about how I solved #3917? 01:05 < bridge> [ddnet] https://github.com/ddnet/ddnet/pull/3917 01:05 < bridge> [ddnet] It works but im not sure if there is a better way 01:06 < bridge> [ddnet] I don't know of any, @heinrich5991 might 01:06 < bridge> [ddnet] but whats wrong with c++11 tho? its standard 01:06 < bridge> [ddnet] ez to read for everyone 01:07 < bridge> [ddnet] I mean if you think `thread_init` is any harder to read there is nothing to discuss, but given they are equally readable we already use one in the codebase, no need to introduce another one 01:08 < bridge> [ddnet] yeah but that makes the code more complex 01:08 < bridge> [ddnet] a name u need to know 01:08 < bridge> [ddnet] if u a new contributor u would search for this function 01:08 < bridge> [ddnet] (fwiw I'd be okay if we replaced all uses of it, mine is just a consistency thing) 01:09 < bridge> [ddnet] a ok 02:00 < bridge> [ddnet] https://www.redox-os.org/news/open-source-mental-health/ 02:04 < bridge> [ddnet] yeah i think georode sent this a few days ago 02:04 < bridge> [ddnet] not sure if i agree with everything psychologically wise 02:04 < bridge> [ddnet] but still good insight 02:08 < bridge> [ddnet] yeah i think gerdoe sent this a few days ago 02:08 < bridge> [ddnet] not sure if i agree with everything psychologically wise 02:19 < bridge> [ddnet] Hm, async rust really does need some more work, I just remembered a condition variable solves my issue perfectly but tokio doesn't have one yet 08:35 < bridge> [ddnet] But rust has cond vars iirc 08:35 < bridge> [ddnet] Or atleast a lib 08:37 < bridge> [ddnet] @Learath2 https://docs.rs/tokio/0.2.13/tokio/sync/struct.Notify.html 08:37 < bridge> [ddnet] I think u can use this 08:38 < bridge> [ddnet] https://docs.rs/tokio/1.7.0/tokio/sync/struct.Notify.html 08:38 < bridge> [ddnet] Updated* 09:05 < bridge> [ddnet] Close but no dice. Condvars are great because they also have a mutex meaning I can safely access the condition after being notified 09:06 < bridge> [ddnet] Rust only has a sync one working with std::sync::Mutex 09:07 < bridge> [ddnet] https://github.com/tokio-rs/tokio/pull/3742 09:07 < bridge> [ddnet] its closed tho 09:07 < bridge> [ddnet] > We discussed this on discord. It seems that implementing an async Condvar that behaves correctly in the face of cancellation is difficult 09:08 < bridge> [ddnet] async-std, a competing runtime to tokio has it, but ignores cancellation 09:08 < bridge> [ddnet] Condvars that behave correctly are indeed very hard :F 09:10 < bridge> [ddnet] http://birrell.org/andrew/papers/ImplementingCVs.pdf here is a paper that shows why 09:12 < bridge> [ddnet] > The tricky part arises because of the binary atomic operation in 09:12 < bridge> [ddnet] > Wait, where the lock is released and the thread is enqueued on the condition variable. 09:12 < bridge> [ddnet] > If you don’t have a suitable binary operation available, and you attempt to construct 09:12 < bridge> [ddnet] > one by clever use of something like a semaphore, you’ll probably end up with an 09:12 < bridge> [ddnet] > incorrect implementation. You should either do the queuing yourself, or lobby your 09:12 < bridge> [ddnet] > kernel implementer to provide a suitable primitive. 09:16 < bridge> [ddnet] Queuing explicitly is what glibc does, I might contribute a similar implementation to tokio but threads you can't cancel, tokio tasks you can, which is kinda difficult to handle 09:21 < bridge> [ddnet] Actually, I know how to fix that one too, most common definition of condition vars only allows a thread queued at the signal point to handle a signal, the cancellation example given there is moot, a task should never be able to wake itself up with a signal 09:22 < bridge> [ddnet] so if a task waiting on a signal is cancelled unless there is another task waiting, the signal should be discarded 09:38 < bridge> [ddnet] what are the standard ports for teeworlds? 09:39 < bridge> [ddnet] 8303? 09:39 < bridge> [ddnet] yes 09:39 < bridge> [ddnet] ty 11:42 < bridge> [ddnet] pls merge 11:44 < bridge> [ddnet] i bet we cant bcs it breaks some old clients xdddd 11:44 < bridge> [ddnet] but funny nobody noticed yet 11:47 < bridge> [ddnet] i am crying 11:47 < bridge> [ddnet] was joke 11:48 < bridge> [ddnet] no you made me cry 11:48 < bridge> [ddnet] too late 11:48 < bridge> [ddnet] i dunno if some messages gets parsed 11:48 < bridge> [ddnet] :''''( 11:48 < bridge> [ddnet] its ok to cry 11:49 < bridge> [ddnet] https://www.youtube.com/watch?v=m_S0qCeA-pc 11:50 < bridge> [ddnet] rest in peace btw 11:51 < bridge> [ddnet] sophie is cool 11:53 < bridge> [ddnet] died waaaaay too soon 11:54 < bridge> [ddnet] @nuborn you like hyperpop? 11:54 < bridge> [ddnet] o let's move to #off-topic 11:54 < bridge> [ddnet] sure 12:37 < bridge> [ddnet] @Jupstar ✪ :mae_death_2::mae_death_1: it says there are no constructors of `std:🧵:thread` with `(void())` arguments 12:37 < bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/855033338921222154/unknown.png 12:41 < bridge> [ddnet] auto ircStartFunc = std::bind ... 12:42 < bridge> [ddnet] :earlessfloppa: 12:42 < bridge> [ddnet] okay 12:42 < bridge> [ddnet] or put the std::bind directly into the iirc thread parameter 12:43 < bridge> [ddnet] it worked 12:43 < bridge> [ddnet] thx 12:43 < bridge> [ddnet] :feelsamazingman: 13:37 < bridge> [ddnet] https://urbit.org/ 13:42 < bridge> [ddnet] i have been following urbit for a whilke 13:42 < bridge> [ddnet] i have been following urbit for a while 13:42 < bridge> [ddnet] but recently havent heard much 15:57 < bridge> [ddnet] https://www.phoronix.com/scan.php?page=news_item&px=Zink-Suballocator-Performance 15:57 < bridge> [ddnet] @Jupstar ✪ 15:58 < bridge> [ddnet] Blumenkrantz summed up the impact in a new blog post as "massively improved performance" across many apps/games. As an extreme example, Tomb Raider (2013) went on Zink from running at a horrible 9 FPS to now at 91 FPS... Quite a big improvement and likely puts it closer to native OpenGL driver performance. 15:59 < bridge> [ddnet] Ddnet zink :greenthing: 19:54 < bridge> [ddnet] short question to developers, is there a "vull command list" of tw somewhere? im looking for a command to display something permant, something like echo but as an hud.... 19:56 < bridge> [ddnet] press tab in console 19:56 < bridge> [ddnet] https://wiki.ddnet.tw/wiki/Settings_and_Commands 19:56 < bridge> [ddnet] im not sure how up to date that is 19:56 < bridge> [ddnet] also the command u search does not exist 19:57 < bridge> [ddnet] u can order that feature for chillerbot-ux tho \:D 19:59 < bridge> [ddnet] thanks 20:09 < bridge> [ddnet] whats that? xd 20:32 < bridge> [ddnet] whats what? \:D 20:40 < bridge> [ddnet] what's chillerbot-ux 20:41 < bridge> [ddnet] it's a custom client by chillerdragon 20:41 < bridge> [ddnet] oh did the bridge swallow a reply again? \:/ 20:41 < bridge> [ddnet] or am i just stoopid? \:D 20:42 < bridge> [ddnet] If it would just work on windows correctly :\