Ordinal not in range(128), wsgi + stdout

[Johannes]

The makro is running fine on Trac 0.12dev-r7195, but is does not handle special chars (e.g. german umlauts). If special chars appear in milestone or ticket names, lines 165f 'name = row[0] ... buff.write( ... name ...)' produce the error: 'ordinal not in range(128)'. Additionaly they contain a typo (celpadding). Maybe this could be fixed using .encode("utf-8"). I did not manage to fix it though :-(

Also I encountered some problems with mod_wsgi, because of 'sys.stdout'. I soluted that with the following workaraund: 'sys.stdout = sys.stderr'. This could be done better, but unfortunately I'm no good ar python :(

[Johannes]

Like alex wrote, the problem with special chars can be fixed like that: '...by changing the line "from cStringIO import StringIO" to "from StringIO import StringIO".'

That works now. Still, there's the typo ans the stdout/wsgi problem, which are not crucial.

[Ryan J Ollos]

Reassigning ticket after changing maintainers.

[Steffen Hoffmann]

rjollos, would you comment about relevance please. I did never encounter this while testing with 0.12dev for quite some time now. Is this related to #2548, #2617 and #7018 (unicode issues at different levels/locations inside the code) and fixed anyway by r7893?

[Steffen Hoffmann]

I can't reproduce with 0.12dev-trac:r9705, so would like to close it soon.

Could someone test with 0.11 and maybe even 0.10 and report back with Trac version included, if there is still an issue? Thanks in advance.

[Steffen Hoffmann]

Since 0.10 is officially depreciated right now, there is only 0.11 branch remaining. 0.12 version should work as stated before.

To bring this to an end I set a deadline for responses:
Report back within 4 months after release date of upcoming Trac 0.12, please. This ticket will be resolved or close with 'worksforme' after that time.

@reporter: Consider opening another ticket for your wsgi related problem, if persisting, since this looks like a different and unrelated subject, to help us with issue tracking here. I change Trac release to 0.12 as well, since issues were reported for 0.12dev. Finally severity 'major' is reinstalled, since one might not be able to use the calendar without a proper fix, but priority is low for missing feedback right now.

[Steffen Hoffmann]

While reworking code from trunk for #7239 I suddenly got the 'Ordinal not in range(128)' too.

Corrected code is available with [8113] right now, that should fix this once and for all by extending use of to_unicode. Next release of new branch versions will contain this as well.

The ticket acceptance applies only to the first reported issue. Still I have no clue on mod_wsgi, but again I demand to move that issue to another ticket, if persisting. Test latest code from trunk now and report back please. This ticket will get closed soon, if no dispute or vote is raised against this.

[Steffen Hoffmann]

I found milestone description with non-ascii chars to throw an Genshi exception. Changeset [8165] brought a fix for this and changing of positions where we use to_unicode().

Since there was no feedback on my info requests for almost a full month I'll leave it like this and go for closing this ticket with one issue reproduced, fixed and tested by myself.

Please test code from current trunk and report back to help propagating the fix from trunk to branch releases soon.

[Steffen Hoffmann]

Trunk got a major code re-design with [8204]. After replacing string operations for HTML construction with Genshi's tag() now the unicode related issues should be finally gone.

[Steffen Hoffmann]

(In [8263]) WikiTicketCalendarMacro: Copy trunk to 0.12 and merge changes to 0.11 as well, closes #7239 #7236 #3159 #7304.

This is a major push to get latest development into both currently maintained branches. Next to a lang rewrite for saner HTML generation there is a new approach to ticket description preview by native CSS style text boxes. Expect some more subtle tweaks to calendar presentation as well.