Times are UTC Toggle Colours
02:20:32 *** keoz has quit IRC 06:30:48 *** Alberth has joined #openttd.dev 06:30:48 *** ChanServ sets mode: +v Alberth 08:07:10 *** keoz has joined #openttd.dev 09:40:52 *** frosch123 has joined #openttd.dev 09:40:52 *** ChanServ sets mode: +v frosch123 10:01:28 <Rubidium> https://rbijker.net/openttd/pkg-config/ <- some simplifications to the configure script by using pkg-config more often 10:05:09 <LordAro> Rubidium: https://i.imgur.com/MEDlmtw.png :( 10:05:52 <frosch123> + # - check for dedicated, 1 is yes. <- "1 is "skip if dedicated" 10:07:19 <frosch123> 40 removes the "skip allegro if osx". is that correct? 10:07:23 <Rubidium> LordAro: yeah, I'm not going to pay for a certificate to prove my identity 10:08:55 <Rubidium> frosch123: about 40, I didn't intend to remove that check 10:13:03 <Rubidium> LordAro: so either assume it's really mine, or use http instead 10:14:11 <LordAro> Rubidium: heh, fair enough, although i'm not sure why you'd bother with a certificate if it's not "trusted" 10:15:23 <Rubidium> LordAro: trust is only because something else tells you it is trustworthy. For normal websites that's something like Verisign that gets its root certificates into browsers 10:16:22 <Rubidium> LordAro: in this case, I could put my root signing certificate onto a USB stick or something and give that to you, then you install that into your browser and... it's trusted 10:17:17 <Rubidium> LordAro: if you're brave enough, just remove all the certificate authorities from you browser and try to find a trusted server 10:17:29 <LordAro> heh, true, true 10:17:45 <frosch123> queue looks nice otherwise 10:21:31 <Rubidium> oh, libtimidity also seems to have a pkg-config file 10:22:26 <Rubidium> oh, only 10 years ago... so that can go with pkg-config as well 10:30:28 <Rubidium> https://rbijker.net/openttd/pkg-config/90-libtimidity-pkg-config.diff <- same with libtimidity 10:32:41 <frosch123> :) 10:32:57 <Rubidium> if only liblzo2 had pkg-config, then I could remove 120 lines of code 10:33:52 <Rubidium> i.e. the function detect_library 10:34:45 <Rubidium> which is just a horrid mess to attempt finding some files in some folders (sorry TrueLight) 11:12:59 <michi_cc> So, the implementation of ScriptExecMode::~ScriptExecMode is somewhat unfortunate (especially in light of C++11). Firstly, throwing in a destructor isn't the best idea in general, as a second throw during exception unwinding means bye bye. Secondly, C++11 makes it worse because the destructor is implicitly defined as being noexcept() and throwing from a noexcept function means instant bye bye as well. 11:13:39 <michi_cc> This can be fixed by explicitly declaring the destructor as throwing, but due to the current class hierarchy of ScriptExecMode this means changing this in ZeroedMemoryAllocator which due to multiple inheritance forces modifications lots of other classes as well. 11:14:45 <frosch123> interesting, i thought throwing in destructors was also invalid before 11:15:24 <michi_cc> Getting rid of that throw would be a lot nicer, but I really don't know the whole scripting stuff good enough to say how. 11:16:38 <michi_cc> It's not invalid, but you have to make sure that you never throw if the destructor is called during stack unwinding, which can be HARD. 11:20:09 <michi_cc> Does anyone know offhand if Engine::u.rail (respectively RailVehicleInfo) is used somewhere in saveload or any other reason why it uses a RailTypeByte insead of RailType? 11:21:41 <Rubidium> I wouldn't expect that to be the case 11:22:06 <Rubidium> maybe it used to be part of Vehicle? 11:22:47 <frosch123> grepping for RailTypeByte looks like a lot of copy&paste 11:23:13 <frosch123> neither the gui nor GRFFile are saved 11:23:34 <frosch123> the only valid instance seems to be in Train 11:24:34 <michi_cc> Different question for the same underlying problem: Why does CompanyPool use CompanyByte instead of CompanyID as index? 11:26:20 <frosch123> also likely not needed :) 11:26:21 <michi_cc> Pool::AllocateItem produces a narrowing warning on MSVC2015 (which is a new c++11 warning), and either any use of a class type as pool index needs to go or TinyEnumT needs to get a copy constructor from uint. TineEnumT which a copy constructor behaves differently in c++11 unions than before leading to new errors. 11:27:00 <frosch123> i am quite sure poolindices are not accessed via the SaveLoad objects 11:27:11 <frosch123> they are always read directly and passed to SetArrayIndex 11:27:12 <michi_cc> Fortunately Engine::u.rail and BuildVehicleWindow seem to be the only two culprits which. 11:27:36 <michi_cc> So I guess using CompanyID is better than messing with TinyEnumT. 11:27:44 <frosch123> yup 11:28:11 <frosch123> the current saveload code will detect and throw if it encounteres an enum 11:28:15 <frosch123> so, no harm trying :) 11:28:59 <michi_cc> Oh, I missed ScriptTestMode::~ScriptTestMode which also throws. 11:30:07 <michi_cc> This is a lot bigger c++11 problem than the remaining new narrowing warnings, if these throws can't go, we have to add a noexcept(false) to many, many destructor declarations. 11:33:05 <michi_cc> Anyway, MSVC2015 compiles OTTD quite fine with to error fixes (#define'ing inline isn't the very best idea, and MSVC finally got a snprintf). 11:33:27 <michi_cc> Eh, vsnprintf I mean :) 11:34:53 <michi_cc> Rubidium: I might have a new openttd-useful build with MSVC2015 later today if everything works. 11:35:11 <Rubidium> michi_cc: that'd be awesome ;) 11:35:27 <Rubidium> I hope it contains fairly recent versions of the libraries as well 11:35:34 <michi_cc> Have to check out WinXP first. 11:35:52 <michi_cc> Everything freshly downloaded yesterday. 11:36:08 <Rubidium> that'd be plenty of fresh 11:39:38 <michi_cc> It has a tiny snag regarding freetype though. Right now we #include <ft2build.h>, which used to be alongside the freetype include dir. It was moved to be inside the freetype include dir. Which means that a) OTTD includes <freetype/ft2build.h>, breaking older freetypes, b) we try to teach people that the have to add both <useful>/include *and* <useful>/include/freetype to their msvc dirs, or c) I modify freetype for the old structure, which is 11:39:38 <michi_cc> a slight PITA due to their stupid #include # 11:39:42 <michi_cc> define stuff. 11:41:27 <Rubidium> what about a include/ft2build.h: #include <freetype/ft2build.h> 11:48:16 <michi_cc> ft2build does *not* include freetype by itself, but only provides #defines for include files (e.g. #include FT_FREETYPE_H). Changing these defines is what I meant with option c). 11:51:04 <Rubidium> any idea how other distro's handle this? 11:55:34 <michi_cc> I'd expect pkg-config (or freetype-config?) to to return -I/use/include/freetype. Which reminds me of options d): I just dump the contents of the freetype subdirectory into the main include dir. Looks ugly but works. 11:56:55 <Rubidium> ah, it does 11:57:39 <Rubidium> well, maybe go with the simplest solution (to the end user) 11:57:59 <Rubidium> which I reckon would be solution d 13:58:09 *** TrueBrain has joined #openttd.dev 13:58:41 *** ChanServ sets mode: +o TrueBrain 13:58:45 *** TrueBrain sets mode: +o DorpsGek 13:58:48 *** TrueBrain has left #openttd.dev 18:35:21 *** keoz has quit IRC 19:14:09 *** Alberth has left #openttd.dev 19:32:37 *** tycoondemon2 has joined #openttd.dev 19:38:03 *** tycoondemon has quit IRC 19:41:23 *** frosch123 has quit IRC 19:43:56 <michi_cc> Rubidium: http://www.icosahedron.de/openttd/patches/openttd-useful-6.0-source.zip and http://www.icosahedron.de/openttd/patches/openttd-useful-6.0-win.zip 19:44:21 <michi_cc> And http://www.icosahedron.de/openttd/patches/p/ has fixes + MSVC2015 project files and some c++11 warning fixes. 19:45:10 <michi_cc> The 0002 path does the necessary thing for the exception-in-destructor stuff to continue working as before, but getting rid of that somehow would be a very good thing. 21:09:50 *** keoz has joined #openttd.dev 21:44:09 <Rubidium> michi_cc: in 2 I'm not seeing any changes to script related classes, just to stuff that doesn't even seem to use throws 21:46:10 <Rubidium> 4, second chunk of strings.cpp; should args_array become int64? 21:49:42 <Rubidium> in 3 I see DebugInformationFormat going from EditAndContinue to ProgramDatabase; is that wanted/expected? 21:51:53 <Rubidium> and what is the MinimumRequiredVersion, and why are 5.01 and 5.02 mentioned? 21:52:39 <Rubidium> likewise it seems like the newline at the end of some files is removed, which might also not be wat we'd want 21:52:57 <Rubidium> the rest looks okay though 21:53:03 <Rubidium> (regarding the patches) 22:34:26 *** keoz has quit IRC