Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Can't test or build

Hello,
I just installed Twine 1.4.1, and the editor seems to work fine but I can't test or build a story.
I get an ascii codec error, even though I don't have any special characters in my story. In fact, I get this error even with the basic starting story that appears when opening Twine too. So, to reproduce the error, I just need to launch Twine and press ctrl+t.

Any idea what's going on?

Comments

  • What OS are you running Twine on?

    Are you using Python that came with Twine or that was already installed on your computer?

    Can you post the full error message? I don't know if Twine includes the backtrace (list of file names, line number and fragments of source code), but if it does, that is very useful for programmers to track down a problem.
  • I'm using Windows 7 64-bit. I have Python 2.7 installed.

    The error message is:
    "An error occured while building your story ('ascii' codec can't decode byte 0xe4 in position 35: ordinal not in range(128))."

    Unfortunately I don't get a traceback. Is there some kind of debug mode? I tried to run Twine from the command line but I didn't get any output there either.
  • It's possible the backtrace doesn't appear if the error is intercepted by the GUI.

    In Linux, running the starting story skeleton works fine, so there must be some particular circumstance that triggers the problem.

    What language is your Windows set to? Byte 0xe4 is a-umlaut in ISO Latin 1; this character doesn't occur in the start story, but maybe it exists in a string that comes from the OS? Or maybe in the path that you installed Twine in?
  • Now that's interesting. An a-umlaut might very well come from an OS string as my language is Swedish. It's not the path though.
  • Can you access app.py? If so, you could add this code at the start of the "displayError" method: (but not between the triple quotes)

    from traceback import print_exc
    print_exc()
    That should print the traceback on the console.
  • I wish I could. Unfortunately, I can't find such a file; the Python-related files all have .pyd extensions as well.
    Maybe I could figure something out by downloading the source and going from there.
  • Yes, a git checkout or a source ZIP export from github would give you app.py. However, to run Twine you'd need wxPython as well, which is probably packaged in the all-in-one .exe, but I don't know if it's easy to install it separately on Windows.
  • Alright, here we go:

    Traceback (most recent call last):
    File "C:\Users\Daniel\Desktop\twine-master\storyframe.py", line 885, in rebuil
    d
    self.lastTestBuild.write(tw.toHtml(self.app, self.target, startAt = startAt,
    defaultName = self.title).encode('utf-8'))
    File "C:\Users\Daniel\Desktop\twine-master\tiddlywiki.py", line 111, in toHtml

    output = output.replace('"TIME"', "Built on "+time.strftime("%d %b %Y at %H:
    %M:%S, %z"))
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 35: ordinal
    not in range(128)
    Perhaps the time output should be changed to a numbers-only format? My guess is that some of these variables contain locale-specific text, which is likely to contain non-ASCII characters for many.
  • The Python date/time format docs even warn about this: "and the output may contain Unicode characters encoded using the locales default encoding" (note 1), which seems to be happening here with the name of the month (I'm guessing January in Swedish contains an a-umlaut).

    It's a weird API choice though; returning Unicode strings would have been safer in my opinion. I guess this is a good example of why Python 3 switched to "all actual strings are Unicode and encoded strings are byte arrays".

    Anyway, it should be simple to fix; I'll make a patch.
    Edit: Patch is in this pull request.
  • Thanks!
    Getting there. January specifically wasn't the issue in my case. It's the last token, the %Z; I ran the strftime function in the console and I'm getting "Vsteuropeisk tid". %Z prints the name of the time zone, in the current locale it seems.
    Could you patch this in as well?
  • That's strange, since the format string in Twine uses "%z" (lower case), which is a numeric time zone indicator, not "%Z" (upper case), which is indeed localized.

    Can you try this in the console?

    time.strftime("%Y-%m-%d at %H:%M:%S, %z")
  • mth wrote:

    That's strange, since the format string in Twine uses "%z" (lower case), which is a numeric time zone indicator, not "%Z" (upper case), which is indeed localized.

    This is a known bug with what seems to be my Windows copy of Python:
    undefined
    This works correctly in the OS X version, however.

    I guess I'll accept the pullreq, but ideally I'd like a solution where it was guaranteed to produce the +nnnn offset instead of the timezone name.
  • Oh yes, the above screenshot shows what I get, except I have umlauts in the timezone name.
    How strange that you can get the timezone name but not the UTC offset. http://pytz.sourceforge.net/ seems to handle this.
  • I've decided to go with this solution instead:

    strftime_encoding = locale.getlocale(locale.LC_TIME)[1] or locale.getpreferredencoding()
    output = output.replace('"TIME"', "Built on "+time.strftime("%d %b %Y at %H:%M:%S, %z").decode(strftime_encoding))
    Yes I did copy-paste it from Stack Overflow, yes it seems to work flawlessly regardless. But I want you to try it too, just to confirm.
  • Encoding with the right locale should fix the immediate problem, but it's not the ideal solution in my opinion: the message the date is used in is "Built on <date>", so having the time zone localized within an English message will both look weird and make it more difficult for people around the world to interpret the message.

    An alternative would be to avoid using the "%z" option and instead format the offset ourselves:

    >>> def formatTZOffset(t):
    ... return '%s%02d%02d' % (('+' if t <= 0 else '-',) + divmod(abs(t) / 60, 60))
    ...
    >>> formatTZOffset(0)
    '+0000'
    >>> formatTZOffset(int(7 * 3600))
    '-0700'
    >>> formatTZOffset(int(-3.5 * 3600))
    '+0330'
    >>> import time
    >>> formatTZOffset(time.timezone)
    '+0100'
    Note that + and - are swapped from what you might expect, this is to match the time.timezone output.
  • OK, thanks a million. I'll use this code to generate the numeric timezone offset in Windows, but I'll include the locale decoding code in case any other part (such as the abbreviated month) of the timestamp format (which I'm a little loathe to change, now that 1.4.1's out) happens to contain non-Latin-1 characters.
  • The argument against using localized strings inside an English message still applies though... ;)

    What would be the problem of changing the timestamp format? The only place it's used is to insert a comment into the HTML, from what I can see. I'm not aware of anyone extracting the build date from games, but if there is, they would probably benefit from having a locale-independent date representation.
  • Twine HATES me...
    Event the help forum didn't want to upload my post, so I write it again.

    I installed Twine two days ago.
    I started writing an interactive fiction.
    No special character, no fancy CSS.
    I tested it and it worked well.
    Yesterday, I improved the story (giving it some more lenght), then tested it... it worked well.

    Today, I just can't test anything.
    I imporved again, deleted all my improvements, de-installed and re-installed Twine twice.
    I made another story with only 3 passages and 2 links.
    Still no special character and no fancy CSS.
    It still won't work.

    The error message says : "An error occured when building your story ('ascii' codec can't decode byte 0xe9 in position 13: ordinal not in range(128))."

    I read this full thread and didn't understand much things (Sorry, I've got no degree in informatics).
    So if I'm not given an easy solution or a clear and detailed explanation of what is discussed in this thread, I'll just uninstall Twine again... and permanently : I don't want to waste time with a program that randomly decides if it works or not.
  • My guess is that because it is February now, the localized version of the name of the month contains non-ASCII characters. Is there some kind of accent on the name for February in your language?

    If that is the case, here are some options:
    • configure Windows to show the date in English
    • set back the date of the computer a few days (I don't know if this could cause problems with other applications)
    • wait for Twine 1.4.2 to be released
    None of them are particularly great options, but it is all I can offer you since I don't run Windows myself.
  • Hello,

    I tried to write something with Twine in German and I get the same error message. I use Windos 7/64. So it isn't ossble to use Twine in a German environment? I think I cold have much fun wit this software and I hope this Ascii Codec problem really can be solved in the next release.I certaily don't want to change my Windows date format or use a virtual ystem. In German i also hae to write Umlauts , , . I hope this isn't a problem.

    Grets
    Thorsten1111
    P.S.: I used Twine now in January (Januar) and February (Februar). There are no accents, umlauts or other special characters in these German month names I think.
  • The French are having the same problem, by the way. February and December both have accents.
  • There are two potential triggers for this problem: the month name and the time zone name. Both problems are already fixed in Git (version control system), but there is no installer with the fix yet.
  • HERE'S SOME BELATED ASSISTANCE

    Sorry for not doing this earlier. :(
  • Thank you so very much for addressing this issue! I was getting the same error and thus spent half a day trying to solve this problem. Many thanks for providing us with the fixed version.
Sign In or Register to comment.