Log for #openttdcoop.devzone on 22nd May 2010:
Times are UTC Toggle Colours
00:03:50  <planetmaker> so, let's see what happens :-)
00:04:33  <Webster> Latest update from devactivity: World Airliners Set - Support #946 (Resolved): Rename worldairlineset -> worldairlinersset <" target="_blank">> || World Airliners Set - Support #946 (Resolved): Rename worldairlineset -> worldairlinersset <> || 2cc train set - Revision 538: merge local heads <> || 2cc train set - Revision 537: Update: Norwegian translation <> || 2cc train set - Revision 536: Added tag Beta1 for changeset d960751ed673 <> || 2cc train set - Revision 535: Added tag beta1 for changeset e3ef4548fc7f <> || 2cc train set - Revision 534: Added tag beta1 for changeset 869dd0208d7b <> || 2cc train set - Revision 532: 2.0-beta1 <> || 2cc train set - Revision 533: Added tag 2.0-beta1 for changeset 9f988d0d9048 <> || 2cc train set - Revision 531: Added tag 2.0-beta1 for changeset 4c4e2c622759 <>
00:18:21  <Ammler> nothing?
00:19:41  <Ammler> hmm, I know why :-)
00:20:11  <Ammler> you use different name for project and repo
00:20:41  <Ammler> and don't forget to add the compile enabler
00:20:58  <Ammler> touch ./devzone/build/releases/enable
00:46:11  *** OwenS has quit IRC
01:21:03  *** V453000 has quit IRC
01:21:20  *** V453000 has joined #openttdcoop.devzone
02:04:18  <Brot6> test: abort: push creates new remote heads!
04:41:42  *** Frankr has quit IRC
05:24:03  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 835: Add: pcx file for Lumber Yard <>
05:47:14  *** ODM has joined #openttdcoop.devzone
06:27:15  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 837: Fix: eliminate various non-critical errors reported... <> || FIRS Industry Replacement Set - Revision 836: Change: progress on Lumber Yard (unfinished) <>
06:29:00  *** yorick has joined #openttdcoop.devzone
06:46:10  *** LA has joined #openttdcoop.devzone
07:00:16  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 838: Change: progress on Lumber Yard <>
07:17:33  <yorick> LA! :p
07:22:04  <LA> hai
07:22:09  <LA> yorick!
07:22:54  <yorick> ltns
07:23:24  <LA> ?
07:23:36  <yorick> long time no see
07:23:39  <LA> oh
07:23:41  <LA> :D
07:23:44  <LA> true enough: D
07:23:57  <yorick> little thicket nature sanctuary ofcourse
07:39:14  <yorick> meh I want to code something
07:40:44  <LA> is that a hint that I should draw something so you could code it?
07:40:46  <LA> :D
07:42:03  <yorick> rather that I should add png support to nml
07:44:10  <yorick> and pcx palettes
07:44:24  <yorick> because currently I think it will rather break when you have a scrambled pcx palette
08:09:54  <LA> wtf is nml? :D
08:10:33  <Hirundo> A human-readable nfo replacement, basically
08:12:37  <LA> omg, another one? :o
08:13:00  <yorick> yes another one
08:13:04  <yorick> and this time a working one
08:13:18  <yorick>
08:13:31  <yorick> for example
08:35:57  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 839: Change: progress on Lumber Yard <>
08:38:11  <planetmaker> oh, LA :-)
08:38:12  *** LA has quit IRC
08:38:16  <planetmaker> :-(
08:38:32  <yorick> LOL
08:38:50  <planetmaker> yorick: NML has already png support
08:39:17  <planetmaker> you 'just' need the correct palettes of course
08:39:39  <yorick> the png support is just the pcx files but converted to png?
08:39:53  <planetmaker> no?
08:40:02  <planetmaker> it's png as input file
08:40:26  <planetmaker> but sure enough they need to use the palettes
08:40:31  <yorick> they look the same as the pcx files, don't they?
08:40:36  <yorick> using spritesets and such
08:40:45  <planetmaker> they should
08:40:55  <planetmaker> would be bad, if they didn't.
08:41:19  <yorick> you could use one sprite per png
08:41:22  <yorick> that would be kindof nice
08:41:39  <planetmaker> of course you can
08:49:10  *** ODM has quit IRC
08:51:16  <Webster> Latest update from devactivity: OpenGFX - Feature #741: toolbar info sprite blue instead red? <>
09:04:12  <Ammler> planetmaker: did you get my comments about release building?
09:04:26  <planetmaker> uhm, no, sorry
09:04:54  <planetmaker> which, where, how?
09:04:58  <Ammler> [10:31] <Ammler> [02:20:11] you use different name for project and repo
09:05:00  <Ammler> [10:31] <Ammler> [02:20:41] and don't forget to add the compile enabler
09:05:01  <Ammler> [10:31] <Ammler> [02:20:58] touch ./devzone/build/releases/enable
09:05:44  <planetmaker> damn. I pushed already
09:05:51  <Ammler> no issue
09:06:00  <Ammler> it will work anyway...
09:06:44  <Ammler> it is like nightlies, if the last tag is other then the one in
09:06:56  <Ammler> it builds it
09:21:42  <Webster> Latest update from devactivity: Nutracks - Bug #949 (Confirmed): missing level crossing sprites <>
09:22:48  <Ammler> that is no bug :-P
09:23:02  <planetmaker> it's ugly ;-)
09:23:03  <Ammler> it is just not finished, quite well known
09:23:24  <planetmaker> I know. But I proposed a work-around so that it gets much better playable
09:24:20  <Ammler> true
09:36:43  <Webster> Latest update from devactivity: Example NewGRF Project - Bug #950 (New): Repo should have same name as project identifier <>
09:39:24  <Rubidium> it's just an incentive to not make level crossings with rail
09:41:05  <Ammler> true, at least the faster ones should simply disable it
09:45:33  <Ammler> andythenorth: the newgrf compile farm has now also release support
09:46:02  <Ammler> it does automatically create a release of newest tag on every push
09:48:50  <Ammler> hg pull 2ccset is like cloning a new repo
09:51:11  *** LA has joined #openttdcoop.devzone
09:51:48  <Webster> Latest update from devactivity: 2cc train set - Revision 539: DevZone: enable new compiler <> || FIRS Industry Replacement Set - Revision 840: Feature: Lumber Yard (known issue: some pixels flash) <>
09:52:27  <Brot6> 2cctrainset: update from  to Beta1 done (4 errors) -
10:00:22  *** OwenS has joined #openttdcoop.devzone
10:16:05  <Ammler> hmm, not that nice tag name
10:17:34  <planetmaker> hm, not really, yeah
10:17:44  <planetmaker> but...
10:17:54  <Ammler> it works :-P
10:22:25  *** KenjiE20 has joined #openttdcoop.devzone
10:26:03  *** frosch123 has joined #openttdcoop.devzone
10:31:37  <planetmaker> LA: concerning the train income icons: did you give differently coloured money symbols a try?
10:32:04  <planetmaker> maybe with different amount of coins at the same time to make it distinguishable either way, colour and shape?
10:32:12  <LA> well i didn't
10:32:45  <planetmaker> I envision currently something like:
10:32:58  <planetmaker> good income: money bill + coin(s) in green
10:33:13  <planetmaker> moderate income (=yellow currently): coin(s) in yellow
10:33:23  <LA> the thing is, I believe it's restricted to 8x8 px
10:33:31  <planetmaker> negative income: coin(s) with "-"-sign in red
10:33:33  <LA> as that's the size of the current ones
10:33:37  <planetmaker> it's not ;-)
10:33:43  <planetmaker> but it shouldn't be really much bigger
10:34:02  <planetmaker> the GUI will re-size according to sprite size, though
10:34:33  <planetmaker> and neutral (=no info yet): money bill + coin(s) in gray
10:35:50  <planetmaker> maybe rather: green --> bill + coins in green; yellow --> coins yellow; neutral --> coin gray; red --> coin + bill red
10:35:57  <planetmaker> note the singular and plural forms ;-)
10:36:43  <planetmaker> it'd give each state a unique symbol AND make it colour-coded the same way as it's now
10:36:55  <planetmaker> so everyone could in principle see it
10:37:26  <LA> only I'm not sure how nice would a red bill be :D
10:37:28  <Webster> Latest update from devactivity: OpenGFX - Feature #741: toolbar info sprite blue instead red? <> || OpenGFX - Feature #741: toolbar info sprite blue instead red? <>
10:37:41  <LA> like it'd have to be recognisable perhaps aswell
10:38:59  <planetmaker> not too dark red.
10:39:04  <planetmaker> like orange or so
10:39:08  <planetmaker> as opposed to yellow
10:39:22  <planetmaker> or the numbers would have to be (near) white. dunno
10:41:04  *** Seberoth has joined #openttdcoop.devzone
10:47:05  <LA> heh
10:47:29  <LA> you know, if I make the neutral coin gray, it looks like silver
10:47:40  <planetmaker> that's ok, too
10:52:28  <LA>
10:52:29  <Webster> Latest update from devactivity: OpenGFX - Feature #741: toolbar info sprite blue instead red? <>
10:52:32  <LA> something like this?
10:53:37  <frosch123> hmm, Zephyris is right, there is only one icon, which is recoloured
10:54:10  <frosch123> and that icon is also uses in the statusbar, the town view and content gui :s
10:54:47  <frosch123> but why is that icon from the extra grf? were there no profit indicators in ttd?
10:55:03  <LA> in that case the start/stop icons should be only changed
10:55:19  <LA> and the money ones should be ignored?
10:55:33  <Ammler> LA: those are already changed, it is a red cross now
10:56:02  <LA> yeh. but it looks a lot like 'delete vehicle' not stop
10:56:32  <Ammler> I don't find the ticket about that anymore, planetmaker?
10:56:42  <frosch123> indeed, that icon is a ottd addition not present in ttd :o
10:56:52  <planetmaker> Ammler: LA yes, that ticket is closed
10:57:14  <Ammler> but the discussion might be interesting still
10:57:15  <LA> alright
10:57:46  <LA>
10:57:46  <frosch123> well, we could also add 3 new icons
10:57:52  <LA> hmm
10:57:59  <LA> were we talking about the same issue?
10:58:32  <planetmaker> Hm, there's only one re-coloured icon you say, frosch123 ?
10:58:47  <planetmaker> Would be interesting indeed to add for this purpose new icons :-)
10:58:52  <frosch123> planetmaker: yes, SPR_BLOT. and it is also used in very different contexts
10:59:24  <planetmaker> hm, not the best choice tbh :-)
10:59:30  <planetmaker> Let's change that, ok?
11:00:06  <frosch123> let's see whether its possible to make ottd fallback to the old icon if the new ones are not yet defined
11:00:09  <planetmaker> even IF it stays the same icon here and there, it's much better future-proof to duplicate that
11:00:28  <planetmaker> hm. good point
11:02:52  <frosch123> so, we have: 3xprofit, exclusive transport rights, content state (missing, present), server compatibility, company profit in network lobby (never saw that one), and news ticker
11:03:38  <planetmaker> frosch123: 4x profit
11:03:47  <frosch123> oh, indeed :)
11:04:14  <planetmaker> news ticker? I guess I never look at news :-P
11:04:55  <planetmaker> hm, I fear to have that backward compatible will be a bit hackish :S
11:05:44  <frosch123> i don't think so. the shore compatibility works quite well
11:08:35  <planetmaker> server compatibility is actually three states, too
11:08:37  <Ammler> "company profit in network lobby", if you join the server, companies which don't make profit are red
11:09:03  <frosch123> yup, just explored it :p
11:09:21  <frosch123> i guess that one can use the same icons as the vehicles
11:09:38  <frosch123> server compatibility and content state could stay with the blot
11:09:39  <planetmaker> the profit thing?
11:09:50  <planetmaker> nvm
11:10:06  <planetmaker> yes, server compatibility + content state could use the same
11:10:09  <frosch123> not sure about exclusive transport rights, and the news reminder thingie
11:10:19  <frosch123> i am not sure what the last one really does :p
11:10:20  <planetmaker> where's that news reminder thing?
11:10:29  <frosch123> in the statusbar
11:10:33  <frosch123> some red dot on the right
11:10:55  <Ammler> can you click on it to open the news?
11:11:08  <planetmaker> hm, when?
11:11:22  <KenjiE20> you can always click on the ticker to get the news
11:11:23  <yorick> hmm...I wonder how to handle m4 output when reading from a non-file stream
11:11:28  <yorick> what if those use includes?
11:11:53  <planetmaker> frosch123: I don't have in my status bar any icons...
11:11:56  <frosch123> ah, it is flashed shortly when news arrive which you set to "off"
11:13:34  <frosch123> i doubt there are lot around who would have known that :p
11:13:53  <planetmaker> even with full or summary for all I don't see that
11:13:56  <yorick> maybe find a way to passthrough arguments to m4(like include)
11:14:09  <frosch123> so, also two separate icons for exclusive transport rights and unread news?
11:14:29  <frosch123> [13:13] <planetmaker> even with full or summary for all I don't see that <- exactly, you have to set them to "off"
11:14:38  <planetmaker> ah!
11:23:08  <Webster> Latest update from devactivity: 2cc train set - Revision 542: Merge <> || 2cc train set - Revision 541: Merge <> || 2cc train set - Revision 540: Fix: Cargo wagons '2cc icon' were 3 pixels to small <> || OpenGFX - Feature #741: toolbar info sprite blue instead red? <>
11:27:38  <frosch123> oh, silly me. the recolouring makes it quite hard to use fallback sprites :s
11:27:56  <frosch123> (unless we also recolour the new ones)
11:28:31  <Ammler> why not?
11:28:38  <Ammler> if company colors are used
11:29:07  <frosch123> i mean the old grey/red/yellow/green recoloring
11:29:26  <Ammler> instead of one sprite per state?
11:29:26  <frosch123> but that is silly for individual icons
11:29:57  <Ammler> why does it need fallback?
11:31:22  <frosch123> fallbacks are nice if you add new icons regulary. less "there are lots of questionmarks" due to old opengfx and such
11:32:08  <Ammler> hmm, does the installer also update base sets?
11:33:42  <Ammler> if you add new icons now, chances are high, that everyone uses new opengfx until next year (1.1.0) :-)
11:34:41  <frosch123> hmm, some fool changed english.txt yesterday? right :p
11:34:46  <Ammler> the shadow icon was just too close to the release
11:37:29  <Ammler> andythenorth: shall I enable the new compiler for your sets or will you try self? (
11:37:40  <frosch123> <- someone fancies drawing 6 new icons for openttdd/w.grf? (well and opengfx)
11:38:25  <Ammler> frosch123: what about those LA made in #942
11:40:43  <frosch123> don't know, since there are both original graphics and opengfx i cannot tell anymore which of them a icon fits itno
11:40:55  <andythenorth> Ammler: I don't know
11:41:19  <andythenorth> does the nml compiler also compile nfo?
11:41:26  <Ammler> nml?
11:41:26  <andythenorth> I haven't really followed the details
11:41:37  <Ammler> this has nothing to do with nml
11:41:45  <andythenorth> oh sorry :)
11:41:50  <andythenorth> what is the new compiler?
11:42:07  <Ammler> well, the new compiler can also use other projects as dependencies, like nml
11:42:45  <Ammler> it can now prepare also releases
11:43:00  <Ammler> if you push a tag, it creates the bundle in releases
11:43:32  <Ammler> and fully chrooted, so you can't hurt the server with a bad makefile
11:49:48  <Hirundo> Would functions be useful in nml?
11:50:57  *** LA has quit IRC
11:53:10  <andythenorth> Hirundo: that's an empty paste? :)
11:53:26  <Hirundo>
11:54:49  <Hirundo> Basically, it's a glorified macro :)
11:56:47  <yorick> Hirundo: someone suggested using m4
11:56:55  <yorick> because it has nice include files too
11:57:01  <andythenorth> I haven't been keeping up with nml :o
11:57:14  * yorick is working on dependency generation
11:58:16  <Ammler> why doesn't NML not simply support custom "import"?
11:58:32  <yorick> because ply doesn't like it
11:59:45  * andythenorth reads nml source and is pleased by python :)
12:00:56  <andythenorth> Hirundo: (excuse my dumbass questions) how extensive could function be
12:00:56  <Ammler> doesn't NML use python syntax?
12:01:50  <yorick> no
12:01:55  <yorick> it uses mixed python css
12:02:01  <Hirundo> andythenorth: At first, I was planning to allow a single parametrized expression only
12:02:15  <yorick> m4 --debug=i < sprites/ogfxplus.m4 -I sprites 3>&2 2>&1 1>&3- 1> /dev/null | grep "input read from" | grep -v "stdin"
12:02:44  <andythenorth> Hirundo: would it support standard python iterators?
12:02:54  <Hirundo> It is already possible to call other switch statements (varact2) as a function
12:03:51  <Hirundo> python iterators? in what context?
12:04:35  <Hirundo> yorick: Could you elaborate on 'ply doesn't like it' ?
12:05:39  <yorick> Hirundo: you'd either need to parse includes beforehand or do some extensive hacking to the lexer to make get it to change input mid-parsing
12:05:45  <yorick> lexing*
12:07:49  * Hirundo checks the code
12:08:18  <andythenorth> Hirundo: I'm not sure.  I should try using nml before asking dumb questions :P
12:08:52  <andythenorth> I was just looking at an industry animation problem in nfo and wondering if it could be solved by iterating over a dict of x, y values
12:09:05  <yorick> m4 --debug=i < sprites/ogfxplus.m4 -I sprites 3>&2 2>&1 1>&3- 1> /dev/null | grep "input read from" | grep -v "stdin" | awk "{ print $5 }"
12:09:07  <andythenorth> I haven't really thought it through though :o
12:09:08  <yorick> yay there it is :)
12:09:16  <Webster> Latest update from devactivity: #openttdcoop - New Compiler on the DevZone <>
12:12:16  <Hirundo> andythenorth: Iteration is generally not possible with varact2
12:12:18  <planetmaker> Hirundo: functions would be quite useful
12:12:45  <planetmaker> in a few cases: Like balancing some action0 for vehicles (e.g. prices as a function of power / TE etc pp)
12:13:06  <planetmaker> or would that not be possible via those functions?
12:13:29  <Hirundo> yes, that's possible
12:13:52  <planetmaker> I know that 2cctrainset uses such scheme for the vehicles. So yes, definitely nice
12:15:34  <Hirundo> I'm thinking about 'true' functions that allow a statement list instead of a single expression, that will be difficult to implement though
12:15:43  <yorick> Hirundo: m4 :)
12:15:59  <planetmaker> yorick: two-layer approach is not the best
12:16:08  <planetmaker> as it means that people have to learn two things
12:16:22  <planetmaker> and makefiles get considerably more difficult. Or necessary in the first place
12:16:34  <Hirundo> yorick: m4 does not magically work with varaction2, unless you want to inline everything
12:17:05  <Ammler> planetmaker: the readme substitutions are a issue of every newgrf, it seems
12:17:22  <yorick> I think it's by far the easiest way to have includes
12:18:01  <Hirundo> Is it possible to separate lexing and parsing with ply?
12:20:11  <Hirundo> If there is some intermediate stage that has a list of tokens, replacing includes with new token lists would be fairly easy
12:20:38  <yorick> it should be
12:36:53  <andythenorth> Hirundo: I was thinking of iterating to write out actions, similar to how we use the CPP already in nfo, but in a way I understand (e.g. python iterators)
12:38:46  <andythenorth> so I dunno, something like define a dict of tile property values then iterate over that to define multiple tile action 2s
12:43:26  <Hirundo> It may be a better idea to write a python (or other) script for that purpose
12:51:28  <Hirundo> Or perhaps, we could allow inlining blocks of python in NML, to be evaluated using exec
12:51:41  <planetmaker> [14:17]	<Ammler>	planetmaker: the readme substitutions are a issue of every newgrf, it seems <-- you mean replacing certain strings to (version / project) dependent strings?
12:51:55  <yorick> Hirundo: that'd be quite a security risk
12:53:01  <Hirundo> It is possible to restrict the functions and variables that can be accessed
12:53:25  <Ammler> planetmaker: yes
12:56:22  <Hirundo> Isn't it possible to run arbitrary python code on the server already, if you have commit rights to a repo?
12:56:51  <Ammler> yep
12:57:28  <Ammler> you have access to every tool you need and available from suse
12:58:01  <Ammler> just define the spec :-)
12:59:44  <planetmaker> Hirundo: but it is run in a chroot. So the arbitrary code normally cannot damage the server
12:59:47  <andythenorth> being able to running arbitrary code with just commit rights seems like a *very* bad idea
13:00:02  <planetmaker> read what I just wrote :-P
13:00:05  <Ammler> andythenorth: cool isn't :-)
13:00:34  <planetmaker> missing an 'it'?
13:00:42  <Ammler> ah, again :-P
13:01:27  <Rubidium> andythenorth: automated builds and not being able to commit arbitrary code are basically mutually exclusive beyond the most trivial stuff
13:01:30  <andythenorth> maybe you've sandboxed the server filesystem, but what's to stop me writing something that DOS's the actual box?  Or...worse, attacks someone elses box?
13:01:52  <Ammler> not intentnet for the sandbox
13:01:56  <Ammler> -t
13:02:08  <Ammler> internet*
13:02:17  <andythenorth> makes sense
13:02:17  * Rubidium wonders whether you can really disable internet in a chroot
13:02:41  <planetmaker> besides, andythenorth: you still need a devzone account in order to commit
13:02:47  * andythenorth lives in a web framework which  limits python for those who don't know what they can do that's bad
13:02:51  <Rubidium> okay, you can make it inaccessible by not providing dns and such
13:03:01  <planetmaker> and new projects can only be created by people who already are project owners or by admins
13:03:09  <Ammler> Rubidium: no idea, please feel free to give me a spec to try it :-)
13:03:56  <Rubidium> but then, one can probably compile their own dns resolver (or hardcode IPs)
13:04:06  <andythenorth> is there any way to execute such code over the web / http?
13:04:30  <planetmaker> the only way is - as I see it - to wait for the CF to call it.
13:05:00  <planetmaker> maybe one could exploit redmine with viewing files
13:05:29  <andythenorth> possible but not if it's built correctly....
13:05:41  <planetmaker> programmes are not bug-free
13:06:58  <Ammler> planetmaker: you can "push" release build :-)
13:09:08  * yorick *needs* something to do
13:09:29  <Ammler> make patch for nml so it accepts nfo as input :-)
13:09:31  <Webster> Latest update from devactivity: Nutracks - Bug #949: missing level crossing sprites <>
13:09:53  <yorick> Ammler: double meh
13:09:56  <planetmaker> or vice versa: grf2nml
13:10:10  <yorick> I can probably use lex to parse nfo
13:11:12  <Ammler> hmm, well, grfcodec for suse factory doesn't work anymore, so this would be a welcome workaround. :-)
13:24:41  <Webster> Latest update from devactivity: Nutracks - Revision 60: Fix: Climate avalability were not properly set; it were in hex form and n... <>
13:38:52  <yorick> r'(0x[0-9a-zA-Z]+)|(\d+)' <-- last time I checked, hex only went to F
13:57:23  <DJ_Nekkid> how do i get a specific version of openttd? i tried 'svn up 19733'
13:57:50  <DJ_Nekkid> with the response: "At revision 19880.
13:57:50  <DJ_Nekkid> "
13:58:08  <yorick> svn up -r19733
13:58:16  <DJ_Nekkid> k, tnx :D
14:13:47  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 841: Change: removed bad pixels from Lumber Yard <>
14:27:16  <yorick> you should use r'"([^"\]|\.)*"' for string literals
14:27:22  <yorick> because what you use now doesn't match ""
14:28:04  <Hirundo> you = someone ?
14:28:20  <yorick> you = nml people
14:34:21  <Hirundo> yorick: <- Your remarks are documented ehre
14:35:30  <yorick> hehe :)
14:35:42  <yorick> I sound a bit grumpy
14:36:42  <Hirundo> "Yorick's issues" can also be interpreted differently :)
14:36:51  <Ammler> lol
14:37:14  <yorick> lol :)
14:38:21  <planetmaker> :-P
14:42:30  <yorick> <-- nfo lexer :)
14:43:51  <planetmaker> for the inaugurated: what's input and output? Input=NFO, output=?
14:44:32  <yorick> output = lexer tokens :)_
14:44:36  <yorick> :)*
14:44:57  <yorick> have yet to find a way to parse it
14:44:59  <Webster> Latest update from devactivity: NFO Meta Language - Bug #951 (New): Yorick's issues <>
14:45:17  <yorick> yacc is probably no good since nfo doesn't have much syntax
14:46:46  <PeterT> Ammler: why did you ban
14:47:10  <Ammler> why do you care about that?
14:47:18  <PeterT> I can't join :-P
14:47:25  <PeterT> Well, with the proxy I'm using
14:47:31  <PeterT> /whois PeterT^
14:47:42  <Ammler> your ip is about to spam?
14:47:58  <PeterT> No
14:50:00  <Ammler> @move -b *!*
14:52:26  <Ammler> @mode -b *!*
14:52:26  *** Webster sets mode: -b *!*
14:52:49  *** PeterT_ has joined #openttdcoop.devzone
14:52:51  <PeterT_> :-)
14:52:55  <yorick> but why
14:55:16  *** PeterT_ has quit IRC
14:56:23  <Ammler> yorick: test get those hosts, which are suspicious spamers
14:56:37  <PeterT> dnsbl = dns black list
14:56:46  <PeterT> But clearly, I'm not a spammer
14:56:57  <PeterT> when they join the network
14:57:00  <PeterT> they are on watch
14:57:05  <PeterT> and killed as soon as they do something bad
14:58:56  <yorick> but why are you on that thing
14:59:19  <PeterT> the only free proxy I could find on the internet was in china :-)
14:59:20  <yorick> why does it find you suspicious
14:59:56  <yorick> aha
15:00:03  <yorick> why do you need that proxy
15:00:59  <PeterT> to hide my origin
15:01:34  <yorick> why do you want to "hide your origin"
15:02:33  <PeterT> my busniess :-)
15:04:22  <Ammler> PeterT: Tor?
15:04:41  <PeterT> I didn't understand the xchat + tor guides when I looked
15:05:06  <Ammler> what is with the bouncer you used?
15:06:26  <PeterT> I switched because it kept getting DDoS'd and it annoyed people
15:06:28  <PeterT> with all my joins and parts
15:06:41  <PeterT> and it also disconnects almost every other day
15:07:48  <yorick> oftc can get you a cloak
15:17:28  <Brot6> firs: update from r834 to r841 done (1 errors) -
15:17:34  <Brot6> nutracks: update from r59 to r60 done (1 errors) -
15:17:34  <Brot6> Following repos didn't need a update: 32bpp-extra (r33), airportsplus (r48), bros (r10), comic-houses (r69), fish (r370), heqs (r318), nmts (r15), opensfx (r88), snowlinemod (r10)
15:21:36  *** Yexo has joined #openttdcoop.devzone
15:24:03  <yorick> hello Yexo
15:31:06  <Webster> Latest update from devactivity: 32bpp-extra - Feature #952 (New): Number the sprites correcty... <>
15:34:26  <Yexo> <- decoding (at least some) grfs to nml is possible :)
15:36:20  <yorick> *blink*
15:37:27  <Brot6> 32bpp-extra: compile of r34 failed -
15:37:32  <yorick> Yexo: <-- nfo lexer :)
15:38:38  <Yexo> yorick: reading a grf is easier then reading nfo
15:38:48  <yorick> I now
15:38:50  <yorick> know*
15:39:03  <Yexo> but with that code converting nfo to nml should be possible too
15:39:17  <yorick> I only got the lexer, not the parser
15:39:31  <yorick> I think the parser needs to be written manually
15:40:36  <yorick> woa someone actually wants to trade a invite for a spotify invite :)
15:40:42  <Yexo> the parser should be pretty simple
15:41:09  <Yexo> read tokens until you encounter a start/double star, drop the last read token (it was the sprite number) and you have read a pseudo sprite
15:42:57  <Brot6> 32bpp-extra: update from  to r34 done (2 errors) -
15:48:56  <Yexo> yorick: your code doesn't parse all string escapes correctly
15:49:10  <Yexo> "some text" <- that is a valid string in nfo
15:49:36  <yorick> hmm
15:49:38  <Yexo> hmm, nvm, i does parse correctly
15:50:20  <Yexo> "" <- I don't think that is valid, but your code does parse it
15:51:57  <yorick> does yours?
15:54:06  <PeterT> Ammler: thanks, I set up Tor
15:54:09  <PeterT> Tor > Proxy
15:54:36  *** PeterT_ has joined #openttdcoop.devzone
15:54:36  *** PeterT_ has left #openttdcoop.devzone
15:54:37  <Ammler> PeterT: yeah, we have banned tor from #openttdcoop
15:54:54  <PeterT> why?
15:55:18  <planetmaker> spammers and grievers use it in order to do their mayhem anonymously
15:55:23  <Ammler> I do unban it for you
15:56:39  <PeterT> Ammler: that's not what I meant
15:56:42  <PeterT> Please reban it
15:56:48  <PeterT> I was just wondering why
15:56:48  <Ammler> why?
15:58:06  <Ammler> we kept the ban as long nobody asked used it, I think, we can try again with it...
15:58:18  <PeterT> oh, I see
16:00:09  <Yexo> yorick: does your lexer also parse real sprites correctly? don't you need an extra token for filenames?
16:00:40  <yorick> Yexo: t_SPRITENAME = r'[0-9a-zA-Z/\-_\(\)~\+]+\.(pcx|wav)'
16:00:54  <yorick> I tested it with the full was file
16:01:18  <Yexo> oh, right :)
16:01:19  <PeterT> Ammler: we started documentation on xShunter's triggers and config
16:01:33  <PeterT> soon we can even document the code
16:02:10  <Webster> Latest update from devactivity: 32bpp-extra - Bug #953 (New): useless newgrf action in the grf <>
16:02:52  <yorick> Yexo: only problem is that token is also after a sound sprite
16:03:00  <yorick> maybe separate them into SOUNDNAME and SPRITENAME
16:07:15  <Yexo> any suggestions for decoding real sprites? do it like grfcoded (all in one file, optional split when the file becomes to large), or write a file per action1, or even something completely different?
16:07:56  <Ammler> one file per sprite?
16:08:06  <yorick> Yexo: 2 secs
16:09:00  <yorick>
16:09:07  <yorick>
16:09:18  <planetmaker> Yexo: one file per sprite might be interesting. Or maybe one per action2 sequence
16:09:24  <yorick> it uses one file per sprite
16:09:26  <planetmaker> But that#s probably more work than it's orth
16:09:28  <planetmaker> *worth
16:09:45  <yorick> planetmaker: generating 5000 files is not nice for the filesystem
16:10:02  <planetmaker> yorick: wrong filesystem then
16:10:07  <yorick> planetmaker: ext4
16:10:10  <planetmaker> and yes, I'd like it
16:10:19  <Ammler> yorick: does that also encode?
16:10:24  <yorick> Ammler: no
16:10:31  <yorick> yexo kinda implemented that part first
16:10:41  <yorick> and I still have no nfo reader
16:10:55  <Ammler> hmm, no nml only encodes nml directly
16:11:01  <Ammler> no nfo encoder :-(
16:11:14  <planetmaker> yes
16:11:37  <yorick> working on the thing
16:12:17  <yorick>
16:12:30  <yorick> this produces some kind of sprite objects
16:14:00  <yorick> not yet parsed
16:14:08  <yorick> only separated into sprites :)
16:15:31  <Yexo> I'm already working on parsing sprites after reading the bytes from a grf file
16:15:43  <Yexo> it's trivial to change to code to read bytes from those sprite objects
16:16:04  <planetmaker> :-)
16:16:09  <yorick> Yexo: shall I submit a patch on the tracker then
16:16:25  <planetmaker> I fear the day when Yexo quits due to having over-worked himself
16:16:48  <Yexo> yorick: feel free, but I won't commit it for a while yet
16:16:53  <yorick> that should have happened by now
16:16:57  <Yexo> first I want parsing gf files somewhat working
16:16:59  <yorick> "I think the shields are protecting it"
16:17:11  <Yexo> planetmaker: that won't happen for a while :)
16:17:25  <planetmaker> weeew :-)
16:18:05  <Brot6> 2cctrainset: compile of r542 failed -
16:18:16  <Brot6> opengfx: compile of r458 failed -
16:18:19  <Brot6> Following repos didn't need a nightlies update: 32bpp-extra (r34), nml (r171), ogfxplus (r18), openmsx (r57), worldairlinersset (r643)
16:19:34  * yorick sees no reason to do the same as yexo
16:19:59  <Yexo> trying to support reading action6 from a grf/nfo will be fun :p
16:20:33  <yorick> Yexo does it faster anyways
16:22:18  <Ammler> hmm
16:23:08  <Ammler> what kind of error is that?
16:23:16  <Ammler> sudo: no tty present and no askpass program specified
16:23:17  <Yexo> yorick: I could really use your help with this, it's a huge task
16:23:24  <Ammler> Pseudo-terminal will not be allocated because stdin is not a terminal.
16:23:29  <Yexo> I'll push writing nml files first, then the basic code for reading from a grf file
16:24:22  <yorick> patch thingy added
16:25:37  <yorick> "following extensive research our UK customers don't listen to spotify in there holiday houses" <-- I'm not from the UK and it knows it, just does it on purpose
16:27:24  <Brot6> 2cctrainset: update from  to r542 done (106 errors) -
16:28:57  <Brot6> opengfx: update from r457 to r458 done -
16:29:01  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r542), 32bpp-extra (r34), nml (r171), ogfxplus (r18), openmsx (r57), worldairlinersset (r643)
16:31:13  <Ammler> why did I get that strange output from cron
16:31:56  <planetmaker> what output?
16:32:17  <Webster> Latest update from devactivity: NFO Meta Language - Patch #954 (New): NFO lexer and basic parser <>
16:32:49  <Ammler> planetmaker: the compiler failed as it was called from cron
16:33:13  <Ammler> it worked as I called it directly on the server
16:47:41  <Webster> Latest update from devactivity: NFO Meta Language - Revision 172: Feature: add --nml commandline flag to specify an nml output file <>
16:50:59  <planetmaker> Yexo: what accepted input does that commit imply?
16:51:17  <Yexo> none (only nml as normal)
16:51:36  <Brot6> nml: update from r171 to r172 done -
16:51:39  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r542), 32bpp-extra (r34), ogfxplus (r18), opengfx (r458), openmsx (r57), worldairlinersset (r643)
16:55:28  <Ammler> worked too
16:55:51  <Ammler> will try again cron, so please commit something :-P
17:03:38  <Brot6> test: compile of Version1 failed -
17:03:41  <Webster> Latest update from devactivity: NFO Meta Language - Revision 173: Change: don't import PIL when we don't need it (when just writi... <>
17:24:07  <Brot6> nml: update from r172 to r173 done -
17:24:10  <Brot6> test: compile of r16 failed -
17:24:11  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r542), 32bpp-extra (r34), ogfxplus (r18), opengfx (r458), openmsx (r57), worldairlinersset (r643)
17:37:08  *** Yexo has quit IRC
17:38:29  *** Yexo has joined #openttdcoop.devzone
17:45:00  <Ammler> Yexo: btw. dunno if know already. It is now possible to push with html and devzone credentials
17:45:24  <Yexo> does it matter? do you want me to change?
17:45:32  * Yexo is happy with his ssh key
17:45:36  <Ammler>
17:45:38  *** Seberoth has quit IRC
17:45:38  <Ammler> no
17:45:43  <planetmaker> no. But just add Alberth to the list of contributors and he has commit rights
17:45:50  <Yexo> ok :)
17:45:51  <planetmaker> (if he has an account, dunno)
17:45:53  <Ammler> just if you like to add someone else to your DevTeam :-)
17:46:25  <planetmaker> contributor? developer I think
17:46:41  <Ammler> Manager and Developer afaik
17:46:49  *** Seberoth has joined #openttdcoop.devzone
17:47:13  <planetmaker> yeah
17:50:21  <Webster> Latest update from devactivity: OpenTTD-GUI - Revision 15257: Merge trunk r19881 <> || FIRS Industry Replacement Set - Feature #955 (New): Some company colours clash with industry sprites <> || OpenTTD-GUI - Revision 15256: (svn r19881) -Fix [FS#3827]: pay for the rail/road when constructin... <> || OpenTTD-GUI - Revision 15255: (svn r19880) -Fix: [NoAI] AIEngine::IsValidEngine() and AIEngine::I... <> || OpenTTD-GUI - Revision 15254: (svn r19879) -Codechange: Also hide invalid engines from purchase l... <>
18:04:18  <Brot6> test: abort: push creates new remote heads!
18:11:17  *** GT has joined #openttdcoop.devzone
18:12:16  <GT> Why is r 34  nightly of 32bpp-extra failing, there isn't even a rev 34?
18:14:02  <yorick> because ammler is messing with the things
18:15:03  <Ammler> GT, I added new devzone settings
18:15:21  <Ammler> why do you think, it is failing?
18:17:13  <yorick> because there isn't a rev 34?
18:17:31  <Ammler> ah ok, get you... :-)
18:18:42  <Ammler> will update...
18:19:08  <Ammler>
18:19:31  <Ammler> r34 was just missing in Redmine, it was in the Repo
18:20:40  <yorick> and it's also failing
18:20:50  <Ammler> how?
18:20:56  <Ammler> please be a bit more specifiy
18:20:59  <Ammler> c
18:21:10  <yorick>
18:21:21  <yorick>
18:22:41  <Webster> Latest update from devactivity: NFO Meta Language - Revision 174: Change: use new style python classes (Alberth) <> || 32bpp-extra - Revision 34: DevZone: enable nightlies compiler <>
18:27:50  <GT> 32bpp_extra-nightly-r34-source is mkdir-ed twice, failing the second time, might be something in the bundle_src,  I dont think is was executed before
18:27:52  <Ammler> yorick: well, could be silenced...
18:28:00  <planetmaker> Ammler: what's the push-URL with redmine credentials?
18:28:04  <planetmaker> (See #openttd)
18:33:41  <GT> Also fails for r33, so I guess that has been changed now, that the src bundle is generated in the nightly
18:35:28  <Ammler> GT, we aren't sure, if we shall provide source packages with nightlies
18:35:41  <Ammler> as you can can always use the repo :-)
18:36:18  <GT> Well, I'll take a look, bundle src should work too, whether you provide it or not, it is a target in the makefile
18:36:53  <GT> Src may be convenient for people that dont use hg.
18:37:06  <yorick> and patches would be more convenient
18:37:43  <GT> yeah, and most convenient is to provide both, that is what is being proposed
18:38:04  <GT> If I understand correctly
18:40:16  <Ammler> <-- you could simply remove it here
18:40:30  <Ammler> as we need a special files file for your grf anyway
18:41:00  <Ammler> also if there is a special build script needed, copy the spec file there
18:41:16  <Ammler>
18:41:44  <Ammler> <-- that is used, if there is no spec file in the project itself
18:42:07  <Ammler> example for custom config:
18:42:35  <Ammler> oh, need to commit my local changes
18:48:38  <Brot6> test: compile of Version1 failed -
18:48:39  <Brot6> Following repos didn't need a releases update: 2cctrainset (Beta1), opengfx (0.2.4)
18:48:47  <Ammler> hmm
18:52:51  <Webster> Latest update from devactivity: NFO Meta Language - Revision 177: -Fix: Make cargotable_list parse rule left recursive. <> || NFO Meta Language - Revision 176: -Codechange: Add some lines and spaces for better readability. <> || NFO Meta Language - Revision 175: -Codechange: Removed white space at end of line. <>
19:00:12  <GT> Ok, found it, MAKEFILE_LOCAL macro was missing from .def file
19:01:02  <Ammler> ?
19:02:55  <GT> When generating the bundle_src, it uses a MAKEFILE_LOCAL macro. That one was missing from the Makefile.def in scripts dir, so source bundle generation failed.
19:04:02  <Ammler> do you regulary update the Makefile Framework?
19:04:15  <Ammler> dunno, if planetmaker does that for you
19:04:23  <GT> Even when I would disable it in the devzone build files, I still like the makefile to be OK
19:04:55  <planetmaker> I didn't so far touch that project. I'm under the impression that GT wanted to deal with those himself
19:05:41  <GT> PM: No, in the beginning I did it  a few times, but having a slightly different dir-structure, it was kind of timeconsuming to diff, so when things looked ok for me, I did not update anymore
19:06:16  <planetmaker> right :-) Different dir structures make it tedious
19:06:55  <planetmaker> is it still a different structure?
19:07:13  <GT> I have a sprites dir for the 32bpp sprites, and grf-def for the grf definition, seemed logical to me
19:07:38  <planetmaker> grfcodec needs a dir called sprites
19:07:53  <GT> No, it doesnt with the right options
19:07:55  <Webster> Latest update from devactivity: NFO Meta Language - Revision 181: Use 'is (not)' for comparing with singleton None. <> || 32bpp-extra - Revision 35: Fix:MAKEFILE_LOCAL macro missing for source bundle generation <> || NFO Meta Language - Revision 180: -Fix: Make switch_body parse rule left recursive. <> || NFO Meta Language - Revision 179: -Codechange: Introduce switch_value parse rule. <> || NFO Meta Language - Revision 178: -Fix: Make conditional parse rule left recursive. <>
19:07:59  <planetmaker> that's what dictates the structure of the Makefile projects did
19:08:00  <GT> I modified that
19:08:06  <planetmaker> well then
19:08:55  <Ammler> that is ok and was the reason for my r34
19:09:07  <Ammler> so we have a compiled nfo with sprite numbers
19:10:20  <Ammler> it is quite important for 32bpp authors to know those numbers, you should somewhere explain that
19:10:32  <Ammler> (or do you already and I missed that?)
19:10:57  <Ammler>
19:12:40  <Ammler> shall I make a symlink latest to the current rev?
19:13:38  <GT> Ok, or just wait til tomorrow, no big problem
19:14:08  <Ammler> what is tomorrow?
19:14:47  <Ammler> [21:12] <Ammler> shall I make a symlink latest to the current rev? <-- that was a generic compile farm question :-)
19:14:49  <GT> A new nightly, but you dint mean that.
19:15:44  <GT> you're right, when authors dont have the resulting nfo, it is hard to find the numbers.
19:16:23  <Ammler> GT, as in your grf, those shouldn't change, you could also mention those in the source...
19:16:37  <Ammler> hmm, I made a ticket about
19:16:45  <GT> I saw it
19:16:57  <GT> I made some very little doc:
19:17:06  <Ammler> I also recently splitted the ogfx-extra, if you like me to do that for you too
19:17:17  <GT> But that is not enough for detailed sprite numbering
19:17:23  <Ammler> maybe splitting the files like that sprite-ranges.txt
19:18:03  <GT> And yes, splitting up is a good idea too, I will take a look at ogfx-extra, I will come back to that later
19:21:14  <GT> Maybe coding them in nml later would be nice, as no fancy stuff is done anyway in this newgrf
19:26:53  <planetmaker> *especially* fancy stuff makes sense in NML
19:27:09  <planetmaker> and yes, I thought about using NML on OpenGFX, too
19:30:40  <GT> Yes, but the simple stuff will be implemented first I guess
19:32:40  <Ammler> opposite, they implemented the fancy stuff first :-)
19:38:57  <Webster> Latest update from devactivity: NFO Meta Language - Revision 183: -Fix: Better regular expression for string literals (yorick, cl... <> || NFO Meta Language - Revision 182: -Fix: Hexadecimal numbers run up to F (yorick, bug #951). <> || NFO Meta Language - Bug #951 (Closed): Yorick's issues <> || 32bpp-extra - Revision 36: Cleanup (#953): Remove unneeded lines from pnfo <>
19:39:04  <GT> Smart, when that's possible, the rest is only work
19:40:03  <GT> Anyway, I do follow it, but I'll wait till it's more or less stable before converting the 32bpp-extra grf.
20:12:38  * yorick is looking for nml stuff to do again
20:13:14  *** Alberth has joined #openttdcoop.devzone
20:13:32  <Alberth> much more useful :p
20:13:59  * yorick is looking for nml stuff to do again(repeat for Alberth)
20:14:43  <Alberth> I don't understand "to do again"
20:15:18  <yorick> skip the again then
20:16:07  <yorick> as in "def t_error(t): print "I don't understand %s" % t.value; t.lexer.skip(1)?
20:16:22  <yorick> "*
20:17:04  <Alberth> I would find a manual very useful, as I have no clue how to write one letter of nml.
20:17:14  <yorick> neither do I
20:17:15  <Alberth> Also, I was wondering about town names
20:17:36  <yorick> I think planetmaker does
20:17:46  <Alberth> but I think they are not supported
20:17:57  <planetmaker> that *might* be
20:18:04  <planetmaker> I haven't tried with town names
20:18:22  <Alberth> and last but not least, in t_number(), the overflow error will never happen, what is the point of that?
20:18:53  <yorick> I think to stop it from writing multiple bytes or so
20:19:41  <Alberth> hmm, perhaps make a bug report :)
20:21:51  <yorick> I can pump in 1 << 10000 without overflowing
20:22:19  <yorick> and 100000 :P
20:22:24  <Alberth> any value less than infinite will work
20:22:50  <Alberth> python has infinitely (up to computer memory) large integers
20:22:51  <yorick> that's quite some range
20:23:12  <yorick> I think it expects you to be running on 64k computers
20:23:38  <Alberth> I never had one of those :p
20:23:54  <Alberth> my first one had 32K, my second one 16MiB
20:24:30  <Alberth> hmm, not true, my second one had 1MiB
20:25:22  <Alberth> there is also some code that does complicated computing for a 32 bit value, which seems quite useless with python integers :p
20:27:00  <planetmaker> well, but NFO has certain bounds which need observing. The NFO math has to be replicated
20:27:45  <Alberth> agreed
20:39:27  <Webster> Latest update from devactivity: NFO Meta Language - Code Review #956 (New): useless ValueError exception handling in t_number() i... <>
20:45:23  <Alberth> I read that as "de-vactivity"     :p
20:45:58  <planetmaker> :-P
20:46:26  <Alberth> good night
20:46:56  <planetmaker> good night
20:47:39  *** Alberth has left #openttdcoop.devzone
20:48:21  <yorick> night
20:51:07  <planetmaker> night, yorick
20:51:59  <PeterT> did I tell you I got tor setup, Ammler?
20:53:49  <yorick> I mean night Alberth :)
20:54:28  *** PeterT_ has joined #openttdcoop.devzone
20:54:28  <PeterT_> here I am!
20:54:28  *** PeterT_ has left #openttdcoop.devzone
20:54:37  <PeterT> See ^^
20:56:16  <Ammler> do you also offer a exit?
20:57:45  <Ammler> I liked to setup tor on our vserver, but then the big server downs started and I trashed the idea :-)
20:58:29  <Ammler> and you need a own ip else it might happen you get banned :-)
21:02:47  <PeterT> an exit?
21:03:00  <PeterT> I won't allow anyone to connect to my tor, if that's what you mean
21:03:28  <Ammler> that's a router or gate, dunno anymore
21:03:43  <Ammler> exit is where others leave tor
21:03:51  <Ammler> else you do only transfer
21:04:00  <PeterT> ?
21:04:13  <PeterT> others leave tor?
21:04:25  <Ammler> maybe you should read a bit, how tor works :-)
21:04:47  <Ammler> long ago I read about, not sure anymore...
21:05:16  <Ammler> PeterT: think about, how you get your "new" ip
21:05:40  <PeterT> you bounce through other tors, right?
21:05:49  <Ammler> yes, like yours
21:06:22  <Ammler> and mostly, you leave tor ar you don't have that origin:address or how those are called
21:06:28  <Ammler> as*
21:06:28  <PeterT> nobody bounces through my tor
21:06:32  <PeterT> It's only a client
21:06:49  <Ammler> and clients need tors to connect
21:07:01  <Ammler> are you sure?
21:07:09  <PeterT> I looked specifically
21:07:39  <Ammler> you are checking the traffic with etheral or so?
21:07:43  <PeterT> under "setup relaying"
21:07:49  <PeterT> it is "use client only"
21:07:57  <Ammler> then we should ban you :-P
21:08:00  <PeterT> "Run as client only" rather
21:08:02  <PeterT> Why, Ammler?
21:08:17  <PeterT> I don't want people using my connection to do their dirty browsing :-P
21:08:24  <Ammler> because you just use it instead giving something back
21:08:55  <PeterT> I won't give something back as I risk getting in trouble
21:09:23  <Ammler> and why you use it?
21:09:40  <PeterT> try it out :-)
21:09:45  <Ammler> as long as you aren't a exit
21:09:46  <PeterT> why do you use it?
21:09:56  <PeterT> I have no idea what an exit is
21:09:57  <Ammler> it is kinda hard to impossible to track you
21:10:24  <Ammler> points where you leave tor network
21:10:42  <yorick> ok good night all
21:10:44  *** yorick has quit IRC
21:10:56  <PeterT> So, connections bounce around and around, then use "exits" to stop connection completely?
21:10:59  <PeterT> that makes no sense
21:11:17  <Ammler> you use it and have no idea how it works :-)
21:11:25  <PeterT> indded
21:11:27  <PeterT> *indeed
21:13:04  <Ammler> tor is mainly for Chinese or other boycott countries
21:13:21  <PeterT> so why do you use it?
21:13:56  <Ammler> I don't
21:14:01  <Ammler> why should I?
21:14:04  <PeterT> you're in #tor randomly?
21:14:23  <Ammler> hmm, I am interested in setup a exit node.
21:14:48  <PeterT> Ok, I will have to look into what exit nodes do
21:14:57  <PeterT> because I still have no idea what "leave tor network" means
21:15:22  <Ammler> is a exit
21:18:21  <Ammler> s/am/was/
21:19:12  <Ammler> I can't "abuse" my vps anymore with the whole devzone stuff on it...
21:28:08  <planetmaker> :-P
21:28:19  <GT> *GT wonders how to update a repo with an applied patch in parallel with a patch q
21:28:51  <planetmaker> like you'd update a repo w/o patch
21:29:37  <GT> No, the patch application creates a new changeset, that will be a new head when pulling from the clean ottd repo
21:30:13  <Ammler> hg qpop -a && hg pull -u && hg qpush ?
21:31:33  <GT> No, once you've applied the patch in the main repo, and committed, there is a changeset that will be a new head when pulling
21:32:27  <Ammler> but qpop does "revert" that
21:32:36  <Ammler> then your repo is again like trunk
21:32:41  <GT> And when you merge that, you cannot qpush anymore, cause the changes are already there
21:32:52  <Ammler> but why should you do that?
21:33:23  <GT> It's not like trunk when you qpop, cause the extra changeset is already pushed/committed, and you cannot undo that
21:33:36  <GT> That works only locally
21:33:54  <GT> Like strip only works locally
21:34:16  <Ammler> hmm
21:34:45  <Rubidium> can't you just pull & merge?
21:35:10  <Ammler> you shouldn't commit something to trunk repo
21:35:55  <planetmaker> GT: you can hide unused / wanted heads
21:36:03  <GT> sure, but then the changes wont be in the patch q, cause when I pull from clean ottd, the patch is not applied anymore in the extra head that is created
21:36:18  <GT> pm: How, but closing it?
21:36:23  <planetmaker> ok, so you want that changeset rather be moved to the patch queue?
21:37:33  <GT> Updating against an upstream repo, without the patch applied is easy, updating a patch q is easy with the help of qsave, but doing both drives me crazy
21:38:41  <planetmaker> hg commit --close-branch -m 'close badbranch, this approach never worked'
21:38:56  <planetmaker> it also works for un-named branches, aka heads
21:39:04  <GT> Only thing I've found is pulling, then merge, then hg diff > .hg/patches/....diff
21:39:54  <GT> PM: closebranch does work ok?
21:39:58  <planetmaker> you can export a revision right now hg diff -rX:Y > file.diff.
21:40:01  <planetmaker> yes, it does
21:40:19  <Ammler> I don't see, why qpush shoud make multiple heads
21:40:31  <Ammler> that would only happen, if you pull after
21:40:49  <GT> qpush doesn't, the pull does, trying to find the ancestors
21:41:06  <Ammler> yes, that is why you could qpop before pull
21:41:30  <planetmaker> before updating a repo, you need to hg qpop -a
21:41:38  <GT> yes, but again, that only works locally, the changeset is still in the repo
21:41:48  <Ammler> it isn't
21:42:04  <Ammler> at least I don't see something here
21:42:24  <Ammler> if I qpop, the repo is again vanilla trunk
21:42:26  <GT> It is, or the patch is not applied or pushed, leaving a clean upstream repo
21:43:18  <Ammler> it is applied but not commited
21:43:55  <Ammler> if you qpush, you get a new head
21:43:56  <GT> yes, if I qpop, the repo is clean again, but then there is no use to push, cause it would only replicate the clean ottd repo.
21:44:27  <Ammler> yes, why should you want to push the main repo?
21:45:03  <GT> To have a repo with an applied patch for the compile farm for instance
21:45:30  <Ammler> hmm, should we make a script and let the server do that?
21:45:38  <Ammler> shouldn't*
21:46:05  <GT> Yes, that would be the ideal situation
21:46:41  <Ammler>
21:46:45  <planetmaker> <-- I recommend that procedure with mq
21:46:46  <Webster> Title: MqMergePatches - Mercurial (at
21:48:05  <GT> PM: That is what I use, and that works perfectly, but only when you have an upstream repo where the patch is not yet applied. Once it is applied, you're in trouble
21:48:54  <GT> Either the patch can not be qpushed anymore, because it is already applied, or you have double heads
21:48:54  <planetmaker> yeah. just remove the patch from the queue
21:49:11  <planetmaker> I don't understand the double heads, though
21:49:17  <planetmaker> the queue will just fail
21:50:06  <planetmaker> but you can always manually edit .hg/patches/series
21:50:10  <GT> Try it: qpush, push, qpop, pull from main repo
21:50:19  <planetmaker> uh?
21:50:20  <Ammler> we should also support hg qclone
21:50:39  <planetmaker> why should I push the repo with applied patch queue?
21:50:45  <Ammler> means putting the patch queue repo to .hg/patches
21:51:07  <GT> PM: to have a full repo with the patch applied for e.g. CF
21:51:22  *** frosch123 has quit IRC
21:51:32  <planetmaker> in that case indeed the only way is to have several heads
21:51:35  <planetmaker> nothing bad about that
21:51:37  <GT> and series file does not help, status file might, but is not recommenden by selenic
21:51:58  <planetmaker> or use different repos for that. That's what I'd do
21:53:09  <GT> How do I imagine that?
21:53:23  <Ammler> we could also simply apply the patch to trunk tip and commit then make compile and rollback trunk
21:53:29  <GT> pull from ottd, apply patch, push, and then?
21:53:48  <Ammler> rollback
21:54:42  <Ammler> but we liked to keep a merged repo _with_ history
21:55:01  <GT> Ammler, that would be best: to have a temp repo against main ottd, apply a patch , ping the CF, dump the bins, pop the patch again and do the next one
21:55:33  <Ammler> yes, that would it be, if we don't have a better idea :-)
21:56:27  <Ammler> we could do that with tag, as soon as you tag your patch queue, the server creates a repo, where the whole queue is applied
21:56:28  <GT> Ammler, I think the history will be a big search, being inbetween all the main ottd commits. Best overview gives the patch q history, but not for the individual files
21:56:54  <GT> Ammler: That actually sounds like a nice idea
21:58:01  <Ammler> GT, if we do something automatically, the commit message could add a prefix like "[<project>] your patch queue message"
21:58:18  <Ammler> then you can simply filter the log for "[<project>]"
21:58:36  <Ammler> hmm
21:59:48  <Ammler> <-- with qpush
22:00:02  <Ammler> <-- without
22:00:47  <Ammler> we could also add a hook server side so the patch queue got automatically qpoped after push
22:04:10  <GT> I think we dont even need to do that, imho every push should be compilable
22:04:30  <GT> Referring to the special commit message
22:05:14  <Ammler> well, that was refering to your "big search"
22:06:01  <GT> Ok, sorry, slight misunderstanding, you're right for that purpose
22:06:45  <Ammler> he
22:06:51  <Ammler> that works
22:07:19  <Ammler> if you clone (not qclone) a repo with pushed patches, you get the patches too
22:07:30  <Ammler> (applied)
22:07:48  <Ammler> tested with
22:08:09  <Ammler> so we need nothing special on server side
22:08:30  <GT> Correct, but when you do a pull after that, you'll have double heads
22:08:46  <Ammler> the server doesn't pull
22:09:08  <Ammler> well, it does, but then you simply qpush
22:09:14  <Ammler> qpop -a*
22:10:00  <Ammler> the question is when do you pull the main repo?
22:10:24  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 842: Feature: prevent General Stores building too close ... <>
22:10:27  <Ammler> and when should the server pull?
22:11:01  <GT> Right, then the server doing the clones won't have a problem, but the dev that maintains the repo with pushed patches will have the problem I described.
22:12:02  <Ammler> he does the same
22:12:09  <Ammler> qpop -a before pull
22:12:17  <Ammler> I don't see the issue
22:13:18  *** Yexo has quit IRC
22:13:19  <Ammler> (you can't push to the main repo)
22:15:34  <Ammler> and you have a file in the patch queue repo which tells the server to which rev it has to pull
22:16:11  <Ammler> is that too simple?
22:16:21  <GT> Well, it's complicated, I'll try to explain again: if he does a qpop -a he will have a clean upstream repo again. There is no use to push that, since is only a copy of the upstream repo. Once you apply the patch, it will create a changeset, that is not in the upstream repo
22:16:54  <Ammler> hg qpop -a && hg pull -u -r`cat .hg/patches/.trunk.rev` && hg push -a
22:17:00  <GT> When you push that, you are perfectly able to make a clone of it, having the patch applied
22:17:50  <GT> But when you push that, every subsequent pull, will create double heads
22:17:51  <Ammler> as said, the main repo is "push protected"
22:18:02  <Ammler> only the server can pull trunk.hg
22:19:45  <Ammler> with tag, you set a "lock", the main repo won't update until the finger is written (from CF)...
22:23:46  <GT> OK, still have the feeling we're talking about different things. Let's clarify with an example:
22:24:04  <GT> Suppose I have an 32bpp-ez-patch queue repo
22:24:32  <Ammler> in trunk.hg/.hg/patches
22:25:01  <GT> It would be perfectly possible for the server to have a clean ottd repo, and apply the 32bpp-ez-patch diff to that
22:25:22  <Ammler> yes, hg qpush -a
22:25:58  <GT> Then let the CF do it's thing, sync the bundles and we're fine
22:26:37  <GT> But the thing I'm talking about is to also have a repo 32bpp-ez.
22:27:16  <Ammler> yes, that is the repo CF uses
22:27:24  <GT> I cannot update such a repo with the patch, without having double heads
22:28:04  <Ammler> yes, you can't, why should you?
22:28:26  <Ammler> you either work with the queue or with repo
22:28:49  <GT> I could push an applied patch, and pull and merge again, but I cannot update the 32bpp-patch-queue repo, cause the changes are already applied
22:29:16  <Ammler> why do you like to maintain also a merged repo?
22:29:38  <Ammler> that is what I wonder since we started this discussion :-)
22:29:57  <GT> Only reason would be to have a repo with patch applied for the ottd CF
22:30:35  <Ammler> that would be done by the server
22:30:36  <GT> But when it can be arranged with a clean ottd repo on the server, I have no need to have a merged repo
22:30:46  <Ammler> devs (you) never have to care about that repo
22:30:59  <GT> We agree :)
22:31:33  <GT> Only thing is that currently it's not yet in place, thats why I thought we would need such a repo
22:31:39  <Ammler> I thought you like maintain a merged repo for history reason, so someone can see "trunk" changes over time
22:32:20  <Ammler> What we need now to do is moving the patch queue repos to .hg/patches of trunk.hg
22:33:06  <Ammler> then also qclone would work
22:33:21  <GT> or pull from there
22:33:35  <Ammler> yes, of course
22:33:39  <Ammler> and push
22:33:41  <GT> what does qclone do? Don't think Ive used it
22:33:58  <Ammler> qclone does clone both at once (main repo and patch queue)
22:35:39  <Ammler> do you have an alias for "hg push -R.hg/patches" or something like that?
22:36:12  <GT> like hg qcommit?
22:36:30  <Ammler> yes
22:36:48  <Ammler> might also be something like "cd .hg/patches && hg push"
22:37:07  <Ammler> dunno, how -R works
22:37:35  <Ammler> hmm, also not sure, what qcommit is :-)
22:37:53  <Rubidium> -R just gives a path to the repository root
22:38:03  <Ammler> my only issue is, how to "protect" server main repo from devs push
22:38:15  <Rubidium> so yes, it's like cd $path && hg push
22:38:38  <Ammler> maybe some simple hooks
22:38:58  <Ammler> with echo "try again with patch queue :-P"
22:40:26  <Ammler> I should test that with
22:43:16  <GT> This command is shorthand for hg 	  commit --cwd .hg/patches
22:43:27  <GT> From the red beans pages
22:44:18  <GT>
22:46:56  <GT> <Ammler>my only issue is, how to "protect" server main repo from devs push
22:47:21  <GT> Does this mean every dev with ssh access can push to every repo?
22:48:31  <GT> Never looked into hg access rights, but wouldnt a chgrp server do the trick
22:51:08  <Ammler> yes
22:51:23  <Ammler> https push is restricted to redmine permissions
22:51:29  <Ammler> but ssh is global
23:13:32  *** GT has quit IRC
23:40:36  <Webster> Latest update from devactivity: OpenTTD-GUI - Revision 15259: - Fix: Mercurial version detection didn't quite work for uncommited... <> || OpenTTD-GUI - Revision 15258: Merge trunk r19881 <>
23:43:56  *** Yexo has joined #openttdcoop.devzone
23:50:01  <Ammler> planetmaker: hg parents --template="{node|short}"
23:52:48  <Ammler> hmm, it is the same as hg id -i
23:53:27  <Ammler> why do you cut?
23:55:02  *** KenjiE20 has quit IRC
23:55:42  <Webster> Latest update from devactivity: NFO Meta Language - Revision 185: Fix: print switch ranges without a return value correctly to nml <> || NFO Meta Language - Revision 184: Fix: parsing the switch block was broken <>
23:57:35  <planetmaker> try out with a not-commited merge and see what it gives. And try what a hg log with that result returns
23:57:47  <planetmaker> the FS entry i made this night explains it :-)
23:58:23  <planetmaker>

Powered by YARRSTE version: svn-trunk