Log for #openttdcoop.devzone on 28th October 2013:
Times are UTC Toggle Colours
07:33:15  <DevZone> Project OpenGFX build #83-push: SUCCESS in 7 min 59 sec:
07:36:19  *** Supercheese has quit IRC
08:30:12  *** zooks has joined #openttdcoop.devzone
09:58:15  *** frosch123 has joined #openttdcoop.devzone
11:42:57  *** zooks has quit IRC
12:11:58  *** zooks has joined #openttdcoop.devzone
14:26:01  *** zooks has quit IRC
16:06:46  *** ODM has joined #openttdcoop.devzone
16:50:36  <DevZone> Project Iron Horse build #350-push: SUCCESS in 3 min 2 sec:
16:50:46  <DevZone> Project xussrset - Trains from Russia build #73-push: SUCCESS in 3 min 26 sec:
16:57:53  <DevZone> Project FIRS Industry Replacement Set build #39-push: SUCCESS in 7 min 16 sec:
17:21:43  <DevZone> Project NML - NewGRF Meta Language build #105-nightlies: SUCCESS in 3 min 7 sec:
17:25:47  *** oskari89 has joined #openttdcoop.devzone
18:08:53  <DevZone> Project finnishtrams build #8-nightlies: SUCCESS in 2 min 16 sec:
18:22:14  <DevZone> Yippee, build fixed!
18:22:14  <DevZone> Project OpenGFX+ Landscape build #30-push: FIXED in 26 min:
18:27:40  <DevZone> Project Finnish Rail Infrastructure - Rails build #127-nightlies: SUCCESS in 1 min 3 sec:
18:31:17  <DevZone> Project Nutracks build #54-nightlies: SUCCESS in 41 sec:
18:49:32  <DevZone> Project Iron Horse build #351-nightlies: SUCCESS in 1 min 51 sec:
18:54:04  *** Supercheese has joined #openttdcoop.devzone
19:00:08  *** andythenorth has joined #openttdcoop.devzone
19:00:57  *** andythenorth has joined #openttdcoop.devzone
19:06:02  <DevZone> Project OpenGFX build #84-nightlies: SUCCESS in 7 min 26 sec:
19:52:28  <DevZone> Project OpenGFX+ Landscape build #31-push: SUCCESS in 27 min:
19:52:53  <Supercheese> 27 minutes, whew
19:55:18  <planetmaker> yeah. It has to generate nearly all sprites
19:55:35  <planetmaker> <-- and that's a lot :-)
19:55:42  <planetmaker> and it cannot use grf caching
19:55:49  <planetmaker> thus locally it's much faster
19:56:06  <planetmaker> and it's limited to one core ;-)
19:56:29  <planetmaker> while locally I let it use at least 6.
19:57:13  <Rubidium> planetmaker: got around to testing my hunch on Windows and OSX?
19:59:43  <planetmaker> I've not yet finnished setting up the compile environment locally to create the windows one... that requires some specially-crafted wine config and python installed therein
20:04:17  <planetmaker> and on OSX I'm repairing my install... I must have left it borked when I toyed with PIL/pillow testing :S
20:05:16  <andythenorth> :P
20:05:42  <andythenorth> planetmaker: I now have guaranteed foolproof python setup on OS X fwiw
20:05:50  <andythenorth> (unless you can find a bigger class of fool)
20:05:50  <planetmaker> can you document it?
20:06:11  <andythenorth> this is a generalised approach, not specific to nml
20:06:34  <Rubidium> oh... let me loose on it ;)
20:06:37  <andythenorth> it avoids issues with Apple python, setuptools, and this insane 'install system wide python modules' approach
20:07:04  * Rubidium has scored points on high school for hanging a Mac with merely magic fingers ;)
20:07:07  <andythenorth> planetmaker: I can copy and paste from our work python instructions :P
20:07:19  <andythenorth> we invested in figuring it out once and for all, after many days lost
20:07:43  *** gelignite has joined #openttdcoop.devzone
20:14:26  <andythenorth> planetmaker: foolproof-ish
20:14:39  <andythenorth> YMMV
20:15:06  <andythenorth> this method survives OS X upgrades and installs, and eliminated a lot of voodoo and silly crap
20:16:05  <andythenorth> concept 1: stay away from the Apple-supplied python, and *never* touch macports
20:16:14  <andythenorth> concept 2: isolate projects with disposable virtualenvs
20:16:48  <planetmaker> I mix apple python with macports :-P
20:16:54  <andythenorth> been there done that :(
20:17:01  <andythenorth> if you're not trying to use python for multiple projects, and you never upgrade OS X, then the method above may seem overkill
20:17:07  <andythenorth> but it's a small investment to avoid a lot of pain
20:17:21  <planetmaker> yeah, I likely are right
20:18:22  <andythenorth> we very nearly switched to doing all development on Linux VMs on OS X, but there was a rebellion :P
20:18:25  <andythenorth> and the issue got fixed
20:29:30  <planetmaker> let's screw it more and install pillow :D
20:34:44  <planetmaker> Rubidium, ok, OSX is fine. And for windows I rather commit that and have devzone build the binary
20:34:53  <planetmaker> you want to take the honour? :-)
20:37:26  <Rubidium> dare I
20:37:44  <Rubidium> what to use a commit message?
20:37:56  <Rubidium> something that doesn't close the bug (yet)
20:40:09  <planetmaker> hm... Change #xxx
20:45:05  <DevZone> Project NML - NewGRF Meta Language build #106-push: SUCCESS in 2 min 32 sec:
20:45:32  <DevZone> Project ISR Industrial Station Renewal build #46-push: SUCCESS in 34 sec:
20:45:35  <Rubidium> does it work? ;)
20:46:33  <planetmaker> what work?
20:46:44  <planetmaker> nmlc --version?
20:46:54  <planetmaker> oh, does it work. Let's see
20:46:55  <Rubidium> yup, in that case where it used to fail
20:54:03  <planetmaker> hm. version of nmlc is unknow
20:54:16  <planetmaker> so, I fear it didn't exactly help :-(
20:54:44  <Rubidium> at least it isn't a wrong version anymore ;)
20:56:34  <planetmaker> true
20:57:06  <Rubidium> so __file__ or realpath isn't doing the same on Windows as on Linux
20:57:09  <Rubidium> but which?
21:03:02  <planetmaker> or that gets screwed by cxfreeze somewhere, where the exe is made from the stuff
21:03:46  <Rubidium> I guess it needs more experimenting, but using the live repository isn't the right way to do it
21:04:14  <Rubidium> first step would be printing __file__ and all the sub steps like realpath(__file__) etc.
21:04:14  <planetmaker> no, it's not
21:04:36  <planetmaker> so... I need that windows here actually work :-)
21:05:13  <Taede> tried abspath?
21:05:55  <Taede> or does that not give the desired output?
21:06:06  <Rubidium> no clue
21:06:23  <Rubidium> mostly what I did was a stab in the dark without knowing much of python
21:06:27  <planetmaker> hm, how do I exit python on windows command line?
21:06:36  <planetmaker> in linux / osx it's ctrl+d. But on windows?
21:06:49  <Rubidium> but keeping stabbing in the dark is kinda a waste of revisions and such
21:07:04  <Rubidium> ctrl+d? ctrl+c?
21:07:12  <Rubidium> task manager -> kill it with fire!!!!
21:07:21  <planetmaker> :-)
21:07:21  <Taede> os.chdir(os.path.dirname(os.path.abspath(__file__))) <- what i use to change the cwd to where the python file is located
21:07:26  *** ODM has quit IRC
21:07:28  <Taede> untested for windows though
21:07:52  <Rubidium> path = os.path.dirname" target="_blank">os.path.dirname(os.path.dirname" target="_blank">os.path.dirname(os.path.realpath(__file__)))
21:08:22  <planetmaker> double?
21:08:33  <Rubidium> yes
21:08:40  <Taede> the outer .dirname seems a bit surplus
21:09:15  <Taede> but try path = os.path.dirname(os.path.abspath(__file__)) ?
21:09:38  <Rubidium> os.path.realpath(__file__) gets (for me) "${the path that I want}/nml/"
21:10:00  <Rubidium> I want to strip the (first dirname), and then the nml (second dirname)
21:10:31  <Rubidium> planetmaker: the exe doesn't even have a .hg folder, so where would it get its version from in any case?
21:11:23  <planetmaker> a packaged nml also has a version. hm.
21:11:36  <Rubidium> I reckon that __version__ isn't created/compiled into the exe
21:12:37  <Taede> path = os.path.dirname" target="_blank">os.path.dirname(os.path.dirname" target="_blank">os.path.dirname(os.path.abspath(__file__))) then
21:16:20  <Rubidium> the path isn't the problem, or at least isn't the problem that is currently faced
21:16:24  <Rubidium> yay oversight ;)
21:18:26  <planetmaker> hm... I wonder. nml/ should exist. Building first runs the regression tests. Which should generate the version file. hm
21:19:02  <planetmaker> ah, there's another version place...
21:19:31  <planetmaker> nml/
21:19:42  <planetmaker> err... nml/
21:21:59  <planetmaker> but I think you're right nevertheless.... nml/ might not be generated... and cxfreeze might need that
21:26:43  <planetmaker> hm... let's try build with a slight modification to the build process
21:27:14  <planetmaker> calling ./ --version before freezing. Thus generating nml/
21:27:35  <DevZone> Project NML - NewGRF Meta Language build #107-push: SUCCESS in 1 min 4 sec:
21:28:23  *** andythenorth has quit IRC
21:29:25  <planetmaker> success
21:29:36  <planetmaker> thank you rubidium :-)
21:30:17  <planetmaker> somewhat success at least. I should change it to the days_since_2000 as well
21:31:18  <Rubidium> oh... that's looming over grfcodec as well, ain't it?
21:31:23  <planetmaker> yes
21:31:38  <planetmaker> it's not that critical there as it's a repo w/o branches
21:31:53  <planetmaker> nml has branches, though. Thus 2037 is actually wrong...
21:32:08  <planetmaker> would I have permission to change grfcodec in that respect?
21:32:28  <planetmaker> (or if you want, do that)
21:32:29  <Rubidium> as long as you don't break openttd's configure script ;)
21:32:48  <planetmaker> versions will only increase. we're at day/version 5049 now :-)
21:33:35  <planetmaker> I'd only want to change the reported version. Not the format it's reported in
21:33:42  <planetmaker> for that very reason you mentioned
21:33:48  <planetmaker> same actually with NML
21:35:30  <Rubidium> though I wonder whether it gets confusing when rREV is about the same as rDAYS
21:35:48  <planetmaker> hm?
21:37:03  <Rubidium> "I'm building r5048, but the binary says r5049"
21:37:39  <planetmaker> days_since_2000 references the commit date, thus should be unique
21:37:51  <Rubidium> I know... but...
21:38:06  <planetmaker> well, would not for many commits in a single day
21:38:27  <Rubidium> imagine the case where the commit/revision count of a repository is roughly equal to the number of days since 2000
21:39:18  <planetmaker> yes, what then?
21:39:28  <Rubidium> and someone new-ish or forgetful tries to figure out what revision is being used. Then whatever comes out of number of days is close to the revision, which might confuse things
21:40:27  <planetmaker> yes. Iff. But the numeric version of any DVCS is basically pointless... only the hash is unique
21:40:32  <Rubidium> e.g. now is 5049 days since, but the repository goes to r5053. I do a hg up and compile. I see r5049 in my --version and wonder why that doesn't match with the revision I'm using
21:41:04  <planetmaker> the repository goes to 5053:af3927b3a43
21:41:28  <Rubidium> mostly due to those numbers being not, relatively easily, identifiable as being days instead of revision
21:41:30  <frosch123> easy solution, just commit more
21:42:11  <planetmaker> sorry, I don't really get the problem you try to construct.
21:42:17  <Rubidium> planetmaker: and you type hg up -r 5053:abcdef1234?
21:42:26  <planetmaker> I know the days-since-2000 is bad for many commits a day. But... we rarely have that
21:42:56  <planetmaker> Rubidium, no. hg up -rXXX. Where XXX is either 5053 or abcdef1234
21:43:07  <Rubidium> it's not about many commits a day, it's about it not being recognisable as something that is likely not a changeset number
21:43:44  <frosch123> does it actually put a "r" in front of the number?
21:43:51  <Rubidium> especially since grfcodec will keep it's r5048 version numbering
21:44:01  <frosch123> an "r" would indeeed be confusing
21:44:15  <planetmaker> I changed it in projects to 'v5053' instead of r
21:44:37  <Rubidium> but that breaks openttd's configure script
21:44:53  <planetmaker> VERSION        :2013-10-28 (5049:6990c2d1af9aM)
21:44:54  <planetmaker> yes
21:46:44  <Rubidium> r20131028 will probaby be slightly less worse
21:47:05  <planetmaker> or we simply break version detection
21:47:09  <Rubidium> not sure whether the configure handles r20131028+abcdef123456 properly
21:49:43  <Rubidium> but then either trunk or stable fails to detect grfcodec properly
21:53:04  <planetmaker> for stable we have a release of grfcodec which compiles it. And we could have for trunk another which does so
21:55:48  <Rubidium> that's not really the problem... but on my system I don't have a dual installation of stable and trunk grfcodec
21:56:06  <Rubidium> if I compile openttd, it's usually with grfcodec HEAD
21:56:33  <Rubidium> and especially with backporting that is occasionally needed to still function
21:57:13  <Rubidium> which is where my worries w.r.t. changing the way versions are written down for grfcodec comes from
21:57:16  *** oskari89 has quit IRC
21:57:56  <Rubidium> anyhow... I'm too sleepy to have coherent thoughts
22:03:42  <planetmaker> same here actually. Sleep well :-)
22:08:10  *** gelignite has quit IRC
23:05:01  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk