Times are UTC Toggle Colours
02:33:26 *** JGR_ has joined #openttd.dev 02:35:52 *** JGR has quit IRC 06:14:11 *** Supercheese has quit IRC 15:01:23 *** Knogle has quit IRC 15:02:29 *** Knogle has joined #openttd.dev 17:00:16 *** Zuu has joined #openttd.dev 17:00:16 *** ChanServ sets mode: +v Zuu 17:44:51 *** Alberth has joined #openttd.dev 17:44:51 *** ChanServ sets mode: +v Alberth 18:36:43 *** frosch123 has joined #openttd.dev 18:36:43 *** ChanServ sets mode: +v frosch123 18:45:10 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26397 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:09:23 *** Supercheese has joined #openttd.dev 19:09:23 *** ChanServ sets mode: +v Supercheese 20:26:37 <fonsinchen> Zuu: there's a tab before that "= equal_range ..." 20:26:48 <fonsinchen> Other than that: looks good 20:32:05 <LordAro> hmm. 20:32:20 <LordAro> would you guys be opposed to me cleaning up the grfcodec code? 20:32:39 <frosch123> do you have a life insurance? 20:33:10 <LordAro> :D 20:33:25 <LordAro> nothing excessive - just fix warnings, and code style 20:33:27 <frosch123> honest recommendation: if you are interested, rewrite it; do not even bother trying cleaning it up 20:33:50 <frosch123> it's a black hole of all horrible 20:34:02 <frosch123> side effects, passing stuff via global vars instead of parameters 20:34:23 <frosch123> all the hacks you did on punchcard machines 20:35:25 <rubidium> my gcc doesn't get any warnings on grfcodec 20:36:34 <LordAro> rubidium: that's because a lot of warnings are disabled ;) 20:36:40 <LordAro> well, a few, anyway 20:37:36 <planetmaker> well, why would we be opposed? 20:37:53 <Alberth> apparently, it's a waste of time? :) 20:38:42 <planetmaker> I'm not sure that "rewrite" is actually the better advise really 20:39:04 <planetmaker> in the end effect it might be - provided you know all intricacies which grfcodec does. But that's not something I'd bet much on 20:39:44 <planetmaker> LordAro, but I'll be curious as to why you want to endeavour that? 20:39:55 <LordAro> i dunno 20:40:00 <LordAro> was curious 20:40:05 <LordAro> and found that it was nasty 20:40:22 <planetmaker> rewrite NML in c++ :) 20:40:40 <frosch123> that i would also recommend not doing :p 20:40:47 <planetmaker> :P 20:41:11 <planetmaker> summary: be lazy :P 20:41:46 <planetmaker> rewrite NML to python3. But talk to Alberth about it ;) 20:42:43 <Alberth> 1 test works, so far :) 20:42:51 <LordAro> rewriting python2 stuff to python3 isn't usually so bad 20:43:11 <Alberth> 70 files with string interpolation :p 20:43:19 <frosch123> py2to3 worked quite well on the redmine library 20:43:32 <frosch123> only had to fix 3 issues afterwards 20:44:02 <Alberth> it skipped all % things in other than print context, ie all error reports :) 20:44:17 <frosch123> :p 20:45:33 <Alberth> you can also do refactoring work in nml 20:45:52 <Alberth> as well as documenting methods/functions 20:46:20 <LordAro> maybe :p 20:46:32 <LordAro> depends how successful i am at getting into GSoC 20:46:34 <LordAro> :p 20:48:11 <LordAro> unless you want to pay me to do this ;) 20:48:30 <Alberth> ever lasting fame? :) 20:48:59 <LordAro> :D 20:49:12 <LordAro> doesn't help me buy more monitors, i'm afraid :p 20:50:18 <Alberth> I tried using 2 at work for a while, but I found it more trouble than it's worth 20:51:36 <frosch123> a few week having 2 at work made me get annoyed at home, so i got 2 at home as well 20:51:41 <LordAro> i regularly run out of screenspace, and tend to lose track of where my workspaces are :L 20:51:41 <planetmaker> two monitors is great 20:51:45 <rubidium> 2 monitors is great 20:52:01 <Alberth> I am clearly outnumbered :) 20:52:02 <planetmaker> helps to have the same kind of monitor 20:52:02 <rubidium> one for your development environment, the other the application you're tracing through 20:52:36 <planetmaker> LordAro, what project do you plan to apply for at gsoc? 20:52:46 <Alberth> my tests are usually too short for that :) 20:52:53 <planetmaker> (btw, via python foundation you can work on hg directly) 20:53:01 <LordAro> Alberth: your opinion is clearly wrong :p 20:53:06 * rubidium agrees with planetmaker about the requirement for the same monitor 20:53:09 <Alberth> yep :) 20:53:36 <LordAro> planetmaker: https://wiki.debian.org/SummerOfCode2014/Projects/DebianBasedOnClang this one, although i'm now having second thoughts :L 20:54:18 <rubidium> on the other hand, using a 1920x1200 laptop is quite useful too if you make most windows half screen wide 20:54:39 <planetmaker> :) 20:54:58 <frosch123> LordAro: well, if you want to port grfcodec to clang, that would be useful 20:55:18 <LordAro> port it? 20:55:26 <frosch123> we will likely not get rid of grfcodec for a while, so porting it to other "platforms" is fine 20:55:38 <LordAro> i just tried it 20:55:49 <frosch123> ah, so it just work? :p 20:55:51 <frosch123> how boring :) 20:55:51 <LordAro> it does compile, funnily enough, but with lotsa warnings :) 20:59:18 <planetmaker> seems that LordAro has no key installed at the devzone :P 20:59:29 <LordAro> ssh key? 20:59:41 <LordAro> yeah, only worked out how to use those a couple of weeks ago 21:01:10 <planetmaker> there's a tutorial! ;) 21:01:17 <planetmaker> still steaming hot 21:13:49 <LordAro> ^^ 21:14:03 <LordAro> hmm, vsprintf 21:14:27 <LordAro> *all* the examples use a 'format' variable as ..the format 21:14:40 <LordAro> however, clang gives me a warning stating that it must be a string literal 21:15:58 <frosch123> so it also complains on gettext? 21:16:35 <LordAro> no, "warning: format string is not a string literal" 21:17:14 <frosch123> yes, but if you use vanilla gnu gettext, that is always the case 21:17:38 <frosch123> though... maybe there were also special gettext-printf thingies 21:18:21 <frosch123> anyway, it's a warning, no error :p 21:20:33 <LordAro> yeah, none of it's an error 21:20:48 <LordAro> but then there are things like this: 21:20:49 <LordAro> src/pseudo.cpp:620:18: warning: adding 'const int' to a string does not append to the string 21:20:49 <LordAro> [-Wstring-plus-int] 21:20:49 <LordAro> outbuf<<" \""+skipspace; 21:21:36 <frosch123> yeah, that looks like grfcodec 21:22:15 <LordAro> :p 21:22:27 <frosch123> everyone else would write: skipspace ? "\"" : " \"" 21:22:45 <LordAro> ha :) 21:22:50 <frosch123> grfcodec and nforenum can be really impressive in that way 21:22:54 <LordAro> thanks for the fix hint, btw :p 21:23:08 <frosch123> sometimes they do stuff in a way, i would never have thought of anyone doing it like that 21:23:18 <rubidium> nah... &" \""[skipspace] ;) 21:24:34 <LordAro> rubidium: that is indeed what's suggested by clang :p 21:25:00 <frosch123> i have never seen " followed by [ 21:25:03 <rubidium> that's just syntactic sugar for " \""+skipspace 21:25:19 *** juzza1 has quit IRC 21:25:19 *** fonsinchen has quit IRC 21:25:20 *** juzza1_ has joined #openttd.dev 21:25:20 <LordAro> the fact that the file's called "psuedo.cpp" is somewhat of a red flag :p 21:25:25 *** juzza1_ is now known as juzza1 21:27:01 <LordAro> oh, and now clang seems to think that the expression is unused anyway 21:27:29 <LordAro> oh wait, a lack of brackets 21:28:02 <rubidium> the pseudo stands for the pseudo sprites 21:28:51 *** fonsinchen has joined #openttd.dev 21:29:46 <LordAro> you with your sensibility 21:30:09 <LordAro> i dread to think what the ttdpatch source looks like, even despite it being in assembly 21:30:58 <rubidium> seen data.cpp? 21:31:32 <frosch123> LordAro: no, assembly is fine 21:32:27 <frosch123> things only start to go wrong, when you code c like assembly, c++ like c, python like c++, ... 21:32:38 <LordAro> rubidium: yup... 21:32:42 <LordAro> i died a little 21:32:58 <LordAro> frosch123: /me looks at OTTD (slightly) :p 21:33:02 <frosch123> LordAro: don't look at it before i changed it :p 21:33:14 <frosch123> (data.cpp) 21:34:08 *** Alberth has left #openttd.dev 21:34:10 <LordAro> :p 21:34:56 <frosch123> https://dev.openttdcoop.org/projects/grfcodec/repository/revisions/e3f03c07695f/entry/src/data.cpp 21:35:24 <rubidium> oh yeah... that's what I remember 21:36:21 <frosch123> kind of lucky that it was at least hex sequences in code, instead of raw binary files edited via hex editor 21:36:32 * LordAro screams a bit 21:36:34 <frosch123> would have been nice "diffs" 21:38:01 <planetmaker> it's one of the most-often changed files, too :D 21:38:19 <frosch123> about the only one that is being changed 21:42:35 <rubidium> in any case, trying to improve the coding style will probably bring more misery than joy 21:43:47 <rubidium> after all, one will undoubtedly introduce bugs and it's used/updated so little that it'll take a long time before every bug is found 21:44:04 <rubidium> (unless you introduce some regression testing) 21:45:00 <LordAro> just compiling a (complex) newgrf will probably work well enough :L 21:45:08 <LordAro> and checking for similarities 21:47:10 <planetmaker> a separate compile job with several newgrfs as dependency certainly is feasible at the devzone 21:47:44 <rubidium> though in the end I think it's too little gain for too much effort 21:47:51 <LordAro> quite possibly 21:48:12 <LordAro> i feel it's important that it's maintained and is at least functional though 21:48:20 <rubidium> improving NML will be better 21:49:05 <rubidium> it is somewhat maintained, although there aren't many NewGRF features, so also little to do for grfcodec (or rather nforenum) 21:49:22 <LordAro> true 21:49:53 <planetmaker> adding the two missing grf features to NML would probably a much bigger gain :) 21:50:48 <LordAro> what "stations" 21:50:48 <LordAro> ? 21:50:53 <LordAro> because that's such a minor thing :p 21:50:57 <planetmaker> stations and bridges 21:52:54 <frosch123> or vehicle var 61 :) 21:52:58 <frosch123> or vehicle capacity :) 21:53:08 <planetmaker> hm? 21:53:21 <planetmaker> is it missing? 21:53:21 <frosch123> or a new random switch :) 21:53:45 <frosch123> planetmaker: #4106 22:01:36 <LordAro> so, i might have sent a friend a link to data.cpp 22:01:38 <planetmaker> hm... I see 22:01:48 <planetmaker> evil you, LordAro ;) 22:01:49 <LordAro> "ignoring the reinventing of directory traversal, the potential collisions with reserved namespaces, the fact that no one seems to have any idea whether C or C++ is the language of the day, the fact that there are at least three naming conventions in place, and the fact that it is exactly true that the only space characters present are those *required* by the parser, it could be worse" 22:02:38 <frosch123> oh, yeah, the letter is absolutely true 22:02:45 <frosch123> *latter 22:04:01 <LordAro> hmm, i wonder if i should run scan-build on it... 22:04:13 <LordAro> see how well it copes >:) 22:04:55 <frosch123> https://dev.openttdcoop.org/projects/grfcodec/repository/revisions/2b9ec70508a8/entry/src/strings.cpp#L333 <- btw. that is literally the worst code i can remember having ever seen :p 22:05:15 <frosch123> i wonder whether you would figure out why :p 22:05:47 <frosch123> i am referring to th swich case, lines 335 - 352 22:06:24 <frosch123> possibly combined with the interaction with the switch-case above it 22:07:19 <planetmaker> uh, all those string control chars... 22:07:39 <LordAro> eeeeeeeeeeeeeeeeeeeeeeeeeee 22:08:08 <frosch123> mind, i am not reffernig to the syntax or formatting 22:08:17 <frosch123> i am scared about the sideeffects involved to make it work 22:08:59 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26398 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 22:09:23 <Zuu> fonsinchen: Thanks for the heads up about the tab :-) 22:09:43 <LordAro> frosch123: "DEAR GOD WHY" from the friend ^^ 22:10:17 <frosch123> a tab within a line? why did the precommit hook not catch that? 22:11:29 <planetmaker> you mean your hook? 22:11:40 <planetmaker> DevZone afaik does not check for tabs in a line, does it? 22:11:53 <frosch123> why devzone? 22:11:56 <frosch123> ottd 22:12:33 <planetmaker> I thought you referred to that grfcodec line? 22:12:44 <frosch123> no, to zuu's commit 22:13:09 <planetmaker> afaik it only checks trailing and leading space? 22:14:47 <LordAro> sooo.... 22:14:55 <LordAro> i tried -Weverything with clang 22:15:19 <LordAro> there's a few more warnings now 22:16:19 <LordAro> i've never seen half of these warnings before! 22:16:51 <frosch123> submit it as clang testcase 22:17:33 <LordAro> ^^ 22:17:38 <LordAro> ...i could, actually 22:24:33 <LordAro> i must say, i'm surprised grfcodec uses boost 22:25:08 <frosch123> afaik only for a single class 22:25:35 <frosch123> anyway, to solve the riddle from above 22:25:58 <frosch123> the trick is that the "ch" in the switch can refer to different things 22:26:17 <frosch123> it can be both the 1st or 2nd char of the stringcode 22:26:48 <frosch123> and it only works because the 2nd char of the 9a stringcodes is < 0x7D, while the other codes are >= 0x7D 22:27:48 <frosch123> so, basically all things < 0x7D in the switch are apples, and all items >= 0x7D are bananas 22:28:02 <planetmaker> :-O 22:28:30 <frosch123> i can only classify that code as "art" 22:30:27 <planetmaker> you're a very kind person :) 22:35:49 <LordAro> :D 22:37:13 <LordAro> a wild grfcodec patch appears! http://paste.openttdcoop.org/show/3171/ 22:38:08 <LordAro> produces no warnings with gcc or clang 22:38:21 <LordAro> ...unless you turn the warning level up super high 22:40:49 <LordAro> frosch123: planetmaker: code 'review'/sanity-check? :p 22:43:42 <frosch123> + for (int i = 0; i < 4; i++) chunk.u8[i] = 0; <- memset, or default initializer 22:44:39 <frosch123> i am not sure about the "anyprocessing" change 22:45:04 <frosch123> it makes it inconsistent to the other extract functions 22:45:36 <frosch123> i don't get the nextpixel->nextspritepixel 22:46:01 <frosch123> you are renaming a virtual function 22:46:09 <frosch123> but you are not renaming any call to it 22:46:36 <frosch123> either it is a bugfix or you add a bug :p 22:47:31 <LordAro> memset, good idea 22:47:33 <frosch123> are you sure the other virtual functions are not used somewhere? 22:47:50 <LordAro> anyprocessing - was unused, what do you suggest instead? 22:48:04 <LordAro> renaming, i'll check again, but i'm reasonably certain it wasn't used 22:48:19 <LordAro> and yes, grep turns up nothing for the others 22:48:27 <planetmaker> I'm not very versed in grfcodec code. However I don't get why the anyprocessing parameter has to go or what that change implies 22:48:46 <LordAro> anyprocessing wasn't used in those functions at all 22:48:53 <frosch123> LordAro: all extract functions have a "anyprocessing" parameter 22:49:03 <LordAro> templates >:p 22:49:06 <frosch123> you could "implement it", or mark it as "unused" 22:49:12 <frosch123> but removing makes it inconsistent 22:49:14 <LordAro> kk 22:49:55 <planetmaker> seems to me somewhat like a patch which tries to fix several different things at the same time, too :) 22:50:23 <planetmaker> also, the has_mask bool is gone in a few places... no influence there either? 22:51:30 <LordAro> indeed 22:52:06 <LordAro> and, does it really matter? :p 22:52:23 <LordAro> if i were to "fix the coding style" that would be one massive ohmygod commit 22:55:52 <planetmaker> no massive un-understandable stuff :( 22:58:36 <LordAro> "<frosch123> + for (int i = 0; i < 4; i++) chunk.u8[i] = 0; <- memset, or default initializer" <-- actually, that one's a bit tricky, as 'chunk' is actually a union 22:58:42 <LordAro> is that still ok, do you think? 22:59:12 <frosch123> memset is likely best for a union 23:04:24 <LordAro> frosch123: ok, done all of those: http://paste.openttdcoop.org/show/3172/ 23:06:28 * LordAro ponders running clang-format on it, just to see the result 23:06:39 <LordAro> it'd be much better, even if not perfect 23:07:57 *** Zuu has quit IRC 23:13:19 <frosch123> LordAro: ping me again tomorrow 23:13:20 <frosch123> night 23:13:23 *** frosch123 has quit IRC 23:13:56 <planetmaker> tomorrow seems a good idea :) 23:14:01 <planetmaker> Good night here, too