Log for #openttdcoop.devzone on 10th January 2016:
Times are UTC Toggle Colours
02:00:07  *** oskari89 has quit IRC
02:06:57  *** skyem123 has quit IRC
02:28:28  *** gelignite_ has joined #openttdcoop.devzone
02:35:47  *** gelignite has quit IRC
02:39:05  *** Supercheese is now known as Guest4335
02:45:34  *** Guest4335 has quit IRC
03:55:49  *** Supercheese has joined #openttdcoop.devzone
04:24:48  *** gelignite_ has quit IRC
11:23:25  *** skyem123 has joined #openttdcoop.devzone
11:39:54  *** tycoondemon has quit IRC
12:29:32  *** tycoondemon has joined #openttdcoop.devzone
12:32:59  *** Supercheese has quit IRC
12:33:25  *** Supercheese has joined #openttdcoop.devzone
13:00:46  *** gelignite has joined #openttdcoop.devzone
14:16:26  *** frosch123 has joined #openttdcoop.devzone
15:13:03  <DevZone> Project 2ccts build #609-push: SUCCESS in 2 min 35 sec:
16:37:01  *** Alberth has joined #openttdcoop.devzone
16:47:05  <Alberth>    frosch123  some first steps for better reverting behavior; 10-60 isn't enough it seems to bring us into clear water, I needed hack 99 too
16:47:05  <Alberth> The deeper issue seems to be to me atm, that we have time stamps associated with texts, as well as with changes. I am pondering whether the latter are really needed, ie can a change in itself change time stamp without changing the time of a string too?
16:47:51  <DevZone> Project hungarian-set build #19-push: SUCCESS in 37 sec:
16:47:59  <Alberth> hi hi DevZone
16:48:41  <frosch123> what when confirming an outdated string without changing it?
16:48:45  <frosch123> is that a change?
16:48:46  <DevZone> Project OpenGFX+ Industries build #121-push: SUCCESS in 50 sec:
16:49:32  <Alberth> currently, I am thinking it should be a change in time stamp of that string
16:49:41  <Alberth> no idea what the code currently does
16:50:12  <Alberth> but "out of date" compares change stamps with text stamps, which looks fishy
16:51:57  <Alberth> webtranslate/    if lchg.base_text != btext or lchg.stamp < btext.stamp:
16:52:55  <Alberth> so maybe change the Text.stamp semantics (which is now  @ivar stamp: Time stamp of creation of this text.)
16:53:44  <Alberth> unless we want to keep duplicate texts at different moments in time separate
16:53:59  <Alberth> but I see no good reason for that
16:55:04  <Alberth> other direction is to keep the chg.stamp, and use that as "last modified/checked" date
16:55:17  <frosch123> hmm, i expected get_lng_change to lose the last parameter "base_text"
16:55:21  <frosch123> but you do not touch that
16:58:19  <frosch123> well, tbh i somewhat lost the overview how eints shall behave it what cases :p
16:58:40  <DevZone> Project World Airliner Set build #1561-push: SUCCESS in 9 min 13 sec:
16:59:14  <DevZone> Project OpenGFX build #190-push: SUCCESS in 10 min:
17:00:06  <Alberth> so maybe we should first decide that?
17:00:25  <frosch123> i started with adding some regression tests
17:00:39  <frosch123> just to traverse the complete state graph and somehow document/define it for me
17:00:57  <frosch123> currently i have no idea how eints treats the timestamps and last_upload and stuff
17:01:25  <frosch123> esp. when the translation is specific to a base language text
17:02:30  <DevZone> Project 2ccts build #610-push: SUCCESS in 3 min 48 sec:
17:02:50  <Alberth> ok, let's try to agree on that first then
17:04:01  <Alberth> btw and  looks like duplicates?
17:04:50  <Alberth> I checked the lang_sync script and indeed it doesn't set the override flag
17:05:18  <frosch123> yes, they are duplicates :)
17:05:33  <Alberth> one of the patches in my queue just discards that check for base languages, as upload is the only way for a base language to change
17:05:45  <Alberth> for translations, I am not sure
17:05:47  <frosch123> yup, i agree with that part
17:06:09  <frosch123> no, upload for translations should not override it
17:06:17  <frosch123> (by default)
17:06:33  <Alberth> we could add a --override flag for them, but it might discard entered translations, which seems too dangerous to allow from eg a script
17:07:09  <Alberth> so my conclusion was not to add such a flag; if you want it, upload manually
17:07:29  <frosch123> the hg and svn script always upload before downloading, to let eints merge the stuff
17:07:41  <frosch123> so, they would never want to replace translations when uploading
17:08:01  <Alberth> except for a very quick user :p
17:08:35  <Alberth> but ok, that problem doesn't exist thus, let's keep it as it is then
17:08:45  <frosch123> drawback of the current svn/hg approach is, that people cannot revert changes from eints via the vcs
17:08:54  <frosch123> since eints will always commit them again
17:09:01  <frosch123> but i don't consider that a problem
17:10:06  <Alberth> maybe that should be considered in more detail when we have a better view of desired behavior
17:25:35  <frosch123> anyway, diffs 10 to 60 look fine to me
17:32:51  <Alberth> ok, thanks
18:15:40  <DevZone> Project Building sprite test project build #100-nightlies: SUCCESS in 37 sec:
18:46:07  <DevZone> Project eints build #61-push: SUCCESS in 18 sec:
18:46:41  <Alberth> we need lots of tests, 18 seconds is so very non-impressive :p
21:21:27  *** Alberth has left #openttdcoop.devzone
22:03:51  *** skyem123 has quit IRC
22:34:38  *** frosch123 has quit IRC
23:05:17  <DevZone> Project xussrset - Trains from Russia build #1295-push: SUCCESS in 6 min 56 sec:
23:18:39  *** gelignite has quit IRC

Powered by YARRSTE version: svn-trunk