IRC logs for #openttd.dev on OFTC at 2013-04-07
⏴ go to previous day
03:05:33 *** Supercheese has joined #openttd.dev
07:35:26 *** Alberth has joined #openttd.dev
07:35:26 *** ChanServ sets mode: +v Alberth
08:42:08 *** Meechmunchie has joined #openttd.dev
08:43:01 *** Meechmunchie has left #openttd.dev
08:48:37 *** Zuu has joined #openttd.dev
09:50:42 *** frosch123 has joined #openttd.dev
09:50:42 *** ChanServ sets mode: +v frosch123
10:20:12 *** Ristovski has joined #openttd.dev
10:21:26 <Zuu> The bug was that shortName is not defined.
10:21:46 <Zuu> I define short_name and use that instead as most of musa do not use camel case.
10:22:22 <frosch123> yay, undefined variables :)
10:22:32 <Zuu> Why I like compiled programs :-)
10:26:34 <Rubidium> though can't python be compiled?
10:29:07 <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:36:11 <Alberth> although that will bark on a lot of other things too by default :p
10:55:21 <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:57:32 <Alberth> for exclude in options.exclude: <-- so you loop over characters?
10:58:14 <Zuu> Alberth: Hmm, maybe not. I just took that code from musa.py
11:00:25 <Zuu> So I didn't actually touch it, but your comment makes sense
11:01:34 <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:03:41 <Alberth> perhaps it was a string at some point in the past
11:06:24 <Zuu> Removing the != "" check altogeather appears to work just fine.
11:08:33 <Zuu> I'll fix musa.py then and remove the check in depgen.patch
11:10:18 <Alberth> you can ask for the type of a value with type(val)
11:10:46 <Zuu> May be a useful tips for debugging
11:12:08 <Zuu> depgen.patch updated. Anything more, or shall I commit it?
11:12:20 <Alberth> In my experience, you have to write doc strings with types for parameters and return values to prevent you from getting lost
11:12:40 <Alberth> I have no more, if you have considered all things I mentioned yesterday
11:13:41 <Zuu> Alberth: I usually have far more comments in my python scirpt. However depgen.py have far more comments than the rest of musa.
11:14:25 <Zuu> Alberth: I've reviewed your comemnts from yesterday and checked the code for implementation of the comments.
13:30:18 *** Ristovski has joined #openttd.dev
13:37:17 *** Ristovski has joined #openttd.dev
13:59:18 *** Ristovski has joined #openttd.dev
14:57:21 *** Ristovski has joined #openttd.dev
15:13:30 *** Zuu has joined #openttd.dev
18:08:09 <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 musa.py delete the tar file before it is uploaded. This I've fixed locally. (http://devs.openttd.org/~zuu/musa-fix3.patch)
18:08:58 <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:11:34 <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:14:39 *** Ristovski has joined #openttd.dev
18:20:45 <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:23:46 <Rubidium> if there are other checks except the filenames, then those should be done before exiting
18:30:45 <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:31:52 *** Alberth has left #openttd.dev
18:34:44 <Rubidium> so, then the patch is fine ;)
18:35:14 <Zuu> Except that I fixed the wrong hegihtmap procedure, but I found and fixed that. :-)
18:36:18 <Zuu> So the commit is correct.
18:38:36 <Zuu> I think you have a new stack trace :-)
18:39:25 <Rubidium> can you trigger some more, looks like it isn't flushed yet
18:40:44 <Zuu> I've trigged som 4-5 more now
18:41:12 <Rubidium> hmm... needs more I guess
18:41:28 <Rubidium> or nothing is coming, but I reckon it's some 4k before it flushes
18:41:41 <Rubidium> or I need to know how to force a flush in python
18:41:56 <Zuu> 4k is quite many "yes I am" for me to type ;-)
18:43:48 <Rubidium> apparantly python has some unbuffered function
18:43:49 <Zuu> oh, now I didn't get a trace locally..
18:43:54 <Rubidium> or command line option
18:44:32 <Zuu> Ah,.. "invalid username/password"
19:00:14 *** Supercheese has joined #openttd.dev
19:17:08 <Zuu> 1) there was a bug in packing of dependency metadata. (locally fixed)
19:17:40 <Zuu> 2) now the server complais that license.txt is missing while the local validation of license.txt succeeds :-)
19:22:54 <Rubidium> might you have a local modification?
19:24:25 <Zuu> I let musa.py 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:25:24 <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:26:13 <Rubidium> that directory is needed to prevent duplicate paths in openttd; it always happens upon repacking in bananas
19:26:29 <Zuu> The "extra directory" do however not show a directory symbol in 7zip but a "unknown filetype" symbol.
19:27:20 <Rubidium> maybe a corrupt tar is generated?
19:27:58 <Rubidium> or it tries/tried to append something because the file was not removed?
19:28:14 <Zuu> that or ther is some Windows path thingy...
19:28:44 <Rubidium> oh... that's possible too
19:29:36 <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:30:39 <Zuu> In depgen.py I instead iterate over all files until I find info.nut or library.nut (or a .png, .bmp, .grf, .. )
19:31:26 <Zuu> The later will accept if someone hides license.txt somwhere else than in the root which may or may not be wanted.
19:32:06 <Rubidium> that's not wanted; it must be next to info.nut in a subfolder of the tar's root
19:38:35 <Zuu> This may very well be that the path to the first subfolder is not correctly working when musa.py 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:39:16 <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:45:59 <Rubidium> maybe the windows "\" may not be in the tar file or so?
19:47:48 * Rubidium really dislikes the genius that used / for parameters in the first DOS
19:47:53 <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:50:43 <Zuu> However, my clock sais that it has to be done another day.
20:22:10 *** Zuu has joined #openttd.dev
continue to next day ⏵