<br><br><div class="gmail_quote">On Sun, Oct 3, 2010 at 16:33, Thomas Kluyver <span dir="ltr"><<a href="mailto:takowl@gmail.com">takowl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">On 3 October 2010 21:43, Fernando Perez <span dir="ltr"><<a href="http://fperez.net" target="_blank">fperez.net</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Hi Thomas,<br>
<div><br>
</div><div class="im">Very interesting... In fact, the twisted dependency shouldn't matter<br>
*at all* for the ipython-qtconsole code, that code uses strictly zmq<br>
and has no twisted dependency:<br></div></blockquote><div><br>Hmm, interesting. I'd tried to import IPython.kernel in a shell session, and it fell over trying to import twisted, so I assumed that the frontend code needed the kernel code.<br>
<br>What it does: The Qt app starts up, and I get the banner message printed (Python version, copyright etc., IPython version, pointers to help systems). There's enough blank space that I can just scroll down to show a blank view. However, there's no prompt of any sort, and typing doesn't seem to do anything. At the terminal where I started it, I see some KSharedDataCache messages (related to icons--I'm running KDE), "Starting the kernel at...", details of four channels, and "To connect another client...". There were previously some error messages at the terminal too, but I tracked them down and fixed them easily enough.<br>
<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
And getting any fixes you may have made back into pyzmq would be great.<br>
All of the pyzmq/ipython-zmq code is brand new, so the earlier we<br>
catch any py3-noncompliance, the better off we'll be.<br></blockquote></div><div><br>You can see my changes at <a href="http://github.com/takowl/pyzmq/tree/py3zmq" target="_blank">http://github.com/takowl/pyzmq/tree/py3zmq</a> (look particularly at this commit, after I'd realised that I should change the .pyx files, not the .c files: <a href="http://github.com/takowl/pyzmq/commit/8261e19189c6733f312e248bf77ee485286634d8" target="_blank">http://github.com/takowl/pyzmq/commit/8261e19189c6733f312e248bf77ee485286634d8</a> ).<br>
<br>In particular, there are a couple of places where you test for Python 3 to decide how to do something. When this is converted to C and compiled, the compiler can't find the relevant symbols for the Python 2 alternative. I don't know if Cython allows you to do the equivalent of C preprocessor code, so to get it working, I just commented out the Python 2 sections.<br>
</div></div></blockquote><div><br></div><div>Thanks for figuring this out, but there are a couple issues. We actually need the buffer code to work on *both* Python 2 and 3, so commenting things out doesn't work. It does help find the real issues elsewhere, though. That file, as it started in mpi4py, works on Pythons 2.3-3.2, but I have clearly broken some of them when I made my adjustments bringing it into pyzmq. I will work these issues out.</div>
<div><br></div><div>As for the PyUnicode instead of PyString: We actually want to enforce PyBytes in Python 3, not PyUnicode. It's critically important that pyzmq never has to deal with Python Unicode objects except through _unicode convenience methods, due to heinous memory performance issues I won't get into here (but have gotten into plenty with Brian and Fernando).</div>
<div><br></div><div>Thanks,</div><div>-MinRK</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>
<br>For the change to Cython that's needed at present, see the attached patch.<br>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
When ipython exits the only code that is meant to run is whatever we<br>
registered via atexti(). Just grep for atexit and you'll find those.<br>
<br>
But the real problem is not what happens to ipython, but to the<br>
*python* interpreter. When *that* is truly being shut down (i.e.<br>
after atexit calls happen, which occur while the interpreter is still<br>
intact and fully operational), then various objects (including modules<br>
and possibly builtins) start getting torn down and may be in<br>
inconsistent state. So __del__ calls that attempt to make use of<br>
other machinery may well find themselves trying to call things that<br>
have become None, and thus blow up.<font color="#888888"><br></font></blockquote></div><div><br>Well, atexit triggers .reset() of the InteractiveShell object, which looks like it should delete locally created variables. And it does; I've just tried that a=A() example, and calling ip.reset() gives me the same "ignored" NameError as exiting the shell. Which is odd, because if I manually do the first step in .reset, clear()-ing each dictionary in .ns_refs_table, the "object A deleted" message pops out flawlessly. Thanks for the information, although I still can't work out exactly where the problem is.<br>
<br>For what it's worth, I did try running the same snippet of code in plain python 3.1, and it works as it should.<br><br>Thanks,<br>Thomas<br></div></div>
<br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br>