Times are UTC Toggle Colours
03:45:06 <Brot6> Redmine HG Patch Queue - Revision 130:ad8aee1edf3b: add test for hg-changeset-order.patch (Yuya Nishihara) @ http://dev.openttdcoop.org/projects/redmine-patches/repository/revisions/ad8aee1edf3b 03:45:06 <Brot6> Redmine HG Patch Queue - Revision 131:85b165edb608: more obvious test for hg-changeset-order.patch (Yuya Nishihara) @ http://dev.openttdcoop.org/projects/redmine-patches/repository/revisions/85b165edb608 06:48:28 *** Alberth has joined #openttdcoop.devzone 07:42:36 *** ODM has joined #openttdcoop.devzone 08:06:51 <Brot6> 2cc train set - Bug #1150 (New): too wide sprites in purchase list (planetmaker) @ http://dev.openttdcoop.org/issues/1150 08:14:50 <Brot6> 2cc train set - Bug #1150: too wide sprites in purchase list (planetmaker) @ http://dev.openttdcoop.org/issues/1150#change-2951 08:18:56 *** thgergo has joined #openttdcoop.devzone 08:29:25 *** Seberoth has joined #openttdcoop.devzone 08:50:43 <Brot6> 2cc train set - Bug #1150: too wide sprites in purchase list (DJNekkid) @ http://dev.openttdcoop.org/issues/1150#change-2952 09:00:57 <Brot6> 2cc train set - Bug #1150: too wide sprites in purchase list (Ammler) @ http://dev.openttdcoop.org/issues/1150#change-2953 09:03:02 <Brot6> 2cc train set - Bug #1150: too wide sprites in purchase list (Rubidium) @ http://dev.openttdcoop.org/issues/1150#change-2954 09:07:03 <Brot6> 2cc train set - Bug #1150: too wide sprites in purchase list (planetmaker) @ http://dev.openttdcoop.org/issues/1150#change-2955 10:03:12 *** Yexo has joined #openttdcoop.devzone 10:35:14 <Ammler> [11:46] <eis_os> [21:06:33] We should all switch to OTTD and fork it <-- hehe 10:37:36 *** Seberoth has quit IRC 10:46:50 <planetmaker> he. where's that from? 10:47:08 <Rubidium> my guess: #tycoon 10:48:48 <Rubidium> but... that coming from oskar... interesting 10:49:11 <planetmaker> well... probably depends upon the context :-) 10:49:41 <Ammler> well, it might be out of context :-) 10:50:04 <Ammler> <eis_os> [21:06:02] Somehow I think ttdpatch versions collection system is broken, sometimes fragments are double searched 10:50:24 <Rubidium> planetmaker: no matter what the context is; he couldn't stand OpenTTD because he doesn't consider it legal for him to work on it 10:50:50 <Ammler> well, and isn't the fun of TTDP to patch a binary? 10:51:03 <Ammler> they could make a OTTDPatch 10:52:11 <Rubidium> Ammler: but that'd likely only work on one version 10:52:29 <Rubidium> or they need an OpenTTD versions collection system 10:52:34 <Ammler> lol 10:56:52 <planetmaker> http://irclogs.qmsk.net/channels/tycoon/date/2010-07-25?page=3 10:56:54 <Webster> Title: irclogs.qmsk.net" target="_blank">irclogs.qmsk.net :: OFTC - #tycoon (at irclogs.qmsk.net" target="_blank">irclogs.qmsk.net) 10:59:45 <Ammler> planetmaker: did you get a copy of "Kündigungsbestätigung Ihres Vertrages: 843217"? 11:00:35 <Ammler> we have now a month do buy a new one :-) 11:00:54 <Ammler> last time, we needed 2 months to migrate 11:02:27 <Rubidium> that's a long time 11:03:46 <Rubidium> even we were done within a month including building a compile farm from scratch, rebuilding svn history, creating git/hg "backups" and such 11:06:54 *** Seberoth has joined #openttdcoop.devzone 11:11:54 <planetmaker> Ammler, I did get a copy, yes 11:12:08 <planetmaker> at least via e-mail 11:13:09 <Ammler> I am quite suprised how fast the snail mail ist 11:13:38 <planetmaker> Ammler, and as stated before: I'm fine with the discussed solution(s). Probably it makes sense that you remain legally the (primary) owner. So ... buy the new one at your discretion. 11:13:47 <planetmaker> I think the options and the preference is clear 11:14:00 <planetmaker> And if Osai wants to share, fine :-) If not, also ok 11:14:02 <Ammler> yeah, we "safe" 15% :-) 11:14:05 <planetmaker> My opinion :-) 11:15:52 <Ammler> maybe we should setup a donating possibility 11:16:55 <Ammler> then I might setup xen 11:24:56 <planetmaker> Wasn't the plan to run a few virtual servers anyway? 11:27:11 *** FooBar has joined #openttdcoop.devzone 11:38:04 <Brot6> grfcodec: compile of r178 failed - http://bundles.openttdcoop.org/grfcodec/nightlies/ERROR/r178 11:38:07 <Brot6> heqs: compile of r371 failed - http://bundles.openttdcoop.org/heqs/nightlies/ERROR/r371 11:38:13 <Brot6> nforenum: compile of r406 failed - http://bundles.openttdcoop.org/nforenum/nightlies/ERROR/r406 11:38:20 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r573), 32bpp-extra (r36), airportsplus (r52), comic-houses (r71), firs (r1074), fish (r386), newgrf_makefile (r124), nml (r563), nutracks (r86), ogfxplus (r40), opengfx (r469), openmsx (r91), opensfx (r97), snowlinemod (r15), swedishrails (r140), worldairlinersset (r659) 11:38:29 <Brot6> 32bpp-extra: compile of r36 failed - http://bundles.openttdcoop.org/32bpp-extra/nightlies/ERROR/r36 11:38:44 <Ammler> ok, now I am confused :-) 11:38:51 <planetmaker> ? 11:39:50 <andythenorth> Ammler: planetmaker: I said before I was happy to donate money for a server. Possibly quite a bit of money...(meaning '3 figures' if necessary). It means I can't buy so much Lego though :O 11:41:44 <planetmaker> With the new server that shall be easier possible, I think :-) 11:42:01 * planetmaker wonders whether to install a devzone donation account :-) 11:42:46 <Ammler> I have already CHF 100 for start :-P 11:42:55 <planetmaker> :-) 11:42:59 <Rubidium> planetmaker: it probably won't hurt to mention donations, and if you somewhat need donations you can add something to the frontpage 11:44:24 <planetmaker> yep. I think that's something we'll indeed do when the new server is running 11:44:35 <planetmaker> we had discussed it before... and it's tempting :-) 11:48:20 *** welshdragon has joined #openttdcoop.devzone 11:50:42 *** ^Spike^ has joined #openttdcoop.devzone 11:50:53 *** ^Spike^ has left #openttdcoop.devzone 11:52:28 *** Yexo has quit IRC 11:53:46 <Brot6> grfcodec: compile of r178 failed - http://bundles.openttdcoop.org/grfcodec/nightlies/ERROR/r178 11:55:23 <Rubidium> booh 11:55:41 <Brot6> heqs: update from r364 to r371 done - http://bundles.openttdcoop.org/heqs/nightlies/r371 11:55:46 <Brot6> nforenum: compile of r406 failed - http://bundles.openttdcoop.org/nforenum/nightlies/ERROR/r406 11:55:55 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r573), 32bpp-extra (r36), airportsplus (r52), comic-houses (r71), firs (r1074), fish (r386), newgrf_makefile (r124), nml (r563), nutracks (r86), ogfxplus (r40), opengfx (r469), openmsx (r91), opensfx (r97), snowlinemod (r15), swedishrails (r140), worldairlinersset (r659) 11:56:08 <Ammler> at least, it works again :-) 11:56:19 <Ammler> now I need to fix the package configs 11:57:50 <Brot6> 32bpp-extra: rebuild of r36 done (3584 errors) - http://bundles.openttdcoop.org/32bpp-extra/nightlies/r36/log 12:03:27 <Brot6> 32bpp-extra: rebuild of r36 done (3584 errors) (Diffsize: 341) - http://bundles.openttdcoop.org/32bpp-extra/nightlies/r36/log 12:12:09 <Brot6> 2cc train set - Bug #1150: too wide sprites in purchase list (DJNekkid) @ http://dev.openttdcoop.org/issues/1150#change-2956 12:16:30 <ODM> 3500 errors, nice 12:19:01 <Ammler> that is no renum 12:35:09 <Brot6> nforenum: update from r405 to r406 done - http://bundles.openttdcoop.org/nforenum/nightlies/r406 12:35:21 <Ammler> now that was too fast? 12:41:44 <Brot6> grfcodec: update from r177 to r178 done - http://bundles.openttdcoop.org/grfcodec/nightlies/r178 12:46:00 <Brot6> #openttdcoop - Revision 107:53bdda937dc0: Fix: replace -j1 with %{?_smp_mflags}, so it is configu... (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/53bdda937dc0 12:51:14 <Rubidium> it's not like that will significantly speed up things 12:52:16 <Rubidium> running two builders next to eachother will help much more 12:54:55 <Ammler> I have it at 1 anyway 12:55:12 <Ammler> just that we use the macro on the scripts 12:55:29 <Ammler> specs* 13:01:21 <Brot6> nforenum: rebuild of r406 done (Diffsize: 14) - http://bundles.openttdcoop.org/nforenum/nightlies/r406/log 13:04:56 *** PeterT has left #openttdcoop.devzone 13:09:40 <Brot6> 2cctrainset: rebuild of r573 done (1 errors) - http://bundles.openttdcoop.org/2cctrainset/nightlies/r573/log 13:14:16 <Brot6> 32bpp-extra: rebuild of r36 done (3584 errors) (Diffsize: 341) - http://bundles.openttdcoop.org/32bpp-extra/nightlies/r36/log 13:16:34 <Brot6> airportsplus: rebuild of r52 done - http://bundles.openttdcoop.org/airportsplus/nightlies/r52/log 13:18:49 <Brot6> comic-houses: rebuild of r71 done (3 errors) - http://bundles.openttdcoop.org/comic-houses/nightlies/r71/log 13:22:40 <Brot6> firs: rebuild of r1074 done (1 errors) - http://bundles.openttdcoop.org/firs/nightlies/r1074/log 13:26:32 <Ammler> hmm, 4mins for one build? 13:26:46 <Brot6> fish: rebuild of r386 done (1 errors) - http://bundles.openttdcoop.org/fish/nightlies/r386/log 13:30:33 <Brot6> heqs: rebuild of r371 done - http://bundles.openttdcoop.org/heqs/nightlies/r371/log 13:34:12 <Brot6> newgrf_makefile: rebuild of r124 done - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/r124/log 13:35:38 <Brot6> nutracks: compile of r86 failed - http://bundles.openttdcoop.org/nutracks/nightlies/ERROR/r86 13:36:01 <Ammler> ups, that was me :-) 13:39:48 <Brot6> opengfx: rebuild of r469 done - http://bundles.openttdcoop.org/opengfx/nightlies/r469/log 13:42:13 <Rubidium> planetmaker: bravo for helping the spammer :) 13:43:59 <Rubidium> argh... must not waste time on the forum right now... 13:44:12 <Brot6> snowlinemod: rebuild of r15 done - http://bundles.openttdcoop.org/snowlinemod/nightlies/r15/log 13:44:31 <planetmaker> hm? 13:44:43 <planetmaker> did I answer a spammer? :-( 13:44:51 <Ammler> I should not announce successful rebuilds 13:45:40 <Rubidium> planetmaker: that billgates.m88 "person" 13:45:59 <planetmaker> hm... might be true. Posting deleted 13:45:59 <andythenorth> Ammler: I could do without the highlights :) 13:46:17 <Brot6> #openttdcoop - Revision 108:e528e7011eea: [Compiler] Use the rebuild with FORCE (-f) (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/e528e7011eea 13:46:19 <planetmaker> andythenorth, it's usually once a day 13:46:31 <Ammler> it was dead for 2 days now 13:46:36 <planetmaker> otherwise don't highlight on every project of yours 13:46:36 <Ammler> or 3? 13:46:58 <Rubidium> ignore brot6? 13:47:18 <planetmaker> :-D 13:48:39 <Brot6> worldairlinersset: rebuild of r659 done - http://bundles.openttdcoop.org/worldairlinersset/nightlies/r659/log 13:58:29 *** welshdragon has quit IRC 14:15:48 *** welshdragon has joined #openttdcoop.devzone 14:45:17 <Brot6> #openttdcoop - Revision 109:637480bf0bc4: [Compiler] Silence rebuild output a bit more... (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/637480bf0bc4 15:53:27 <Brot6> #openttdcoop NewGRF package - Revision 243:51d4692cdae9: Doc: wrap readme at 80, include info abo... (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/51d4692cdae9 15:54:49 <Brot6> #openttdcoop NewGRF package - Revision 244:f8cbfa9be621: Remove versioned files from the repo, th... (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/f8cbfa9be621 16:00:29 <Ammler> hmm, now I miss network support 16:16:11 *** Yexo has joined #openttdcoop.devzone 16:18:17 <Ammler> Rubidium: you don't provide md5sums for the bananas zips, do you? 16:18:31 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r573), 32bpp-extra (r36), airportsplus (r52), comic-houses (r71), firs (r1074), fish (r386), grfcodec (r178), heqs (r371), newgrf_makefile (r124), nforenum (r406), nml (r563), nutracks (r86), ogfxplus (r40), opengfx (r469), openmsx (r91), opensfx (r97), snowlinemod (r15), swedishrails (r140), worldairlinersset (r659) 16:21:03 <Rubidium> nope, just of the important content 16:21:46 <Brot6> nutracks: rebuild of r86 done (164 errors) (Diffsize: 243) - http://bundles.openttdcoop.org/nutracks/nightlies/r86/log 16:23:27 <Ammler> hmm, maybe we need a diff of the diff :-) 16:32:32 <Alberth> meta-diff ! 16:32:48 <Alberth> those are quite non-readable :) 16:33:56 <planetmaker> quite so 16:35:23 <Alberth> you also get them when committing mq patches 16:42:25 <Ammler> well, it's not about reading, more about _if_ it changes at all 16:42:52 <Ammler> redmine has a nice diff viewer, imo 16:44:04 <Ammler> like http://dev.openttdcoop.org/projects/clientpatches/repository/revisions/4a41ee62ae81/diff/FilterSignList.diff 16:49:31 *** frosch123 has joined #openttdcoop.devzone 17:25:51 <frosch123> FooBar: fs#3979 can be closed? or is there something left? 17:26:22 <FooBar> if the weird behaviour with faulty code is correct, then it can be closed 17:26:39 <FooBar> if one would read the newgrf spec, then everything works as it should 17:27:08 <FooBar> also an option to enable a railtype without vehicles available for it would be nice :P 17:27:48 <frosch123> not my building site :) 17:29:56 <FooBar> :) 17:34:06 <frosch123> FooBar: property 12 of feature 10 is "default station graphics" :) 17:34:13 <frosch123> so, yes, it works correctly :) 17:55:23 <Alberth> is there something in nml to hook the snowline table in? 17:55:46 <Alberth> I have made some new syntax, but it does not seem to fit action0 stuff already there 17:55:59 <Alberth> but I may be missing some thing 17:58:00 <Yexo> Alberth: see railtype table / cargotable, it needs custom code 17:58:10 <planetmaker> hm... :-) 17:58:26 * planetmaker should then re-write the mod-snowline in NML 17:58:31 <planetmaker> much more elegant supposedly 17:58:50 <FooBar> frosch123: ah, I see. Well, never mind then :P 18:02:44 <Hirundo> Alberth: What is your new syntax? 18:04:08 <Alberth> http://pastebin.org/420636 but it must become part of action0, I guess 18:06:58 <Hirundo> + """snowlinedate : DATEHEIGHT LPAREN expression expression COMMA expression RPAREN <- missing COMMA here? 18:07:51 <Alberth> no 18:08:12 <andythenorth> evning 18:08:14 <Hirundo> Does "expression expression" work with the parser? 18:08:15 <andythenorth> evening even 18:08:41 <Alberth> http://pastebin.org/420641 18:09:06 <Alberth> ply does not complain 18:10:06 <Hirundo> does it parse "1 - 1 - 1" as "(1 - 1), 1" or "1, (-1 - 1)" ? 18:10:46 <Yexo> not entirely sure, but I think "(1 - 1), -1" 18:11:00 <Yexo> maybe you could use "expression ID" here instead? 18:11:11 <Alberth> I was thinking that too 18:11:27 <Yexo> or even "NUMBER ID" ? 18:11:31 <Yexo> not sure if it has to be constant 18:12:19 <Alberth> I must make a 12*32 byte table, so yeah, I need an integer constant number :) 18:12:40 <Hirundo> What's so bad about action6? 18:13:09 <Alberth> are you talking about snowlines? 18:13:18 <Hirundo> yes 18:13:40 <Hirundo> As long as you don't have to write them by hand, of course 18:14:10 <Yexo> Alberth: does the code allow expressions as snowline height or only constant numbers? 18:14:32 <Yexo> is "date_height(1 feb, param[3])," valid for example? 18:14:33 <Alberth> it needs a height for every day of the year 18:15:13 <Alberth> if you want to interpolate heights, it must be done at compile time, I think 18:15:44 <Yexo> does the snowline table have to be one table or can it be written in small parts? 18:15:56 <frosch123> one table :( 18:16:03 <Alberth> if you want the same height for a (part of the) year, it is easier 18:16:49 <Alberth> http://wiki.ttdpatch.net/tiki-index.php?page=Action0GeneralVariables#Snow_line_height_table_10_ 18:16:59 <Alberth> one big table of 12*32 bytes indeed 18:17:19 <Alberth> where some of the entries are not used 18:18:09 <Alberth> the simplest I think would be to specify a few heights at dates in the year, and the program interpolates between them 18:18:16 <Hirundo> I agree 18:18:25 <Yexo> so if you want to compute intermediate values you have to do it at compile time 18:18:34 <Alberth> where 'interpolate' can be either the same height as the day before, or some linear value in between 18:19:09 <Yexo> it's easy to implement it via expressions (as opposed to constant numbers) if you can just specify a few days in the year where it will change and no interpolation is done 18:19:12 <Alberth> practically, yes 18:19:46 <Yexo> ie with "same as day before" expressions are ok, with "some value in between" they are not 18:20:02 * Alberth agrees 18:20:40 <Hirundo> In any case, I would avoid encoding too much in the parser, as each time a word is 'reserved' and cannot be used anywhere else 18:20:40 <Yexo> I'd like to have at least "same as day before with expressions", the other option I don't care as much about 18:20:56 <Alberth> I care about the other one :) 18:21:21 <Alberth> but I don't understand yet where to put things 18:21:29 <Alberth> in the code 18:21:31 <Hirundo> I tend to agree with Yexo, the amount of interpolation steps is relatively small so it can be done by hand 18:21:43 <planetmaker> [20:15] <Alberth> if you want to interpolate heights, it must be done at compile time, I think <-- yes, correct 18:22:15 <planetmaker> quite a pain. And the reason I change it in the snowlinemod thing only every 14 days. 18:22:24 <planetmaker> But of course via action6 one can change the table run-time 18:22:36 <planetmaker> which is... "interesting" 18:23:02 <Alberth> I don't see the value, but then again I am not a newgrf coder :) 18:23:26 <Alberth> but if yexo wants it, he gets it :) 18:23:30 <planetmaker> [20:21] <Hirundo> I tend to agree with Yexo, the amount of interpolation steps is relatively small so it can be done by hand <-- small?! 18:23:48 <planetmaker> try to make sinoidal snowline height with a configurable height limit. 18:23:53 <planetmaker> A BIG pain. 18:23:57 <Yexo> Alberth: moving snowline height customizable by a parameter 18:24:01 <planetmaker> or any variation 18:24:18 <Yexo> for example in winter it's always 4 tiles heigher then during summber, but the base height depends on some parameter 18:24:20 <planetmaker> if it shall be sufficiently small-scale 18:24:32 <Alberth> Yexo: ok, sounds like fun 18:24:55 <planetmaker> Yexo: yes... that's what usual newgrf want. Though the offset must be able to be negative (Southern hemisphere) 18:25:09 <Hirundo> http://pastebin.org/420666 18:25:48 <Alberth> fine by me :) 18:26:00 <Hirundo> ^^ a replacement for date() for months/days only would be nice, though 18:26:40 <planetmaker> looks like a good approach, Hirundo 18:26:45 <Alberth> any hints on how to connect this in the code? 18:27:04 <Yexo> make it "expression : expression SEMICOLON" 18:27:30 <Yexo> then introduce a new compiletime function "day_in_month" (probably with another name) that accepts two parameters and returns one number (index in snowline table) 18:31:06 <Hirundo> Add a container in ast.py and some code generation in action0.py and you're done :) 18:31:35 <Alberth> ok :) 18:31:46 <Alberth> lots of stuff to discover 18:32:09 <Hirundo> While we're at it, though, I feel the code could use some more structure wrt. what is handled were (ast/actions) 18:32:10 <planetmaker> "Entdecke die Möglichkeiten" 18:32:41 <Hirundo> Sometimes expressions are reduced in the ast, sometimes in the action generating code, sometimes not at all 18:39:03 <Alberth> is there even a standard way of doing things? ie is there always an ast node or not? where is it defined (all in ast seems like a bad idea to me) 18:40:49 <Hirundo> There is none, that's the issue 18:45:52 <Alberth> I have little insight in how the code works everywhere, but if you have an idea, why not define something? then we can discuss it 18:47:04 <Alberth> although I'd expect that I have little to add, other than general python things, like less dense code, and more documentation and comments 18:47:43 <Alberth> and perhaps a line length limit (although we seem to do something sane-ish already) 18:54:39 <Yexo> wrt to reduce I'd say we either move all calls to ast.py or all to the action code 18:54:43 <Yexo> not sure whichever is better 18:57:33 <Yexo> ie is there always an ast node or not? <- yes, the ast is the internal representation of the nml input file, so everything in the input should be defined in some ast node 19:01:09 <Alberth> but putting everythting in 'ast.py' just makes that file explode imho 19:01:50 <Alberth> perhaps have a file for each primitive (or group of primitives or so)? 19:01:55 <Yexo> we could split up ast.py by creating a subdirectory ast/ and making multiple files there 19:01:59 <Yexo> grouping related things 19:02:05 <Yexo> so yes :) 19:03:14 <Alberth> structure may also improve if we have a few base classes, I think 19:03:33 <Alberth> also a good opportunity to move common stuff upwards 19:03:54 <Yexo> I'm not sure if there is much common stuff in ast.py 19:04:37 <Alberth> what about the unique id's that we have? 19:04:59 <Yexo> those are handled mostly in the action/*.py files 19:05:04 <Alberth> now they are tightly connected to the actionX 19:05:38 <Alberth> but perhaps we could have a common interface and/or a seperate manager for it? 19:05:57 <Yexo> if that's possible, yes 19:06:18 <Alberth> an interface should be possible at least, I think 19:06:22 <Yexo> hard to say if that would actually be an improvement without coding it first 19:06:25 <Hirundo> The fruits of my thought processes are hanging here: http://pastebin.org/420717 19:06:32 * Hirundo reads back the discussion 19:07:22 <Hirundo> It seems I had the same idea about IDs, they need some interface :) 19:08:21 <Alberth> it should also be able to handle grf and nfo in some way? 19:08:39 <Yexo> yes 19:08:41 <Alberth> more steps in the processing is good 19:09:14 <Yexo> we have two types of data structures: "AST" (internal representation of NML) and "action list" (internal representation of nfo/grf) 19:09:26 <Yexo> currently we only have code to do "ast" -> "action list" conversion 19:10:27 <Alberth> that's 'processing' at line 22, isn't it? 19:10:32 <Hirundo> Doing the conversion backwards is mostly easy, as long as you ignore action6 19:11:03 <Yexo> yes (but it'd be good to support at least some of action6) 19:11:17 <Yexo> Alberth: I don't get your question 19:11:44 <Yexo> oh, sorry, missed your pastebin link 19:11:55 <Alberth> I was making a connection between your 'currently we only have code to do "ast" -> "action list" conversion' and the pastebin 19:13:12 <Yexo> yes, it'd indeed "Processing" 19:13:46 <Alberth> for the reverse, the action list should be processed and generate an ast again 19:13:57 <Yexo> yes 19:14:07 <Alberth> can you decide the ast based on a single action? 19:14:15 <Yexo> no 19:14:28 <Yexo> that is, you can for action0 / action2 for example 19:14:32 <Alberth> so we need some smart code there 19:14:38 <Yexo> but not for conditionals / loops / action6 19:14:54 <Alberth> a global function? 19:15:54 <Alberth> can we also define how and what to document in the core structures, ie the actions and the ast nodes? 19:16:04 <Yexo> I think the key is to reduce the actionlist to as small parts as possible (preferable single action0 / action2 / etc.) and process those 19:16:14 <Hirundo> It largely depends on the naivety of the actions -> ast conversion. If you want to recognize and parse NML's own output without excessive code bloat, that's hard 19:16:16 <Yexo> yes, we should do that 19:16:34 <Yexo> Hirundo: NML's own output is hard to read back 19:16:48 <Yexo> but it'd be nice to be able to read simple vehicle newgrfs for example and create nml from those 19:18:01 <Hirundo> Even action6 is pretty doable I think, if you ignore the more 'insane' usages of it 19:18:28 <Alberth> I'd prefer a warning or error then, but yes :) 19:18:32 <Hirundo> insane = changing bytes that have a semantic instead of numerical meaning 19:18:58 <Yexo> agreed, action6 support for "numerical" values is more then enough 19:19:33 <Yexo> and yes, "error" instead of "ignoring" (but you might've ment that already) 19:20:31 <Hirundo> Sort of, I wasn't being too precise 19:22:29 <Yexo> http://devs.openttd.org/~yexo/nml/move_ast.diff move code from nml/ast.py to nml/ast/*.py 19:22:32 <Yexo> good idea or not? 19:23:57 <Alberth> +1 19:23:57 <planetmaker> uh... some major re-work in progress, eh? 19:24:14 <Yexo> not really major re-work 19:24:17 <Yexo> just moving code around 19:24:18 <Hirundo> agreed, don't forget to check the parser though 19:24:20 <Alberth> we haven't even started :) 19:24:38 <Yexo> oh, the discussion above may be classified as "major re-work" :p 19:25:00 <planetmaker> :-P 19:25:15 <planetmaker> possibly there should be more regression tests before... 19:25:50 <planetmaker> hm... actually I'd like to see the missing features also implemented... but then... 19:25:56 <planetmaker> It's holiday time :-) 19:28:01 <FooBar> planetmaker: why CC-BY and not CC-BY-SA? (on shanghai maglev track subject) 19:28:03 <Alberth> at work I have been using epydoc (http://epydoc.sourceforge.net/) for documenting. 19:28:03 <Alberth> example: http://twistedmatrix.com/trac/browser/tags/releases/twisted-10.1.0/twisted/application/app.py#L276 19:28:03 <Alberth> while the site claims that it is active, the last commit was 17 months ago. However, pydoctor seems to be an alternative. 19:28:03 <Alberth> Note that I care little for the nice html output. In my experience, reading from the source code is just as easy. 19:28:04 <Webster> Title: Epydoc (at epydoc.sourceforge.net) 19:28:08 <Webster> Title: /tags/releases/twisted-10.1.0/twisted/application/app.py – Twisted (at twistedmatrix.com) 19:28:53 <Alberth> of course there is also doxygen, but the last time I looked, it did not do python doc strings 19:29:13 <planetmaker> FooBar: if you like CC-SA as well. 19:29:39 <FooBar> well, thing with CC-BY (I believe) is that it's relicensable by anyone 19:29:56 <FooBar> so someone can take your work and make it closed-source. The SA-bit prevents that 19:30:03 <planetmaker> yes, so what. Attribution is important. And that cannot be un-done by any license change 19:30:29 <planetmaker> the -SA might not be compatible with GPL 19:30:43 <planetmaker> I'm not sure 19:31:02 <FooBar> none of the CC-licenses are compatible with GPL? 19:31:24 <planetmaker> CC-BY certainly is. 19:31:40 <planetmaker> one can use any CC-BY stuff in a GPL project 19:31:49 <FooBar> interesting... 19:31:56 <planetmaker> attribution. 19:32:02 <planetmaker> that's what GPL also requires 19:32:10 <planetmaker> (plus additional things) 19:32:41 <planetmaker> vice versa is NOT possible, though 19:33:07 <FooBar> hmmm, there's advantages and disadvantages to CC-BY then :P 19:33:31 <planetmaker> the difference basically is: need to lay open the source 19:33:32 <FooBar> as for GPL, it's "once GPL, always GPL" I believe 19:33:47 <planetmaker> basically yes 19:33:56 <Alberth> you could have a double license 19:34:33 <planetmaker> of course 19:34:41 <planetmaker> http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License <-- that's an interesting one, too :-) 19:34:42 <Webster> Title: Common Development and Distribution License - Wikipedia, the free encyclopedia (at en.wikipedia.org) 19:34:42 <Alberth> or theoretically, make a new release with another license 19:36:08 <planetmaker> dual-licensing is no problem 19:37:26 <planetmaker> but I'll keep gpl for now. The whole of OpenTTD is, so it's good to keep it compatible with that (which is IMHO the best argument) 19:37:39 <Alberth> Hirundo: perhaps move your ideas to the wiki? 19:38:27 <Hirundo> which wiki? 19:41:02 <Alberth> https://dev.openttdcoop.org/projects/nml/wiki this one? 19:41:49 <planetmaker> :-) 19:41:57 <planetmaker> or create a document for it 19:42:25 <planetmaker> https://dev.openttdcoop.org/projects/nml/documents 19:42:31 <planetmaker> whatever seems more appropriate 19:42:59 <planetmaker> documents have the 'user' and 'technical' documentation section 19:43:03 <Ammler> then you might better make a docs in the nml repo? 19:43:23 <planetmaker> Not for a thing like this 19:43:29 <Yexo> docs in the nml repo shouldn't be used for idea documents 19:43:35 <Yexo> just for actual documentation 19:44:04 <Alberth> speaking of docs, should the reference not be split into more managable pieces? 19:44:14 <Alberth> or use of a different formalism to write it? 19:44:20 <Yexo> yes 19:44:22 <Alberth> eg restructured text? 19:44:30 <planetmaker> which reference? 19:44:35 <Yexo> but which format to use is another discussion 19:44:38 <Alberth> reference.html 19:44:50 <Alberth> LaTeX :p 19:44:51 <Yexo> when I started I just wanted "something" and not start a discussion about the best format to use 19:45:13 <planetmaker> oh. It might make sense to split it into more documents. yes. But... I'd not put too much energy into that before a first release 19:45:14 <Alberth> I think we are beyond that point now :) 19:45:25 <planetmaker> Alberth: no problem whatsoever with latex 19:45:31 <planetmaker> but use pdflatex then 19:45:32 <Alberth> good! 19:45:50 <planetmaker> that allows to include png :-) 19:46:20 <planetmaker> Let's see :-) 19:47:17 <Alberth> with restructured text, there is also a LaTeX backend :) 19:47:48 <Alberth> the advantage is that it is plain ascii, editable by everybody 19:53:51 <Alberth> one for the python coding-style: which quotes to use " or ' ? 19:54:28 <Yexo> is there any technical difference? 19:55:11 <Alberth> no 19:55:36 <Alberth> except that you can use the other quotes inside without escaping them 19:57:00 <Alberth> hmm, pastebin.org is broken wrt copy/paste part of the text (just like RM) 19:57:12 <Yexo> personally I don't care which type of quotes we use 19:57:42 <planetmaker> [21:47] <Alberth> with restructured text, there is also a LaTeX backend :) <-- you mean to not write latex directly? 19:58:38 <Alberth> it is fine by me, but many people do not understand how to write latex, so from a project perspective, we amy want something else 19:59:02 <Alberth> s/amy/may/ 19:59:55 <Yexo> latex is fine by me 19:59:57 <Yexo> Hirundo? 20:00:49 <Hirundo> Does it have enough advantage to rewrite existing documentation? 20:02:13 <Alberth> nice pdf output? 20:03:30 <Alberth> rewriting is not that difficult imho, just some shuffling of existing text 20:03:35 <Yexo> we need to split the existing documentation anyway, and keeping crosslinks between multiple html-documents working manually is a lot more work than automating that 20:04:00 <frosch123> isn't online html more useful than pdf? 20:04:14 <frosch123> i.e. it is quotable via "links" 20:04:21 <Yexo> yes, but the nice thing about latex is that you can output html too 20:04:27 <frosch123> for forums or irc 20:04:36 <Alberth> right, wasn't there a latex2html thingie? 20:04:52 <frosch123> long ago that i tried tex2html 20:04:54 <Rubidium> pdf2html :) 20:05:14 <Rubidium> (though that's definitely not the preferred way) 20:05:18 <frosch123> but yes, maybe you are right :) 20:07:20 <Alberth> Yexo: never done that. by (pdf)latex itself or some conversion? 20:07:40 <Yexo> tex2html or something like that 20:08:20 <Alberth> latex2html site seems stable since 2001, and the download links are broken 20:08:53 <frosch123> dev-tex/latex2html 20:08:54 <frosch123> Latest version available: 2008 20:09:10 <Alberth> my fedora package manager has it 20:09:24 <Yexo> there is also http://hyperlatex.sourceforge.net/html/hyperlatex.html 20:09:25 <Webster> Title: Hyperlatex Manual (at hyperlatex.sourceforge.net) 20:09:30 <Yexo> haven't tried it yet though 20:11:05 <planetmaker> last time I tested it ( a few years back) it gave acceptable results 20:11:06 <frosch123> ah, i uses "tth" 10 years ago, but it is somewhat non-free 20:11:37 <frosch123> http://hutchinson.belmont.ma.us/tth/ 20:11:39 <Webster> Title: \TtH: the \TeX to HTML translator (at hutchinson.belmont.ma.us) 20:16:19 <planetmaker> hm, conversion is kinda quick, I guess 20:16:50 <Alberth> also found sphinx, another python documentation system. It uses restructured text 20:17:02 <Alberth> planetmaker: I'd expect that to be the case 20:17:28 <Alberth> our docs are not that complicated :) 20:34:17 <Yexo> http://devs.openttd.org/~yexo/nml/move_ast.diff Split ast.py to ast/*.py files 20:34:36 <Yexo> all regression test work, but it's easy to miss an import somewhere 20:35:56 <Alberth> pylint or pyflakes can find those 20:36:39 <Alberth> one for the python code style, how do we import? 20:37:04 <Alberth> ie why not from nml.ast import switch 20:38:18 <Alberth> and do we allow relative imports? 20:38:36 <Yexo> I don't really care about the style of imports 20:38:42 <Yexo> but preferable no relative imports 20:40:05 <Alberth> +from nml.ast.general import feature_ids and do we allow import of something else than a module? 20:41:47 <Yexo> that particular import is temporary 20:41:59 <Yexo> in general, I think it's better to only include modules 20:42:21 <Alberth> the whole parser is full with relative imports 20:43:07 <Yexo> s/from actions/from nml.actions/ and that is solved, right? 20:44:00 <Alberth> + t[0] = ast.assignment.Assignment(t[1], t[3]) 20:44:07 <Alberth> I was refering to those 20:44:22 <Alberth> you removed from nml import ast 20:45:09 <Alberth> I think we should do from nml.ast import assignment, ... 20:45:19 <Yexo> ok 20:45:20 <Alberth> and drop the "ast." prefixes 20:45:47 <Alberth> then we do absolute module import :) 20:48:13 <Yexo> new diff, updated parser.py 20:48:17 <Alberth> but otherwise, just do the commit, we'll find any missing import soon enough :) 20:48:43 <Alberth> it looks much better imho 20:49:09 <Hirundo> Feel free to add more stuff here: http://dev.openttdcoop.org/projects/nml/wiki/Coding_Style 20:50:14 <Alberth> I am also tempted to split the parser rules into more methods, one for each alternative ( x : A | B would then be 2 methods instead of 1) 20:50:41 <Yexo> feel free, but watch out for code duplication 20:51:04 <Brot6> NewGRF Meta Language - Revision 564:64e4ddccfde2: Codechange: split nml/ast.py to nml/ast/*.py (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/64e4ddccfde2 20:51:25 <Yexo> that document is not so much "coding style" but more "program design" 20:51:59 <Alberth> in fact, completely no code style at all :) 20:52:30 <Alberth> Hirundo: now since the AST is empty, how and where to do the pre-processing and processing? 20:52:37 *** frosch123 has quit IRC 20:53:12 <Hirundo> AST and ast.py do not have to be synonyms 20:53:56 <Alberth> ah, so the class may still have code for those things. 20:53:57 <Hirundo> feel free to edit, it's wiki 20:53:57 <Alberth> ok 20:53:58 <Yexo> Unpack parameter lists definitely belongs in the ast code imo 20:54:06 <Hirundo> Isn't it there? 20:54:13 <Alberth> what is it? 20:54:15 <Yexo> not in all cases I think 20:54:44 <Hirundo> hm... I didn't document that very cleanly 20:55:43 <Hirundo> changed 20:56:01 <Yexo> Hirundo: what about real_sprite.py parsing "sprite.param_list' instead of splitting "param_list" in the parameter names in ast/spriteblock.py ? 20:57:02 <Hirundo> That ought to be changed, I'd say (without looking at the actual code) 20:57:24 <Alberth> would stating where the code is located in the files for each stage be any good here? 20:57:56 <Yexo> yes 20:58:53 <Hirundo> done :P 20:59:11 <Hirundo> another question: what should be validated where? 20:59:16 <Hirundo> to give an example 20:59:40 <Hirundo> real sprite ysize needs to be in range 1..255. Where to check that? 21:00:00 <Alberth> i'd say in pre-processing if possible, processing otherwise 21:00:27 <Yexo> all/most compile time constants can be checked during pre-processing 21:00:41 <Alberth> giving an error in post-processing seems not very nice 21:00:56 <Yexo> does "register identifiers" really belong in the pre-processing stage? 21:01:04 <Hirundo> [pre-]processing is the only sane option, but that still leaves two 21:01:23 <Hirundo> Yexo: how can you resolve identifiers at that stage if you don't register them? 21:01:36 <Alberth> new stage: register identifiers 21:01:42 <Yexo> you can only use identifiers after you've declared them 21:01:58 <Yexo> use some_switch; declare some_switch; <- that isn't valid 21:02:06 <Yexo> the other way around would be valid 21:02:11 <Hirundo> So this is an immediate check that no forward references are used 21:02:40 <Yexo> currently those identifiers are added to a list at the time they are processed, so only lines later in the code can reference them 21:02:47 <Alberth> what about allocating values to them? 21:03:03 <Yexo> not possible, you need to know the last usage first before you can allocate values 21:03:34 <Yexo> on the other hand if all identifiers are also resolved during pre-processing it would work 21:03:41 <Alberth> yes, so your processing code becomes complicated as you refer to an identifier without knowing its value 21:03:49 <Yexo> that actually makes sense, because resolving those ids is part of "reduce expressions" 21:04:03 <Yexo> Alberth: yes, there is no way around that 21:04:10 <Hirundo> The way I saw it is that in that stage, Identifiers are replaced with references to other objects or reduced to numbers, whichever is appropriate 21:04:21 <Yexo> currently we refer to a name and map values to those names during post-processing 21:04:30 <Alberth> Yexo: then you need a seperate sweep to handle identifiers 21:05:34 <Yexo> which is exactly what the current code does 21:06:14 <Brot6> FIRS Industry Replacement Set - Bug #1151 (New): Fishing Harbours should try and locate reasonabl... (andythenorth) @ http://dev.openttdcoop.org/issues/1151 21:06:27 <Alberth> no, I mean a seperate sweep 'what identifiers do you define and what identifiers do you use?' then do value assignment, then do processing of expressions etc 21:06:44 <Yexo> ah, ok 21:06:59 <Yexo> but that is not possible, because the values also depend on some generated varaction2s 21:07:07 <Yexo> those are generated during processing 21:07:23 <Yexo> only after all (var)action2s are known we can assign values 21:07:43 <Alberth> ok, we keep it as it is now 21:09:02 <Alberth> well, I'll read the results tomorrow. Good night 21:09:08 <Yexo> night Alberth 21:09:52 *** Alberth has left #openttdcoop.devzone 21:32:12 <Hirundo> goodnight 22:08:06 *** FooBar has quit IRC 22:38:15 *** ODM has quit IRC 22:41:21 <Brot6> feed devactivity had 13 updates, showing the latest 10 22:41:21 <Brot6> #openttdcoop NewGRF package - Revision 248:a39b6a521290: DevZone: tee is something else (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/a39b6a521290 22:41:21 <Brot6> #openttdcoop NewGRF package - Revision 249:95ee7b1614c8: [Scripts] fix [ ] (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/95ee7b1614c8 22:41:21 <Brot6> #openttdcoop NewGRF package - Revision 250:c94302ba74e9: [DevZone] use nightly nforenum and grfcodec (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/c94302ba74e9 22:41:24 <Brot6> #openttdcoop NewGRF package - Revision 251:955c5cfe0948: DevZone: fix the file names (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/955c5cfe0948 22:41:28 <Brot6> #openttdcoop NewGRF package - Revision 252:3ea6675a6d33: [Scripts] move packaging from setup.sh t... (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/3ea6675a6d33 22:41:32 <Brot6> #openttdcoop NewGRF package - Revision 253:7b5eecf4f6bd: [Scripts] short date should be in readme (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/7b5eecf4f6bd 22:41:36 <Brot6> #openttdcoop NewGRF package - Revision 254:b13e6d1d10aa: DevZone: bananas newgrfs needs to be unz... (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/b13e6d1d10aa 22:41:40 <Brot6> #openttdcoop NewGRF package - Revision 255:ad1f7ae7d4e2: DevZone: mkdir the temporary dir (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/ad1f7ae7d4e2 22:41:44 <Brot6> #openttdcoop NewGRF package - Revision 256:56a1bec4d2fb: Added tag 8-beta1 for changeset ad1f7ae7... (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/56a1bec4d2fb 22:41:50 <Brot6> #openttdcoop - Revision 110:61f74c90fa1d: [Compiler] Feature: support for wgets and local rpm repo (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/61f74c90fa1d 22:41:54 <Brot6> grfpack: update from to 8-beta1 done - http://bundles.openttdcoop.org/grfpack/releases/8-beta1 22:58:24 <Brot6> #openttdcoop NewGRF package - Revision 244:f8cbfa9be621: Remove versioned files from the repo, th... (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/f8cbfa9be621 22:58:59 <Brot6> grfpack: compile of 8-beta1 failed - http://bundles.openttdcoop.org/grfpack/releases/ERROR/8-beta1 22:59:41 <Brot6> #openttdcoop NewGRF package - Revision 256:d898d19c830b: DevZone: files to publish (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/d898d19c830b 22:59:41 <Brot6> #openttdcoop NewGRF package - Revision 257:748012e718a2: Added tag 8-beta1 for changeset d898d19c... (Ammler) @ http://dev.openttdcoop.org/projects/grfpack/repository/revisions/748012e718a2 23:01:16 *** Seberoth has quit IRC 23:01:22 *** Seberoth has joined #openttdcoop.devzone 23:15:48 <Brot6> grfpack: update from 8-beta1 to 8-beta1 done - http://bundles.openttdcoop.org/grfpack/releases/8-beta1