Times are UTC Toggle Colours
01:13:44 *** frosch123 has quit IRC 01:45:06 *** gelignite has quit IRC 04:04:01 *** LSky` has joined #openttdcoop.devzone 06:38:04 <DevZone> Project 2ccts build #129-push: SUCCESS in 1 min 27 sec: https://jenkins.openttdcoop.org/job/2ccts/129/ 07:12:48 <planetmaker> juzza1, the answer is very simple: your offsets are totally wrong. See https://rhodecode.openttdcoop.org/pota-ghat/files/ab644fa60ca3e0fadf35858869149100db72eaae/src/waterfeatures.pnml#L24 for correct ones 07:12:52 <planetmaker> mind the signs 07:14:28 <juzza1> the offsets look good to me, if the mask is not used 07:14:39 <juzza1> my sprite sources are not at all in the same format as pota 07:17:01 <planetmaker> additionally your 8bpp 1x does not correspond to the 32bpp in (scaled) size. That's also a prerequesite 07:18:29 <juzza1> did you check the source for that newgrf 07:18:37 <juzza1> the sprite and mask are of the same size 07:24:37 <planetmaker> yes, they are 07:26:14 <planetmaker> but still your offsets are wrong 07:26:33 <planetmaker> as you don't specify the sprite size, the whole file is used. which is WAY too large for a ground sprite 07:27:30 <juzza1> there is a commented line in test.nml where you can check the tile without the mask, it looks fine to me 07:27:45 <juzza1> and does it matter if the overlapping part is fully transparent? 07:28:03 <juzza1> but i will try without any overlapping parts, even transparent 07:28:36 <planetmaker> also fix it to supply a corresponding 8bpp with *the same relative* offsets 07:29:19 <planetmaker> (in principle the mask sprite can work as that) 07:29:55 <V453000> that looks wtf why dont you just animate the water tile? 07:30:31 <V453000> aka apply the mask in whatever program you use 07:30:42 <V453000> and export png sequence 07:31:03 <juzza1> water tiles can only be animated with action colors 07:31:56 <planetmaker> V453000, water can only be animated by action colours in the 8bpp mask 07:32:16 <V453000> oh god 07:32:53 <V453000> I guess chances that it is going to change are low? 07:33:14 <planetmaker> they're extremely low. Much lower than additional ground tile types 07:33:19 <V453000> y 07:33:31 <V453000> well that is quite bad :D 07:34:09 <planetmaker> though... hm... depends on how it's done, I guess 07:43:31 <planetmaker> juzza1, well, when I fix the offsets, everything works fine 07:44:23 <planetmaker> offsets for a ground tile are -32 0. And not -32 -16 07:45:40 <planetmaker> actually, rather -31, 0 07:47:12 <juzza1> did you change the sprites or code only? and could you paste it somewhere 07:48:08 <juzza1> i cant seem to get it working, removed all the extra from those sprites so that they are 256x127, and now only the top half of the sprites get animated 07:48:23 <juzza1> also changed the offsets 07:48:38 <planetmaker> both 07:49:01 <planetmaker> on closer inspection the top half, yes 07:49:20 <planetmaker> but I didn't yet fix the 8bpp sprite 07:52:43 <juzza1> i changed it to use the mask sprite, and also tried to use a downscaled (64x31) version of the mask sprite, no change 08:02:19 <juzza1> looks like the mask of the water tile is somehow affecting the mask of the water tile above it... as the water tiles with no flat water tile below them work ok 08:13:49 <juzza1> for example this situation http://imgur.com/qEKJSwQ the bottom water tile animates properly, but those two arent animated for the parts which overlap with the mask of the the tile below 08:13:50 <Webster> Title: imgur: the simple image sharer (at imgur.com) 08:16:20 *** Alberth has joined #openttdcoop.devzone 08:43:29 <planetmaker> o/ 08:43:50 <V453000> ._. 08:51:09 *** Supercheese has quit IRC 08:59:11 <planetmaker> juzza1, besidest he offsets, I think there's an issue with your 32bpp sprite. It's not 100% transparent where it should be 09:00:02 <planetmaker> when I cut away everything non-tile in the 32bpp sprite it works for me 09:00:31 <Alberth> hi hi 09:05:05 <juzza1> planetmaker: thanks, that indeed fixed it! 09:06:17 <juzza1> will try to figure out what those pixels were 09:07:36 <planetmaker> Been there, done that. It happens when you use the eraser tool or a some paint tools instead of cutting away. 09:09:43 <V453000> :) 09:17:38 <juzza1> indeed the "transparent" pixels had an alpha value of one 09:30:45 <juzza1> also it seems that nml can also crop unneeded transparent pixels from 32 bit images, which is good 09:31:55 <planetmaker> yes, it does 09:33:22 <juzza1> nmlc help message could use some updating ;) wrt the -c parameter 09:36:04 <planetmaker> what should it say? skip the word 'blue'? 09:39:12 <juzza1> or "crop extraneous transparent blue from 8bpp realsprites, and fully transparent pixels from 32bpp realsprites" 09:39:58 <Alberth> the fun part is of course that 8bpp doesn't have transparency :) 09:40:40 <Alberth> in particular "blue transparent" is nice, how do you know it's blue when it's supposed to be transparent? :p 09:41:20 <Alberth> (sorry, just posted a rant on git, still in a somewhat bad mood) 09:42:31 <planetmaker> you can excuse yourself, if you give me the link to the rant :P 09:45:20 <Alberth> https://groups.google.com/d/msg/freerctgame/PYaKE8fVWCU/ClFG-t4HGUEJ apparently 09:45:22 <Webster> Title: Google Groups (at groups.google.com) 09:45:49 <Alberth> ie "migrate to github" topic in that group 09:54:25 <planetmaker> hm, I wonder... whether rhodecode allows cross-server pull requests 09:54:46 <planetmaker> though in principle you can exercise pull requests always yourself by simply pulling from another repo and then merging 09:57:14 <planetmaker> hm, no. Also only rhodecode-rhodecode, if one uses its web interface 10:38:27 <Alberth> pull-requests are a bad feature :p 10:39:31 <planetmaker> :) 10:39:58 <planetmaker> I'm unsure about them tbh. I never really used any. But the problem with them is that one might want to make small amends here and there to the commits 10:40:06 <planetmaker> so... not sure 10:40:21 <Alberth> indeed, you need a simple way to twiddle them :) 10:40:38 <Alberth> git solution to that is rebase, of course 10:40:47 <planetmaker> they probably are better used with hg draft phase where you then can amend the single commits. And then merge the resultant queue to default 10:41:18 <Alberth> I think those are quite comparable 10:41:39 <Alberth> although I never experimented much with "rebase"-like techniques in hg 10:41:51 <planetmaker> depends on how you look at it. draft phase explicitly indicates 'mutable'. While this concept does not exist with git 10:42:16 <planetmaker> and it does not necessarily mean that you need rebase 10:42:22 <Alberth> isn't it just "not pushed" ? 10:43:07 <planetmaker> no. You can set a repository to "non-publishing". Then you can have commits with phase 'public' and phase 'draft' 10:43:17 <planetmaker> draft changesets are exchanged but still considered mutable 10:43:25 <planetmaker> only phase 'secret' is not exchanged 10:44:09 <planetmaker> such repo is more a working repo which allows to easily exchange changesets with collegues 10:44:20 <planetmaker> and to keep working on the queues while allowing updates which propagate 10:44:27 <Alberth> you see both hg and git struggle with the twiddling idea :) 10:44:31 <planetmaker> the old changesets will then be obsoleted (thus hidden) 10:44:39 <planetmaker> but the changesets remain 10:44:58 <Alberth> hg seems to move to a nicer solution 10:45:29 <planetmaker> I heard rumors that git will copy the phases idea :D 10:45:48 <Alberth> of course they do :) 10:46:02 <planetmaker> I think generally it's difficult to find a nice concept for WIP changesets 10:46:21 <planetmaker> the phases and obsolescence markers with hg go the right way, I think, too 10:46:31 <Alberth> yep, vcs is not designed for handling changes that change :) 10:46:32 <planetmaker> the handling of those is not yet finished with core hg 10:46:53 <planetmaker> but several facebook devs work on that 10:47:29 <planetmaker> (they basically hired 2/3 of the hg devs) 10:48:15 <planetmaker> but changes which change always require some form of rebasing. There's little way around that, I think 10:48:51 <planetmaker> as if you change a changeset in the middle, the children always need a rebaseing 10:48:51 <Alberth> and you probably even want that, you need to be able to go back to the previous state 10:49:29 <Alberth> yeah, but children are a bit too strict in accepting changes imho 10:49:39 <planetmaker> yeah. I'll be scared to *not* be able to go back. In case I mess up rebasing and only find out later or so 10:50:02 <planetmaker> what you mean with 'too strict in accepting changes'? 10:50:25 <Alberth> it's just silly that a patch queue dies because I added a line in a file that is later needed as context of a child patch 10:50:27 <planetmaker> you mean you need to rebase too often for too trivial changesß 10:50:36 <planetmaker> *changes? 10:51:10 <Alberth> patch is designed to detect that a source has changed since the patch was created 10:51:15 <planetmaker> ah. Well, that's a problem with MQ rather than with the newer concept of evolve. MQ handles the requires rebases / merges worse than it can be handled with full changesets 10:51:31 <planetmaker> s/requires/required/ 10:51:43 <Alberth> which is good if you have unrelated modifications 10:52:04 <Alberth> but with a MQ you know exactly what patches come nexr 10:52:07 <Alberth> *next 10:52:50 <planetmaker> with changesets you do that, too. Just look at hg log :) 10:53:43 <Alberth> yep, if you stay in the same repository you can figure it all out 10:54:00 <planetmaker> from what I gathered in #mercurial, what is the 'problem' with MQ: it requires some sort of break in the concept in the thinking 10:54:04 <Alberth> although there is of course that problem that at some point you do break a change 10:54:37 <planetmaker> while the goal is to handle everything draft just like normal changesets. So you don't need to think about any difference in handling. Just that you can freely rebase or amend those changesets 10:55:06 <planetmaker> but of course... it doesn't change the fact, that some alterations of history necessarily break descendent changesets 10:55:20 <planetmaker> s/descendent/child/ 10:55:26 * Alberth nods 10:55:57 <planetmaker> it's an inherent problem. Not all changes are compatible with eachother (without thinking) 10:56:13 <Alberth> with patch queues I fully expect that 10:57:02 <Alberth> even patch queues are not flexible enough in my experience 10:57:29 <Alberth> at work I had a queue of 12 patches or so, which I could only test after applying all of them 10:57:46 <Alberth> obviously, you break things at first, so you make changes 10:57:53 <planetmaker> sure 10:58:10 <Alberth> but those changes belong in earlier patches, often in several different ones 10:58:16 <planetmaker> yup 10:58:26 <Alberth> getting them there is a big job in itself 10:58:37 <planetmaker> yes, that's a bit of a pita 10:59:20 <Alberth> hmm, maybe mq should work the other way around, you push changes from the top down to the earlier patches 10:59:23 <planetmaker> I also often write a patch queue. Then I fiddle around and then are left with a 'last' patch which fixes everything and needs be distributed into various earlier patches (and completely be erased itself) 11:00:20 <planetmaker> what one can do in that case is: hg uncommit FILENAME 11:00:34 <planetmaker> hg record (to possibly re-add some hunks) 11:00:53 <planetmaker> hg up -rTARGETCHANGESET 11:00:55 <planetmaker> hg amend 11:01:00 <planetmaker> hg evolve -a 11:01:18 <planetmaker> and rinse and repeat for each patch in the queue until the last changeset is dissolved and distributed 11:01:23 <Alberth> right, "hg uncommit -h" fails :) 11:01:34 <planetmaker> yeah, it's part of the evolve / mutable history extension 11:02:55 <planetmaker> do you use the record extension, though? 11:03:12 <planetmaker> (or at least know) 11:05:24 <Alberth> I have heard of it :) 11:06:40 <Alberth> but usually, my coding problem is too complicated to be messing with vcs things, for me at least 11:07:26 <planetmaker> yeah. That's why I have a messy last commit in patch queues usually. Which then needs careful analysis and putting into the previous changesets. Which is tedious 11:07:47 <planetmaker> vcs indeed easily can distract from the real work 11:09:05 <planetmaker> and it's supposed to be a tool, not a purpose in itself 11:10:14 <planetmaker> thus it also happens half the time, that I get myself a summary patch of the whole queue in a file. And based on that I write it anew in separate patches to show for review (and final commit) 11:11:30 <Alberth> I often make a fresh clone, and open gvimdiff for every file that I touch between the "old" and the "fresh" repo 11:11:55 <Alberth> after copying changes, you can qnew in the fresh one, and qpush in the old one 11:12:45 <Alberth> or do qpush -a and cherry-pick changes, of course 11:16:01 <planetmaker> similar workflow :) 11:16:37 <Alberth> indeed 11:17:00 <Alberth> working on anything? 11:17:54 <planetmaker> just started the centosVM to hopefully recreate windows building for VM now on the correct distro as CF has 11:18:15 <Alberth> always useful :) 11:18:28 <planetmaker> didn't have time as much as I hoped before 11:18:58 <Alberth> build stuff always takes ages to get right, so many bits that can go wrong 11:19:45 <Alberth> testing is always very slow due to long execution times 11:26:50 *** frosch123 has joined #openttdcoop.devzone 11:29:51 <planetmaker> \o 11:30:24 <Alberth> o/ 11:30:52 <V453000> omg mutated horned ponies 12:20:19 *** yorick has joined #openttdcoop.devzone 12:45:15 <DevZone> Project opengfx-mars build #120-push: SUCCESS in 2 min 31 sec: https://jenkins.openttdcoop.org/job/opengfx-mars/120/ 12:45:26 <DevZone> Project Townnames - German build #79-push: SUCCESS in 10 sec: https://jenkins.openttdcoop.org/job/german-townnames/79/ 12:45:27 <DevZone> Project NML - NewGRF Meta Language build #335-push: SUCCESS in 3 min 30 sec: https://jenkins.openttdcoop.org/job/nml/335/ 13:17:19 *** oskari89 has joined #openttdcoop.devzone 13:29:22 *** gelignite has joined #openttdcoop.devzone 13:35:00 <planetmaker> hm... drat. I fail to re-create the python setup I managed to create on my machine which builds nml-py3 13:35:06 <planetmaker> even on my machine I fail to do so :P 13:36:22 <Alberth> :( 13:57:56 <planetmaker> I've the tar of the .wine dir of both, DevZone CF with py27. As well mine with py33, though... but if I copy my python33 to DevZone it crashes quite soundly... 13:59:46 <Alberth> it doesn't say anything? 14:00:18 <Alberth> python33 exists at centos? 14:00:27 <Alberth> sounds a bit too newish 14:00:48 <planetmaker> python33 does not need to exist there. It's the wine thingy 14:00:52 <planetmaker> so it only needs wine 14:00:56 <planetmaker> and the install therein 14:01:02 <Alberth> oh, right 14:02:21 <planetmaker> o-O. My local .wine dir is 290MB as .tgz 14:04:03 <Alberth> you may be missing a few bits then :) 14:21:57 <planetmaker> hm... probably there's for everything exactly one way. While they seem equivalent they are somehow subtly not 14:24:13 <planetmaker> oh, hilarious 14:24:49 <planetmaker> first install easy_install via linux command line: wine "C:\Python32\Pythonw.exe" ez_setup.py 14:25:03 <planetmaker> then enter windows cmd. easy_install.exe pip 14:25:08 <planetmaker> pip install pillow 14:25:11 <planetmaker> pip install pillow 14:25:51 <planetmaker> beware, do not do differently. do things in windows as here, not calling it from linux cmd via wine "C:\Python32\Scripts\pip.exe" install pillow 14:25:59 <planetmaker> or similar. It makes a frigging difference... 14:27:04 <planetmaker> and yes, it needs easy_install in order to be able to install pip. Or so it seems :D 14:27:27 <planetmaker> but it needs pip to get the uncompressed modules installed 14:33:31 <planetmaker> haha. And now there's no pre-compiled windows binary for cx_freeze. And I definitely won't install a compiler within wine :) 15:02:43 * Alberth would expect \ in linux comandlines 15:10:12 <planetmaker> hm, maybe that's what made it fail 15:10:47 <planetmaker> however, in wine cmd it's not needed, so seems to work now somewhat. 15:10:56 <planetmaker> let's see how a copy of the .wine dir performs on CF 15:11:25 <planetmaker> uploading 150MB .xz file now :P 15:12:25 <planetmaker> xz really has a nice compression ratio... >~ 50% here 16:05:33 <DevZone> Project opengfx-mars build #121-push: SUCCESS in 2 min 14 sec: https://jenkins.openttdcoop.org/job/opengfx-mars/121/ 16:05:46 <DevZone> Project Townnames - German build #80-push: SUCCESS in 12 sec: https://jenkins.openttdcoop.org/job/german-townnames/80/ 16:05:47 <DevZone> Project NML - NewGRF Meta Language build #336-push: SUCCESS in 3 min 14 sec: https://jenkins.openttdcoop.org/job/nml/336/ 16:06:50 <planetmaker> right... 2.7. still works 16:07:18 <Alberth> phew :p 16:16:09 <planetmaker> and py3 fails on missing linux python modules :P 16:17:16 <planetmaker> and "phew" is justified if you consider the merging method: take wine-py2.7 and the copy wine-py3.3 onto it, overwriting everything where things are different ;) 16:20:58 <Alberth> wow :) 16:22:03 <DevZone> Project Japanese Buildings build #215-nightlies: SUCCESS in 18 sec: https://jenkins.openttdcoop.org/job/jpbuild/215/ 16:34:12 <DevZone> Project Finnish Rail Infrastructure - Rails build #329-nightlies: SUCCESS in 8 min 27 sec: https://jenkins.openttdcoop.org/job/frissrails/329/ 16:41:22 <DevZone> Project road-hog build #215-nightlies: SUCCESS in 36 sec: https://jenkins.openttdcoop.org/job/road-hog/215/ 16:42:39 <planetmaker> right... I guess I'll create a fork repo for testing 16:45:57 <DevZone> Project nml-py3 build #1: FAILURE in 2.3 sec: https://jenkins.openttdcoop.org/job/nml-py3/1/ 16:46:03 <planetmaker> aha :P 16:48:28 <DevZone> Project Iron Horse build #894-nightlies: SUCCESS in 1 min 31 sec: https://jenkins.openttdcoop.org/job/iron-horse/894/ 16:49:10 <DevZone> Project Dutch Trainset build #176-push: SUCCESS in 1 min 32 sec: https://jenkins.openttdcoop.org/job/dutchtrains/176/ 16:49:38 <DevZone> Project ecs build #36-push: SUCCESS in 27 sec: https://jenkins.openttdcoop.org/job/ecs/36/ 16:49:40 <DevZone> Project nml-py3 build #2: STILL FAILING in 2.3 sec: https://jenkins.openttdcoop.org/job/nml-py3/2/ 16:50:00 <DevZone> Project 2ccts build #130-push: SUCCESS in 1 min 31 sec: https://jenkins.openttdcoop.org/job/2ccts/130/ 16:53:01 <DevZone> Project nml-py3 build #3: STILL FAILING in 2.2 sec: https://jenkins.openttdcoop.org/job/nml-py3/3/ 16:56:27 <DevZone> Project nml-py3 build #4: STILL FAILING in 2.2 sec: https://jenkins.openttdcoop.org/job/nml-py3/4/ 17:08:11 <DevZone> Project nml-py3 build #5: STILL FAILING in 2.4 sec: https://jenkins.openttdcoop.org/job/nml-py3/5/ 17:09:18 <DevZone> Yippee, build fixed! 17:09:19 <DevZone> Project nml-py3 build #6-push: FIXED in 18 sec: https://jenkins.openttdcoop.org/job/nml-py3/6/ 17:10:51 <planetmaker> hm... 17:24:21 <DevZone> Project NML - NewGRF Meta Language build #337-push: FAILURE in 6.4 sec: https://jenkins.openttdcoop.org/job/nml/337/ 17:32:04 <DevZone> Project opengfx-mars build #122-push: SUCCESS in 2 min 19 sec: https://jenkins.openttdcoop.org/job/opengfx-mars/122/ 17:32:12 <DevZone> Project Townnames - German build #81-push: SUCCESS in 7.7 sec: https://jenkins.openttdcoop.org/job/german-townnames/81/ 17:32:13 <DevZone> Yippee, build fixed! 17:32:14 <DevZone> Project NML - NewGRF Meta Language build #338-push: FIXED in 3 min 12 sec: https://jenkins.openttdcoop.org/job/nml/338/ 17:34:08 <DevZone> Project NML - NewGRF Meta Language build #339-push: FAILURE in 5.3 sec: https://jenkins.openttdcoop.org/job/nml/339/ 17:37:44 <DevZone> Project opengfx-mars build #123-push: SUCCESS in 2 min 13 sec: https://jenkins.openttdcoop.org/job/opengfx-mars/123/ 17:37:52 <DevZone> Project Townnames - German build #82-push: SUCCESS in 7.8 sec: https://jenkins.openttdcoop.org/job/german-townnames/82/ 17:37:54 <DevZone> Yippee, build fixed! 17:37:54 <DevZone> Project NML - NewGRF Meta Language build #340-push: FIXED in 3 min 9 sec: https://jenkins.openttdcoop.org/job/nml/340/ 17:59:30 <DevZone> Project nml-py3 build #7-push: FAILURE in 3.4 sec: https://jenkins.openttdcoop.org/job/nml-py3/7/ 18:00:39 <planetmaker> Alberth, ^ can you make sense of that error? I don't get that locally... 18:02:52 <planetmaker> (the code is at ssh://hg@hg.openttdcoop.org/nml-py3 18:24:43 <Alberth> planetmaker: one of the imported python files is shorter than normal? 18:25:36 <planetmaker> hm, not that I know... I would need to verify 18:26:31 <Alberth> I don't get it locally either 18:26:59 <planetmaker> hm, k 18:27:12 <planetmaker> thanks for testing 18:28:03 <Alberth> or perhaps the sound file is faulty, but I wouldn't expect that to happen on import 18:29:01 <Alberth> if you split the import in more lines, you may be able to get more precise information 18:29:11 <Alberth> as in which import fails exactly 18:30:12 <Alberth> but even then, if import is broken, you'd expect the first run to fail too, or do you make things in parallel? 18:33:16 <Alberth> planetmaker: hmm, maybe that's the trick indeed 18:33:32 <DevZone> Project nml-py3 build #8-push: STILL FAILING in 3.5 sec: https://jenkins.openttdcoop.org/job/nml-py3/8/ 18:33:33 <Alberth> parser.py writes a parsetab.tbl file or so 18:33:51 <Alberth> which a second process may read before it is written entirely? 18:34:06 <planetmaker> hm, maybe 18:34:31 <planetmaker> funnily enough, when I ssh to the CF, and call that build script from console. Then it works, too... 18:34:44 <planetmaker> so it's something more elusive even 18:35:01 <Alberth> it's all about timing in that case 18:36:08 <Alberth> https://dev.openttdcoop.org/attachments/download/3148/no_parsetab.py perhaps try that patch? 18:37:01 <Alberth> https://dev.openttdcoop.org/issues/4091 <-- that issue 18:40:10 <planetmaker> let's see. It's a test fork :) 18:40:38 <DevZone> Yippee, build fixed! 18:40:39 <DevZone> Project nml-py3 build #9-push: FIXED in 33 sec: https://jenkins.openttdcoop.org/job/nml-py3/9/ 18:40:50 <planetmaker> :-O :-) 18:41:22 <planetmaker> so... will you also push it to the official repo? 18:42:03 <planetmaker> (or shall I?) 18:42:50 <Alberth> sure, one moment 18:46:37 <Alberth> pushed 18:49:29 <DevZone> Project opengfx-mars build #124-push: SUCCESS in 2 min 16 sec: https://jenkins.openttdcoop.org/job/opengfx-mars/124/ 18:49:37 <DevZone> Project Townnames - German build #83-push: SUCCESS in 8.3 sec: https://jenkins.openttdcoop.org/job/german-townnames/83/ 18:49:38 <DevZone> Project NML - NewGRF Meta Language build #341-push: SUCCESS in 3 min 10 sec: https://jenkins.openttdcoop.org/job/nml/341/ 18:49:41 <DevZone> Project nml-py3 build #10-push: FAILURE in 3.5 sec: https://jenkins.openttdcoop.org/job/nml-py3/10/ 18:50:36 <planetmaker> eh 18:50:44 <planetmaker> can't say I get that now 18:51:56 <DevZone> Project nml-py3 build #11-push: STILL FAILING in 3.5 sec: https://jenkins.openttdcoop.org/job/nml-py3/11/ 18:53:21 <Alberth> I wonder whether this can happen with generated python files too 18:53:53 <planetmaker> hm.... 18:53:56 <Alberth> or, did you run out of disk space or disk quota ? 18:54:03 <DevZone> Yippee, build fixed! 18:54:04 <DevZone> Project nml-py3 build #12-push: FIXED in 32 sec: https://jenkins.openttdcoop.org/job/nml-py3/12/ 18:54:07 <planetmaker> maybe not that 18:54:24 <planetmaker> but my terminal was still in the workspace dir. But the workspace dir is supposed to be deleted and re-created 18:54:52 <planetmaker> let's test that 18:55:22 <DevZone> Project nml-py3 build #13-push: SUCCESS in 33 sec: https://jenkins.openttdcoop.org/job/nml-py3/13/ 18:55:54 <planetmaker> weired 18:56:04 <DevZone> Project nml-py3 build #14-push: SUCCESS in 32 sec: https://jenkins.openttdcoop.org/job/nml-py3/14/ 18:56:52 <DevZone> Project nml-py3 build #15-push: SUCCESS in 32 sec: https://jenkins.openttdcoop.org/job/nml-py3/15/ 19:00:27 <DevZone> Project nml-py3 build #16-push: FAILURE in 1 min 1 sec: https://jenkins.openttdcoop.org/job/nml-py3/16/ 19:02:39 <DevZone> Yippee, build fixed! 19:02:39 <DevZone> Project nml-py3 build #17-push: FIXED in 1 min 5 sec: https://jenkins.openttdcoop.org/job/nml-py3/17/ 19:05:21 <DevZone> Project nml-py3 build #18-push: SUCCESS in 47 sec: https://jenkins.openttdcoop.org/job/nml-py3/18/ 19:13:59 <planetmaker> hm... ogfx-industries.grf seems to work, both ways, generated with the linux nmlc as well as the windows nmlc 19:14:09 <planetmaker> but the md5sums of the resulting grf is different :( 19:14:21 <planetmaker> but the used python version is different, too 19:19:22 <Alberth> also, it uses sets, and dictionaries, which are not fixed in order 19:19:33 <Alberth> unless someone fixed that in the past in nml 19:19:47 <planetmaker> so, little chance for identical output? 19:19:59 *** andythenorth has joined #openttdcoop.devzone 19:20:05 <Alberth> I think so 19:20:18 <planetmaker> then I'll not worry about it 19:20:20 <planetmaker> for now 19:20:24 <Alberth> you could run a grfcodec over it and compare differences 19:20:57 <planetmaker> yeah, I should do that, I guess 19:21:16 <Alberth> allocated numbers are hopefully the only difference 19:21:18 *** Supercheese has joined #openttdcoop.devzone 19:21:39 <Alberth> we could look into making nml provide more fixed order in the output 19:26:19 <planetmaker> https://paste.openttdcoop.org/show/3373/ <-- you're right though 19:26:56 <planetmaker> in the medium run we possibly could look at making it depend less on implementation 19:27:16 <planetmaker> But I'm not 100% sure how important that is... comparing different builds is always tricky with nml 19:27:19 *** ODM has joined #openttdcoop.devzone 19:28:39 <Alberth> :o string tables? 19:29:07 <planetmaker> seems so 19:33:55 <planetmaker> anyhow... except this thing... it looks like nml-py3 works. Surprisingly, but works 19:34:23 <Alberth> \o/ 19:34:25 <planetmaker> the windows nmlc will only be able to read png images. No jpeg or other fancy formats, but that's acceptable, I think 19:34:31 <andythenorth> :) 19:34:43 <planetmaker> or something to worry about later, re-compiling pil with jpeg support when absolutely needed 19:34:50 <andythenorth> our big work app is still stuck on python 2.4 :P 19:34:51 <Alberth> jpeg is not useful anyway 19:34:51 <planetmaker> s/pil/pillow 19:35:00 <Supercheese> .jpeg is of the devil 19:35:14 * Supercheese crosses himself 19:35:35 <planetmaker> it's useful for photos. But not in this area 19:36:39 <planetmaker> so, Alberth, should we push the changes to the main NML repo? 19:36:44 <planetmaker> s/we/I/? 19:37:01 <Alberth> fine by me 19:37:19 <planetmaker> or run some timing tests first? :) 19:37:46 <Alberth> you make a branch for 2.7? 19:38:03 <planetmaker> I would/will do that when we have anything to backport, yes 19:38:28 <planetmaker> thus we'll be heading towards 0.4.0 then and the new branch would be 0.3 19:38:56 <Alberth> do we have any idea on slow acceptable nml compile speed is? 19:39:39 <planetmaker> different people have different thresholds, I guess 19:40:27 <planetmaker> ogfx-industries is 5.2s vs 4.5s (real time) 19:40:32 <planetmaker> one test 19:42:23 <planetmaker> firs is 1m:25.851 vs. 1m17.160s (real time, one run) 19:44:22 <Alberth> not too bad, I guess 19:44:31 <planetmaker> ho... one missing conversion? https://paste.openttdcoop.org/show/3374/ 19:45:12 <planetmaker> hm... I recall something like that already... 19:45:28 <Alberth> I changed some palette stuff indeed 19:46:49 <Alberth> but it is totally possible I missed one or more 19:47:24 <planetmaker> that was line 548. This is 200 lines further down 19:48:16 <planetmaker> c92497a4508adb5dd54c2668ddd0e7feec93bba3 is previous 19:48:30 <planetmaker> (my numeric revisions will be off quite a bit) 19:49:19 <planetmaker> I guess I can add a similar fix to the py2to3 conversion patch 19:52:52 <Alberth> translate_d2w = bytearray(v for v in palmap_d2w) <-- that's what I have in my py3 branch 19:52:52 <Alberth> translate_d2w = ''.join(chr(v) for v in palmap_d2w) <-- that's from py3nml 19:53:52 <planetmaker> aye 20:02:24 <planetmaker> 3.384s vs. 3.170s for ogfxe_extra.grf 20:03:42 <Alberth> quite comparable imho 20:03:45 <planetmaker> win for py3 for big 32bpp: 4.956s vs. 7.220s for pota-ghat 20:03:52 <planetmaker> yes 20:04:09 <planetmaker> using cached times from repeated builds 20:06:05 <planetmaker> possibly the py3-pillow is more optimized 20:20:37 *** ODM has quit IRC 20:21:25 <planetmaker> hg ci -m "-Change: Convert from Python2 to Python 3.2+ (changes to .devzone / setup.py by planetmaker)" -u "Alberth <alberth@openttd.org>" <-- fine with that for a squashed commit? 20:21:39 <planetmaker> I see little way to split it 20:21:52 <Alberth> you cannot, imo 20:22:02 <Alberth> +1 20:22:40 <DevZone> Project NML - NewGRF Meta Language build #342-push: FAILURE in 5.9 sec: https://jenkins.openttdcoop.org/job/nml/342/ 20:23:56 <DevZone> Project NML - NewGRF Meta Language build #343-push: STILL FAILING in 5.3 sec: https://jenkins.openttdcoop.org/job/nml/343/ 20:24:06 <planetmaker> hm 20:26:11 <DevZone> Project NML - NewGRF Meta Language build #344-push: STILL FAILING in 5.3 sec: https://jenkins.openttdcoop.org/job/nml/344/ 20:27:55 *** LSky` has quit IRC 20:29:29 <DevZone> Project NML - NewGRF Meta Language build #345-push: STILL FAILING in 5.6 sec: https://jenkins.openttdcoop.org/job/nml/345/ 20:30:26 <Alberth> is it reproducable locally? 20:30:33 <planetmaker> no 20:30:47 <planetmaker> also not when I run the build script on the server. Same thing really as before... 20:31:04 <planetmaker> it seems to be another issue than parsetab.py 20:31:18 <Alberth> yeah, we eliminated that one :p 20:33:44 <Alberth> planetmaker: https://bugs.launchpad.net/ubuntu/+bug/1029683/comments/5 ? 20:33:45 <Webster> Title: Comment #5 : Bug #1029683 : Bugs : Ubuntu (at bugs.launchpad.net) 20:34:52 <planetmaker> Alberth, but why does it happen sometimes but not always? 20:35:03 <planetmaker> I expect that bug to be deterministic 20:35:40 <Alberth> your guess is as good as mine :) 20:35:51 <planetmaker> it then should also occur when I manually run the commands instead of in the script? 20:36:45 <planetmaker> hm... I forced -j1 on regression test now. That currently builds successful 20:37:03 <planetmaker> so there is something nasty racy on parallel usages of nmlc 20:37:19 <DevZone> Project opengfx-mars build #125-push: SUCCESS in 2 min 18 sec: https://jenkins.openttdcoop.org/job/opengfx-mars/125/ 20:37:26 <planetmaker> but good enough fix for now. Just minimal longer build 20:37:27 <DevZone> Project Townnames - German build #84-push: SUCCESS in 7.9 sec: https://jenkins.openttdcoop.org/job/german-townnames/84/ 20:37:28 <DevZone> Yippee, build fixed! 20:37:29 <DevZone> Project NML - NewGRF Meta Language build #346-push: FIXED in 3 min 32 sec: https://jenkins.openttdcoop.org/job/nml/346/ 20:39:23 <planetmaker> I guess we need to announce this fundamental change in requirements 20:39:52 <Alberth> seems useful :) 20:40:25 <Alberth> although people will generaly run just one nml 20:41:20 <Alberth> file system is at NFS? 20:41:41 <Alberth> perhaps something with locking? 20:42:53 <Alberth> but you'd again also get those problems if you run make by hand :( 20:44:01 *** andythenorth has left #openttdcoop.devzone 20:47:29 <planetmaker> http://www.tt-forums.net/posting.php?mode=reply&f=68&t=48891 20:47:30 <Webster> Title: Transport Tycoon Forums Login (at www.tt-forums.net) 20:47:54 <planetmaker> the file system for the working dir is not on NFS, that's local to the build VM 20:49:33 *** oskari89 has quit IRC 20:50:39 <planetmaker> announcement ok with you? 20:50:47 <planetmaker> anything missing or too much? 20:59:29 <Alberth> that url is empty for me 21:00:44 <planetmaker> hm, can you reload? 21:01:16 <Alberth> http://www.tt-forums.net/viewtopic.php?p=1121924#p1121924 this one worked 21:01:17 <Webster> Title: Transport Tycoon Forums View topic - NML - a Newgrf Meta Language (at www.tt-forums.net) 21:01:21 <Alberth> seems ok to me 21:03:42 <Alberth> gn 21:03:58 *** Alberth has left #openttdcoop.devzone 21:52:48 *** frosch123 has quit IRC 22:58:32 *** yorick has quit IRC 23:50:53 *** gelignite has quit IRC