01:40 <+bridge_> [ddnet] <Evgesha> Add a DDNet Discord bot feature to post in #records 
01:40 <+bridge_> [ddnet] <Evgesha> `%username% just finished all maps on [%ServerName%]`
01:42 <+bridge_> [ddnet] <Gwendal> bad idea imo xd
02:06 <+bridge_> [ddnet] <jao> good idea
02:12 <+bridge_> [ddnet] <jao> but very expensive
02:16 <+bridge_> [ddnet] <jao> or maybe not
06:48 <+bridge_> [ddnet] <fokkonaut> @coffee, now that I updated to master we can work on it :)
06:49 <+bridge_> [ddnet] <fokkonaut> My server is running 24/7 now, will probably make some improvements/ changes next week
15:08 <+Learath2> C++ classes are really quite lacking for reliable software
15:08 <+Learath2> s/$/ development/
15:09 <+Learath2> A failure in the constructor is very hard to communicate up the stack
15:09 <+Learath2> Exceptions/decoupling error handling from error detection, is also quite an unwise pattern
15:11 <+Learath2> OOP in general is quite unwieldy...
16:06 <@deen> having 50 manual error checks is also unwieldy compared to a single catch
16:18 <+Learath2> 50 manual error checks that know the context of the error and are easy to spot if missing
16:19 <+Learath2> exceptions can travel all the way up the stack if you forget to handle some and it's not so easy to know from a glance what exceptions can arise from calling a function
16:21 <+bridge_> [ddnet] <qshar> what exactly does %current% do as entities background? Does it allow to see the quads layers that are placed before the game group or all other quad layers too?
16:22 <+bridge_> [ddnet] <fokkonaut> It uses the current map as your entities background
16:22 <+bridge_> [ddnet] <fokkonaut> Same rules as for any other map too
16:22 <+bridge_> [ddnet] <fokkonaut> Nothing in front of game is displayed
16:23 <+bridge_> [ddnet] <fokkonaut> Thats why i told you before, it doesnt work for your servers with Movable objects. You would need to play both; one layer behind and one in front of game
16:25 <+bridge_> [ddnet] <n000b ryozuki sucks> @qshar you can set whatever bg you want
16:25 <+bridge_> [ddnet] <n000b ryozuki sucks> With this
16:25 <+bridge_> [ddnet] <fokkonaut> @n000b ryozuki sucks sorry that was absolutely not helpful
16:25 <+bridge_> [ddnet] <qshar> ye, thats sad. Is it hard to implement such option to display all quad layers with entities?
16:26 <+bridge_> [ddnet] <qshar> bg means behind the game layer - so it doesn't fit
16:26 <+bridge_> [ddnet] <jao> no
16:26 <+bridge_> [ddnet] <jao> shouldn't be hard
16:26 <+bridge_> [ddnet] <fokkonaut> this is very simple
16:31 <+bridge_> [ddnet] <qshar> Can I ask anyone to create such pull request? Or advice me where to take a look (I found something in background.cpp, bit still not sure)
16:36 <+Learath2> C++ ppl: "exceptions should only be used in exceptional situations" Also C++ ppl: "Only way to fail in a constructor is an exception"
16:36 <+Learath2> @qshar: What are you trying? Maybe I can give you a pointer
16:41 <+bridge_> [ddnet] <qshar> I'm trying to make quads layers visible when you play with entities. It should help many pros to play maps with moving objects using entities
16:44 <+bridge_> [ddnet] <qshar> In my mod there is a map configuration that says that the map is using this modification, so it can be used to enable this by default. Or in the background entities setting can be set to something like %quads% to see all quads layers of this map
18:05 <+bridge_> [ddnet] <fokkonaut> @Ryozuki nice duplicate
18:06 <+bridge_> [ddnet] <Ryozuki> is it already there?
18:06 <+bridge_> [ddnet] <Ryozuki> xd
18:06 <+bridge_> [ddnet] <Ryozuki> i didnt see it
18:06 <+bridge_> [ddnet] <fokkonaut> https://github.com/ddnet/ddnet/pull/1848
18:07 <+bridge_> [ddnet] <Ryozuki> dont worry i remove it
18:07 <+bridge_> [ddnet] <fokkonaut> my fix is better, because the timer itself has nothing to do with the DDRaceEffects, calling that agin would make no sense
18:07 <+bridge_> [ddnet] <Ryozuki> why u open a issue if u fix it urself tho?
18:07 <+bridge_> [ddnet] <Ryozuki> its useless
18:07 <+bridge_> [ddnet] <fokkonaut> i opened the issue, the though mh i could try to fix it
18:07 <+bridge_> [ddnet] <fokkonaut> then fixed it
18:07 <+bridge_> [ddnet] <fokkonaut> not useless
18:34 <+bridge_> [ddnet] <Learath2> I just read a piece about how to check errors in a `std::ifstream` properly, much more convoluted then I imagined
18:40 <+bridge_> [ddnet] <Learath2> Did you know that errno is only set if badbit is set? Not if failbit is set
19:58 <+bridge_> [ddnet] <Ryozuki> https://fedoramagazine.org/introducing-fedora-coreos/
21:47 <+bridge_> [ddnet] <cruzomat> @Learath2  @heinrich5991 @ChillerDragon  So i´ve just tried the new power brick nothing changed... 😦 
21:47 <+bridge_> [ddnet] <cruzomat> So my raspi is dead, actually this piece of sh.. never worked...
21:50 <+bridge_> [ddnet] <Learath2> Hmm, it's pretty rare that a raspi is DOA
21:53 <+bridge_> [ddnet] <Learath2> @cruzomat unlucky 😦
22:03 <@deen> cruzomat: Might want to try another cable
22:04 <@deen> https://arstechnica.com/gadgets/2019/07/raspberry-pi-4-uses-incorrect-usb-c-design-wont-work-with-some-chargers/
22:08 <+bridge_> [ddnet] <heinrich5991> @Learath2 the solution to that is: don't do nontrivial work in constructors
22:09 <+bridge_> [ddnet] <Learath2> @heinrich5991 then you can have an object in invalid state
22:09 <+bridge_> [ddnet] <heinrich5991> can you give an example?
22:09 <+bridge_> [ddnet] <Learath2> e.g. I have a socket class, if it can't acquire a socket from the OS, it's left in a broken state
22:10 <+bridge_> [ddnet] <heinrich5991> then you can add a private constructor that just takes the fd and a static member function that creates a socket
22:10 <+bridge_> [ddnet] <Learath2> I don't like compensating for the shortcomings of languages
22:10 <+bridge_> [ddnet] <deen> Just throw an exception from the constructor: https://isocpp.org/wiki/faq/exceptions#ctors-can-throw
22:11 <+bridge_> [ddnet] <Learath2> I already do have a `static optional<T> create()`
22:11 <+bridge_> [ddnet] <deen> only destructors are bad, see the next question in the FAQ
22:12 <+bridge_> [ddnet] <Learath2> I don't like the exception pattern to begin with, but yes, it's the only proper solution in C++
22:12 <+bridge_> [ddnet] <heinrich5991> with static member functions and trivial constructors, you basically mirror what rust does
22:13 <+bridge_> [ddnet] <Learath2> I think the constructor should be private tbh
22:13 <+bridge_> [ddnet] <Learath2> in that case atleast
22:13 <+bridge_> [ddnet] <Learath2> The thing we are trying to avoid is that state where an object is constructed but isn't yet valid
22:13 <+bridge_> [ddnet] <deen> But yeah, I also get pissed when exceptions are thrown all the time in regular usage
22:14 <+bridge_> [ddnet] <deen> Because when I notice some exception that's not traced properly, I use gdb and "catch throw"
22:14 <+bridge_> [ddnet] <heinrich5991> that works? ^^
22:15 <+bridge_> [ddnet] <deen> yes, very cool
22:15 <+bridge_> [ddnet] <deen> then I get a backtrace for every exception
22:15 <+bridge_> [ddnet] <Learath2> I don't really like decoupling the errors from their context
22:16 <+bridge_> [ddnet] <deen> So you want to handle potential failure in every possible location separately?
22:16 <+bridge_> [ddnet] <Learath2> @deen I mean it's how I've been going about it for quite some time now, a lot of programs do that
22:16 <+bridge_> [ddnet] <deen> Yes, and sometimes it makes sense. But if some kind of error has the same handling all the time, why repeat yourself?
22:17 <+bridge_> [ddnet] <deen> then people used the "goto failure" pattern and that's what exceptions give you but more generalized and safer
22:17 <+bridge_> [ddnet] <deen> And what if you forget to handle an error one time?
22:17 <+bridge_> [ddnet] <Learath2> Well is it really safer?
22:17 <+bridge_> [ddnet] <deen> In our case we have a component with lots of code by dozens of developers
22:18 <+bridge_> [ddnet] <deen> and by having a catch(std::exception) around the central calling place we can make sure that no exceptions will leave
22:18 <+bridge_> [ddnet] <Learath2> goto's can't get out of the functions bounds
22:19 <+bridge_> [ddnet] <Learath2> Besides if exceptions even travel up a couple frames it becomes really not obvious how to handle them
22:19 <+bridge_> [ddnet] <Learath2> As you lose context
22:20 <+bridge_> [ddnet] <Learath2> They are indeed very useful when throwing things together, a very easy to work with pattern, but when you want to make sure things happen a certain way, I think it's harder to read
22:20 <+bridge_> [ddnet] <deen> at least catch and log them is good for us already
22:20 <+bridge_> [ddnet] <Learath2> Well tbh, what do I know, you work on software that needs to be much more reliable then what I write
22:21 <+bridge_> [ddnet] <deen> Nah, that's not a good argument in my favour 😄
22:21 <+bridge_> [ddnet] <deen> > Using exceptions for error handling makes your code simpler, cleaner, and less likely to miss errors. But what’s wrong with “good old errno and if-statements”? The basic answer is: Using those, your error handling and your normal code are closely intertwined. That way, your code gets messy and it becomes hard to ensure that you have dealt with all errors
22:21 <+bridge_> [ddnet] <deen> https://isocpp.org/wiki/faq/exceptions#why-exceptions
22:22 <+bridge_> [ddnet] <Learath2> Was reading around today, find if anyone else thought along my line and found this http://250bpm.com/blog:4
22:22 <+bridge_> [ddnet] <deen> i remember that post
22:24 <+bridge_> [ddnet] <Learath2> Well I guess it depends a lot on how well versed you are in a language, I find it's clearer with the `if(!foo()){ handle_error(); }` but that might just be bias on my part
22:24 <+bridge_> [ddnet] <Learath2> rather the pattern then the language, to be more precise
22:34 <+bridge_> [ddnet] <Learath2> I guess that also applies to any readability argument,  experience factors in heavily and thus the argument is quite subjective