Config
Log for #openttdcoop.devzone on 24th July 2014:
Times are UTC Toggle Colours
11:36:04  *** Alberth has joined #openttdcoop.devzone
11:45:58  <planetmaker> btw, Alberth http://dev.openttdcoop.org/issues/3739 might be something we can implement now :)
11:46:05  <planetmaker> in NML
11:47:37  <Alberth> oh, I wondered whether the link wasn't striked out, but it was another bug tracker :p
11:47:55  <planetmaker> :)
11:48:15  <V453000> would make a lot of sense :)
11:48:30  <planetmaker> it seems to work, but I didn't extensively test or check it. And I didn't exactly understand it yet - need to understand the underlaying NFO for that
11:48:49  <planetmaker> hehe, Alberth :) I wondered yesterday the same thing :)
11:52:29  <Alberth> a V would be happy probably :)   hyhy btw
11:53:03  <Alberth> I don't understand what it actually does, it seems to switch to an extended action 1 form
11:53:40  <Alberth> tbh I would expect nml to use the old form if you don't have this need
11:54:00  <planetmaker> yes. And - as I understood frosch yesterday - to reference differently-sized sprite sheets in the same layout
11:54:03  <Alberth> also nicer for existing newgrfs
11:54:29  <planetmaker> thus make some things easier to write / with less boiler-plate
11:54:31  <Alberth> but perhaps there are limitations in how you can combine them?
11:54:47  <planetmaker> nml would simply always use extended action1 then
11:54:54  <planetmaker> no reason not to :)
11:55:05  <Alberth> md5 sum existing newgrfs?
11:55:20  <planetmaker> it would change the output of nml, yes
11:55:33  <planetmaker> but what about the md5sum of existing grfs?
11:57:32  <DevZone> Project Dutch Tramset build #41-push: FAILURE in 5 sec: https://jenkins.openttdcoop.org/job/dutchtramset/41/
11:57:39  <Alberth> they would change, wouldn't they?
11:57:50  <Alberth> or is that not a problem?
11:58:09  *** Jasper has joined #openttdcoop.devzone
11:58:25  *** Jasper is now known as FooBar
11:58:36  <planetmaker> Alberth, it's not a problem. All we need to do is adopt our regression tests
11:58:54  <Alberth> kk
11:59:00  *** FooBar is now known as Guest3706
11:59:03  <planetmaker> and yes, a re-build of an existing grf would give a different result. But that's a common thing when changing NML, so nothing special
11:59:44  <Alberth> hi hi foobar / Guest3706.
11:59:47  <planetmaker> we never guarantee the output to remain constant between versions. We can't, even when we try :)
11:59:54  <Guest3706> hi Alberth
12:00:14  <planetmaker> hi hi :)
12:00:20  <Guest3706> I need to re-figure-out how to log in with my old name
12:00:26  <Guest3706> and what my password is
12:01:15  <planetmaker> :) you might have had an e-mail registered, then you can use that to reset pw
12:01:28  <planetmaker> if not... dunno :) ask in #oftc
12:01:47  <Alberth> probably read the faq first :)
12:02:52  <Alberth> omg, action1 keeps 'old' spritesets now, for each feature :)   Nice if you want to figure out what you have defined at one point :p
12:03:36  <Alberth> ok, always using extended format looks like the way to go
12:06:30  *** Guest3706 is now known as FooBar2
12:06:39  <FooBar2> meh, I cannot be bothered
12:06:55  <Alberth> :)
12:07:24  <FooBar2> Anyways, planetmaker (or somebody) I was to ask if you could do this findversion.sh magic on the dutchtramset repo as well
12:07:55  <planetmaker> pull, FooBar2 ;)
12:08:02  <planetmaker> I committed and pushed that last evening :P
12:08:13  <planetmaker> when I saw that misery and no follow-up push :P
12:08:37  <planetmaker> (or was that another repo?)
12:08:58  <FooBar2> yes, thanks for that. I forgot, but it's also impossible to do from Windows
12:09:20  <FooBar2> Now I have updated the dutchtramset makefile as well, so that is going to need the same treatment
12:09:21  <planetmaker> might have been another.
12:09:37  <FooBar2> yes, that was dutchtrains last night
12:09:56  <planetmaker> there you go also for trams
12:10:15  <planetmaker> you don't use the VM approach anymore, eh? :)
12:10:16  <Alberth> who invented this trams-2cc?   it's a bit of a boring name
12:10:18  <DevZone> Yippee, build fixed!
12:10:19  <DevZone> Project Dutch Tramset build #42-push: FIXED in 26 sec: https://jenkins.openttdcoop.org/job/dutchtramset/42/
12:10:35  <FooBar2> planetmaker: thanks!
12:10:55  <planetmaker> you're welcome
12:10:57  <FooBar2> And yes, don't use the VM anymore.
12:11:35  <FooBar2> But I tried it again to chmod the file, but that proved impossible for a virtualbox mapped windows drive
12:12:11  <FooBar2> all file rights on that mapping are 770, chmod (from root) didn't change anything
12:12:45  <FooBar2> Alberth: that would be me. 2cctrams was forbidden according to the rules ("may not start with number")
12:13:15  <Alberth> kk
12:13:28  <Alberth> 2cc is the most distinguishing feature of the set?
12:13:41  <planetmaker> the rules are... pointless, I think. Not sure why redmine claims so, but it would work, as far as I know
12:14:48  <Alberth> planetmaker: not entirely, package management systems, or archiving systems may get hopelessly confused
12:15:05  <Alberth> they often work with  name-versionnumber
12:15:14  <FooBar2> Alberth: the project isn't my idea, I'm just coding it :)
12:15:28  <FooBar2> name can be changed later, this is just the identifier
12:16:13  <Alberth> not sure you can that easily, these names get used as identification, not easy to change people's mind :)
12:16:31  *** yorick has joined #openttdcoop.devzone
12:18:45  <planetmaker> afk for a bit
12:18:51  *** FooBar2 is now known as FooBar
12:19:39  <FooBar> there, I fixed it
12:19:50  <FooBar> the nickname, that is
12:21:40  <FooBar> I'm surprised the registration still exists, after all this time
12:27:03  <Alberth> no other foobars on irc, apparently :)
12:27:27  <FooBar> I did get a change password email a while back though, I didn't ask for that
12:27:48  <FooBar> so I ignored it then
12:28:11  <FooBar> was useful though, so now I knew I had an email address registered :)
12:33:58  <Alberth> iirc if you don't use the name for a while, and another person wants it, they give the other person the name. That didn't happen thus :)
12:35:11  <FooBar> or they didn't change the email address, but that seems unlikely :P
12:40:53  <Alberth> :)
12:50:23  <DevZone> Project Dutch Tramset build #43-push: SUCCESS in 25 sec: https://jenkins.openttdcoop.org/job/dutchtramset/43/
12:50:49  <DevZone> Project Dutch Tramset build #44-releases: SUCCESS in 25 sec: https://jenkins.openttdcoop.org/job/dutchtramset/44/
12:51:10  <planetmaker> back :)
12:51:37  <planetmaker> FooBar, they never delete a nick at #oftc. Unless it's unused for > 6 months and someone wants to have it
12:52:28  <planetmaker> btw, FooBar, a change I plan to implement somewhen with devzone, but you might prepare for it
12:52:50  <FooBar> what is it?
12:52:51  <planetmaker> the .devzone/build/pull/enable and .devzone/build/releases/enable files
12:53:08  <planetmaker> they hadn't been observed for some time, but I plan to make use of them again
12:53:25  <FooBar> ah, that may actually explain something
12:53:26  <planetmaker> any project which hasn't them wouldn't build. Dunno whether you have them
12:53:43  <FooBar> I believe I have them in place everywhere, but I'll check that to be sure
12:54:07  <planetmaker> no ETA for that yet, but... I think this year ;)
12:54:12  <FooBar> is .devzone/build/nightlies/enable still used?
12:54:42  <FooBar> or is this completely replaced by push
12:54:46  <planetmaker> no file in .devzone/build is currently used. But I don't plan to make use of the nightlies anymore
12:54:59  <planetmaker> only push and releases. And the latest push is promoted once a day to nightly
12:55:44  <planetmaker> I might somewhen think of a "rebuild everything" build job, but not for now
12:55:52  <FooBar> ok, push doesn't create excessive server load? because I don't really need them, but nightlies would be nice
12:55:54  <planetmaker> it would break anyway on old projects
12:56:20  <planetmaker> there's few enough pushes that it really doesn't matter. And it gives feedback when people need it, when they work on it
12:56:23  <planetmaker> instead of once a day
12:56:34  <FooBar> that is true
12:56:44  <FooBar> especially when people like me update the makefile :P
12:56:58  <planetmaker> for instance
12:57:50  <planetmaker> also, you will be able to use the .devzone/build files to control whether you want a particular branch to be build. Every repository tip will now be build, so that might make sense with more branchy setups
12:59:30  <FooBar> I see I don't have the push file everywhere; I'll add those somewhen
13:00:01  <planetmaker> tbh, I'm not sure whether I'll trigger on the exact filename or simply on .devzone/build/*enable ;)
13:00:56  <planetmaker> http://devs.openttd.org/~planetmaker/patches/trigger.diff <-- that's my current approach, not yet live
13:01:25  <FooBar> in that case I'll wait, every project has at least some sort of .devzone/build/*enable
13:02:14  <planetmaker> ok :) Just thought I mention it while you're here. You're not around too often, sadly, I have to say :)
13:02:59  <FooBar> sadly I'm not working on newgrfs very actively the past months/years
13:03:13  <planetmaker> basically I'm unsure whether it makes sense to distinguish push and releases separately for buiding
13:03:14  <FooBar> that comes in waves, now there is a bigger wave so I thought I might come on here
13:03:20  <planetmaker> :)
13:04:00  <FooBar> it may make sense if you only would want releases, but I don't immediately see a use case
13:05:49  <planetmaker> yeah. That's exactly my problem, too :)
13:05:59  <FooBar> so I guess it would be fine if you have either both, or neither
13:06:47  <FooBar> sometimes it's better to have less (configuration) options
13:09:11  <planetmaker> yeah :)
13:12:21  <FooBar> there's this one game that has so many options they had to categorize them as not to overwhelm new players
13:12:37  <planetmaker> yeah, we know it :P
13:27:14  <Alberth> FooBar:  if not str.isdigit(...)  <-- what does the string contain if this holds?
13:27:55  <FooBar> this value comes from the database, so could hold anything
13:28:20  <FooBar> normally either Null or an integer, but with a faulty database it could be anything
13:29:27  <FooBar> but come to think of it I may have implemented that wrongly
13:30:37  <Alberth> http://paste.openttdcoop.org/show/3532/   in that case, your code is broken :)
13:31:14  <FooBar> I guess so
13:31:20  <FooBar> should be something like
13:31:27  <FooBar> str(v['vehicle_life']).isdigit()
13:31:48  <Alberth> kk
13:32:05  <FooBar> I'm used to PHP functions, that clearly shows here
13:32:25  <FooBar> where you'd go
13:32:35  <FooBar> if (is_numeric($val))
13:34:13  <planetmaker> https://jenkins.openttdcoop.org/view/All/builds <-- btw, FooBar. That's about DevZone's activity
13:34:43  <Alberth> If it's always a string, that would help, but I guess you cannot rely on that
13:35:42  <FooBar> planetmaker: that's not too much, even days without anything happening. Building on all push wouldn't hurt I think.
13:36:00  <planetmaker> yeah :)
13:37:10  <FooBar> Alberth: I need to figure out how python handles data types from the database
13:37:48  <FooBar> in PHP everything you read from the database is a string, even integer data types, but with PHP's type conversion that doesn't matter
13:38:29  <Alberth> Never used data bases in anything serious, so no idea
13:38:30  <FooBar> it may be that python respects the data types from the database and that an integer field will be an integer in python
13:39:11  <Alberth> a data base still seems a bit overkill-ish to me, did you consider json?
13:39:42  <FooBar> didn't you make eints? surely that uses a database
13:40:01  <Alberth> https://docs.python.org/2.7/library/json.html?highlight=json#module-json
13:40:02  <Webster> Title: 18.2. json — JSON encoder and decoder Python v2.7.8 documentation (at docs.python.org)
13:40:18  <Alberth> I am quite sure it uses a flat xml file at the disk :p
13:40:33  <FooBar> :)
13:41:04  <Alberth> I know that WT3 uses a data base, and is slow on updating
13:41:12  <FooBar> I know json, but didn't consider it.
13:41:32  <FooBar> would need to make a gui to edit the contents
13:41:45  <Alberth> I guessed you need all strings of a project together always, so it seemed just as simple to just sequentially load everything from a file
13:42:23  <Alberth> which is quite hard to beat with almost anything; OSes are good at reading data sequentially :)
13:42:38  <Alberth> json is a standard, I would guess there are tools for it
13:42:43  <FooBar> true, but ask a json file "give me all liveries for this vehicle"
13:43:20  <FooBar> could be done, but needs more programming
13:43:24  <Alberth> you can have a list or dict of vehicles, and within that a list or dict of liveries
13:43:57  <Alberth> ie you can store the data in a non-flat way
13:44:44  <planetmaker> python has nice json handling libraries
13:44:45  <Alberth> just an alternative you can consider
13:45:25  <FooBar> I know, I'm not against it or anything, just against having to redo everything
13:45:28  <FooBar> maybe for next project
13:46:25  <FooBar> but I guess it would make sense to just store it in a python object then, like andy does
13:48:00  <FooBar> I do like databases though
13:50:17  <Alberth> that much was clear :)
13:51:12  <FooBar> :)
13:51:38  <planetmaker> :P
13:52:47  <FooBar> but thanks for finding that str.isdigit bug
13:57:46  <FooBar> cast as string is necessary though. Null database values are a NoneType in python
13:59:01  <FooBar> maybe I'll do if v == None instead
14:00:01  *** LSky` has joined #openttdcoop.devzone
14:03:06  <Alberth> is None   :)
14:03:22  <Alberth> there was another bug I found somewhere
14:03:40  <Alberth> ok if I dump my findings in a public paste?
14:03:52  <Alberth> (ie the comments I have)
14:04:09  <FooBar> the code is already public, so go ahead
14:06:19  <Alberth> http://paste.openttdcoop.org/raw/3534/
14:07:03  <Alberth>          v['articulated'] = 'length:                         return ' + str(veh_lengths[0]) + ';' + "\n"
14:07:04  <Alberth>          v['articulated'] = '        cargo_capacity:                 return ' + str(v['capacity'][0]) + ';'   <-- this line overwrites the previous text
14:07:11  <Alberth> that was the other bug :)
14:07:26  <FooBar> thanks! I'll have a look
14:08:39  <Alberth> paste.o.o seems to have a little trouble getting the entire paste.
14:08:39  <Alberth> +    >>> v.model_life  # nice x.y access :)
14:08:39  <Alberth> +    0
14:08:39  <Alberth> +    """          these are the last 3 lines you should have
14:08:47  <Alberth> otherwise get the raw version
14:09:29  <Alberth> quite nice for your first Python program :)
14:11:09  <FooBar> you linked the raw, so I have the three lines ;)
14:11:31  <FooBar> and thanks, I'm not entirely new to programming, just op Python
14:12:20  <FooBar> this list/tuple/dict stuff is still a bit of witchcraft to me. In PHP "we" just have an array and that's it
14:12:54  <FooBar> so that certainly is something to get used to
14:15:34  <Alberth> list/tuple is just a sequence of values, while dict is a hash table of key to value, which is bigger in storage. Also, you cannot iterate over the elements of a dict in a known order, the order may change at any time theoretically
14:16:31  <Alberth> a list can have varying number of elements, and you can change the elements like x[3] = 5
14:16:56  <Alberth> that makes a list unusable as key in a dict, which is why there are also tuples
14:17:11  <Alberth> fixed length, and cannot be changed once created
14:17:50  <Alberth> (the tuple that is, you can still mess up the internal value of the elements if they are mutable :) )
14:18:03  <FooBar> yeah, I already found that annoying, hence the v = dict(v) :P
14:19:18  <Alberth> that's quite normal to do :)
14:19:28  <FooBar> oh ok :)
14:19:58  <Alberth> hmm, now I wonder whether namedtuples can be modified, let's check that :)
14:21:19  <FooBar> +            # Wouldn't  len(res_purgui) == len(res) - 2 (rather than == 2) ??
14:21:50  <Alberth> hmm, it cannot :(   sorry, but my last comment about namedtuples is less useful than I thought, you cannot add new fields to a named tuple
14:21:51  <FooBar> res_purgui contains purchase and gui sprite information. There should be always two
14:22:34  <FooBar> len(res_purgui) == len(res) - values['vehicleparts']
14:22:45  <Alberth> oh, you're correct.
14:22:48  <FooBar> would work, but seems less useful because values['vehicleparts'] is already tested
14:23:24  <FooBar> I thought I'd explain that since you had questions yoursef
14:23:27  <Alberth> I got confused by your 'not'  in the condition
14:24:34  <FooBar> the smelly thing about vehicle lengths:
14:25:00  <FooBar> different liveries could technically have different lengths, but that is not supported
14:25:28  <FooBar> therefore I keep the lengths from the first valid livery to use later for all liveries
14:27:03  <Alberth> shouldn't you test 'len(temp_vehicle_lengths) > 0' then?
14:28:19  <Alberth> now you are testing whether you have not found a valid solution previously, rather than having a valid solution now
14:28:50  <FooBar> temp_vehicle_lengths is filled for every livery, so if I test that the condition will be true for the second and further liveries as well
14:29:54  <Alberth> but now, temp_vehicle_lengths could be 0 entries a few time, and you generate code each time
14:30:26  <Alberth> I guess you should check both
14:31:00  <Alberth> is vehicle_lengths == []   a valid solution at the end?
14:31:28  <Alberth> if not, Python uses None in such a case, to denote it's not filled yet
14:32:31  <FooBar> temp_vehicle_lengths could be 0, but then the condition if len(res) == values['vehicleparts'] + 2 and len(res_purgui) == 2: will not be passed
14:33:08  <FooBar> maybe I should test len(res) earlier on
14:33:30  <FooBar> because if that fails, it doesn't make sense to do the other stuff
14:33:37  <Alberth> not if you only define a 'gui' and a 'purchase' thingie?
14:34:05  <FooBar> it shouldn't be allowed to define only a 'gui' and 'purchase' row
14:34:24  <FooBar> there always must be vehicle sprites defined as well
14:35:39  <Alberth> kk, so it fails on 'vehicleparts' not 0 thus
14:36:19  <Alberth> maybe   assert len(res) > 2      ?
14:37:03  <FooBar> vehicleparts must always be larger than 0
14:38:33  <Alberth> if that's a fundamental property to the entire application, it would be ok
14:39:15  <planetmaker> it's fundamentally important, yes. length >= 1
14:39:22  <FooBar> yes, each vehicle must have at least length 1 :)
14:39:37  <planetmaker> and <= 8 :P
14:39:55  <FooBar> that I'm not sure
14:40:10  <FooBar> this is amount of articulated parts, not length of individual part
14:40:14  <FooBar> it's a bit confusing
14:41:08  <planetmaker> oh, sorry :)
14:41:23  <Alberth> 8 articulated parts sounds quite long :)
14:41:55  <FooBar> actually vehicle_lengths is a list that contains the lengths of the parts, such that the length of the list is the number of vehicle parts...
14:45:46  <Alberth> name sounds good to me :)
14:46:24  <FooBar> "+    # The 'return' code above for 'length' and 'capacity' looks identical, you may want to abstract that to a function."
14:46:36  <FooBar> I agree, just couldn't be bothered at the time :P
14:50:01  <FooBar> +def setup_prop(props, name, value):
14:50:10  <FooBar> nice and clean idea, I might steal that :)
15:03:35  <Alberth> :)
15:04:38  <Alberth> for name, default in OPTIONAL_PROPS:  setup_props(v, name, default)
15:05:08  <Alberth> useful if you have more than about 3-4 :)
16:49:17  <DevZone> Project Dutch Trainset build #213-push: SUCCESS in 1 min 30 sec: https://jenkins.openttdcoop.org/job/dutchtrains/213/
16:49:19  <DevZone> Project redfish build #29-push: SUCCESS in 1 min 55 sec: https://jenkins.openttdcoop.org/job/redfish/29/
16:56:07  *** yorick has quit IRC
18:12:31  *** andythenorth has joined #openttdcoop.devzone
18:44:27  *** frosch123 has joined #openttdcoop.devzone
20:07:12  *** yorick has joined #openttdcoop.devzone
20:55:13  *** Alberth has left #openttdcoop.devzone
20:59:17  *** frosch123 has quit IRC
21:02:45  *** oskari89 has joined #openttdcoop.devzone
21:15:53  *** andythenorth has quit IRC
21:27:07  *** LSky` has quit IRC
22:15:58  *** FooBar has quit IRC
22:30:44  *** oskari89 has quit IRC
23:51:58  *** yorick has quit IRC

Powered by YARRSTE version: svn-trunk