IRC logs for #openttd on OFTC at 2015-08-20
⏴ go to previous day
00:00:58 *** Stimrol_ has joined #openttd
00:15:04 *** eQualizer|dada has quit IRC
00:16:10 *** V453000 has joined #openttd
00:16:10 *** planetmaker has joined #openttd
00:16:10 *** helix.oftc.net sets mode: +ov planetmaker planetmaker
00:18:28 *** Nathan1852_ has joined #openttd
00:18:28 *** LadyHawk has joined #openttd
00:18:28 *** HerzogDeXtEr1 has joined #openttd
00:18:28 *** Wormnest has joined #openttd
00:18:28 *** Belugas has joined #openttd
00:18:28 *** TheMask96 has joined #openttd
00:18:28 *** snorre_ has joined #openttd
00:18:28 *** Eddi|zuHause has joined #openttd
00:18:28 *** Cursarion^ has joined #openttd
00:18:28 *** jonty-co1p has joined #openttd
00:18:28 *** Biolunar_ has joined #openttd
00:18:28 *** michi_cc has joined #openttd
00:18:28 *** Defaultti has joined #openttd
00:18:28 *** TrueBrain has joined #openttd
00:18:28 *** theholyduck_ has joined #openttd
00:18:28 *** innocenat has joined #openttd
00:18:28 *** OsteHovel has joined #openttd
00:18:28 *** glevans2 has joined #openttd
00:18:28 *** mntasauri has joined #openttd
00:18:28 *** Smedles has joined #openttd
00:18:28 *** strohalm has joined #openttd
00:18:28 *** tycoondemon has joined #openttd
00:18:28 *** guru3-vps has joined #openttd
00:18:28 *** a_sad_dude has joined #openttd
00:18:28 *** Rubidium has joined #openttd
00:18:28 *** dustinm` has joined #openttd
00:18:28 *** luaduck has joined #openttd
00:18:28 *** synthon.oftc.net sets mode: +ovoo Belugas michi_cc Rubidium orudge
00:18:28 *** Born_Acorn has joined #openttd
00:18:28 *** Antheus has joined #openttd
00:18:28 *** mari_kiri has joined #openttd
00:18:28 *** Ether_Man has joined #openttd
00:18:28 *** Extrems has joined #openttd
00:18:28 *** blathijs has joined #openttd
00:18:28 *** synthon.oftc.net sets mode: +v orudge
00:18:28 *** kirjs_______ has joined #openttd
00:18:28 *** Warrigal has joined #openttd
00:18:28 *** argoneus has joined #openttd
00:18:28 *** Xaroth_ has joined #openttd
00:18:28 *** joho^_^ has joined #openttd
00:18:28 *** ccfreak2k has joined #openttd
00:18:28 *** mercutio has joined #openttd
00:18:28 *** gnu_jj_ has joined #openttd
00:18:28 *** eQualizer|dada has joined #openttd
00:18:28 *** mikegrb has joined #openttd
00:18:28 *** davidstrauss_ has joined #openttd
00:18:28 *** NGC3982 has joined #openttd
00:19:20 *** ChanServ sets mode: +v Belugas
00:19:20 *** ChanServ sets mode: +v Rubidium
00:29:27 *** Nathan1852 has joined #openttd
00:40:36 *** Supercheese has joined #openttd
01:15:34 *** Nathan1852_ has joined #openttd
01:52:38 *** Nathan1852__ has joined #openttd
02:02:27 *** supermop has joined #openttd
02:39:37 *** LadyHawk has joined #openttd
04:26:09 *** Biolunar has joined #openttd
04:51:22 *** tycoondemon2 has joined #openttd
05:37:20 *** Hiddenfunstuff has joined #openttd
06:18:22 *** Hiddenfunstuff has quit IRC
06:56:16 *** Eddi|zuHause has joined #openttd
07:42:19 <help> please how can I change the language on windows in openttd
07:42:23 *** help is now known as Guest2856
07:43:01 <Guest2856> I have gone to the settings there was only Englih availble
07:45:03 <Supercheese> did you install the other languages?
07:45:09 <Supercheese> you might need to run the installer again
08:45:23 *** minimoo has joined #openttd
09:34:07 *** smoke_fumus has joined #openttd
10:04:47 *** sla_ro|master has joined #openttd
10:15:08 *** andythenorth has joined #openttd
10:28:16 <planetmaker> ho... orduge killed the forums :P
10:32:50 *** Pensacola has joined #openttd
12:00:18 *** zeknurn has joined #openttd
12:14:19 <Ether_Man> Anyone that has been playing with making any larger passenger services? Been toying around a bit and it's just take two towns, put 4 bus stops and a train station in each and the buses end up growing the town to silly amounts, feeding your trains for long hauls... The question is though, it does not take long for those silly numbers to be WAY more than what buses can handle. Like, it's pretty much impossible as I see it to scale a bus service that takes 10k
12:14:19 <Ether_Man> passengers/month. And at this point, the city is too dense to make any real progress to make trains of a size that can handle that kind of traffic either. Any tips for how to handle this situation?
12:18:39 <planetmaker> Ether_Man, plan for the future growth, build stations in appropriate places in advance before the town occupies those. But build them such, that town growth is not reduced much
12:19:21 <planetmaker> Ether_Man, #openttdcoop has a few savegames where we focus on passengers and growing towns; they might interest you
12:20:36 <Ether_Man> I've tried to get their saves to work without success... Even when I can get the files that is required, it just says the save is corrupt, cannot be read, or that something failed to initialize... So I've given up on looking at any actual saves there
12:21:03 <planetmaker> that should not happen. Any particular savegame?
12:21:19 <planetmaker> you will need the (legacy) grfpack, though for some savegames
12:21:33 <Ether_Man> All I've tried (some 10-15 different ones) all give errors
12:21:34 <planetmaker> only very few savegames might have issues
12:24:51 *** zeknurn has joined #openttd
12:40:07 <V453000> Ether_Man: which game revision do you have?
12:40:14 <V453000> getting the latest nightly is best
12:41:00 <Ether_Man> I'm using 1.5.1 Stable
12:41:17 <V453000> the newest games certainly wont work with that
12:41:25 <V453000> which save did you try?
12:42:29 *** Hiddenfunstuff has joined #openttd
12:43:58 <Ether_Man> I've tried a lot from all over... Nothing in between 100 and 200 works due to INFRA Stolen Trees no longer being available so those are out straight away. And below 100 is a pain with the settings so havnt even tried those actually. Above 200 I've tried let's see... 201, 217, 231, 246, 247, 249, 257-262, 271, 290 and 299. All fail with various errors
12:46:39 *** andythenorth has joined #openttd
12:47:18 <planetmaker> Ether_Man, yeah, that NewGRF is a sad story... you can load those savegames with a trick: become scenario_developer and then ignore the missing NewGRF
12:48:15 <planetmaker> scenario_developer is a setting which you can enable in the console of OpenTTD
12:53:41 <Ether_Man> Sorry, but I prefer to follow the wishes of the dev and since he has pulled the file, I interpret that as that he does not want the file being spread anymore. Thanks for the thought though :)
12:54:06 <V453000> the file is ancient and packed with GPL license
12:54:47 <V453000> and if it breaks your savegames, it doesnt make any sense to not distribute it
13:01:28 <V453000> but yeah you can just scenario_developer the way around it
13:23:24 <planetmaker> Ether_Man, as it once was uploaded by the author, s/he consented to the file being distributed eternally. We only removed it to get rid of that eternal bitching when she found out that she couldn#t read
13:24:47 <Ether_Man> planetmaker, I care less about the license as such, as I care about the wishes of the developer. The developer does not want it distributed, thus I will not be using it, even if they have it under a license that allows it.
13:32:13 *** Supercheese has joined #openttd
13:34:15 <V453000> you are a weird person.
13:35:08 <Ether_Man> Because I care more about what a person want now, rather than what they wanted in the past?
13:38:33 <V453000> no, because you support something which is ultra not constructive, yet you feel like you are helping anybody with such attitude
13:39:33 <Ether_Man> Where have I said anything about helping someone or that I support something? I support someONE, but that's not to say I'm helping that someone.
13:40:01 <V453000> that is kind of the same :)
13:40:49 <V453000> the only useful solution here is to continue distributing it, and keep the savegames not broken as they always should have been according to bananas TOC
13:41:06 <Ether_Man> I dont consider those things to be the same at all. But whatever. You're free to consider me as weird as you like :)
13:42:14 <V453000> well, SAC fucked us all over, by supporting it you are just blindly worshipping bullshit
13:42:25 <V453000> no offense intended :)
13:44:49 <V453000> if everybody behaved like her, we could just shut down bananas outright and go outside (worst possible scenario!)
13:46:14 <Ether_Man> Not true, since as you point out, it was released under a license that allows it. I'm just saying that I personally do not want to use things the developer no longer wants me to, regardless if I'm actually allowed or not.
13:46:18 <andythenorth> might as well shut bananas too
13:46:35 <planetmaker> forums are back, andythenorth :)
13:46:59 <planetmaker> all shiny-new. And looks like the old. Or something
13:47:09 * andythenorth wants people to stop using HEQS, but they won’t :P
13:47:18 * andythenorth wants people to stop downloading FISH, but they won’t :P
13:48:26 <V453000> andythenorth: you should be offended
13:48:43 <Wolf01> Ether_Man: so you are telling us you don't use truecrypt or derivates, mega and other softwares whose developers got tired about and "retired" them?
13:49:19 <Ether_Man> andythenorth, if you're serious, I have no problem with removing HEQS from my install. I don't have FISH but I can certainly make sure I don't download that either.
13:49:35 <andythenorth> don’t download FISH
13:50:58 <Ether_Man> I do not use truecrypt or its derivates no. Mega, I am not aware of any dev saying they don't want people to use... And no, that's not about dev being tired and retiring them, but if I hear of a dev that has actively expressed their wishes that the software not be used, then I will avoid using it to the best of my abilities yes
13:51:25 <Wolf01> Kim Dotcom itself said to not use that
13:53:11 <Ether_Man> 1. Kim Dotcom is not the developer of Mega. He was the owner and CEO. He had no relation to it at the time he made the statement in question. 2. He did not say he did not want people to use it. He said he does not trust them.
13:53:46 <Wolf01> and also you might download music, movies and games
13:54:06 <Ether_Man> Only when those are legally available.
13:55:39 <V453000> you arent hurting anybody by using their software
13:55:48 <V453000> nobody even needs to know
13:56:00 <Ether_Man> I did not say that anyone was
13:56:23 <V453000> then avoiding to do so is just wtf
13:56:24 <peter1138> planetmaker, forums are back where?
13:56:33 <planetmaker> in my web browser
14:03:47 <peter1138> he probably shouldn't've used a permanent redirect then
14:10:09 <andythenorth> probably snappier
14:10:29 <Eddi|zuHause> "you won't need to enable/disable DST twice a year" yay!
14:11:30 <planetmaker> sounds like a welcoming feature :P
14:13:51 <peter1138> i don't remember changing it
14:20:51 <Eddi|zuHause> uhm, is that me or does the new theme have a spacing issue?
14:22:23 <peter1138> looks alright to me
14:22:46 <peter1138> i use the silver theme though
14:28:27 <peter1138> hmm, 152KB patch :S
14:32:06 *** sla_ro|master has joined #openttd
14:35:34 * andythenorth uses the silver theme
14:42:57 <orudge> Eddi|zuHause: what browser?
14:43:13 <Eddi|zuHause> orudge: konqueror. with scripts and stuff disabled
14:44:13 <orudge> The standard theme makes minimal use of scripts etc
14:44:23 <orudge> Tried a hard refresh etc?
14:44:38 <Eddi|zuHause> if by hard refresh you mean ctrl+f5, then yes
14:45:03 <orudge> I don't have a copy of Konqueror handy I'm afraid, but can try to look into it at some point
14:48:44 * andythenorth wonders if Konqueror is just webkit
14:56:39 <Eddi|zuHause> you can switch konqueror between webkit and KHTML
14:56:52 <planetmaker> any objection if I just un-sticky this ancient topic?
14:57:50 <Eddi|zuHause> planetmaker: make a new updated version, guiding people to the wiki, grfcodec/nmlc and bananas?
14:58:37 <planetmaker> Be my guest, Eddi|zuHause
14:58:57 <planetmaker> mind that there are also announcments etc which cover very similar stuff
14:59:38 <Eddi|zuHause> announcements have a different target audience, i think
15:00:16 <Eddi|zuHause> planetmaker: a post like this should be made by a person that is likely to keep it updated
15:00:53 <planetmaker> that's why it shouldn't be a post but a link to wiki at most
15:01:43 <planetmaker> so either it continues to bit-rot and lead people to wrong places, *you* update it, or I unsticky it ;)
15:02:12 <orudge> planetmaker: feel free to unsticky it
15:02:44 <planetmaker> a link could then go to the FAQ announcement or so
15:03:04 <planetmaker> which is quite bit-rotten, too :P
15:08:36 *** supermop has joined #openttd
15:08:43 <planetmaker> as it's your posting... do I have permission to edit?
15:13:11 <orudge> planetmaker: yes, I'd suggest destickying Dinges's post and then you could copy the contents into my post
15:15:59 <planetmaker> yes, that's the plan, orudge
15:22:48 *** shirish has joined #openttd
15:23:25 <planetmaker> it always itches me when there's more than half a dozen stickies and announcement. Then no-one will mind them anymore at all :)
15:25:03 <Eddi|zuHause> orudge: i have a feeling it is related to image sizes. because entries without images are vertically centered, but entries with images are aligned at the top
15:41:11 *** andythenorth has left #openttd
15:43:14 <orudge> Eddi|zuHause: hmm, odd
15:56:35 *** Nathan1852__ has joined #openttd
17:07:47 *** Wormnest has joined #openttd
17:16:22 *** Alberth has joined #openttd
17:16:22 *** ChanServ sets mode: +o Alberth
17:32:54 *** Nathan1852 has joined #openttd
17:36:28 *** Progman has joined #openttd
17:38:09 *** Nathan1852_ has joined #openttd
17:56:14 *** Nathan1852 has joined #openttd
18:00:42 *** TheMask96 has joined #openttd
18:04:16 *** ChanServ sets mode: +v tokai
18:07:43 *** HerzogDeXtEr has joined #openttd
18:19:52 *** Nathan1852_ has joined #openttd
18:25:18 *** Biolunar has joined #openttd
18:49:17 *** Nathan1852 has joined #openttd
18:56:54 *** Nathan1852_ has joined #openttd
19:30:26 *** gelignite has joined #openttd
19:45:25 <DorpsGek> Commit by translators :: r27388 trunk/src/lang/dutch.txt (2015-08-20 19:45:15 +0200 )
19:45:26 <DorpsGek> -Update from WebTranslator v3.0:
19:45:27 <DorpsGek> dutch - 4 changes by TheTycoonist
20:07:35 *** snorre_ has joined #openttd
20:23:46 *** OsteHovel has joined #openttd
20:29:08 <Ether_Man> Couple of questions regarding the source. 1. Is nightly going in the trunk or some other place? 2. For windows, is MinGW still an option? The wiki says it's only been tested with 1.2.x or trunk, which suggests it's been a long time since it was tested last with the current versions.
20:29:44 <Zuu> Nightlies are daily/nightly builds of trunk.
20:30:03 <Zuu> About 20 o clock at CEST or so.
20:31:28 <Zuu> I only compile on windows using Visual Studio, but from what I know it should still work to use mingw/msys to compile on Windows.
20:33:16 <Ether_Man> GMT+2 would be CEDT atm. And for another 2 months :)
20:34:11 <Ether_Man> Anyway. Thank you for the answers. Guess I'll try mingw. Personally hate vc++ >_<
20:40:21 *** frosch123 has joined #openttd
20:40:43 <Eddi|zuHause> Ether_Man: last i heard was that mingw has trouble with 64bit architectures
20:41:03 <Ether_Man> Wouldnt that only apply to MinGW64 in that case?
20:41:12 <Eddi|zuHause> and 20:00 CEST was a little over half an hour ago
20:41:42 <Ether_Man> No it wasnt. CEDT was. CEST is standard time, as in, winter time... CEDT is daylight savings time, as in summer time. We're currently in summer time
20:42:01 <Eddi|zuHause> S stands for summer
20:42:18 <Ether_Man> ?? Where I'm from, it's standard time
20:42:18 <Zuu> CET is winter/standard time in central europe.
20:42:29 <Eddi|zuHause> winter time is called CET
20:43:04 <Ether_Man> Oh well. Guess we use different shorts here then :)
20:44:50 <Eddi|zuHause> i have never seen anybody use "CEDT"
20:45:21 <frosch123> Eddi|zuHause: on the other side of the ocean they have PST/PDT, EST/EDT and stuff
20:46:11 <frosch123> he, did someone really unsticky the completely useless "useful tools" thread?
20:46:14 <Ether_Man> But yea, it seems CEST is the normal abbriv for summer
20:47:00 <planetmaker> frosch123, I did today. It annoyed me
20:47:46 <frosch123> i think i reported that thread years ago :p
20:47:58 <planetmaker> last modification was ~5 years ago
20:48:15 <planetmaker> and tbh, I didn't hear of 2/3 of the "useful" tools before :P
20:49:00 <Zuu> You make the thread sound interesting. Where do I find it?
20:49:40 <planetmaker> in the depths of the forum :P. I added to our wiki a link to that thread for hysteric reasons, though
20:49:56 <frosch123> ^^ that's how i noticed its removal :)
20:51:00 <Zuu> When I googled for 'openttd useful thread', the first result was wiki page 'Rejected features' :-)
20:52:37 <Zuu> 2) 'requested features', 3) comparison of AIs
20:59:05 <frosch123> why do you not get anything about the openttd-useful package?
20:59:11 <frosch123> for compiling on windows
21:00:42 <Zuu> frosch123: Because it has too little to do with 'thread'? Just searching for 'openttd useful' will get that package on first result.
21:01:12 <frosch123> well, when i searched one of the features thread was at position 8, and the other i did not see :p
21:01:46 <Zuu> Well, I was logged in, so that probably skewed my results :-)
21:21:46 *** FLHerne has joined #openttd
21:36:36 <Ether_Man> Meh... ini.cpp:84:31: error: 'fdatasync' was not declared in this scope int ret = fdatasync(fileno(f)); time to play the what dep is missing game >_<
21:38:12 <Eddi|zuHause> i've seen that before, i think...
21:38:44 <Ether_Man> Oh right... It's MinGW that entire lacks fdatasync... It does not have it, and will never have it... And openTTD currently just assumes that it will be there >_<
21:39:04 <Ether_Man> So yea, MinGW cannot compile openttd currently it seems >_<
21:39:21 <frosch123> add an #if _POSIX_SYNCHRONIZED_IO > 0 or something
21:39:33 <frosch123> likely windows filesystem does not support such stuff
21:40:16 <Ether_Man> It doesn't. Hence why MinGW doesnt support it. It's not needed for windows because windows does this for us without programs having to tell it to
21:43:17 <Rubidium> weird... old msys/mingw compiles that just fine, just like msys2/mingw64 (although there're some issues compiling on msys2/mingw64 out-of-the-box)
21:43:52 <Ether_Man> But hmm... That entire snippet should only be used if #ifdef WITH_FDATASYNC, which, as far as I can see, isnt being set :/
21:50:59 <Ether_Man> Meh. Cant find where it sets that... I'll just disable the If entirely instead as a temporary thing at least >_<
21:53:38 <Ether_Man> Doesnt seem like it :/
21:53:52 <Alberth> 19:# define WITH_FDATASYNC
21:54:50 <frosch123> "On POSIX systems on which fdatasync() is available, _POSIX_SYNCHRONIZED_IO is defined in <unistd.h> to a value greater than 0." <- from the manpage
21:54:56 <frosch123> so, should we use that instead?
21:57:20 <Alberth> we seem to check for >= specific posix version , or >= specific xopen version
21:59:36 <glx> and compile farm works too
22:00:06 <planetmaker> well, the CF uses MSVC not, mingw
22:04:17 <Alberth> hmm apparently it does
22:04:22 <frosch123> Ether_Man: so, does above diff work for you?
22:04:53 <Ether_Man> frosch123, it compiles. Will soon know if it results in a working install :)
22:09:54 <Alberth> I don't understand why we have it, surely closing the file descriptor would be enough?
22:11:21 <Rubidium> Alberth: nope, that's the thing... those are not enough
22:11:35 <frosch123> yeah, no idea either, it even uses a rename afterwards for atomic replacement
22:11:46 <Alberth> it only helps if the system crashes, by the looks of it?
22:13:46 <Rubidium> I'm not sure about the exact reasons anymore, but there was some reason why it's done this way
22:13:58 <Alberth> so there exist silly systems that don't write out written data after closing the file?
22:14:05 <Eddi|zuHause> the probability that the system crashes is decidedly nonzero
22:15:00 <Ether_Man> Alberth, posix systems do not
22:15:32 <DorpsGek> frosch123: Commit by rubidium :: r15686 trunk/src/ini.cpp (2009-03-12 15:22:17 +0100 )
22:15:33 <DorpsGek> frosch123: -Codechange: make it a bit harder for crashes to trash your config file.
22:15:53 <frosch123> so, yeah, it's about something breaking
22:16:09 <glx> and it never caused problem for mingw
22:16:16 <Alberth> Ether_Man: I am quite sure that data you give to the OS will end up at the disk
22:16:30 <Ether_Man> And for good reasons actually. If a program crashes, you want to know that the data you have is actually correct and that it wasnt trashed due to crashing halfway through a file save.
22:16:50 <Alberth> Ether_Man: that's the point, it is done after writing, I guess
22:17:03 <Alberth> so nothing "half way"
22:17:21 <Eddi|zuHause> Ether_Man: i don't quite follow that argument
22:17:27 <Alberth> and it can equally well crash a long time just before
22:18:01 <frosch123> he, that commit also added the "rename"
22:18:07 <Ether_Man> Alberth, that's just it though. If you just close the handle, you havnt actually given the data over to the OS yet. You just closed the handle
22:18:37 <frosch123> hmm, maybe it is about disk full or something weird?
22:19:00 <Ether_Man> If the handle is currently busy, it will fail
22:19:05 <Alberth> "The fclose() function flushes the stream pointed to by stream (writing any buffered output data using fflush(3)) and closes the underlying file descriptor."
22:19:06 <frosch123> fdatasync returns an error code, which ottd checks after the fclose
22:20:15 <Alberth> if fclose fails, you're dead already
22:20:42 <Ether_Man> Alberth, Yep. And again, if the program crashes after issuing that, the handle closes and the remaining data is never turned over to the OS. The buffered output, is buffered in app memory space. It's never actually given to the OS until it's time to write it
22:21:29 <Alberth> Ether_Man: indeed, but that can happen any time while writing, a fdata sync at the end doesn't fix that
22:22:32 <Alberth> if fclose doesn't do what it is supposed to do, the implementation is broken, imho
22:22:35 <Ether_Man> Alberth, oh certainly not no. fdatasync has the exact same problem. The only difference really is that you can basically sync to a "backup", and then only if the sync results in a success, do you consider that to have been a successful write and can delete or ignore the old
22:23:51 <glx> Ether_Man: anyway something should be wrong in your mingw setup
22:24:19 <Ether_Man> glx, no. Mingw does not have, nor has it ever had support for fsync or fdatasync.
22:24:28 <Rubidium> you are aware that fclose does not guaranteed anything being flushed to disk? It just guarantees that the buffers of libc are flushed.
22:24:48 <glx> Ether_Man: and it's not a problem as it should not go there
22:24:48 <Alberth> yes, so it's in the OS
22:24:57 <Alberth> Rubidium: and thus eventually at the disk
22:25:42 <Ether_Man> glx, except it does. And according to the source, should be. "(defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE >= 199309L) || (defined(_XOPEN_SOURCE) && _XOPEN_SOURCE >= 500)" is true for a mingw install. Which then sets with_fdatasync
22:26:12 <Alberth> Ether_Man: I really doubt those numbers are by accident
22:26:21 <glx> doesn't happen for my msys/mingw nor my msys2/mingw-w64
22:26:25 <frosch123> those numbers are from the manpage as well :)
22:26:37 <Alberth> no doubt someone figured out that's when fdatasync should exist
22:26:41 <Rubidium> Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
22:26:43 <frosch123> they refer to glibc
22:26:47 <Rubidium> fdatasync(): _POSIX_C_SOURCE >= 199309L || _XOPEN_SOURCE >= 500
22:26:59 <Ether_Man> Alberth, yep. But the thing is, for mingw, it NEVER exists.
22:27:10 <frosch123> but the same page mentions _POSIX_SYNCHRONIZED_IO further below
22:27:20 <Alberth> Ether_Man: then mingw is wrong in claiming the number
22:27:47 <glx> and I think I should have noticed a compile failure since 2009
22:27:51 <frosch123> so, i think the man page is ambiguous
22:27:56 <Alberth> but euhm , you've got two installs here that do work
22:28:07 <Ether_Man> Alberth, no it's not. It is using that number. That version specifically says that it does not garantee that that function exists. It gives a specific handle, as frosch123 mentions for when that function does exist.
22:29:41 <Alberth> so explain how two other install do work?
22:31:30 *** Hiddenfunstuff has quit IRC
22:32:30 <Ether_Man> There's literally thousands of explanations for why... Without further information on their specific environments, it would be impossible to say which one. The fact is however that as the source is written, it is correct that it will fail on mingw
22:33:14 <Rubidium> the manpage says, if those those defines have a particular value the function exists
22:33:20 <Ether_Man> Because "(defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE >= 199309L) || (defined(_XOPEN_SOURCE) && _XOPEN_SOURCE >= 500)" is indeed true on mingw
22:34:03 <glx> not for my two different mingw, not for the compile farm, not for Rubidium's
22:34:04 <Rubidium> then *your* MinGW (whatever version it is), does say it complies to a particular POSIX/XOPEN version without actually complying
22:34:34 <Rubidium> ergo, *your* MinGW environment is wrong
22:35:04 <Ether_Man> Rubidium, it IS complying... As frosch123 points out, it's supposed to give you an ADDITIONAL def IF that function exists. It's OPTIONAL...
22:35:33 <glx> no trace for POSIX/XOPEN in "echo | g++ -dM -E -" for me
22:35:46 <Rubidium> Ether_Man: then what define do we need to check?
22:36:05 <Ether_Man> _POSIX_SYNCHRONIZED_IO
22:36:46 <frosch123> the man page lists two different availability conditions
22:36:50 <frosch123> one at the top, one at the bottom
22:36:57 <frosch123> that diff checks both :p
22:38:08 <Rubidium> in any case, there are a few (unknown versions) of MinGW that have a different behaviour than either glx or I have
22:39:12 <Ether_Man> I'm using official mingw. From the exact archive listed on the wiki, as well as the latest. Both have the exact same thing.
22:40:22 <Rubidium> frosch123: have fun committing ;)
22:41:01 <frosch123> it's defined on my system
22:41:12 <frosch123> noone will notice if it is not defined somewhere :p
22:41:45 <frosch123> it's a case of "noone notices if it breaks" :)
22:42:04 <Rubidium> until their OpenTTD crashes and the config gets trashed
22:43:34 <frosch123> openttd crahsing is not enough
22:43:39 <frosch123> the whole computer has to crash
22:44:09 <frosch123> there is a rename after an fclose, so the data has left openttd at that point
22:44:23 <frosch123> so, you really have to crash during the write-delay of the disk cache
22:44:29 <frosch123> *crash the computer
22:47:51 <DorpsGek> Commit by frosch :: r27389 trunk/src/ini.cpp (2015-08-20 22:47:45 +0200 )
22:47:52 <DorpsGek> -Fix: There are two different availability conditions for fdatasync in the manpage. Use them both, since at least on some MinGW versions one is not enough.
23:09:16 *** Nathan1852__ has joined #openttd
23:12:00 *** tokai|noir has joined #openttd
23:12:00 *** ChanServ sets mode: +v tokai|noir
23:15:19 *** crabster has joined #openttd
23:15:53 *** UukGoblin has joined #openttd
23:16:41 *** HerzogDeXtEr1 has joined #openttd
continue to next day ⏵
