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 <http://dev.openttdcoop.org/issues/929#change-2509> 05:56:03 <Webster> Latest update from devactivity: NFO Meta Language - Revision 155: Fix: precedence rules for the shift operators <http://dev.openttdcoop.org/projects/nml/repository/revisions/155> || NFO Meta Language - Revision 154: Fix: crop takes a single tuple as argument, not 4 ints <http://dev.openttdcoop.org/projects/nml/repository/revisions/154> || NFO Meta Language - Revision 153: Fix: switch-blocks were broken <http://dev.openttdcoop.org/projects/nml/repository/revisions/153> 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> http://code.google.com/p/pypp/ 08:14:34 <Webster> Title: pypp - Project Hosting on Google Code (at code.google.com) 08:15:10 <yorick> hmm http://www.makotemplates.org/ 08:15:11 <Webster> Title: welcome to Mako! (at www.makotemplates.org) 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 <http://dev.openttdcoop.org/issues/935#change-2510" target="_blank">http://dev.openttdcoop.org/issues/935#change-2510> || NFO Meta Language - Revision 156: Change: use optparse instead of getopt (yorick) (closes #935) <http://dev.openttdcoop.org/projects/nml/repository/revisions/156> || NFO Meta Language - Patch #935 (Closed): Switch to optparse <http://dev.openttdcoop.org/issues/935> 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... <http://dev.openttdcoop.org/issues/934#change-2512> || NFO Meta Language - Revision 158: Add: -c/-u commandline options to enable cropping / disable com... <http://dev.openttdcoop.org/projects/nml/repository/revisions/158> || NFO Meta Language - Revision 157: Add: -o/--grf/--nfo flags to set the output filenames <http://dev.openttdcoop.org/projects/nml/repository/revisions/157> || NFO Meta Language - Feature #933 (Closed): Add commandline flags to select between nfo/grf output <http://dev.openttdcoop.org/issues/933#change-2511> 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 <http://dev.openttdcoop.org/projects/nml/repository/revisions/160> || NFO Meta Language - Revision 159: Fix: actionD != action2 <http://dev.openttdcoop.org/projects/nml/repository/revisions/159> 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> https://build.opensuse.org/stage/package/show?package=openttd-devel-nml&project=home%3Aopenttdcoop <-- 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 output_grf.py 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 setup.py 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? http://devs.openttd.org/~yexo/no_pil.diff 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: setup.py 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> https://build.opensuse.org/stage/package/live_build_log?arch=i586&package=openttd-devel-nml&project=home%3Aopenttdcoop&repository=CentOS_5 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 setup.py 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 setup.py 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 setup.py 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... <http://dev.openttdcoop.org/projects/nml/repository/revisions/161> 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) - http://bundles.openttdcoop.org/fish/nightlies/ 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> http://bundles.openttdcoop.org/versions.txt <-- 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> http://pastebin.com/vQwkApZf 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 <http://dev.openttdcoop.org/projects/openttd-gui/repository/revisions/15187> || OpenTTD-GUI - Revision 15186: - Change: preliminary integration of the height map into the new ga... <http://dev.openttdcoop.org/projects/openttd-gui/repository/revisions/15186> 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 <http://dev.openttdcoop.org/projects/fish/repository/revisions/363> 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 <http://dev.openttdcoop.org/projects/fish/repository/revisions/364> 20:27:35 <PeterT> <Ammler> http://bundles.openttdcoop.org/versions.txt <-- 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