IRC logs for #openttd.dev on OFTC at 2015-08-09
⏴ go to previous day
00:57:44 *** Belugas has joined #openttd.dev
00:57:44 *** Rubidium has joined #openttd.dev
00:57:44 *** charm.oftc.net sets mode: +vv Belugas Rubidium
01:02:16 *** gnu_jj has joined #openttd.dev
01:02:16 *** Yexo has joined #openttd.dev
01:38:31 *** keoz has joined #openttd.dev
08:30:48 *** Alberth has joined #openttd.dev
08:30:48 *** ChanServ sets mode: +v Alberth
10:07:10 *** keoz has joined #openttd.dev
11:40:52 *** frosch123 has joined #openttd.dev
11:40:52 *** ChanServ sets mode: +v frosch123
12:05:52 <frosch123> + # $5 - check for dedicated, 1 is yes. <- "1 is "skip if dedicated"
12:07:19 <frosch123> 40 removes the "skip allegro if osx". is that correct?
12:07:23 <Rubidium> LordAro: yeah, I'm not going to pay for a certificate to prove my identity
12:08:55 <Rubidium> frosch123: about 40, I didn't intend to remove that check
12:13:03 <Rubidium> LordAro: so either assume it's really mine, or use http instead
12:14:11 <LordAro> Rubidium: heh, fair enough, although i'm not sure why you'd bother with a certificate if it's not "trusted"
12: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
12: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
12: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
12:17:45 <frosch123> queue looks nice otherwise
12:21:31 <Rubidium> oh, libtimidity also seems to have a pkg-config file
12:22:26 <Rubidium> oh, only 10 years ago... so that can go with pkg-config as well
12:32:57 <Rubidium> if only liblzo2 had pkg-config, then I could remove 120 lines of code
12:33:52 <Rubidium> i.e. the function detect_library
12:34:45 <Rubidium> which is just a horrid mess to attempt finding some files in some folders (sorry TrueLight)
13: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.
13: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.
13:14:45 <frosch123> interesting, i thought throwing in destructors was also invalid before
13: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.
13: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.
13: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?
13:21:41 <Rubidium> I wouldn't expect that to be the case
13:22:06 <Rubidium> maybe it used to be part of Vehicle?
13:22:47 <frosch123> grepping for RailTypeByte looks like a lot of copy&paste
13:23:13 <frosch123> neither the gui nor GRFFile are saved
13:23:34 <frosch123> the only valid instance seems to be in Train
13:24:34 <michi_cc> Different question for the same underlying problem: Why does CompanyPool use CompanyByte instead of CompanyID as index?
13:26:20 <frosch123> also likely not needed :)
13: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.
13:27:00 <frosch123> i am quite sure poolindices are not accessed via the SaveLoad objects
13:27:11 <frosch123> they are always read directly and passed to SetArrayIndex
13:27:12 <michi_cc> Fortunately Engine::u.rail and BuildVehicleWindow seem to be the only two culprits which.
13:27:36 <michi_cc> So I guess using CompanyID is better than messing with TinyEnumT.
13:28:11 <frosch123> the current saveload code will detect and throw if it encounteres an enum
13:28:15 <frosch123> so, no harm trying :)
13:28:58 <michi_cc> Oh, I missed ScriptTestMode::~ScriptTestMode which also throws.
13: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.
13: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).
13:33:27 <michi_cc> Eh, vsnprintf I mean :)
13:34:53 <michi_cc> Rubidium: I might have a new openttd-useful build with MSVC2015 later today if everything works.
13:35:11 <Rubidium> michi_cc: that'd be awesome ;)
13:35:27 <Rubidium> I hope it contains fairly recent versions of the libraries as well
13:35:34 <michi_cc> Have to check out WinXP first.
13:35:52 <michi_cc> Everything freshly downloaded yesterday.
13:36:08 <Rubidium> that'd be plenty of fresh
13: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
13:39:38 <michi_cc> a slight PITA due to their stupid #include #
13:41:27 <Rubidium> what about a include/ft2build.h: #include <freetype/ft2build.h>
13: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).
13:51:04 <Rubidium> any idea how other distro's handle this?
13: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.
13:57:39 <Rubidium> well, maybe go with the simplest solution (to the end user)
13:57:59 <Rubidium> which I reckon would be solution d
15:58:09 *** TrueBrain has joined #openttd.dev
15:58:41 *** ChanServ sets mode: +o TrueBrain
15:58:45 *** TrueBrain sets mode: +o DorpsGek
15:58:48 *** TrueBrain has left #openttd.dev
21:14:08 *** Alberth has left #openttd.dev
21:32:37 *** tycoondemon2 has joined #openttd.dev
21: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.
23:09:50 *** keoz has joined #openttd.dev
23: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
23:46:10 <Rubidium> 4, second chunk of strings.cpp; should args_array become int64?
23:49:42 <Rubidium> in 3 I see DebugInformationFormat going from EditAndContinue to ProgramDatabase; is that wanted/expected?
23:51:53 <Rubidium> and what is the MinimumRequiredVersion, and why are 5.01 and 5.02 mentioned?
23: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
23:52:57 <Rubidium> the rest looks okay though
23:53:03 <Rubidium> (regarding the patches)
continue to next day ⏵
