Log for on 7th April 2013:
Times are UTC Toggle Colours
00:19:45  *** Zuu has quit IRC
03:03:15  *** Supercheese has joined
07:33:08  *** Alberth has joined
07:33:08  *** ChanServ sets mode: +v Alberth
08:12:33  *** Supercheese has quit IRC
08:39:49  *** Meechmunchie has joined
08:40:43  *** Meechmunchie has left
08:46:19  *** Zuu has joined
08:46:19  *** ChanServ sets mode: +v Zuu
09:48:24  *** frosch123 has joined
09:48:24  *** ChanServ sets mode: +v frosch123
10:14:20  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25158 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
10:16:16  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25159 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
10:17:54  *** Ristovski has joined
10:18:35  <Zuu> Fixes a bug in musa validation of short name in dependencies:
10:19:08  <Zuu> The bug was that shortName is not defined.
10:19:28  <Zuu> I define short_name and use that instead as most of musa do not use camel case.
10:20:04  <frosch123> yay, undefined variables :)
10:20:14  <Zuu> Why I like compiled programs :-)
10:24:01  <Rubidium> yeah ;)
10:24:15  <Rubidium> though can't python be compiled?
10:26:49  <Zuu> I guess there is at least some automatic detectors out there. For example in this case shortName has never been used previously in that method and is not an parameter to the method nor is it defined globally. Thus it shouldn't be impossible to write a program that could detect this error.
10:27:33  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25160 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
10:33:16  <Alberth> pylint
10:33:53  <Alberth> although that will bark on a lot of other things too by default :p
10:53:03  <Zuu> <Alberth> if options.exclude is not None and options.exclude != "":  <-- I would expect a test against an empty list  <---- exclude is here a regex string
10:54:23  * Alberth looks for the patch
10:55:10  <Zuu>
10:55:14  <Alberth> for exclude in options.exclude:    <-- so you loop over characters?
10:55:16  <Zuu> I just updated it
10:55:56  <Zuu> Alberth: Hmm, maybe not. I just took that code from
10:58:07  <Zuu> So I didn't actually touch it, but your comment makes sense
10:59:16  <Zuu> But why would you check if a list is empty before looping it? Just loop it instead and if its empty there is just zero iterations of the loop?
11:00:59  <Alberth> I agree with that :)
11:01:23  <Alberth> perhaps it was a string at some point in the past
11:04:06  <Zuu> Removing the != "" check altogeather appears to work just fine.
11:06:15  <Zuu> I'll fix then and remove the check in depgen.patch
11:07:05  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25161 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
11:08:00  <Alberth> you can ask for the type of a value with   type(val)
11:08:28  <Zuu> May be a useful tips for debugging
11:09:50  <Zuu> depgen.patch updated. Anything more, or shall I commit it?
11:10:02  <Alberth> In my experience, you have to write doc strings with types for parameters and return values to prevent you from getting lost
11:10:22  <Alberth> I have no more, if you have considered all things I mentioned yesterday
11:11:23  <Zuu> Alberth: I usually have far more comments in my python scirpt. However have far more comments than the rest of musa.
11:12:07  <Zuu> Alberth: I've reviewed your comemnts from yesterday and checked the code for implementation of the comments.
11:13:05  <Alberth> k
11:18:06  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25162 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
12:02:00  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25163 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
12:51:54  *** Zuu has quit IRC
13:24:21  *** Ristovski has quit IRC
13:28:00  *** Ristovski has joined
13:30:43  *** Ristovski has quit IRC
13:34:58  *** Ristovski has joined
13:55:12  *** Ristovski has quit IRC
13:57:00  *** Ristovski has joined
14:54:01  *** Ristovski has quit IRC
14:55:03  *** Ristovski has joined
15:11:12  *** Zuu has joined
15:11:12  *** ChanServ sets mode: +v Zuu
17:42:57  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25164 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:05:51  <Zuu> I have now finalized my .ini files for uploading using an AI, a GS and a scenario using musa. The first problem that occured was that delete the tar file before it is uploaded. This I've fixed locally. (
18:06:40  <Zuu> Now, when uploading I get a problem which looks like the server closes the ssl connection when the last part of the tar file have been uploaded, but before the file termination is sent.
18:06:58  <Zuu> output:
18:07:12  <Zuu> Current (including line numbers):
18:09:02  <Rubidium>
18:09:16  <Zuu> I don't really understand the server code and why this happens. Isn't this part equal for all content types and have been verified to work with base graphics?
18:09:36  *** Ristovski has quit IRC
18:10:06  <Zuu> Thank you Rubidium
18:12:21  *** Ristovski has joined
18:18:27  <Zuu> Ah, the reason is that the server will call Validate(metadata, None) first, then let client upload tar and last call Validate(metadata, tar) when the tar have been uploaded. This allows verifying some limited aspects of the metadata without the tar.
18:18:47  <Zuu> This should fix this issue for scripts, heightmap and scenario:
18:19:35  <Rubidium> seems okay to me
18:21:11  <Rubidium> though...
18:21:28  <Rubidium> if there are other checks except the filenames, then those should be done before exiting
18:28:26  <Zuu> The only such chcek that exist is to verify that the md5sum of a NewGRF is not a system/invalid NewGRF. For scripts I could verify that the uniqueid on integer form is within the range 0 to 2^32 -1.  But other than that it is not much that can be verified without having the tar file.
18:29:33  *** Alberth has left
18:32:26  <Rubidium> so, then the patch is fine ;)
18:32:32  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25165 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:32:56  <Zuu> Except that I fixed the wrong hegihtmap procedure, but I found and fixed that. :-)
18:33:59  <Zuu> So the commit is correct.
18:34:20  <Rubidium> updated
18:34:27  <Zuu> thanks
18:36:17  <Zuu> I think you have a new stack trace :-)
18:37:07  <Rubidium> can you trigger some more, looks like it isn't flushed yet
18:38:25  <Zuu> I've trigged som 4-5 more now
18:38:53  <Rubidium> hmm... needs more I guess
18:39:10  <Rubidium> or nothing is coming, but I reckon it's some 4k before it flushes
18:39:22  <Rubidium> or I need to know how to force a flush in python
18:39:38  <Zuu> 4k is quite many "yes I am" for me to type ;-)
18:40:33  <Rubidium> true
18:41:30  <Rubidium> apparantly python has some unbuffered function
18:41:30  <Zuu> oh, now I didn't get a trace locally..
18:41:36  <Rubidium> or command line option
18:42:14  <Zuu> Ah,.. "invalid username/password"
18:42:30  <Rubidium> okay, try again
18:42:37  <Rubidium> bingo
18:43:00  <Rubidium>
18:57:55  *** Supercheese has joined
19:14:49  <Zuu> 1) there was a bug in packing of dependency metadata. (locally fixed)
19:15:21  <Zuu> 2) now the server complais that license.txt is missing while the local validation of license.txt succeeds :-)
19:20:35  <Rubidium> might you have a local modification?
19:22:07  <Zuu> I let not remove the temporary tar file. I then renamed it to tmp.tar and opened it in 7zip. In its root it has a file named the same as the old name of the temporary file. If I doubleclick that one I get at the next level a folder "Beginner_Tutorial__Ship_AI-14".
19:23:05  <Zuu> I don't know if this is because it saves the tar inside a temporary file that or if this means that the tar will contain a silly extra directory at the remote side too.
19:23:54  <Rubidium> that directory is needed to prevent duplicate paths in openttd; it always happens upon repacking in bananas
19:24:11  <Zuu> The "extra directory" do however not show a directory symbol in 7zip but a "unknown filetype" symbol.
19:24:32  <Zuu> Ok
19:25:01  <Rubidium> maybe a corrupt tar is generated?
19:25:39  <Rubidium> or it tries/tried to append something because the file was not removed?
19:25:55  <Zuu> that or ther is some Windows path thingy...
19:26:26  <Rubidium> oh... that's possible too
19:27:17  <Zuu> But the thing is that the license.txt validator do not look for "license.txt" in the tar, but instead tries to calculate a absolute path to it in the tar. Thus if the license.txt is not where it expects it to be, it will fail.
19:28:21  <Zuu> In I instead iterate over all files until I find info.nut or library.nut (or a .png, .bmp, .grf, .. )
19:29:07  <Zuu> The later will accept if someone hides license.txt somwhere else than in the root which may or may not be wanted.
19:29:48  <Rubidium> that's not wanted; it must be next to info.nut in a subfolder of the tar's root
19:36:16  <Zuu> This may very well be that the path to the first subfolder is not correctly working when is used on Windows. (assuming you and TB only tested it on Linux) validation of the license is the first server side validation that looks into the tar.
19:36:58  <Zuu> "Beginner_Tutorial__Ship_AI-14" is sent to the server as metadata. If that extra layer in the tar is also present on the server, then that may be why it fails.
19:43:40  <Rubidium> maybe the windows "\" may not be in the tar file or so?
19:44:25  <Zuu> possible
19:45:29  * Rubidium really dislikes the genius that used / for parameters in the first DOS
19:45:35  <Zuu> I can think of two interesting tests. 1) try to upload from Linux instead.  2) try to obtain the tar from the server. (possible by me running the server locally as it doesn't really need any dB access to test the parts that currently fail)
19:48:24  <Zuu> However, my clock sais that it has to be done another day.
19:58:12  <Rubidium> ;)
20:19:28  *** Zuu has quit IRC
20:19:52  *** Zuu has joined
20:19:52  *** ChanServ sets mode: +v Zuu
20:44:30  *** Ristovski has quit IRC
21:17:40  *** frosch123 has quit IRC
23:18:27  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk