Log for #openttd on 20th August 2015:
Times are UTC Toggle Colours
00:02:27  *** supermop [] has joined #openttd
00:08:23  *** joho^_^ [] has quit [Ping timeout: 480 seconds]
00:39:37  *** LadyHawk [] has joined #openttd
01:11:12  *** Nathan1852__ [] has quit [Ping timeout: 480 seconds]
01:40:57  *** glx [] has quit [Quit: Bye]
02:26:09  *** Biolunar [] has joined #openttd
02:31:04  *** JezK [~jez@2407:7800:400:107f:3db5:daca:8457:e66a] has joined #openttd
02:33:10  *** Biolunar_ [] has quit [Ping timeout: 480 seconds]
02:51:22  *** tycoondemon2 [] has joined #openttd
02:53:25  *** tycoondemon [] has quit [Ping timeout: 480 seconds]
03:28:52  *** supermop [] has quit [Ping timeout: 480 seconds]
03:37:20  *** Hiddenfunstuff [] has joined #openttd
04:18:22  *** Hiddenfunstuff [] has quit [Ping timeout: 480 seconds]
04:24:00  *** JezK [~jez@2407:7800:400:107f:3db5:daca:8457:e66a] has quit [Ping timeout: 480 seconds]
04:27:51  *** JezK [~jez@2407:7800:400:107f:3db5:daca:8457:e66a] has joined #openttd
04:56:01  *** Eddi|zuHause [] has quit []
04:56:16  *** Eddi|zuHause [] has joined #openttd
04:56:40  *** DDR [] has quit [Ping timeout: 480 seconds]
05:01:08  *** liq3 [] has joined #openttd
05:37:35  *** joho [] has joined #openttd
05:41:47  *** help [~oftc-webi@] has joined #openttd
05:42:19  <help> please how can I change the language on windows in openttd
05:42:23  *** help is now known as Guest2856
05:43:01  <Guest2856> I have gone to the settings there was only Englih availble
05:45:03  <Supercheese> did you install the other languages?
05:45:09  <Supercheese> you might need to run the installer again
05:51:24  <Guest2856> yes okay thanks
05:51:32  *** Guest2856 [~oftc-webi@] has quit [Quit: Page closed]
05:55:04  *** minimoo_ [quasselcor@2a01:4a0:44:118::2] has quit [Ping timeout: 480 seconds]
06:45:23  *** minimoo [quasselcor@2a01:4a0:44:118::2] has joined #openttd
07:34:07  *** smoke_fumus [~smoke_fum@] has joined #openttd
08:00:47  *** DDR [] has joined #openttd
08:04:47  *** sla_ro|master [] has joined #openttd
08:15:08  *** andythenorth [] has joined #openttd
08:16:52  <andythenorth> o/
08:17:26  <planetmaker> \o
08:28:16  <planetmaker> ho... orduge killed the forums :P
08:32:50  *** Pensacola [~quassel@] has joined #openttd
08:42:49  *** JezK [~jez@2407:7800:400:107f:3db5:daca:8457:e66a] has quit [Quit: :q!]
09:19:41  *** Wolf01 [] has joined #openttd
09:20:08  <Wolf01> hi hi
09:49:18  *** snorre [~snorre@] has joined #openttd
09:51:08  *** snorre_ [~snorre@] has quit [Ping timeout: 480 seconds]
09:56:35  *** zeknurn [] has quit [Read error: Connection reset by peer]
10:00:18  *** zeknurn [] has joined #openttd
10:08:20  *** zeknurn [] has quit [Ping timeout: 480 seconds]
10:10:02  *** andythenorth [] has quit [Quit: andythenorth]
10: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
10: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?
10: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
10:19:21  <planetmaker> Ether_Man, #openttdcoop has a few savegames where we focus on passengers and growing towns; they might interest you
10:20:09  <planetmaker> but also check the normal list of savegames
10: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
10:21:03  <planetmaker> that should not happen. Any particular savegame?
10:21:19  <planetmaker> you will need the (legacy) grfpack, though for some savegames
10:21:33  <Ether_Man> All I've tried (some 10-15 different ones) all give errors
10:21:34  <planetmaker> only very few savegames might have issues
10:23:15  *** efess [] has quit [Ping timeout: 480 seconds]
10:24:51  *** zeknurn [] has joined #openttd
10:40:07  <V453000> Ether_Man: which game revision do you have?
10:40:14  <V453000> getting the latest nightly is best
10:41:00  <Ether_Man> I'm using 1.5.1 Stable
10:41:17  <V453000> the newest games certainly wont work with that
10:41:25  <V453000> which save did you try?
10:42:29  *** Hiddenfunstuff [] has joined #openttd
10: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
10:46:39  *** andythenorth [] has joined #openttd
10: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
10:47:50  *** KouDy [~koudy@] has quit [Ping timeout: 480 seconds]
10:48:15  <planetmaker> scenario_developer is a setting which you can enable in the console of OpenTTD
10:51:25  *** KouDy [~koudy@] has joined #openttd
10:52:01  <V453000>
10:52:11  <V453000> there you go
10:53:03  *** DDR [] has quit [Ping timeout: 480 seconds]
10: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 :)
10:54:06  <V453000> the file is ancient and packed with GPL license
10:54:47  <V453000> and if it breaks your savegames, it doesnt make any sense to not distribute it
10:56:24  *** Pereba [~UserNick@] has joined #openttd
11:01:28  <V453000> but yeah you can just scenario_developer the way around it
11: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
11: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.
11:31:38  *** Supercheese [] has quit [Read error: Connection reset by peer]
11:32:13  *** Supercheese [] has joined #openttd
11:34:15  <V453000> you are a weird person.
11:35:08  <Ether_Man> Because I care more about what a person want now, rather than what they wanted in the past?
11:38:33  <V453000> no, because you support something which is ultra not constructive, yet you feel like you are helping anybody with such attitude
11: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.
11:40:01  <V453000> that is kind of the same :)
11:40:25  * andythenorth likes trains
11: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
11: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 :)
11:42:14  <V453000> well, SAC fucked us all over, by supporting it you are just blindly worshipping bullshit
11:42:25  <V453000> no offense intended :)
11:44:49  <V453000> if everybody behaved like her, we could just shut down bananas outright and go outside (worst possible scenario!)
11:45:02  <peter1138> let's do it
11:46:13  <andythenorth> forums are shut
11: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.
11:46:18  <andythenorth> might as well shut bananas too
11:46:35  <planetmaker> forums are back, andythenorth :)
11:46:40  <andythenorth> wat
11:46:59  <planetmaker> all shiny-new. And looks like the old. Or something
11:47:09  * andythenorth wants people to stop using HEQS, but they won’t :P
11:47:18  * andythenorth wants people to stop downloading FISH, but they won’t :P
11:47:54  <V453000> terrible people
11:48:18  *** sla_ro|master [] has quit [Ping timeout: 480 seconds]
11:48:26  <V453000> andythenorth: you should be offended
11: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?
11: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.
11:49:35  <andythenorth> don’t download FISH
11: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
11:51:25  <Wolf01> Kim Dotcom itself said to not use that
11: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.
11:53:46  <Wolf01> and also you might download music, movies and games
11:54:06  <Ether_Man> Only when those are legally available.
11:54:15  <Wolf01> yes yes
11:55:39  <V453000> you arent hurting anybody by using their software
11:55:40  <V453000> at all
11:55:48  <V453000> nobody even needs to know
11:56:00  <Ether_Man> I did not say that anyone was
11:56:23  <V453000> then avoiding to do so is just wtf
11:56:24  <peter1138> planetmaker, forums are back where?
11:56:33  <planetmaker> in my web browser
11:56:54  <planetmaker>
12:00:53  <planetmaker>
12:03:47  <peter1138> he probably shouldn't've used a permanent redirect then
12:09:57  <andythenorth> new forums
12:10:09  <andythenorth> probably snappier
12:10:29  <Eddi|zuHause> "you won't need to enable/disable DST twice a year" yay!
12:11:30  <planetmaker> sounds like a welcoming feature :P
12:13:51  <peter1138> i don't remember changing it
12:18:56  *** efess [] has joined #openttd
12:20:51  <Eddi|zuHause> uhm, is that me or does the new theme have a spacing issue?
12:22:23  <peter1138> looks alright to me
12:22:46  <peter1138> i use the silver theme though
12:28:27  <peter1138> hmm, 152KB patch :S
12:32:06  *** sla_ro|master [] has joined #openttd
12:33:03  <Eddi|zuHause> this is how it looks for me:
12:35:26  <andythenorth> cached CSS?
12:35:34  * andythenorth uses the silver theme
12:42:57  <orudge> Eddi|zuHause: what browser?
12:43:13  <Eddi|zuHause> orudge: konqueror. with scripts and stuff disabled
12:44:07  <orudge> Hm
12:44:13  <orudge> The standard theme makes minimal use of scripts etc
12:44:23  <orudge> Tried a hard refresh etc?
12:44:38  <Eddi|zuHause> if by hard refresh you mean ctrl+f5, then yes
12:44:41  <orudge> Yeah
12: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
12:48:44  * andythenorth wonders if Konqueror is just webkit
12:56:39  <Eddi|zuHause> you can switch konqueror between webkit and KHTML
12:56:52  <planetmaker> any objection if I just un-sticky this ancient topic?
12:56:54  <planetmaker>
12:57:50  <Eddi|zuHause> planetmaker: make a new updated version, guiding people to the wiki, grfcodec/nmlc and bananas?
12:58:37  <planetmaker> Be my guest, Eddi|zuHause
12:58:57  <planetmaker> mind that there are also announcments etc which cover very similar stuff
12:59:38  <Eddi|zuHause> announcements have a different target audience, i think
13:00:16  <Eddi|zuHause> planetmaker: a post like this should be made by a person that is likely to keep it updated
13:00:53  <planetmaker> that's why it shouldn't be a post but a link to wiki at most
13:01:43  <planetmaker> so either it continues to bit-rot and lead people to wrong places, *you* update it, or I unsticky it ;)
13:02:12  <orudge> planetmaker: feel free to unsticky it
13:02:44  <planetmaker> a link could then go to the FAQ announcement or so
13:03:04  <planetmaker> which is quite bit-rotten, too :P
13:04:21  *** Pereba [~UserNick@] has quit [Quit: Now with emoticons support! 【ツ】]
13:05:55  *** Pereba [~UserNick@] has joined #openttd
13:07:51  <planetmaker> orudge, I also want to merge and
13:08:36  *** supermop [] has joined #openttd
13:08:43  <planetmaker> as it's your posting... do I have permission to edit?
13:12:52  <supermop> what is going on
13:13:11  <orudge> planetmaker: yes, I'd suggest destickying Dinges's post and then you could copy the contents into my post
13:15:59  <planetmaker> yes, that's the plan, orudge
13:22:48  *** shirish [~quassel@] has joined #openttd
13:22:55  <planetmaker> done
13: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 :)
13:25:04  <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
13:30:33  *** Biolunar [] has quit [Quit: yo!]
13:41:11  *** andythenorth [] has left #openttd []
13:43:15  <orudge> Eddi|zuHause: hmm, odd
13:56:35  *** Nathan1852__ [] has joined #openttd
14:06:20  *** Pereba [~UserNick@] has quit [Ping timeout: 480 seconds]
14:58:03  *** roidal [] has joined #openttd
14:58:44  *** Zr40 [] has joined #openttd
15:07:47  *** Wormnest [] has joined #openttd
15:16:22  *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
15:16:25  *** mode/#openttd [+o Alberth] by ChanServ
15:32:54  *** Nathan1852 [] has joined #openttd
15:36:28  *** Progman [] has joined #openttd
15:38:09  *** Nathan1852_ [] has joined #openttd
15:39:11  *** Nathan1852__ [] has quit [Ping timeout: 480 seconds]
15:44:45  *** Nathan1852 [] has quit [Ping timeout: 480 seconds]
15:52:35  *** Nathan1852_ [] has quit [Read error: Connection reset by peer]
15:55:25  *** TheMask96 [] has quit [Ping timeout: 480 seconds]
15:56:14  *** Nathan1852 [] has joined #openttd
16:00:42  *** TheMask96 [] has joined #openttd
16:04:16  *** tokai [] has joined #openttd
16:04:19  *** mode/#openttd [+v tokai] by ChanServ
16:07:43  *** HerzogDeXtEr [] has joined #openttd
16:19:52  *** Nathan1852_ [] has joined #openttd
16:25:18  *** Biolunar [] has joined #openttd
16:27:15  *** Nathan1852 [] has quit [Ping timeout: 480 seconds]
16:33:20  *** glx [] has joined #openttd
16:33:23  *** mode/#openttd [+v glx] by ChanServ
16:49:17  *** Nathan1852 [] has joined #openttd
16:55:56  *** Nathan1852_ [] has quit [Ping timeout: 480 seconds]
16:56:54  *** Nathan1852_ [] has joined #openttd
17:03:55  *** Nathan1852 [] has quit [Ping timeout: 480 seconds]
17:30:26  *** gelignite [] has joined #openttd
17:40:25  *** Pensacola [~quassel@] has quit [Remote host closed the connection]
17:45:25  <DorpsGek> Commit by translators :: r27388 trunk/src/lang/dutch.txt (2015-08-20 19:45:15 +0200 )
17:45:26  <DorpsGek> -Update from WebTranslator v3.0:
17:45:27  <DorpsGek> dutch - 4 changes by TheTycoonist
18:07:35  *** snorre_ [~snorre@] has joined #openttd
18:08:53  *** snorre [~snorre@] has quit [Ping timeout: 480 seconds]
18:18:16  *** Zuu [] has joined #openttd
18:21:15  *** liq3 [] has quit []
18:22:07  *** OsteHovel [] has quit [Ping timeout: 480 seconds]
18:23:46  *** OsteHovel [] has joined #openttd
18: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.
18:29:44  <Zuu> Nightlies are daily/nightly builds of trunk.
18:30:00  <Ether_Man> Cheers :)
18:30:03  <Zuu> About 20 o clock at CEST or so.
18:30:37  <Zuu> (GMT+2)
18: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.
18:32:40  *** snorre [~snorre@] has joined #openttd
18:33:16  <Ether_Man> GMT+2 would be CEDT atm. And for another 2 months :)
18:34:11  <Ether_Man> Anyway. Thank you for the answers. Guess I'll try mingw. Personally hate vc++ >_<
18:34:26  *** snorre_ [~snorre@] has quit [Ping timeout: 480 seconds]
18:40:21  *** frosch123 [] has joined #openttd
18:40:43  <Eddi|zuHause> Ether_Man: last i heard was that mingw has trouble with 64bit architectures
18:41:03  <Ether_Man> Wouldnt that only apply to MinGW64 in that case?
18:41:12  <Eddi|zuHause> and 20:00 CEST was a little over half an hour ago
18: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
18:42:01  <Eddi|zuHause> S stands for summer
18:42:18  <Ether_Man> ??  Where I'm from, it's standard time
18:42:18  <Zuu> CET is winter/standard time in central europe.
18:42:29  <Eddi|zuHause> winter time is called CET
18:43:04  <Ether_Man> Oh well. Guess we use different shorts here then :)
18:44:50  <Eddi|zuHause> i have never seen anybody use "CEDT"
18:45:21  <frosch123> Eddi|zuHause: on the other side of the ocean they have PST/PDT, EST/EDT and stuff
18:45:58  <Ether_Man> Eddi|zuHause, top thing there.
18:46:11  <frosch123> he, did someone really unsticky the completely useless "useful tools" thread?
18:46:14  <Ether_Man> But yea, it seems CEST is the normal abbriv for summer
18:47:00  <planetmaker> frosch123, I did today. It annoyed me
18:47:06  <planetmaker> hi ho :)
18:47:46  <frosch123> i think i reported that thread years ago :p
18:47:58  <planetmaker> last modification was ~5 years ago
18:48:03  <frosch123> so, yay \o/
18:48:15  <planetmaker> and tbh, I didn't hear of 2/3 of the "useful" tools before :P
18:49:00  <Zuu> You make the thread sound interesting. Where do I find it?
18:49:40  <planetmaker> in the depths of the forum :P. I added to our wiki a link to that thread for hysteric reasons, though
18:49:56  <frosch123> ^^ that's how i noticed its removal :)
18:50:05  <planetmaker> ;D
18:50:23  <planetmaker> <-- last link
18:51:00  <Zuu> When I googled for 'openttd useful thread', the first result was wiki page 'Rejected features' :-)
18:51:08  <planetmaker> :D
18:51:24  <frosch123> haha :)
18:52:37  <Zuu> 2) 'requested features',  3) comparison of AIs
18:59:05  <frosch123> why do you not get anything about the openttd-useful package?
18:59:11  <frosch123> for compiling on windows
18:59:27  <V453000> quak
18:59:39  <frosch123> hoi
19: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.
19:01:12  <frosch123> well, when i searched one of the features thread was at position 8, and the other i did not see :p
19:01:46  <Zuu> Well, I was logged in, so that probably skewed my results :-)
19:21:46  *** FLHerne [] has joined #openttd
19:24:48  *** shirish [] has quit [Remote host closed the connection]
19:28:26  <Alberth> hi hi
19: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 >_<
19:38:12  <Eddi|zuHause> i've seen that before, i think...
19: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 >_<
19:39:04  <Ether_Man> So yea, MinGW cannot compile openttd currently it seems >_<
19:39:21  <frosch123> add an #if _POSIX_SYNCHRONIZED_IO > 0 or something
19:39:33  <frosch123> likely windows filesystem does not support such stuff
19: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
19: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)
19: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 :/
19:44:13  <Eddi|zuHause> there's a related discussion in here somewhere:
19: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 >_<
19:52:26  <Alberth> probably configure
19:53:38  <Ether_Man> Doesnt seem like it :/
19:53:52  <Alberth> src/ini.cpp
19:53:52  <Alberth> 19:# define WITH_FDATASYNC
19:54:08  <Alberth> so it seems :)
19: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
19:54:56  <frosch123> so, should we use that instead?
19:56:06  <planetmaker> hm... :)
19:57:20  <Alberth> we seem to check for  >= specific posix version , or >= specific xopen version
19:57:27  <glx> I never had this problem
19:57:48  <frosch123> <- no idea what that would break :p
19:59:16  <planetmaker> try :P
19:59:36  <glx> and compile farm works too
20:00:06  <planetmaker> well, the CF uses MSVC not, mingw
20:00:16  <glx> win9x build uses mingw
20:03:39  <Alberth> 64 bit?
20:04:17  <Alberth> hmm apparently it does
20:04:22  <frosch123> Ether_Man: so, does above diff work for you?
20:04:53  <Ether_Man> frosch123, it compiles. Will soon know if it results in a working install :)
20:06:15  <Ether_Man> Yay. It does :)
20:09:54  <Alberth> I don't understand why we have it, surely closing the file descriptor would be enough?
20:10:52  <Alberth> or even fflush()
20:11:21  <Rubidium> Alberth: nope, that's the thing... those are not enough
20:11:35  <frosch123> yeah, no idea either, it even uses a rename afterwards for atomic replacement
20:11:46  <Alberth> it only helps if the system crashes, by the looks of it?
20:13:46  <Rubidium> I'm not sure about the exact reasons anymore, but there was some reason why it's done this way
20:13:58  <Alberth> so there exist silly systems that don't write out written data after closing the file?
20:14:04  <Alberth> ugh :(
20:14:05  <Eddi|zuHause> the probability that the system crashes is decidedly nonzero
20:15:00  <Ether_Man> Alberth, posix systems do not
20:15:09  <Alberth> huh?
20:15:11  <glx> windows is not posix
20:15:32  <frosch123> @commit 15686
20:15:32  <DorpsGek> frosch123: Commit by rubidium :: r15686 trunk/src/ini.cpp (2009-03-12 15:22:17 +0100 )
20:15:33  <DorpsGek> frosch123: -Codechange: make it a bit harder for crashes to trash your config file.
20:15:45  <frosch123> that added it
20:15:53  <frosch123> so, yeah, it's about something breaking
20:16:09  <glx> and it never caused problem for mingw
20:16:16  <Alberth> Ether_Man: I am quite sure that data you give to the OS will end up at the disk
20: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.
20:16:50  <Alberth> Ether_Man: that's the point, it is done after writing, I guess
20:17:03  <Alberth> so nothing "half way"
20:17:21  <Eddi|zuHause> Ether_Man: i don't quite follow that argument
20:17:27  <Alberth> and it can equally well crash a long time just before
20:18:01  <frosch123> he, that commit also added the "rename"
20: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
20:18:24  <Alberth> Ether_Man: wrong
20:18:37  <frosch123> hmm, maybe it is about disk full or something weird?
20:18:42  <frosch123> can fclose fail?
20:18:47  <Ether_Man> frosch123, yes
20:19:00  <Ether_Man> If the handle is currently busy, it will fail
20: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."
20:19:06  <frosch123> fdatasync returns an error code, which ottd checks after the fclose
20:20:15  <Alberth> if fclose fails, you're dead already
20: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
20:21:29  <Alberth> Ether_Man: indeed, but that can happen any time while writing, a fdata sync at the end doesn't fix that
20:22:32  <Alberth> if fclose doesn't do what it is supposed to do, the implementation is broken, imho
20: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
20:23:10  <Alberth> just bloody silly
20:23:51  <glx> Ether_Man: anyway something should be wrong in your mingw setup
20:24:19  <Ether_Man> glx, no. Mingw does not have, nor has it ever had support for fsync or fdatasync.
20: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.
20:24:48  <glx> Ether_Man: and it's not a problem as it should not go there
20:24:48  <Alberth> yes, so it's in the OS
20:24:57  <Alberth> Rubidium: and thus eventually at the disk
20: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
20:26:12  <Alberth> Ether_Man: I really doubt those numbers are by accident
20:26:21  <glx> doesn't happen for my msys/mingw nor my msys2/mingw-w64
20:26:25  <frosch123> those numbers are from the manpage as well :)
20:26:37  <Alberth> no doubt someone figured out that's when fdatasync should exist
20:26:41  <Rubidium> Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
20:26:43  <frosch123> they refer to glibc
20:26:47  <Rubidium> fdatasync(): _POSIX_C_SOURCE >= 199309L || _XOPEN_SOURCE >= 500
20:26:59  <Ether_Man> Alberth, yep. But the thing is, for mingw, it NEVER exists.
20:27:10  <frosch123> but the same page mentions _POSIX_SYNCHRONIZED_IO further below
20:27:20  <Alberth> Ether_Man: then mingw is wrong in claiming the number
20:27:47  <glx> and I think I should have noticed a compile failure since 2009
20:27:51  <frosch123> so, i think the man page is ambiguous
20:27:56  <Alberth> but euhm , you've got two installs here that do work
20: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.
20:29:41  <Alberth> so explain how two other install do work?
20:31:30  *** Hiddenfunstuff [] has quit [Ping timeout: 480 seconds]
20: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
20:32:51  <Rubidium> why?
20:33:14  <Rubidium> the manpage says, if those those defines have a particular value the function exists
20:33:20  <Ether_Man> Because "(defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE >= 199309L) || (defined(_XOPEN_SOURCE) && _XOPEN_SOURCE >= 500)" is indeed true on mingw
20:33:28  <glx> it's not
20:33:33  <Ether_Man> Yes it is.
20:34:03  <glx> not for my two different mingw, not for the compile farm, not for Rubidium's
20:34:04  <Rubidium> then *your* MinGW (whatever version it is), does say it complies to a particular POSIX/XOPEN version without actually complying
20:34:34  <Rubidium> ergo, *your* MinGW environment is wrong
20: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...
20:35:33  <glx> no trace for POSIX/XOPEN in "echo | g++ -dM -E -" for me
20:35:46  <Rubidium> Ether_Man: then what define do we need to check?
20:36:05  <Ether_Man> _POSIX_SYNCHRONIZED_IO
20:36:25  <frosch123> Rubidium:
20:36:46  <frosch123> the man page lists two different availability conditions
20:36:50  <frosch123> one at the top, one at the bottom
20:36:55  <Rubidium> yay...
20:36:57  <frosch123> that diff checks both :p
20:37:42  *** Ribena [] has quit []
20: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
20: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.
20:39:48  *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
20:40:22  <Rubidium> frosch123: have fun committing ;)
20:41:01  <frosch123> it's defined on my system
20:41:12  <frosch123> noone will notice if it is not defined somewhere :p
20:41:45  <frosch123> it's a case of "noone notices if it breaks" :)
20:42:04  <Rubidium> until their OpenTTD crashes and the config gets trashed
20:43:34  <frosch123> openttd crahsing is not enough
20:43:39  <frosch123> the whole computer has to crash
20:44:09  <frosch123> there is a rename after an fclose, so the data has left openttd at that point
20:44:23  <frosch123> so, you really have to crash during the write-delay of the disk cache
20:44:29  <frosch123> *crash the computer
20:47:51  <DorpsGek> Commit by frosch :: r27389 trunk/src/ini.cpp (2015-08-20 22:47:45 +0200 )
20: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.
21:09:16  *** Nathan1852__ [] has joined #openttd
21:12:00  *** tokai|noir [] has joined #openttd
21:12:03  *** mode/#openttd [+v tokai|noir] by ChanServ
21:15:19  *** crabster [~mccrabbym@] has joined #openttd
21:15:53  *** UukGoblin [] has joined #openttd
21:16:15  *** Nathan1852_ [] has quit [Ping timeout: 480 seconds]
21:16:41  *** HerzogDeXtEr1 [] has joined #openttd
21:17:12  *** HobGoblin [] has quit [Read error: Connection reset by peer]
21:17:13  *** DDR [] has joined #openttd
21:17:55  *** frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
21:17:57  *** gelignite [] has quit [Read error: Connection reset by peer]
21:18:35  *** tokai [] has quit [Ping timeout: 480 seconds]
21:21:17  *** lobster [~mccrabbym@] has quit [Ping timeout: 480 seconds]
21:21:47  *** HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
21:35:23  *** smoke_fumus [~smoke_fum@] has quit [Quit: KVIrc 4.2.0 Equilibrium]
21:55:14  *** Progman [] has quit [Remote host closed the connection]
21:55:51  *** Zuu [] has quit [Quit: Leaving]
22:07:47  *** snorre_ [~snorre@] has joined #openttd
22:09:36  *** snorre [~snorre@] has quit [Ping timeout: 480 seconds]
22:10:28  *** HerzogDeXtEr1 [] has quit [Quit: Leaving.]
22:13:56  *** Nathan1852_ [] has joined #openttd
22:13:57  *** FLHerne [] has quit [Ping timeout: 480 seconds]
22:21:15  *** Nathan1852__ [] has quit [Ping timeout: 480 seconds]
22:40:21  *** roidal [] has quit [Quit: WeeChat 1.2]
22:43:17  *** supermop [] has quit [Ping timeout: 480 seconds]
22:44:53  *** Wormnest [] has quit [Quit: Leaving]
23:15:05  *** sla_ro|master [] has quit []
23:17:44  *** Nathan1852__ [] has joined #openttd
23:22:56  *** namad7 [] has joined #openttd
23:24:47  *** Nathan1852_ [] has quit [Ping timeout: 480 seconds]
23:35:06  *** namad7 [] has quit []

Powered by YARRSTE version: svn-trunk