Log for #openttdcoop.devzone on 14th May 2010:
Times are UTC Toggle Colours
00:40:16  *** KenjiE20 has quit IRC
05:40:02  <Webster> Latest update from devactivity: NFO Meta Language - Bug #929 (Closed): allow fractional units for unit 'tons' for vehicles <>
05:56:03  <Webster> Latest update from devactivity: NFO Meta Language - Revision 155: Fix: precedence rules for the shift operators <> || NFO Meta Language - Revision 154: Fix: crop takes a single tuple as argument, not 4 ints <> || NFO Meta Language - Revision 153: Fix: switch-blocks were broken <>
06:33:37  *** ODM has joined #openttdcoop.devzone
07:28:57  *** yorick has joined #openttdcoop.devzone
07:33:14  <Yexo> m4 as preprocessor for nml, good idea or not?
08:02:59  <yorick> Yexo: I proposed that a while ago
08:03:03  <yorick> people need to have m4 then
08:03:07  <yorick> and not everyone dos
08:03:09  <yorick> does*
08:04:42  <planetmaker> I think if we can go without preprocessor for now, it'd be nice
08:04:59  <yorick> also, have you seen #935?
08:05:04  <Yexo> we could, but I think we really need something to include files
08:05:12  <Yexo> a preprocessor would be an easy way to achieve that
08:05:14  <Yexo> yes yorick
08:05:22  <planetmaker> that's not going to work natively?
08:05:30  <yorick> gnu autoconf requires m4
08:05:48  <Yexo> it could, but that would require me writing (a lot) of extra code to support it
08:06:05  <planetmaker> hm
08:06:50  <Yexo> autotools requires m4 indeed, so I think a lot of systems will already have it
08:07:05  <Yexo> but I'm not sure how standard it is in linux distributions
08:07:29  <yorick> standardized by POSIX
08:07:44  <yorick> "All UNIXes make the m4 macro processor available"
08:07:53  <yorick> it's included in mingw too
08:10:07  <planetmaker> Yexo: for what it's worth: both my linux workplace box as my mac do have it
08:10:28  <Yexo> and cygwin, and mingw apparently
08:10:30  <planetmaker> if writing native include is a long way it's probably worth it
08:10:54  <Yexo> writing a native include isn't easy
08:11:20  <Yexo> it requires either extensive hacking on ply or writing a second parsing step (in other words: implementing a preprocessor in python)
08:11:40  <planetmaker> I hoped it was just a few lines, but I didn't do research on it. So taking your word on it, given our limited time, m4 seems like a reasonable alternative then
08:11:55  <planetmaker> no need to re-invent a wheel
08:13:07  <planetmaker> but then one doesn't have to worry about that much anyway: then the pre-processor could just as well be left open to the makefile
08:13:34  <planetmaker> or do you want to call m4 pre-processing via nml?
08:13:44  * planetmaker ponders
08:13:55  <Yexo> that was my plan yes
08:14:33  <yorick>
08:14:34  <Webster> Title: pypp - Project Hosting on Google Code (at
08:15:10  <yorick> hmm
08:15:11  <Webster> Title: welcome to Mako! (at
08:15:26  <Yexo> I've seen pypp, don't really like it
08:15:30  <yorick> but these things compile into python
08:15:46  <yorick> doesn't django have templaty stuff
08:15:56  <Yexo> yes
08:16:04  <Yexo> but that's a bit overkill
08:16:20  <Yexo> m4 is something most systems already have, django would just be another requirement
08:20:39  <Ammler> if you need it for include, cpp can do that already...
08:21:17  <Yexo> I'll just leave it to the makefile for now
08:22:03  <planetmaker> honest question: why don't you like pypp, Yexo ?
08:22:26  <Yexo> the syntax looks too much html-ish
08:22:28  <planetmaker> it looks a bit funny with the include syntax...
08:22:32  <planetmaker> ok :-)
08:22:44  <Yexo> which is perfectly fine if it's for a webpage, but doesn't fit the style of nml
08:25:11  <Ammler> maybe, it isn't that hard to change the syntax?
08:27:16  <Yexo> pypp needs mako, so that would be 2 packages to install just for a preprocessor
08:29:08  <yorick> can't you just use mako?
08:29:15  <planetmaker> yeah... reading that. A bit fishy :-)
08:29:29  <Yexo> sure, but then again, why use mako over m4/cpp?
08:44:56  <Yexo> -o filename / --grf-output=filename to specify the filename of the grf output file, default is basename+.grf
08:45:13  <Yexo> --nfo-output=filename <- same for nfo output, default to None (don't write the nfo file at all)
08:45:28  <Yexo> and only read a single nml filename, not multiple files
08:46:01  <Yexo> reading multiple files is possible in theory, but specifying output names will become a problem, and running nml2nfo multiple times is no problem
08:46:15  <Yexo> any comments on that? a possible short name for --nfo-output?
08:51:42  <yorick> -o=nfo
08:51:55  <yorick> hmm no
08:52:28  <planetmaker> Yexo: just --nfo
08:52:30  <planetmaker> ?
08:52:46  <Yexo> good idea :)
08:52:54  <Yexo> same for grf then? --grf
08:54:17  <planetmaker> hm, yes. Why not?
08:55:15  <planetmaker> a bit unrelated: how difficult would be grf2nml? :-)
08:55:43  <Yexo> don't know, probably very hard
08:56:02  <planetmaker> ok, that's my perception, too.
08:56:20  <Yexo> nml2nfo is "easy" because you can make assumptions on the nfo that you write
08:56:40  <Yexo> the other way around you can't do that, you ahve to accept all nfo
08:56:48  <planetmaker> yeah
08:57:06  <Yexo> it might be worth a try though, even if it doesn't work completely
08:57:43  <planetmaker> hm... nml2nfo should be nml2grf :-)
08:57:52  <planetmaker> or not worth to change it?
08:58:09  <Yexo> doesn't matter much
08:58:14  <Yexo> but feel free to change it
08:58:34  <planetmaker> [10:58]	<Yexo>	doesn't matter much <-- that :-)
09:03:47  <Yexo> should it also write a grf file if --nfo was specified but no filename for the grf?
09:04:05  <planetmaker> yes
09:04:19  <yorick> Yexo: how about autodetect
09:04:45  <planetmaker> though I'm not sure how posix wants it
09:04:47  <yorick> like nml2nfo thing -o thing.grf or nm2nfo thing -o thing.nfo
09:05:44  <planetmaker> actually... I think posix then would want it to write to stdout
09:06:00  <Yexo> yes, but writing a grf to stdout isn't a good idea
09:06:16  <planetmaker> of course not :-)
09:06:39  *** Seberoth has joined #openttdcoop.devzone
09:07:01  <yorick> I think you should default to nfo on stdout, and otherwise to grf, because nfo is used for debugging mostly
09:07:03  <Webster> Latest update from devactivity: NFO Meta Language - Patch #935 (Closed): Switch to optparse <" target="_blank">> || NFO Meta Language - Revision 156: Change: use optparse instead of getopt (yorick) (closes #935) <> || NFO Meta Language - Patch #935 (Closed): Switch to optparse <>
09:07:09  <Yexo> gcc writes to a.out if you don't specify an output file
09:07:14  <planetmaker> then I guess the default behaviour of nml2grf file.nml should give you the grf. Always
09:07:32  <Yexo> but I think defaulting to basename.grf is the best solution
09:07:42  <planetmaker> yes
09:08:26  <Yexo> and --nfo=- / --nfo - to write the nfo to stdout?
09:08:52  <planetmaker> hm. Not quite sensible either IMHO
09:09:07  <planetmaker> apply the same scheme as for grf
09:09:11  <planetmaker> consistency :-)
09:09:42  <Yexo> and what exactly is that? should it also write a nfo file always?
09:09:52  <planetmaker> :-)
09:09:57  <planetmaker> No, only, if asked to
09:10:00  <Yexo> right now that is useful while debugging nml itself
09:10:03  <Yexo> exactly :)
09:10:51  <planetmaker> well... using --nfo as means to pipe it to stdout. Where would that be useful?
09:11:07  <planetmaker> do you want to pipe it somewhere?
09:11:08  <Yexo> piping the output to nforenum?
09:11:29  <planetmaker> well, then make it so
09:38:36  <Webster> Latest update from devactivity: NFO Meta Language - Feature #934 (Closed): Add commandline flags to enable/disable sprite croppin... <> || NFO Meta Language - Revision 158: Add: -c/-u commandline options to enable cropping / disable com... <> || NFO Meta Language - Revision 157: Add: -o/--grf/--nfo flags to set the output filenames <> || NFO Meta Language - Feature #933 (Closed): Add commandline flags to select between nfo/grf output <>
10:12:43  <planetmaker> what a big commit / push :-)
10:41:06  *** KenjiE20 has joined #openttdcoop.devzone
11:33:09  <Ammler> is nml also able to make a grf from nfo?
11:46:07  <planetmaker> I think it's not. nfo is an output format.
11:46:13  <planetmaker> But... maybe it could :-)
11:46:44  <planetmaker> but for now I wouldn't persue that further. It'd have one benefit, though: pngs in nfo
11:49:37  <Yexo> Ammler: no, it cna't read nfo files
12:09:40  <Ammler> well, the other benefit is that grfcodec doesn't work on newer linux anymore
12:09:55  <Ammler> or is it just suse?
13:03:49  <Hirundo> It seems I finally got PIL to *build*
13:19:49  <Yexo> Hirundo: does nml run without pil? (if you use --nfo=outputfile.nfo as commandline option)
13:20:49  <Hirundo> It failed for me, but I don't know what precise commandline arguments it gave
13:21:11  <Hirundo> just ./nml2nfo data.nml IIRC
13:27:56  <Hirundo> Yexo: Are lang files still placed in the lang/ dir?
13:28:15  <Yexo> yes, but they need to have a .lng extension now
13:34:56  <planetmaker> ogfxplus should work :-)
13:35:12  <planetmaker> and I need to add some fancy varaction2 stuff there, so that it gets a better example :-)
13:35:27  <planetmaker> I still have the example you made, Yexo, so it should be quite straight forward
13:55:02  <Yexo> should there be some special support for callback 36?
13:55:13  <Yexo> I'm mainly thing about using the same units as in the action0
14:02:53  <Webster> Latest update from devactivity: NFO Meta Language - Revision 160: Fix: and another fix in the same line <> || NFO Meta Language - Revision 159: Fix: actionD != action2 <>
14:19:54  <planetmaker> what was CB36?
14:24:51  <Yexo> vehicle property callback
14:28:26  <planetmaker> ok, I see that. What kind of special support does that CB need?
14:28:57  <Yexo> it doesn't "need" any support, but I think it would be nice to be able to use the units in that callback like in the property block
14:29:12  <planetmaker> ah. Yes, sure it would be :-)
14:29:29  <planetmaker> sounds like a bit of hack required, though
14:32:08  <Hirundo> How do callbacks currently work? Just a switch statement based on CB ID?
14:32:52  <Yexo> yes
14:34:17  <planetmaker> it's action2s, yes
14:43:18  <Hirundo> time to finish templates at last
14:43:49  <planetmaker> yeah :-)
14:54:08  <Hirundo> Yexo: What is 'basestring'?
14:54:55  <Yexo> superclass of both string and unicodestring
14:55:03  <Hirundo> ah, ok
14:55:30  <Yexo> all files are opened as utf-8, but that is not always possibel with stdin
14:55:36  <Yexo> so in that case we end up with ascii strings
14:58:09  <Ammler> Yexo: do you have any test scripts, so we could add check to nightly?
14:58:29  <planetmaker> Ammler, ogfxplus ;-)
14:58:54  <Yexo> nothing yet, it's one of the things that still has to be done
14:59:04  <Ammler> planetmaker: but how you know, the error isn't at your nml?
14:59:51  <Hirundo> I'd say we need an equivalent of regression.nut (NoAI)
14:59:52  <planetmaker> :-) I don't
15:00:02  <Ammler> I just wonder, how we should manage the nml package
15:00:05  <Ammler> for ogfx+
15:00:32  <Ammler> shall we build a nightly of nml every day, before we build the grf nightlies?
15:00:45  <Ammler> and use that for ogfx+?
15:00:46  <planetmaker> yes
15:01:05  <planetmaker> if it doesn't work with the latest nml, ogfxplus is at fault.
15:01:06  <Ammler> or would you like to trigger that automatically
15:01:18  <Ammler> manually*
15:01:21  <planetmaker> Even if it's due to the fact that nml changed - which can be expected in its current alpha stage
15:01:40  <planetmaker> doing it automagically is fine
15:01:54  <planetmaker> if automatic building fails it requires action
15:02:25  <Ammler> <-- as you see, nml builds fine now
15:02:32  <Ammler> except python 2.4
15:02:39  <Ammler> but I guess, we don't need that, do we?
15:03:08  <planetmaker> we need python 2.5+
15:03:10  <Yexo> supporting python 2.4 wouuld mean losing the shorthand if else syntax
15:04:11  <Ammler> yexo, it also means, it doesn't work on the LTS distros centos/rhel
15:04:37  <planetmaker> bad luck. But don't they have 2.6 or so?
15:04:44  <Ammler> 2.4
15:04:58  <planetmaker> by default, yes. But it's not like 2.5 is out since yesterday only
15:05:04  <Ammler> that was one of the reasons, I dropped centos again
15:07:50  <Hirundo> How can I disable the grf output? I only want the nfo since grf output requires existing image files
15:08:17  <Yexo> --nfo=outputfile.nfo
15:08:32  <Yexo> then it won't write the grf file, unless you also give a name for the grf file
15:10:13  <Hirundo> ./nml2nfo -d --nfo=data.nfo data.nml <- still getting stack traces to
15:10:21  <Ammler> well, you don't use LTS for clients usually, so it is fine
15:11:23  <Ammler> yexo, shouldn't the check for python version and exit, if there is no >=2.5 available?
15:11:32  <Yexo> yes :)
15:11:48  <planetmaker> Ammler, patch! :-)
15:11:56  <Ammler> hehe
15:12:06  <Yexo> Hirundo: does this solve it?
15:12:49  <Hirundo> PIL works by now, that is not the problem
15:13:12  <Yexo> what kind of traces do you get then?
15:13:23  <Hirundo> I think line 75 is a bit over-enthusiastic about outputting to grf
15:13:50  <Yexo> ah, yes
15:13:52  <Hirundo> an output grf is always assigned, unless you screw your argument list
15:14:00  <Yexo> should be "if not (opts.grf_filename or opts.nfo_filename):"
15:14:11  <Yexo> like line 65
15:15:03  <Yexo> Ammler: already checks the python version
15:15:13  <Hirundo> My errors relate to non-existent pcx files, and I'd like to keep it that way since it makes for easier testing if the sprites don't actually have to exist
15:15:37  <Ammler>
15:15:42  <Hirundo> shall I commit the fix?
15:15:50  <Yexo> go ahead
15:16:29  <Ammler> oh, maybe I need to update
15:17:42  <Ammler> he, indeed, you added the check one rev after I made the package :-P
15:20:14  <Ammler> how should a nightly of nml look?
15:20:22  <Ammler> (beside the rpm)
15:21:31  <Yexo> a tarball with the source
15:22:04  <planetmaker> :-) Nightlies of NML
15:22:05  <Ammler> hg archive -ttbz2 nml-r`hg id -n`.tar.bz2
15:22:16  <Ammler> is that ok?
15:22:21  <Yexo> Ammler: no, "python sdist"
15:22:56  <planetmaker> that creates a tarball?
15:22:56  *** Chris_Booth has joined #openttdcoop.devzone
15:22:59  <Yexo> but your code would probably work too :)
15:23:02  *** Chris_Booth has left #openttdcoop.devzone
15:23:32  <Yexo> it creates nml-0.1.tar.gz
15:23:45  <Yexo> versioning is another thing that needs doing
15:24:42  <planetmaker> hm, yes
15:25:12  <Ammler> hmm, you prefer gz?
15:25:38  <planetmaker> you don't want to offer plain tars for download, do you?
15:25:51  <Ammler> well, rpm prefers bz2
15:25:55  <Yexo> I don't really care if it's a plain tar or a .tar.gz
15:26:05  <Ammler> but gz works too
15:26:35  <planetmaker> bz2 is smaller, yes
15:27:20  <Yexo> Ammler: give --formats=tar,bztar as argument to to create both a plain tar and a bz2 tar
15:27:20  <Ammler> hmm, I guess, it could work with that setup sdist tool
15:27:30  <Ammler> I just need to replace the file name with revision
15:27:50  <Yexo> no, the script needs to get the python id somehow
15:28:08  <Ammler> well, until you have done that...
15:31:49  <Hirundo> Yexo: Am I correct in thinking that reduce_expr parameter unkown_id_fatal [sic] is only False for LayoutParams?
15:32:07  <Yexo> currently yes
15:33:43  <Hirundo> Why is that needed for layout parameters?
15:34:38  <Yexo> because the expression can be either an industrytile id or a numeric value (original tile)
15:35:00  <Yexo> and the industrytile id case can't be handled in reduce_expr
15:35:26  *** OwenS has joined #openttdcoop.devzone
15:35:28  <Webster> Latest update from devactivity: NFO Meta Language - Revision 161: Fix: Don't assign a default output grf if we are already output... <>
15:35:42  <Hirundo> Because they are not defined at that point?
15:36:15  <Yexo> no, because they need to be written as FF id-as-word
15:36:31  <Yexo> so you can't just resolve them to their id
15:37:23  <Yexo> but that code could use a lot of improvement probably
15:38:28  <Hirundo> Main thing I'm fixing currently is that reduce_expr should not modify the original expression, else templates fail
15:39:14  <Yexo> ah, ncie
15:42:33  <Ammler> what is MANIFEST? something like sources.list in openttd?
15:43:20  <Yexo> I haven't figured that out exactly, but something like that
16:18:23  <Brot6> fish: update from r360 to r362 done (1 errors) -
16:18:24  <Brot6> Following repos didn't need a update: 2cctrainset (r528), 32bpp-extra (r32), airportsplus (r48), bros (r10), comic-houses (r69), firs (r820), heqs (r318), nmts (r15), nutracks (r59), opengfx (r456), openmsx (r53), opensfx (r88), snowlinemod (r10), worldairlineset (ERROR r637)
16:20:14  *** welshdragon has quit IRC
16:23:28  *** Seberoth has quit IRC
16:23:33  *** Seberoth has joined #openttdcoop.devzone
17:05:48  *** PeterT has quit IRC
17:13:59  *** PeterT has joined #openttdcoop.devzone
17:27:18  *** welshdragon has joined #openttdcoop.devzone
17:44:58  *** PeterT has quit IRC
17:48:53  *** PeterT has joined #openttdcoop.devzone
18:09:26  *** ODM has quit IRC
18:18:43  *** OwenS has quit IRC
19:01:01  <Ammler> <-- is this useable also for the projects on DevZone?
19:01:38  <Ammler> the script I use to write the file is quite easy
19:02:42  <Ammler>
19:09:01  <Webster> Latest update from devactivity: OpenTTD-GUI - Revision 15187: - Feature: Add a WWT_TAB widget and use that in the newgame dialgue <> || OpenTTD-GUI - Revision 15186: - Change: preliminary integration of the height map into the new ga... <>
19:10:57  <planetmaker> it's definitely usable, I think
19:11:35  <planetmaker> the question is where it is needed for other projects other than opengfx, opensfx, openmsx and openttd projects
19:21:29  <Ammler> well, I add that to the script, so it automatically there, does it hurt?
19:21:39  <Ammler> is*
19:39:22  <Webster> Latest update from devactivity: FISH - Revision 363: Feature: loading sprites (empty hold) for Large Coaster <>
19:48:53  <planetmaker> it doesn't hurt at all IMHO
19:49:30  <Ammler> I meant, it will add a version row of all projects compiled there
20:26:23  <Webster> Latest update from devactivity: FISH - Revision 364: Feature: loading sprites (empty cargo hold) for Medium Coaster <>
20:27:35  <PeterT> <Ammler> <-- is this useable also for the projects on DevZone? <-- if not on the devzone, it could be useful to Zuu for his ottdau
20:27:36  <PeterT> see #openttd
20:37:07  <planetmaker> andythenorth: instead of uploading the grfs to tt-forums you should rather link the nightly folder of the compile farm
20:37:33  <andythenorth> yes indeedy
21:32:10  *** yorick has quit IRC
22:50:12  *** Seberoth has quit IRC

Powered by YARRSTE version: svn-trunk