DType.canon sees 'i8' type (provided by TensorType) as invalid when running mnist or char-rnn examples

[tjrileywisc]

When I attempt to run the mnist or char-rnn examples, I get the following error stack:
...
File "C:\Users\triley\workspace\cgt\cgt\core.py", line 1386, in typ_apply
return TensorType('i8',0)
File "C:\Users\triley\workspace\cgt\cgt\core.py", line 65, in init
self.dtype = Dtype.canon(dtype)
File "C:\Users\triley\workspace\cgt\cgt\core.py", line 31, in canon
raise ValueError("Invalid dtype %s"%dt)
ValueError: Invalid dtype int64

The error appears to occur because the dtype check in Dtype.canon (in /cgt/core.py) resolves the numpy dtype of 'i8' into 'q', which isn't part of the 'fdg', 'iulBb?', or 'FDG' types. I tried to add 'q' myself (to the second group, I think this is where it goes) but then I ran into another problem with an assert and neither script ran.

This is on Windows 10, with Python 2.7.10 and running cgt straight from the github repo (no compilation).

[John Schulman]

OK, interesting. I'd certainly like to support windows usage for pure-python mode if possible.
What's the other problem?

[tjrileywisc]

I get this assert if I put 'q' where I think it belongs (in the iulBb? group). I'm not sure if that's where it should be though::

...
maybe_pair = process_top_stack_item_and_maybe_get_replacement(stack, analysi
s, repl)
File "C:\Users\triley\workspace\cgt\cgt\core.py", line 2432, in process_top_st
ack_item_and_maybe_get_replacement
assert newnewnode.typ == orig.typ
AssertionError

[John Schulman]

Made a small fix in 994728a that chooses the dtype in a more sensible way in Dtype.canon. Could you try it out?
I'm a little worried about the AssertionError, but we'll see what happens.