Log for on 11th March 2014:
Times are UTC Toggle Colours
02:33:26  *** JGR_ has joined
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
17:00:16  *** Zuu has joined
17:00:16  *** ChanServ sets mode: +v Zuu
17:44:51  *** Alberth has joined
17:44:51  *** ChanServ sets mode: +v Alberth
18:36:43  *** frosch123 has joined
18:36:43  *** ChanServ sets mode: +v frosch123
18:45:10  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26397 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:09:23  *** Supercheese has joined
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: 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
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
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
21:34:10  <LordAro> :p
21:34:56  <frosch123>
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> <- 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: || 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!
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:
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

Powered by YARRSTE version: svn-trunk