Log for #openttdcoop.devzone on 24th June 2010:
Times are UTC Toggle Colours
02:45:14  <Brot6> Redmine - Revision 3811: Sanitize image links and handle nils in the toc formatter. #5445 (edavis10) @
02:45:14  <Brot6> Redmine - Revision 3812: Merged r3811 from trunk. (edavis10) @
03:27:21  <Brot6> Swedish Rails - Feature #1036: Add more elaborate level crossings for railtypes (planetmaker) @
03:29:04  <Brot6> Swedish Rails - Feature #1036: Add more elaborate level crossings for railtypes (planetmaker) @
03:44:48  <Brot6> Redmine - Revision 3813: Force string comparison for login search to be case sensitive on MySQL. ... (edavis10) @
04:04:54  <Brot6> NewGRF Meta Language - Revision 490:ab2a9bd9c4cf: Doc: Mention some global parameters (planetmaker) @
04:35:07  <Brot6> NewGRF Meta Language - Revision 491:6db051e5ff56: Doc: Rename the TTDPATCH flags into CONFIGFLAG ... (planetmaker) @
06:31:40  *** ODM has joined #openttdcoop.devzone
07:07:47  <Brot6> OpenGFX+ - Revision 31:2fddbc3d6e5b: Fix: dependency check was broken (planetmaker) @
07:25:16  *** andythenorth has joined #openttdcoop.devzone
07:26:19  <Brot6> Swedish Rails - Revision 78:b3de947f6d69: Fix: Dependency check was broken (planetmaker) @
07:30:43  <Brot6> Example NewGRF Project - Revision 101:3d049157d52a: Fix: [NML] Dependency check was broken (planetmaker) @
07:53:58  <Brot6> Swedish Rails - Revision 79:edeb7dd29f8c: Change: Implement drive side and parameter choice for l... (planetmaker) @
08:36:20  *** dan123 has joined #openttdcoop.devzone
08:36:45  <dan123> hello to all
08:37:48  <dan123> I was messing around with 2cctrainset and found where wagon weights are stored (and set to 0t)
08:38:17  <Rubidium> and now they don't accelerate anymore?
08:38:45  <dan123> well, I couldn't complie it (some strange issues with my linux)
08:38:50  <dan123> :/
08:39:36  <dan123> "Error: Encountered invalid character looking for literal byte.
08:39:36  <dan123> 	While reading sprite:610"
08:39:57  <dan123> I did try to change locale to en_US, but it didn't change a thing
08:40:03  <Rubidium> so there's something wrong with that sprite
08:40:47  <dan123> and that's output I get not only from version modified by me, but also vanila one
08:41:45  <Rubidium> what version of grfcodec?
08:42:19  <dan123> 0.9.10
08:42:22  <Rubidium> (assuming it is grfcodec spitting that error)
08:42:42  <dan123> yes
08:42:54  <Rubidium> "only" 0.9.10? Or 0.9.10 r....?
08:43:41  <dan123> complied version form
08:44:17  <Rubidium> try it with the one from
08:45:11  <Rubidium> it's roughly 3.5 years newer
08:47:11  <dan123> now it worked, thanks!
08:48:22  <Rubidium> everything from the ttdpatch side has a bit of a "release new version" problem
09:05:02  <dan123> Rubidium: well...
09:05:13  <dan123> it *works* as intended :)
09:05:42  <dan123> now only problem is to get around what those weights should be :)
09:13:40  <planetmaker> dan123, did you get the 2cctrainset's source?
09:13:47  <dan123> hmm, almost as intended
09:13:47  <dan123> for some strange reason 1st and 2nd gen have the same masses
09:13:57  <dan123> also 3rd and 4th
09:14:00  <dan123> planetmaker: yes
09:14:12  <planetmaker> dan123, if you find errors / have improvements, patches for the trainset are warmly welcome
09:14:39  <planetmaker> The (main) author is currently on vacation, but still.
09:14:41  <dan123> that's why I'm here :)
09:14:43  <planetmaker> If you post patches to the bug tracker or post in the forum thread, they'll be noticed
09:15:05  <planetmaker> ok :-) Sweet
09:15:18  <planetmaker> There are not many around who actually dare to mess with newgrfs
09:45:40  *** KenjiE20 has joined #openttdcoop.devzone
10:35:10  *** MindB_ender has joined #openttdcoop.devzone
10:35:32  <MindB_ender> ola's
10:37:05  <Rubidium> ohla
10:39:20  <MindB_ender> you knowledgable about Openttd svn? I use tortoise normally for other projects, but I'm kinda confused by the whole setup on the OpenTTD site.
10:41:55  <MindB_ender> normally i'd just make a mydocs "OpenTTD" folder and do a "create repository here" via tortoise. But i see all links are to c:/dev/ etc. Just wondering if that's code related, cause i just want to do data (gfx) changes/addon.
10:44:52  <MindB_ender> (uhm... "check out")
10:45:05  <planetmaker> MindB_ender, if you're just into writing (new)grfs, you might just want to a) look at existing projects found here and b) look at and maybe, just maybe look at NML and the swedishrails project as a first example
10:45:14  <planetmaker> you don't need to chew through OpenTTD code in order to develop graphic extensions for it
10:46:30  <MindB_ender> that's what i thought
10:46:58  <MindB_ender> this link seems more useful, thanks.
10:47:24  * MindB_ender thought the svn may have a /art or /data folder he would have to use
10:48:41  <planetmaker> it does does. Somewhat.
10:49:06  <planetmaker> But have a look at all the projects found at
10:49:15  <planetmaker> those are a range of more or less advanced newgrf extensions for OpenTTD
10:49:39  <planetmaker> Personally I find it VERY helpful to have existing code to start from
10:49:43  <planetmaker> I don't know what your intentions are.
10:50:20  <MindB_ender> just want to do basically a "skin" mod, not so much changing the game as just the graphics and strings
10:50:39  <planetmaker> If you're totally new to this, I very much like to recommend to look at the new grf language which is currently developed, NML
10:50:39  <planetmaker> it's much easier to read than the byte code which all graphics were programmed in so far
10:51:14  <planetmaker> strings might need patching (that's what translations are for) - except if they are part of a newgrf extension
10:51:36  <MindB_ender> any chance of the project going png instead of sticking to pcx? i'm fine with pcx and 256 palettes etc, just think i'll miss having real opacity:)
10:51:39  <planetmaker> if it's just for simple replacement of sprites... easy
10:52:05  <planetmaker> check out NML ;-)
10:52:05  <planetmaker> but the palette won't change
10:52:09  <planetmaker> what you can do is 32bpp
10:52:18  <planetmaker> you can replace each 8bpp sprite by a 32bpp sprite
10:52:30  <MindB_ender> ah yes, game needs to be able to change the company colors i guess
10:52:39  <planetmaker> there's a whole 32bpp replacement project also
10:52:48  <planetmaker> yes, for example
10:53:08  <planetmaker> but it also does that in 32bpp
10:53:39  <MindB_ender> using a greyscale pic?
10:53:39  <planetmaker> but for starters I advise to go for 8bpp with the palette
10:53:44  * MindB_ender nods
10:53:44  <planetmaker> if you want more than 1:1 replacement with just more colours
10:54:07  <planetmaker> MindB_ender, 8bpp isn't gray scale. The colours actually are quite well defined
10:54:39  <planetmaker> Everything you usually see in OpenTTD is based on that palette
10:55:04  <MindB_ender> well i'm more wanting to make a sci-fi type deal out of the existing game. so really just a 1:1 data replacement. I like the gameplay as it is, so for now not really wanting to touch code. (well, ok.. i'm just no coder)
10:55:39  <planetmaker> and there is and won't be a way around that - except the 32bpp thingy
10:55:39  <planetmaker> Ok, you can do a Sci-Fi style without looking at the source
10:56:09  <MindB_ender> For the 32bpp greyscale could be colored by code for compay colors, is what i meant.
10:56:39  <planetmaker> You mostly need MANY sprites and probably to make it somewhat fitting you also need to get into coding: vehicles want different stats, industries and houses have different properties then most likely - even if they generally on average stay the same
10:57:05  <planetmaker> MindB_ender, there's some means to identify company colour in 32bpp. Dunno how though
10:57:05  <planetmaker> But it's well-established
10:57:14  <MindB_ender> but thanks for the link to that tutorial. i'll first will have to just go through and see how far i get with the existing 8bpp stuff for quite a while i guess:)
10:57:45  <planetmaker> MindB_ender, how far you go, you'll 99% likely need everything at least also in 8bpp.
10:58:05  <planetmaker> as that's the common denominator for everything
10:58:39  <planetmaker> but... don't worry about that when drawing graphics.
10:58:41  <planetmaker> There exists a half-done Marsian theme
10:59:07  <planetmaker>
10:59:08  <Webster> Title: Download new graphics (at
10:59:47  * MindB_ender favs it
11:00:06  <planetmaker> But be warned: to create a full replacement for even one climate means to draw like 3000+ sprites at least
11:00:26  <MindB_ender> no biggie. that's why i picked tttd to mod in the first place
11:00:39  <planetmaker> and as piece of advise:start with the drawing :-)
11:00:48  <MindB_ender> nah, rendering>:)
11:01:09  <planetmaker> Post your results, also intermediate, in the forums
11:01:09  <planetmaker> it will excite interest
11:01:29  <MindB_ender> the moment i do have results, of course i will:)
11:02:07  <planetmaker> also like "this is a set of ground sprites"
11:02:10  <planetmaker> "this is an assortment of foundations"
11:02:17  <planetmaker> not like already the whole thing :-)
11:02:45  <MindB_ender> recently found that to do lotsa sprites quick, the fastest ways are just 3dmax, rendering out animations to loose bitmaps and bulkprocess those to the sprite format
11:03:06  <planetmaker> the whole thing (all graphics) took like 3 years to finish. With various people contributing drawings, and various people coding them
11:03:15  * MindB_ender nods
11:03:16  <planetmaker> if you know that and it works for you awesome. :-)
11:03:39  * planetmaker has no clue about drawing graphics
11:03:55  <MindB_ender> i'll prolly just go for vehicles first, then buildings and perhaps skip environment entirely
11:03:56  * ODM has no clue period:P
11:04:27  <Rubidium> be very aware of the perspective (or whatever it's called)
11:04:34  <MindB_ender> not really interested in a "new game", more just a different setting.:)
11:05:09  <planetmaker> MindB_ender, well, "different" is a relative thing
11:05:09  <MindB_ender> yes, another reason for max. you set the camera and lighting right once and your perspective is fine for everything.
11:05:39  <planetmaker> But you certainly don't want your new skyranger having the stats of a 1930 turboprop machine?
11:05:58  <MindB_ender> well, gfx first. stats and strings later:)
11:06:12  <planetmaker> :-)
11:06:16  <planetmaker> good approach
11:06:17  <MindB_ender> although, in star wars for example.. the stats of the fighters are those of ww2 ones.
11:06:39  <planetmaker> he :-)
11:06:39  <MindB_ender> it would all be relative afterall.
11:07:05  <planetmaker> yeah
11:07:39  <Brot6> NewGRF Meta Language - Revision 492:785dc43dbfc9: Change: failed regression test fails the build,... (Ammler) @
11:07:39  <planetmaker> though of course it could also be used as the frequently-sought "new vehicles past the 2050 date" extension ;-)
11:07:39  <planetmaker> then it should kinda extend stat-wise the existing set(s)
11:08:06  <planetmaker> hm... regression fails?
11:08:39  <planetmaker> nope
11:09:09  <Ammler> if the regression test fails, also build will fail
11:09:11  <MindB_ender> yes, but progressing stats beyond the 2050 also unbalances the game and is actually not as much fun as initially thought.
11:09:19  <Ammler> so my error counter became useless :-)
11:09:39  <planetmaker> in any case, MindB_ender, I'm looking forward to seeing your work :-)
11:09:39  <planetmaker> MindB_ender, yes, the balance issue is present, I fully agree
11:10:05  <planetmaker> in what way, Ammler ?
11:10:10  <MindB_ender> and thankies.. off to painstshop. latah:)
11:10:17  <planetmaker> :-)
11:10:22  *** MindB_ender has quit IRC
11:10:23  <Ammler> hmm?
11:11:07  <planetmaker> what's your 'error counter'?
11:11:22  <Ammler> before I marked the rpm as required, we had output like Compile NML from r345 to r350 done (5 errors)
11:11:39  <planetmaker> the thing which stops it from re-compiling?
11:11:55  <Ammler> we still use that for newgrfs
11:12:05  <planetmaker> yes
11:12:25  <Ammler> but in case of nml, we decided that a failed regression test should also fail building
11:12:37  <Ammler> so you don't use such a version for the grfs
11:14:05  <planetmaker> yes.
11:14:11  <planetmaker> quite reasonably :-)
11:14:36  <Ammler> basically the change I made just does silence a compiler error, not noticeable at all for you
11:15:39  <planetmaker> ok :-)
11:15:55  <Ammler> just one email fewer for me
11:17:23  <Ammler> E;%{BUILD}/regression/*.log <-- E means, it does count the lines and outputs as (XX errors)
11:17:39  <planetmaker> hehe
11:17:41  <planetmaker> hm, there should probably be a difference between warning and error
11:18:12  <Ammler> I think, it doesn't matter, our newgrfs devs wouldn't care more or less
11:18:16  <planetmaker> <-- I find those errors quite pointless. And a bit sad to have always an error reported
11:18:47  <Ammler> I thought about a sed script to prefilter those
11:19:06  <planetmaker> that might be the hack we just need.
11:19:10  <planetmaker> Probably the best idea
11:19:19  <Ammler> afaik "yacc: Warning. Token 'RANDOM' defined, but not used." is valid
11:19:39  <planetmaker> the first two lines are attributed to the CF's own installation. The other two will go in time, but are NML errors rather than newgrf errors
11:20:01  <Ammler> shouldn't NML silence those?
11:20:05  <planetmaker> it is
11:20:19  <planetmaker> yes. By implementing random varaction2
11:20:27  <Ammler> I meant the md5 part
11:20:39  <planetmaker> :-)
11:20:39  <planetmaker> Hirundo is working on that
11:21:02  <Ammler> then I don't need to add a sed script, do I?
11:21:09  <planetmaker> ah. NML cannot silence the first two lines. It's warnings in yacc
11:21:09  <planetmaker> And yacc is a python package
11:21:39  <planetmaker> an installed package. Just read where the warning comes from
11:21:54  <Ammler> I think, we shouldn't silence errors, which others also might get, if the clone the repo and build those self
11:22:09  <planetmaker> it's our server installation using a package which uses a deprecated call
11:22:23  <Ammler> nono
11:22:29  <Ammler> I get the same locally
11:22:39  <planetmaker> others don't if they use other versions
11:22:45  <Ammler> I would bet, all rpm distros would get that error
11:22:45  <planetmaker> But having always a non-clean output. ALWAYS.
11:23:06  <planetmaker> That's not the point of the build errors
11:23:18  <planetmaker> it's nothing a newgrf author (nor an NML author) can fix
11:23:39  <planetmaker> only we as server admins by installing 'propery' python version
11:23:39  <planetmaker> *'proper'
11:23:47  <Ammler> that, we should ask the python pros
11:23:49  <planetmaker> As such the first two lines need to be filetered
11:23:56  <Ammler> I am not sure about.
11:24:05  <planetmaker> Ammler, you asked them. They told what I just told ;-)
11:24:22  <Ammler> yes :-)
11:25:06  <planetmaker> The error message is clear IMHO
11:25:37  <Ammler> the problem is likely the problem we have with nfo disable errors
11:25:58  <Ammler> how will we ever find out, if something of that get fixed?
11:26:06  <planetmaker> eh?
11:26:09  <planetmaker> no
11:26:15  <planetmaker> Ammler, it's completely different
11:26:18  <Ammler> if we disable error messages
11:26:34  <Ammler> we also won't notice fixes about those
11:26:39  <planetmaker> We just need to grep -v "/usr/lib/python2.6/site-packages/ply/ DeprecationWarning: the md5 module is deprecated; use hashlib instead" and fine is
11:27:06  <planetmaker> we won't notice them, unless we update python on the server, e.g. the md5 module
11:27:11  <Ammler> planetmaker: then we update to python 3.0 and that error might go away
11:27:15  <Ammler> but we won't notice
11:27:39  <planetmaker> silencing errors which are way out of our control is fine. But nforenum / grfcodec, that's something we can do about the errors as we build it ourselves
11:27:39  <planetmaker> Not so the md5module
11:28:09  <planetmaker> Ammler, yes. But then we grep on a message which won't exist. So what
11:28:09  <Ammler> so hiding python erorrs is worse :-P
11:28:39  <planetmaker> It's not like we disable all errors. We disable ONLY the md5 module deprecation.
11:28:39  <planetmaker> *sigh*
11:28:39  <planetmaker> I give up
11:28:46  <Ammler> does it really hurt, since we moved the logs to a subfolder?
11:29:06  <planetmaker> The error reports are useless
11:29:10  <Ammler> maybe we could just add a threshold
11:29:13  <planetmaker> I don't need compile news which will ALWAYS tell me that it failed
11:29:46  <planetmaker> if I have a failure announced here everyday we can skip the announcements entirely
11:29:54  <Ammler> which is currently 2, so you get only (2 errors) in the annoucement
11:30:38  <Ammler> well, you know, your current "level" is 4, you have check again, if that changes
11:30:39  <planetmaker> while there is NO error
11:30:40  <planetmaker> so the ERROR in the CF is to tell there are errors while there is none
11:31:09  <planetmaker> Ammler, that's like having zillions of whitespace warnings. Errors will also be reported. yes
11:31:09  <planetmaker> But they will pass unnoticed
11:31:44  <Ammler> like andy and djn do ignore nfo errors
11:32:41  <Ammler> planetmaker: we tell the CF, which python packages it should use to build
11:32:55  <Ammler> the CF doesn't decide that magically
11:33:05  <planetmaker> then it uses the wrong md5 one
11:33:28  <Ammler> either that, or nml uses the wrong version
11:33:44  <planetmaker> ?
11:34:05  <planetmaker> NML has no fixed preference on a python version
11:34:21  <Ammler> if I read that message right yacc should use hash instead md5
11:34:39  <planetmaker> it might be like >=2.5 and <=3.0(?), but...
11:35:06  <planetmaker> yes. And yacc is a python module provided by the CF
11:35:39  <planetmaker> as such it's a problem with the server modules
11:36:01  <Ammler> planetmaker: the server might even not have installed those
11:36:07  <planetmaker> it's like gcc 4.0 reporting warnings when compiling openttd code. pointless but annoying
11:36:26  <Ammler> those packages will be installed evertime just for building nml
11:36:36  <Ammler> or the projects
11:36:40  <planetmaker> Ammler, ok, but then the obs(?) might want to define one which doesn't exercise this warning
11:37:06  <planetmaker> ok, my error there :-)
11:37:58  <Ammler> hmm, where is yacc included?
11:38:01  <Ammler> in ply?
11:38:18  <planetmaker> Actually I don't really mind how that warning about the md5 module is silenced. Whether by a different python or a sed script
11:38:19  <Ammler>
11:38:56  <Ammler> you don't like my idea about a simple threshold?
11:39:33  <Ammler> which is 4 for nml projects
11:39:39  <planetmaker> yacc:
11:39:39  <planetmaker> Ammler, no, I don't
11:39:40  <Ammler> then it wouldn't report any errors
11:39:44  <planetmaker> A threshold will hide real errors
11:39:49  <Ammler> no
11:39:55  <Ammler> the log is still there
11:40:05  <planetmaker> just kicking out a specific on, the md5 one is safe
11:40:20  <Ammler> and if error get fixed from nml, it would go below 0
11:40:33  <Ammler> so you could "fix" the threshold
11:40:39  <planetmaker> cluttered with pointless errors
11:40:39  <planetmaker> it's a non-error. A non-message
11:40:39  <planetmaker> It really should go
11:40:42  <planetmaker> We cannot do anything about it
11:41:09  <planetmaker> Ammler, definitely the wrong approach to set a threshold for errors in general
11:41:25  <Ammler> I guess, you don't get me :-/
11:41:39  <planetmaker> warn about every error except a single pointless and known error: fine
11:42:05  <planetmaker> you want to not report errors in IRC if there are less than 4
11:42:07  <planetmaker> I consider that very bad
11:42:11  <planetmaker> correct?
11:42:29  <Ammler> no
11:42:37  <Ammler> if there are exactly 4
11:43:04  <Ammler> if there are less then 4, you need to be notified about a fix
11:43:06  <planetmaker> still: conceptually totally wrong
11:43:36  <Ammler> then tell me, how someone will be notified about a fix, if we just silence it, that is what I have my issue with
11:43:39  <planetmaker> We know what warnings there are and which is pointless. Then we should just ignore the single, known warning
11:43:41  <planetmaker> not generally assume that with 4 warnings everything is in order
11:44:05  <planetmaker> Ammler, it doesn't matter. It's not our bug nor our fix
11:44:39  <planetmaker> we cannot do a bloody thing about the md5 python module using deprecated shit
11:44:55  <Ammler> we could force using the right package version
11:45:06  <planetmaker> and OLD python module also. As it is supposedly fixed in upstream md5 modules
11:45:39  <planetmaker> if you want.
11:46:06  <planetmaker> But the only other solution is to ignore this single known bogus warning specifically. Not blindly anything which produces exactly 4 lines of warnings
11:46:11  <Ammler> or nml could check the package versions and silence it maybe directly
11:46:39  <planetmaker> how would it do that?
11:47:06  <planetmaker> restrict possible python versions on the basis of one bogus warning?
11:47:06  <planetmaker> sounds not nice, too
11:47:39  <planetmaker> if OpenTTD did that our servers couldn't compile it anymore
11:49:05  <Ammler> I didn't say something about restrictions, just silence
11:49:24  <Ammler> but I think, it is the easiest to prefilter the errorlog
11:49:39  <planetmaker> how can OpenTTD silence a bogus compiler warning?
11:50:15  <Rubidium> it can't in all cases
11:50:49  <Ammler> you really would prefer if openttd would silence compile warning, if those are caused by gcc version difference?
11:51:09  <ODM> how was the party btw?:P
11:52:15  <Ammler> he, weren't you invited? :-)
11:52:39  <ODM> mightve been
11:53:08  <Ammler> it was very funny to see some faces to the nicks here
11:56:55  <Ammler> planetmaker: grep -vP "(DeprecationWarning:)|(^yacc:)|(^  import)"
11:57:05  <planetmaker> Ammler, yes, a prefilter on this very single known message is all I advocated the whole time ;-)
11:57:23  <Ammler> that would make the current swedishrail log empty
11:57:41  <planetmaker> like a grep -v "..."
11:57:41  <planetmaker> why grep on a regex, if you can grep on the full thing to really only grep that?
11:58:05  <planetmaker> and the (valid) NML warnings: they should stay
11:58:06  <planetmaker> they will go anyway soon
11:58:12  <planetmaker> and: they are not bogus
11:58:27  <Ammler> hmm, ok, so only the first 2 lines?
11:58:39  <planetmaker> or at least we can do something about it ;-)
11:58:43  <planetmaker> yes
11:58:49  <planetmaker> which is one
11:59:05  <planetmaker> warning
11:59:09  <Ammler> no, 2, it has a linebreak
11:59:40  <Ammler> but that shouldn't be a big issue
11:59:45  <planetmaker> yes: message + line raising the warning
12:00:39  <planetmaker> but I'd really filter only the exact message.
12:00:39  <planetmaker> we want to know when anything else changes
12:04:29  <Ammler> hmm, I can't "cat log | grep -v filter > log"
12:05:06  <planetmaker> nope
12:05:11  <planetmaker> that'll give you an empty file
12:07:07  <planetmaker> can't you pipe the log directly?
12:14:34  *** dan123 has quit IRC
12:44:42  <Brot6> #openttdcoop - Revision 69:7a13eff40c31: [OTTD] Change: output created patch again to IRC (Ammler) @
12:45:11  *** TheODM has joined #openttdcoop.devzone
12:49:40  *** ODM has quit IRC
13:51:51  *** Seberoth has joined #openttdcoop.devzone
14:22:17  *** dan123 has joined #openttdcoop.devzone
14:41:49  <Brot6> #openttdcoop - Revision 70:fffed18b5271: [Compiler] Feature: Add support for NML as own global type (Ammler) @
14:42:48  *** dan123 has quit IRC
14:43:06  *** dan123 has joined #openttdcoop.devzone
14:43:51  <Brot6> #openttdcoop - Revision 71:b27c75d3b895: [Compiler] Fix (r70): requires was in wrong location (Ammler) @
15:09:26  <Brot6> OpenGFX+ - Revision 32:8cdb75ff5bfb: DevZone: Use new global type nml (Ammler) @
15:11:12  <Brot6> Swedish Rails - Revision 80:81c3fb6c11b8: DevZone: Use new global type nml (Ammler) @
16:15:02  <planetmaker> yippieh :-)
16:15:09  <planetmaker> let's see :-)
16:15:17  * planetmaker time warps
16:18:44  <Brot6> newgrf-makefile: compile of r101 failed -
16:18:59  <Brot6> newgrf_makefile: compile of r101 failed -
16:19:39  <Brot6> nml: update from r485 to r492 done -
16:20:05  <Ammler> the newgrf_makefile is a silly thing
16:20:20  <Brot6> ogfxplus: update from r29 to r32 done (2 errors) -
16:20:51  <Ammler> planetmaker: happy? ^
16:21:10  <Brot6> swedishrails: update from r76 to r80 done (2 errors) -
16:21:13  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r557), 32bpp-extra (r36), airportsplus (r50), bros (r12), comic-houses (r70), firs (r1010), fish (r375), heqs (r320), nmts (r16), nutracks (r69), opengfx (r460), openmsx (r57), opensfx (r94), snowlinemod (r12), worldairlinersset (r643)
16:22:20  <planetmaker> what about the newgrf makefile?
16:22:51  <planetmaker> I actually thought yesterday to remove the distinction on the Makefile level between the two projects
16:23:08  <Ammler> ?
16:25:26  <Ammler> planetmaker: shouldn't we for debug and demo reasons create also a nfo with nml projects?
16:26:04  <planetmaker> I thought about that. I'm not sure
16:26:33  <planetmaker> I guess currently it might not be the best of ideas. I recall yexo to say that currently the nfo output might be somewhat a bit ill-maintained
16:26:39  <planetmaker> though it seems to work, though
16:27:13  <planetmaker> concerning NML vs NFO project: there's no real need to distinguish between different projects actually
16:27:25  <planetmaker> I just define the rules for one and the other files - and that's it.
16:27:39  <planetmaker> only a combination of both methods for the same grf file won't work
16:27:45  <Ammler> you could define different targets, if you like
16:28:00  <Ammler> since we use now different setup sepcs
16:28:21  <planetmaker> that's what is being done. basically
16:28:38  <planetmaker> the main file either depends upon a nml or an nfo file
16:28:49  <planetmaker> and then the rest follows automatically by the rules give
16:28:50  <planetmaker> n
16:29:18  <planetmaker> the only distinction there currently is, is the rules for the dependency check: the type of files being parsed is different
16:34:33  <planetmaker> I actually made the distinction of nfo / nml also as I thought that they need different dep checks. But that's absolutely not the case.
17:19:01  *** frosch123 has joined #openttdcoop.devzone
17:21:34  *** Alberth has joined #openttdcoop.devzone
17:26:50  <Alberth> hmm, why does redmine not show the 3 open issues in the roadmap?
17:33:18  <planetmaker> you selected "bugs" and not "all"?
17:33:28  <planetmaker> they're features presumably
17:34:45  <Alberth> oh, there is a selection box at the right :)
17:34:47  <Alberth> thanks
17:35:06  <planetmaker> np. I wondered the same two days ago :-P
17:39:00  *** TheODM has quit IRC
17:40:02  <planetmaker> <-- care to comment on the optics? :-)
17:40:36  <Brot6> NewGRF Meta Language - Support #1042 (New): beautify the documentation a bit (planetmaker) @
18:09:51  <Alberth> the joys of having a log :)
18:09:59  <Brot6> NewGRF Meta Language - Patch #1040: name of the main script (Alberth) @
18:11:11  <Alberth> bah, redmine does not save my roadmap checkbox settings :(
18:15:29  <planetmaker> Alberth: each project has also its own activity page
18:16:20  <Alberth> euhm, how is this related to what?
18:16:42  <planetmaker> it shows commits and comments and tracker activity
18:16:53  <planetmaker> I read you being happy about logs ;-)
18:17:10  <planetmaker> reading the update to the issue it seems to me that you meant it slightly different ;-)
18:17:46  <planetmaker> nmlc for nml compiler maybe :-)
18:20:27  <Alberth> sounds generic enough :)
18:20:47  <planetmaker> :-) Yexo found it also agreeable
18:21:38  <planetmaker> btw, re: version thingy. I implemented that. And added the version to the internal NML errors
18:21:48  <planetmaker> That's what I mostly would like it for :-)
18:22:26  <planetmaker> And build and error version determination are now the same. But granted, it's kinda the same principle
18:22:43  <Ammler> Alberth: my suggestion was and then the copy in /usr/bin just nml :-)
18:23:11  <Alberth> w.r.t. #1042, the block below "An example of a part is" should be blue, I think (examples are blue, seems to be the rule). There is a run-away "string" text just below Railtypes, but that is seperate from your patch. Otherwise, it seems a nice step to me.
18:23:12  <planetmaker> I thought about adding a flag to the get_version() thing like update_version, so that the file is not written to
18:23:15  <Ammler> I thought, that is the usual python script handling
18:23:58  <planetmaker> Alberth: do you know where the run-away string is found? I searched for it... but without avail
18:25:23  <Alberth> <tr><td>menu_text</td>                   string<td></td><td></td></tr>
18:25:23  <Ammler> hmm, does it need to put someone on the watcher list, who is already memeber?
18:25:33  <planetmaker> oh
18:26:10  <Ammler> he, actually you can only members put on the list :-)
18:27:10  <planetmaker> Ammler: watchlist = e-mail upon update (if e-mail is enabled)
18:27:12  <Alberth> planetmaker: reporting versions when an error happens is a good move
18:27:23  <planetmaker> in our cases it might be over-engineered
18:28:03  <Alberth> Ammler: I don't understand your '' remark
18:28:35  <Ammler> well, that my guess was wrong, all fine :-P
18:28:40  <Ammler> then*
18:29:01  <Alberth> planetmaker: I am still not happy about writing data when doing a 'get'.
18:29:22  <Alberth> it may break in unexpected ways, like when I put installed software in a hg repo.
18:30:06  <Alberth> or when installing in a non-writable place like in /usr
18:30:34  <planetmaker> that's why it's in try... except
18:31:21  <planetmaker> but that's why I proposed a flag to the routing (write_version) which is true when called from and false when from nml
18:31:30  <Ammler> planetmaker: I said that already sometimes, feel free to use our compiler chroots to test installs...
18:31:42  <planetmaker> :-)
18:32:09  <planetmaker> Alberth: does that sound like a solution? I understand and agree to the reservation
18:32:26  <planetmaker> otherwise we'd have kinda quite a bit duplication
18:33:02  <Ammler> for example with " -q -n ogfxplus" to build the chroot fro ogfxplus but without publishing
18:33:17  <Alberth> you cannot refactor the code, and have a 'write_version()' and a 'get_version()' function?
18:34:00  <planetmaker> well..., I guess
18:48:01  <Ammler> planetmaker: if you fix that, the newgrf_makefile might also work:
18:48:23  <Ammler> I postpone my investigation in that direction :-)
18:49:00  <planetmaker> I don't understand how that's related
18:49:12  <Ammler> it looks for a grf, but there isn't one
18:49:16  <Ammler> only a tar
18:50:28  <planetmaker> but isn't it the same like every other newgrf?
18:50:35  <Brot6> newgrf_makefile: compile of r101 failed -
18:51:00  <Ammler> rm: cannot remove `mynewgrf-nightly/*.grf': No such file or directory
18:52:22  <Ammler> anyway, as I asked for taring the opengfx grfs, I didn't expect you do it in the framework for every grf :-)
18:52:29  <Ammler> it really should be fixed
18:53:13  <Ammler> also needed for ttdp btw.
18:53:35  <planetmaker> the latter is a good argument
18:54:03  <Ammler> well, another is that you can't use the zip for bananas
18:54:38  <planetmaker> well, that's really minor. I can use the tar ;-)
18:54:54  <Ammler> but then, you have to build or unzip first
18:55:18  <planetmaker> make bundle_tar is anyway executed by make bundle_zip
18:55:38  <planetmaker> zip = bundle_tar + docs
18:55:57  <planetmaker> bundle_tar = grf + docs
18:56:12  <Ammler> so you have grf + 2docs :-P
18:56:31  <planetmaker> yes
18:56:50  <Ammler> that is fine for opengfx, but stupid for all others
18:57:34  <Ammler> we could make a big devzone.tar :-)
18:58:21  <planetmaker> :-)
18:58:30  <planetmaker> 2cctrainset and firs are not small either
18:58:58  <Ammler> but still only one grf
18:59:23  <planetmaker> Ammler: so you want the zip without a tar inside, just docs + grf, yes?
18:59:34  <Ammler> in a directory
18:59:42  <planetmaker> hm, ok
18:59:47  <planetmaker> everything in a dir
18:59:47  <Ammler> hmm, I have a big deja-vu :-P
18:59:52  <planetmaker> exactly
19:00:03  <planetmaker> and I remember to exactly your bidding :-P
19:00:33  <Ammler> yep, I asked that for opengfx
19:00:36  <Ammler> and you did it for all
19:01:39  <Ammler> maybe, just revert that commit?
19:03:12  *** Seberoth2 has joined #openttdcoop.devzone
19:03:58  *** Seberoth is now known as Guest1068
19:03:58  *** Seberoth2 is now known as Seberoth
19:08:25  *** Seberoth has quit IRC
19:08:30  *** Seberoth has joined #openttdcoop.devzone
19:10:37  *** Guest1068 has quit IRC
19:21:02  <Alberth> f.write('# this file is autogenerated by\n')  <-- that is incorrect comment
19:23:05  <Brot6> NewGRF Meta Language - Revision 493:db127e629d25: Codechange: Merge version_info import with the ... (Alberth) @
19:24:53  <Brot6> NewGRF Meta Language - Revision 494:dec8d691941c: Doc: Add some more css directives to the refere... (planetmaker) @
19:28:17  <Brot6> NewGRF Meta Language - Support #1042 (Closed): beautify the documentation a bit (planetmaker) @
19:28:17  <Brot6> NewGRF Meta Language - Support #1042 (Closed): beautify the documentation a bit (planetmaker) @
19:47:05  <Brot6> NewGRF Meta Language - Revision 495:8753f92a5391: Fix: Errors found by pylint. (Alberth) @
19:55:05  <Ammler> Alberth: would it make sense to include pylint to the nightly build script?
19:56:04  <Alberth> only if we aim to reduce the number of lines it outputs
19:56:19  <Ammler> :-)
19:56:21  <Alberth> but that first needs a decision on a python coding style
19:57:00  <Alberth> the same more or less holds for automagic function documentation generation, but that needs an agreement on style as well.
19:57:11  <Alberth> currently I am the only person doing that.
19:58:06  <Alberth> (documenting functions)
19:59:09  <Alberth> currently, pylint produces 2383 lines output :)
19:59:38  <planetmaker> he :-)
20:00:00  <planetmaker> I guess the common idea was: get some working version, then refactor...
20:00:10  <planetmaker> though questionable how sane that is.
20:00:38  <Rubidium> Alberth: if you're bored you can always work on reducing :)
20:01:28  <Alberth> I know, and did some already in the past :)
20:01:57  <Alberth> unfortunately, the "get some working version, then refactor.." approach was used much longer there :)
20:03:56  <planetmaker> haha :-)
20:13:33  <Brot6> NewGRF Meta Language - Revision 496:b5a8abb57249: Codechange: Move command line parsing to its ow... (Alberth) @
20:17:58  *** frosch123 has quit IRC
20:18:43  <planetmaker> Alberth: <-- like that maybe?
20:22:49  <Alberth> why do you write the file if you don't use it?
20:23:07  <planetmaker> I do use it in get_version
20:23:20  <planetmaker> for the cases when we don't have a hg repo
20:23:32  <planetmaker> it's the version info we ship in tars
20:23:46  <Alberth> ie I don't understand how software with this code is supposed to be used
20:23:56  <planetmaker> does that
20:24:10  <Alberth> no, main() does
20:24:15  <planetmaker> ?
20:24:24  <planetmaker> writes the version
20:24:46  <planetmaker> as only that calls it. Wasn't that your concern?
20:25:24  <planetmaker> only when building a distribution bundle via setup we need to store it - as later we most probably won't have a hg repo anymore for reference?
20:25:36  <Alberth> oh, you changed that. Good
20:27:26  <Alberth> even during setup you may not have it, eg with 'hg archive'. or a version may get installed in a hg repo, and it promptly looses its version number.
20:27:55  <Alberth> but those are cases that should not happen, I guess
20:27:58  <planetmaker> well. yes. But then we don't know it
20:28:07  <planetmaker> we cannot be sure then about the version
20:28:53  <planetmaker> that's the whole point
20:28:59  <Alberth> if you first read the version file, and if it fails check the hg the latter case would still work
20:29:46  <planetmaker> that fails in all our cases where we use the repo
20:30:43  <Alberth> we never run setup, so you never get a version file
20:31:10  <planetmaker> hm, true
20:31:42  <planetmaker> but hg check should always be first
20:32:05  <planetmaker> we could test the version file, if that fails, though
20:32:20  <Alberth> like you do now :p
20:32:28  <planetmaker> :-)
20:32:53  <planetmaker> well, I don't quite understand why I should do the other way around.
20:36:15  <planetmaker> well. What's wrong with checking for the hg repo first?
20:36:29  <planetmaker> I honestly fail so far to understand that. Honest question
20:38:21  <planetmaker> so you say that we fail here, if we put it into another hg repo?
20:39:23  <Ammler> Alberth: you create source pack with "./ sdist", not hg archive
20:40:03  <Alberth> to run, you must have the files at the disk
20:42:28  <Ammler> if you check first for the file, then for the repo, how would it work with updates?
20:42:32  <Alberth> and why would you clone a repo for that?
20:42:52  <Ammler> does it?
20:43:36  <Alberth> (10:43:02 PM) Alberth: and why would you clone a repo for that? <-- was intended as part of my previous line
20:45:09  <planetmaker> Alberth: the question I think is: when and under what conditions will it be used
20:45:18  <planetmaker> a) by us to create a distribution bundle
20:45:22  <Alberth> well, it all comes down to how you consider version numbers, and how you assign and keep track of them
20:45:26  <planetmaker> b) by end users to install it locally
20:46:15  <planetmaker> maybe c) someone with a repo who just installs it.
20:46:37  <planetmaker> but sure, it comes down to exactly that what you say
20:46:39  <Alberth> d) by us without ever doing a propoer install
20:47:07  <planetmaker> so, what should happen?
20:47:15  <planetmaker> d): report the repo version in use
20:47:25  <planetmaker> c) report the repo version used
20:47:39  <planetmaker> b) report the version which was bundled
20:47:42  <Alberth> d) does not matter much imho
20:47:47  <planetmaker> a) report the repo version
20:48:31  <Ammler> IMO, source packages should be the whole hg repo anyway
20:48:32  <planetmaker> the critical part is b) as it means to maintain the version as we don't have access to the repo
20:49:07  <Ammler> then we would need to keep only one version :-)
20:49:26  <planetmaker> Ammler: a user should not require to have hg for using nml
20:49:31  <Alberth> Ammler: 423340 for hg_trunk of openttd :)
20:49:42  <Alberth> KB
20:50:49  <Alberth> hmm, -300000 KB for the HTML document :)
20:51:13  <Alberth> but still a lot of source if you just need 1 revision
20:51:21  <Ammler> hehe
20:51:54  <Ammler> well, the hg requirement is also a valid reason against
20:54:16  <Alberth> the difference is I think, that in your view, the version number is kept in the repo, while in my view, it becomes part of the source code when you make a release.
20:54:30  <Ammler> which it does
20:54:42  <Ammler> with version file
20:54:51  <Alberth> you check that into the repo?
20:55:03  <Alberth> when you tag eg 0.1 ?
20:55:05  <Ammler> no, but writes that, afaik
20:55:31  <Ammler> the release source is made with sdisk
20:55:34  <Ammler> t*
20:55:45  <Alberth> "becomes part of the source code" means literally that in my view
20:55:54  <planetmaker> Alberth: it's not checked in but written and distributed
20:56:40  <Alberth> I know
20:56:43  <planetmaker> it's implicitly in the repo by the repo having that exact tag - and thus any distributable version will get that file
20:57:17  <Alberth> *IF* you run setup from a repo dir
20:57:39  <Alberth> in my case, just checking out, or even 'archive' would be enough
20:58:24  <Alberth> but I don't know which is better, I just observe that is the fundamental difference in idea of versioning software
20:58:37  <planetmaker> Alberth: but it requires to add that on every release, to make a separate branch for them. All work which doesn't really help
20:58:52  <planetmaker> hg archive wouldn't be any official release
20:59:15  <planetmaker> and when I take e.g. OpenTTD's release source as tar archive... oh well. I can write anything into the version, too
20:59:31  <planetmaker> so 'unknown' is quite accurate
21:01:14  <planetmaker> IF you want to have a version inside the repo, I propose to add a kind of target version
21:01:17  <Alberth> well, if you don't do certain things, it will work, and as I don't know which is better, let's keep the current system
21:01:27  *** ODM has joined #openttdcoop.devzone
21:01:49  <planetmaker> which then could be reported back as 'maybe XXXX' in the cases we currently say 'unknown'
21:02:26  <planetmaker> then the target version only needs changing prior or after a release (however one wants to handle it)
21:04:10  <Alberth> please drop it, I have had enough of the subject. When it appears to be broken we can consider fixing it. Until that time, just keep the current system.
21:04:18  <Ammler> is it really not possible to silence that md5 warning?
21:04:29  <Ammler> I get that on every command
21:04:52  <planetmaker> sorry, I didn't mean to annoy you :-)
21:07:00  <Alberth> Ammler: what md5 warning, nml does not even have the word "md5" in its sources
21:07:18  <Ammler> salieri:~> nml2nfo --version
21:07:20  <Ammler> /usr/lib/python2.6/site-packages/ply/ DeprecationWarning: the md5 module is deprecated; use hashlib instead
21:07:21  <Ammler>   import re, types, sys, cStringIO, md5, os.path
21:07:23  <Ammler> r496 (b5a8abb57249)
21:07:32  <Alberth> oh,
21:08:01  <Alberth> what version of do you use?
21:08:40  <Alberth> __version__    = "3.3"   here, and I don't get warnings
21:08:56  <Alberth> line 62
21:09:21  <Ammler> installing python-ply-2.5-5.1
21:09:29  <Ammler> how do I get the yacc version?
21:09:44  <Alberth> open /usr/lib/python2.6/site-packages/ply/
21:09:47  <Ammler> <-- build script
21:10:35  <Ammler> __version__    = "2.5"
21:11:52  <Alberth> very old :)
21:12:10  <Rubidium> 2.5's in Debian stable
21:12:28  <Ammler> for me, it seems logical to use 2.5 with python 2.6
21:12:34  <Brot6> NewGRF Meta Language - Revision 497:b16329f37a7e: Codechange: Only write the version file when ca... (planetmaker) @
21:12:38  <Ammler> 3.3 sounds like python 3
21:13:06  <Alberth> 2.5 is the last one before 3.0, so it is not that old
21:13:46  <Alberth> ply 3.3 is python 3 compatible afaik, but it also works with python 2.x
21:14:12  <Ammler> windows seems to mix versions
21:14:36  <Ammler> or do you also use python 3 already?
21:14:49  <Alberth> ply 2.5 README is of 2008-05-28 in the .tar.gz
21:14:59  <Alberth> so a little over 2 years
21:15:40  <Alberth> no, still using python 2 (2.6)
21:15:51  <Alberth> and I expect that to do for a few years to come
21:16:07  <Ammler> I see no linux distro which uses python-ply >2.5
21:16:20  <Alberth> fedora 13 does :)
21:16:36  <Alberth> python-ply.noarch                                                      3.3-2.fc13                                       @fedora
21:17:00  <Alberth> python3-ply.noarch                                                     3.3-2.fc13                                       fedora
21:17:01  <Ammler> hmm, true
21:17:12  <Alberth> and they also have a python 3 version, apparently
21:17:13  <Ammler> but the upcomming suse 11.3 doesn't
21:17:13  <Rubidium>
21:17:16  <Webster> Title: “ply” package : Ubuntu (at
21:17:34  <Alberth> yeah, of course ubuntu does :)
21:17:58  <Ammler> then I might make my own package :-)
21:17:59  <Rubidium> but then the question is whether Ubuntu counts as a distribution or as Debian Unstable + extra issues
21:18:34  <Ammler> Rubidium: fedora does, I don't care about ubuntu :-P
21:18:34  * Alberth votes for the latter option
21:19:07  <Alberth> fedora is also quite bleeding edge, in general
21:20:01  <Alberth> but ply is just 2 python files
21:20:18  <Alberth> I am not even sure it comes with a
21:21:23  <Alberth> good night
21:21:43  <Rubidium> slaapze
21:22:51  <Alberth> you as well, although it will probably a few hours from now :)
21:22:59  *** Alberth has left #openttdcoop.devzone
21:25:42  *** ODM has quit IRC
21:51:32  *** Yexo has joined #openttdcoop.devzone
22:00:07  <Ammler> we have now ply-3.3 :-)
22:00:47  <planetmaker> yippieh :-)
22:03:07  <Yexo> so the only warning is now the unused random token?
22:03:59  <planetmaker> without testing on my part I assume so
22:08:14  <Ammler> deleting unwanted python-ply-2.5-5.1
22:08:16  <Ammler> installing python-ply-3.3-13.1
22:08:18  <Ammler> yes :-)
22:08:36  <Ammler> planetmaker: the whole silencing is now obsolete :-P
22:08:45  <planetmaker> yep
22:08:56  <planetmaker> good this way :-)
22:14:06  <planetmaker> have a good night
22:25:15  <Ammler>
22:41:31  *** Yexo has quit IRC
23:01:18  *** Seberoth has quit IRC
23:53:07  *** KenjiE20 has quit IRC

Powered by YARRSTE version: svn-trunk