Issue 17618: base85 encoding - Python tracker (original) (raw)
Created on 2013-04-02 13:23 by pitrou, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (47)
Author: Antoine Pitrou (pitrou) * 
Date: 2013-04-02 13:23
Base85 encoding (see e.g. http://en.wikipedia.org/wiki/Ascii85 ) allows a tighter encoding than Base64: it has a 5/4 expansion ratio, rather than 4/3. It is used in Mercurial, git, and there's another variant that's used by Adobe in the PDF format.
It would be nice to have a Base85 implementation in either the binascii or base64 modules.
(unfortunately the Mercurial implementation is GPL'ed, although if we want to copy it we might simply ask them for a relicensing)
Author: Sijin Joseph (sijinjoseph)
Date: 2013-04-07 15:20
Is anyone working on this? I'd like to include this in a CPython sprint @MIT on 4/13.
Author: R. David Murray (r.david.murray) *
Date: 2013-04-07 15:24
Antoine is talking to Mercurial about relicensing, and I believe at this point it is just a matter of working out the mechanical details (that is, he has an agreement-in-principal from them).
Author: Antoine Pitrou (pitrou) *
Date: 2013-04-07 15:29
The Mercurial authors have given their informal agreement for a relicensing. OTOH, they must still sign a contributor's agreement. The relicensing would allow us to use their pure Python implementation (in mercurial/pure/base85.py). OTOH, the C implementation (in mercurial/base85.c) is a ripoff of the git one, so we'd better rewrite our own.
My current plan would be the following:
- create a binascii.py and rename binascii.c to _binascii.c
- add Mercurial's pure Python implementation to binascii.py
- add a custom C implementation to _binascii.c
- make sure the binascii test suite tests both implementations
OTOH, if we don't get the Mercurial authors' contributor agreement, we can also re-write our own pure Python implementation.
In any case, our implementation should IMHO be compatible with Mercurial's (i.e. produce identical outputs for the same inputs).
Author: Martin Morrison (isoschiz) *
Date: 2013-04-07 15:53
I wrote an implementation from scratch (based on the wikipedia article; I've not looked at any existing implementations) in pure Python in the attached diff. It includes tests.
Feel free to use it as the pure Python implementation if desired, though I won't be offended if you just end up using the Mercurial one. :-)
Author: Martin Morrison (isoschiz) *
Date: 2013-04-07 15:58
(sorry for spam)
Forgot to mention, I included an optional keyword argument to support the 'btoa' shortcut for sequences of space characters as described in the Wikipedia article. However, I'm unsure if any other implementation supports this, so might not be worth including it in our implementation.
A better feature might be to support full btoa output, but the Wikipedia article doesn't have a complete enough specification, and I couldn't find (didn't really look for) one elsewhere. If no one uses it though, again. probably not worth including it.
Author: Antoine Pitrou (pitrou) *
Date: 2013-04-07 16:09
Forgot to mention, I included an optional keyword argument to support the 'btoa' shortcut for sequences of space characters as described in the Wikipedia article. However, I'm unsure if any other implementation supports this, so might not be worth including it in our implementation.
In this issue I would really like to aim for Mercurial/git-like
behaviour: i.e. no special shortcuts, and no armoring ('<' and '>').
Also, the base85 alphabet used by Mercurial and git may be different, I
haven't checked.
(by the way, it seems "btoa" has been dead for a long time, I don't think it's useful as a reference here)
Author: Martin Morrison (isoschiz) *
Date: 2013-04-07 16:15
Ok, having now looked at mercurial's implementation... it looks like they implemented the RFC1924 version, whereas my implementation is the Ascii85 version (and I verified it against, amongst others: http://www.tools4noobs.com/online_tools/ascii85_encode/ ).
The Ascii85 version is what is used with PDF, and the default output format for the equivalent Ruby library, so seems useful to have. So I guess what might be desirable is to have both in the codebase?
Author: Antoine Pitrou (pitrou) *
Date: 2013-04-07 16:19
The Ascii85 version is what is used with PDF, and the default output format for the equivalent Ruby library, so seems useful to have. So I guess what might be desirable is to have both in the codebase?
Yes, it could be useful to have both.
Author: Martin Morrison (isoschiz) *
Date: 2013-04-07 16:42
Ok, I'm not even sure that Mercurial follows RFC1924! That RFC is specifically for encoding IPv6 addresses, and mandates that the calculations be performed on a 128bit integer.
The Mercurial implementation seems to follow the Ascii85 policy of taking each 4 bytes separately and doing 32bit arithmetic, but uses the lookup table from RFC1924, and is less lenient about spacing, and has no compression for sequences of zeroes.
It therefore looks like Mercurial (and I guess Git) have their own, non-standard base64 encoding. The Web at large mostly has "standard" Ascii85 encoding/decoding described. RFC1924 itself has a Python implementation on Github:
https://github.com/drkjam/netaddr/blob/rel-0.7.x/netaddr/ip/rfc1924.py
So I'm not sure what you want to do. I would suggest a standard Ascii85 encoder is definitely useful, and provides feature parity with Ruby. If we want the standard library to be able to read/write Mercurial/Git base64 encoded files, then I guess that can be added too. If we think RFC1924 is useful/used, then the implementation in the netaddr lib looks right.
Author: Antoine Pitrou (pitrou) *
Date: 2013-04-07 17:18
So I'm not sure what you want to do. I would suggest a standard Ascii85 encoder is definitely useful, and provides feature parity with Ruby. If we want the standard library to be able to read/write Mercurial/Git base64 encoded files, then I guess that can be added too. If we think RFC1924 is useful/used, then the implementation in the netaddr lib looks right.
Agreed for both the Ascii85 encoder and the hg/git brand of base85 (which is used for "binary diffs", by the way). I don't think supporting RFC1924 is useful, though.
(I think using "ascii85" and "base85" for those encodings, respectively, provides a nice way to distinguish them)
Author: Antoine Pitrou (pitrou) *
Date: 2013-04-13 17:59
For the record, Mads and Brendan have submitted a contributor's agreement, so we can now take what we want from Mercurial's base85.py (which you can find at http://selenic.com/hg/file/4e1ae55e63ef/mercurial/pure/base85.py).
Author: Martin Morrison (isoschiz) *
Date: 2013-04-13 18:25
Ok, great. I'll update the patch to include both encoding schemes.
Author: Martin Morrison (isoschiz) *
Date: 2013-04-14 00:24
Updated patch that includes both my original implementation of Ascii85, as well as the Mercurial implementation of base85. A few notes/questions:
I named the Mercurial base85 implementation functions with the "b85" prefix. For the Ascii85 ones, I used "a85". I considered overloading the same functions with a keyword argument to select which encoding, but rejected that. Thoughts?
I made only minor modifications to the Mercurial code to use bytes throughout (to match all the other APIs in the module). I also updated the docstrings a bit. My goal was to change as little as possible to guarantee identical behaviour.
I haven't made the changes to add a pure Python binascii module as suggested in . Although poorly named, "base64.py" already contains a number of other encodings, so this seemed the best place for these too. I'm happy to make that change as well though if you really want it as part of this issue.
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-04-14 08:51
I want to see both algorithms to be similar so far as it is possible. It might be worth extract and reuse a common code. Mercurial's code looks far more optimal (for example a85encode has a quadratic complexity in result accumulating).
Author: Martin Morrison (isoschiz) *
Date: 2013-04-14 15:51
I've updated the Ascii85 algorithms to remove the quadratic complexity, and use a single struct.pack/unpack. They should now be much quicker for large input strings.
It's difficult to factor out commonality with b85* because the encodings and rules differ. This is especially true for decode (where Ascii85 allows arbitrary whitespace, so it either has to be stepped through as I've implemented it, or it would have to first be sanitised with .replace() or similar, which is expensive for large inputs). For encode, the special cases supported by Ascii85 make it impossible to just use a lookup table, and the simplified algorithm for encoding means it isn't necessary to use one at all. I also wanted to keep the Mercurial code intact as much as possible, so it can be kept in sync in future if necessary.
My notes from the previous diff also still apply if anyone has thoughts on those.
Author: Antoine Pitrou (pitrou) *
Date: 2013-04-14 17:36
Hi and thanks for the patch!
I named the Mercurial base85 implementation functions with the "b85" prefix. For the Ascii85 ones, I used "a85". I considered overloading the same functions with a keyword argument to select which encoding, but rejected that. Thoughts?
I agree, it's better like this.
I haven't made the changes to add a pure Python binascii module as suggested in . Although poorly named, "base64.py" already contains a number of other encodings, so this seemed the best place for these too.
Yes, I think it's ok. I was thinking about binascii in the context of making a C version, but we can refactor things later anyway.
Now about the patch: I haven't read it in detail, but it seems to lack tests for b85decode and b85encode. It should be easy enough to get some test values by calling Mercurial's version.
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-04-17 13:58
After a more careful look of the b85encode code I say that it's implementation is not optimal. For the sake of simplicity the entire volume of data is copied several times. This can affect the processing of a large volume of data. On other hand, this dumb copying can be faster then more smart processing in a85encode. Only benchmarks will show the truth.
Using a trick with struct.unpack() has very unpleasant side effect. It might be a few speed up encoding, but creates the Struct object with the size is many times larger than the size of the processed data. Worse, this object is cached and continues to consume memory. Since the size of the data most likely will be unique, almost every call of b85encode creates a new object. This will lead to memory leaks.
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-04-17 15:28
After searching a lot of other implementations of this encoding I conclude that there are at least three different variants.
The original btoa/atob encoding. 4 zeros are packaged as 'z', last incomplete 4 bytes are padded by zeros, an output is wrapped into several lines and decoder ignores '\n'. There are many implementations of this algorithm in different languages.
Adobe version. This is an extended version of (1). The last incomplete 4 bytes produces less then 5 output characters, an output is enclosed in <~ and ~>. Decoder ignores all ascii whitespaces, not only '\n'. There are many implementations of this algorithm in different languages.
Git and Mercurial version. This is a very simplified version of (1) with an alternative character set. Zeros are not packed, an output is not broken into several lines and decoder doesn't ignores any whitespaces. I don't know is whether this variant used besides Git and Mercurial.
Some implementations combine (1) and (2) (optionally enclose an output in <~ and ~>, optionally wrap an output into several lines, optionally pad last 4 incomplete bytes).
Author: Antoine Pitrou (pitrou) *
Date: 2013-04-17 15:47
After searching a lot of other implementations of this encoding I conclude that there are at least three different variants.
Yes. The current proposal is to include both the Adobe version ("ascii85") and the Mercurial/Git version ("base85"). btoa/atob seems extinct.
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-04-17 18:14
btoa/atob seems extinct.
At least half of ascii85 encoders in wild implement this variant.
I think we can provide a universal solution compatible (with some pre/postprocessing) with both variants. Enclose encoded data in <~ and ~> or not, and at which column wrap an encoded data. Padding can be easy implemented as preprocessing (data + (-len(data)) % 4 * b'\0').
As for Git/Mercurial's base85, what other applications use this encoding?
Author: Antoine Pitrou (pitrou) *
Date: 2013-04-17 18:21
Le mercredi 17 avril 2013 à 18:14 +0000, Serhiy Storchaka a écrit :
I think we can provide a universal solution compatible (with some pre/postprocessing) with both variants. Enclose encoded data in <~ and ~> or not, and at which column wrap an encoded data. Padding can be easy implemented as preprocessing (data + (-len(data)) % 4 * b'\0').
That's ok with me. It's just more work for whoever does it :-)
As for Git/Mercurial's base85, what other applications use this encoding?
I don't know, but they use it to produce binary diffs ("diff" chunks of binary files), so any application wanting to parse Mercurial/Git diffs would have to recognize base85 data.
(and I also like that the Mercurial/Git variant is the simpler of all 3 :-))
Author: Martin Morrison (isoschiz) *
Date: 2013-04-17 18:39
Using a trick with struct.unpack() has very unpleasant side effect. It might be a few speed up encoding, but creates the Struct object with the size is many times larger than the size of the processed data. Worse, this object is cached and continues to consume memory. Since the size of the data most likely will be unique, almost every call of b85encode creates a new object. This will lead to memory leaks.
Can you elaborate on this? What leakage is there? I assume this is some implementation quirk of the struct module that I'm not aware of.
Le mercredi 17 avril 2013 à 18:14 +0000, Serhiy Storchaka a écrit :
I think we can provide a universal solution compatible (with some pre/postprocessing) with both variants. Enclose encoded data in <~ and ~> or not, and at which column wrap an encoded data. Padding can be easy implemented as preprocessing (data + (-len(data)) % 4 * b'\0').
That's ok with me. It's just more work for whoever does it :-)
As I mentioned in one of my previous comments, I was trying very hard not to touch the Mercurial solution (b85(en|de)code in the latest patch), and just copy it wholesale. Mostly, I don't really like the way the solution reads (unpythonic in my eyes), but can understand that for this kind of thing that might be the best way.
In my solution (a85(en|de)code) I wrote it from scratch in what I felt was a readable way. I can quite easily extend my version to support your description of the btoa/atob version (i.e. no bracketing, always pad, always wrap output).
I'm less convinced it's sensible to merge the ascii85 implementations and the Mercurial b85 one. If you really want that though, I would be in favour of using my a85 implementation and just changing the encode inner function to use the lookup table.
(we can do all this independently of the function names, which I think Antoine and I are agreed should be separate for the different implementations)
As for Git/Mercurial's base85, what other applications use this encoding?
I don't know, but they use it to produce binary diffs ("diff" chunks of binary files), so any application wanting to parse Mercurial/Git diffs would have to recognize base85 data.
(and I also like that the Mercurial/Git variant is the simpler of all 3 :-))
I actually prefer the Ascii85 one for the simplicity of the encoding (shift base 85 chunks of the input by 33 to get into the printable ascii range) rather than the clunky lookup table approach. À chacun son goût. :-)
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-04-17 18:51
Can you elaborate on this? What leakage is there? I assume this is some implementation quirk of the struct module that I'm not aware of.
.
Author: Martin Morrison (isoschiz) *
Date: 2013-04-17 19:03
Can you elaborate on this? What leakage is there? I assume this is some implementation quirk of the struct module that I'm not aware of.
.
Thanks for the pointer. I will rework the patch for the encoder/decoders to use an explicit Struct so that the inbuilt cache gets bypassed and we don't "leak",
Author: Antoine Pitrou (pitrou) *
Date: 2013-04-17 19:37
Serhiy, Martin, perhaps one of you could report the potential memory leak on the Mercurial bug tracker: http://bz.selenic.com/
Author: Martin Morrison (isoschiz) *
Date: 2013-04-17 22:39
New diff. Changes from the last one:
change in struct handling to avoid
Addition of btoa85 and atob85 functions that do legacy 'btoa' encoding/decoding. These are just wrappers around a85(en|de)code, which now have additional keyword args to control wrapping, padding, framing, and whitespace skipping
New tests covering all 3 variants
Author: Martin Morrison (isoschiz) *
Date: 2013-04-18 22:20
Raised http://bz.selenic.com/show_bug.cgi?id=3894 against Mercurial for them to workaround .
Author: Martin Morrison (isoschiz) *
Date: 2013-04-18 22:25
Attached a minor tweak over the last diff - I'd forgotten to fix the Struct handling inside the Mercurial implementation as well.
All other comments still apply to this diff.
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-04-20 23:23
There are some bugs in ascii85 end base85 implementations (see in Rietveld for details). Besides, ascii85 implementation was too slow. I've prepared a patch that corrects errors and speeds up encoding and decoding.
Microbenchmarks:
./python -m timeit -r 1 -n 1 -s "from base64 import a85encode as encode; data = open('python', 'rb').read(1000001)" "encode(data)" ./python -m timeit -r 1 -n 1 -s "from base64 import b85encode as encode; data = open('python', 'rb').read(1000001)" "encode(data)" ./python -m timeit -r 1 -n 1 -s "from base64 import a85encode as encode, a85decode as decode; data = encode(open('python', 'rb').read(1000001))" "decode(data)" ./python -m timeit -r 1 -n 1 -s "from base64 import b85encode as encode, b85decode as decode; data = encode(open('python', 'rb').read(1000001))" "decode(data)"
Old patch New patcha85encode 8.4 sec 1.13 sec b85encode 1.35 sec 1.09 sec a85decode 9.28 sec 3.29 sec b85decode 3.17 sec 2.37 sec
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-04-21 16:38
As for interface, I think 'adobe' flag should be false by default. It makes encoder simpler. ascii85 encoder in Go's standard library doesn't wrap nor add Adobe's brackets. btoa/atob functions looks redundant as we can just use a85encode/a85decoder with appropriate options. Perhaps we should get rid from 'adobe' flag in a85decode and autodetect it. And perhaps to do the same with other a85decode's options.
Author: Martin Morrison (isoschiz) *
Date: 2013-04-21 17:06
On 21 Apr 2013, at 17:38, Serhiy Storchaka <report@bugs.python.org> wrote:
Serhiy Storchaka added the comment:
As for interface, I think 'adobe' flag should be false by default. It makes encoder simpler. ascii85 encoder in Go's standard library doesn't wrap nor add Adobe's brackets. btoa/atob functions looks redundant as we can just use a85encode/a85decoder with appropriate options. Perhaps we should get rid from 'adobe' flag in a85decode and autodetect it. And perhaps to do the same with other a85decode's options.
The problem with autodetecting is that it makes it impossible for an application to use this library to verify that something is encoded in a specific way. Explicit is better than implicit.
Otherwise, your changes look good to me.
Author: Antoine Pitrou (pitrou) *
Date: 2013-04-23 17:28
The problem with autodetecting is that it makes it impossible for an application to use this library to verify that something is encoded in a specific way. Explicit is better than implicit.
Agreed. Also, you generally known what format your data is in. Otherwise, how do you know that it is base85 rather than, say, base64 or uuencode?
Author: Antoine Pitrou (pitrou) *
Date: 2013-08-23 19:08
Serhiy, Martin, is one of you still working on this?
Author: Jason Stokes (glasper)
Date: 2013-10-06 05:03
What issues are there with the implementation as it stands? I am happy to contribute (as I need to code a base36 implementation myself, and it's basically the same work) but it looks like the existing implementation is fine, except possibly some people don't like "adobe" being implemented by default?
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-10-06 07:11
I'm not very interesting in working on this (but analyzing and optimizing made fun to me). You Antoine as originator definitely are interested. So make decision about interface which you need and finish the work using proposed patches as a basis. I would made a review.
I'm a little doubt about appropriateness base85 codec in the base64 module ("This module provides data encoding and decoding as specified in RFC 3548."). Base85 is not standard. But I don't see better place for it. At least the description of the base64 module should be corrected.
I suggest first resolve . Perhaps it will get suggestions about base85 interface.
Author: Antoine Pitrou (pitrou) *
Date: 2013-10-06 11:56
Well, I think the following comments (Serhiy's) should be implemented:
"""As for interface, I think 'adobe' flag should be false by default. It makes encoder simpler. ascii85 encoder in Go's standard library doesn't wrap nor add Adobe's brackets. btoa/atob functions looks redundant as we can just use a85encode/a85decoder with appropriate options."""
Author: Antoine Pitrou (pitrou) *
Date: 2013-11-16 22:42
Updated patch with suggested API changes, + docs.
Author: Antoine Pitrou (pitrou) *
Date: 2013-11-16 23:31
Updated patch incorporating Serhiy's self-review from 6 months ago (grr).
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-11-17 13:37
I added more comments on Rietveld.
Author: Antoine Pitrou (pitrou) *
Date: 2013-11-17 13:49
I added more comments on Rietveld.
Did you forget to publish them?
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-11-17 13:59
Grr.
Author: Antoine Pitrou (pitrou) *
Date: 2013-11-17 18:42
Updated patch after Serhiy's comments.
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2013-11-17 21:49
Yet one nitpick and the patch LGTM.
Author: Roundup Robot (python-dev) 
Date: 2013-11-17 22:54
New changeset 42366e293b7b by Antoine Pitrou in branch 'default': Issue #17618: Add Base85 and Ascii85 encoding/decoding to the base64 module. http://hg.python.org/cpython/rev/42366e293b7b
Author: Antoine Pitrou (pitrou) *
Date: 2013-11-17 22:55
Now committed, thanks for the reviews and the code!
Author: Roundup Robot (python-dev)
Date: 2014-03-08 17:54
New changeset 1853679c6f71 by R David Murray in branch 'default': whatsnew: base65 encodings. (#17618) http://hg.python.org/cpython/rev/1853679c6f71
History
Date
User
Action
Args
2022-04-11 14:57:43
admin
set
github: 61818
2014-03-08 17:54:16
python-dev
set
messages: +
2013-11-17 22:55:05
pitrou
set
status: open -> closed
resolution: fixed
messages: +
stage: needs patch -> resolved
2013-11-17 22:54:18
python-dev
set
nosy: + python-dev
messages: +
2013-11-17 21:49:54
serhiy.storchaka
set
messages: +
2013-11-17 18:42:13
pitrou
set
files: + base85-3.patch
messages: +
2013-11-17 13:59:43
serhiy.storchaka
set
messages: +
2013-11-17 13:49:23
pitrou
set
messages: +
2013-11-17 13:37:23
serhiy.storchaka
set
messages: +
2013-11-16 23:31:08
pitrou
set
files: + base85-2.patch
messages: +
2013-11-16 22:42:04
pitrou
set
files: + base85.patch
messages: +
2013-10-06 11:56:47
pitrou
set
messages: +
2013-10-06 07:12:22
serhiy.storchaka
set
assignee: pitrou
2013-10-06 07:11:30
serhiy.storchaka
set
messages: +
2013-10-06 05:03:47
glasper
set
nosy: + glasper
messages: +
2013-09-24 21:29:25
pitrou
set
nosy: + vstinner
2013-08-23 19:08:10
pitrou
set
messages: +
2013-04-23 17:28:48
pitrou
set
messages: +
2013-04-21 17:06:42
isoschiz
set
messages: +
2013-04-21 16:38:47
serhiy.storchaka
set
messages: +
2013-04-20 23:23:41
serhiy.storchaka
set
files: + issue17618-fast.diff
messages: +
2013-04-19 20:38:24
serhiy.storchaka
set
files: + issue17618-5.diff
2013-04-18 22:25:56
isoschiz
set
files: + issue17618-5.diff
messages: +
2013-04-18 22:20:02
isoschiz
set
messages: +
2013-04-17 22:39:25
isoschiz
set
files: + issue17618-4.diff
messages: +
2013-04-17 19:37:57
pitrou
set
messages: +
2013-04-17 19:03:35
isoschiz
set
messages: +
2013-04-17 18:51:07
serhiy.storchaka
set
messages: +
2013-04-17 18:39:40
isoschiz
set
messages: +
2013-04-17 18:21:48
pitrou
set
messages: +
2013-04-17 18:14:42
serhiy.storchaka
set
messages: +
2013-04-17 15:47:55
pitrou
set
messages: +
2013-04-17 15:28:33
serhiy.storchaka
set
messages: +
2013-04-17 13:58:49
serhiy.storchaka
set
messages: +
2013-04-14 17:36:26
pitrou
set
messages: +
2013-04-14 15:51:49
isoschiz
set
files: + issue17618-3.diff
messages: +
2013-04-14 08:51:55
serhiy.storchaka
set
messages: +
2013-04-14 00:24:54
isoschiz
set
files: + issue17618-2.diff
messages: +
2013-04-13 18:25:06
isoschiz
set
messages: +
2013-04-13 17:59:15
pitrou
set
messages: +
2013-04-07 17🔞29
pitrou
set
messages: +
2013-04-07 16:42:54
isoschiz
set
messages: +
2013-04-07 16:21:25
serhiy.storchaka
set
nosy: + serhiy.storchaka
2013-04-07 16:19:23
pitrou
set
messages: +
2013-04-07 16:15:44
isoschiz
set
messages: +
2013-04-07 16:09:22
pitrou
set
messages: +
2013-04-07 15:58:17
isoschiz
set
messages: +
2013-04-07 15:53:37
isoschiz
set
files: + issue17618.diff
nosy: + isoschiz
messages: +
keywords: + patch
2013-04-07 15:29:50
pitrou
set
messages: +
stage: needs patch
2013-04-07 15:24:24
r.david.murray
set
nosy: + r.david.murray
messages: +
2013-04-07 15:20:16
sijinjoseph
set
nosy: + sijinjoseph
messages: +
2013-04-03 01:43:31
jcea
set
keywords: + easy
2013-04-03 01:42:50
jcea
set
nosy: + jcea
2013-04-02 14:16:31
flox
set
nosy: + flox
2013-04-02 13:23:35
pitrou
create