On Jun 12, 2009, at 17:13 PM, Andrej Falout wrote: > > Hi Francois, > > Any chance for a fix in a near future? 1.3 no longer works (usably) with > allmydata.com and I do need Unicode support, so I cant do backups ATM...
What changed which caused this regression? The next step for François's unicode patches is to write complete tests. For example, here is one of the patches: http://allmydata.org/trac/tahoe/attachment/ticket/534/%20tahoe%20manifest%20unicode%20support.darcspatch Since this is changing the behavior of the parseArgs() method of the Manifest object, it needs a test to check whether the resulting 'self.where' is right even when the 'where' argument isn't ascii but is instead in the encoding appropriate for argv on the current platform. Now there is already a test of the manifest command: http://allmydata.org/trac/tahoe/browser/src/allmydata/test/test_cli.py?rev=20090609210509-92b7f-540d8762ba78bcb54be6775a376332d453ea2f7b#L1371 So one easy way to test the decoding of the arguments to manifest would be to change that extant test to pass a non-ascii argument to manifest. (I guess this would require changing it to pass an alias name instead of a cap, or to pass a cap followed by ":./pathname" with a non-ascii pathname.) It might be nicer to construct a new test specifically for this decoding -- I'm not sure how it should be done. Maybe just instantiate an instance of Manifest, invoke its parseArgs() passing an argument in the appropriate encoding for the current platform, and then assert that its self.where member is right. Brian: what do you think? Now, what *is* the appropriate encoding of argv on various platforms? I think the answer is sys.stdin.encoding -- at least on Windows if you set the codepage with the chcp command and then run Python, the sys.stdin.encoding changes to reflect the chosen codepage. Regards, Zooko _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
