From fperez.net at gmail.com Tue Mar 1 04:18:44 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 1 Mar 2011 01:18:44 -0800 Subject: [IPython-dev] Feedback on slides for SIAM CSE presentation? Message-ID: Hi folks, At the SIAM CSE 2011 conference, in conjunction with Hans-Petter Langtangen (you may know his scientific computing books) and Randy LeVeque, we've oranized a minisymposium on python for scientific computing, in two parts: http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=11706 http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=11707 As you can see there, we'll have two talks specifically about ipython. In the second one, Min will focus on the parallel aspects, while in the first I'll try do introduce the project and the new interactive architecture. If you have any feedback on the slides, I'd appreciate it (talk time is 25 minutes): http://fperez.org/tmp/1102_siam_cse_ipython.pdf Note: I don't expect them to be 'read', as I try to create slides that complement/support what I'll be saying instead of reading out loud, so I realize it's not easy to give the best of feedbacks. But if you see anything you think can be improved, I'm all ears. Thanks! f From jorgen.stenarson at bostream.nu Wed Mar 2 14:49:46 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 02 Mar 2011 20:49:46 +0100 Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97 Message-ID: <4D6E9F5A.3050109@bostream.nu> Hi, I'm not sure where I should report this. Should it go into its own issue or as a comment on the commit that caused the problem? Anyway commit 2ccc90d68ac01145ab97 gives unicode errors for lines with a bare string containing non-ansi characters: In [1]: "?" UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in position 1: ordinal not in range(128) /J?rgen From jorgen.stenarson at bostream.nu Wed Mar 2 14:52:12 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 02 Mar 2011 20:52:12 +0100 Subject: [IPython-dev] Test failures on master Message-ID: <4D6E9FEC.1070009@bostream.nu> Hi, I'm seeing some test errors and failures on master is this known? As usual this is using windows. I believe at least some of them are windows related. /J?rgen From takowl at gmail.com Wed Mar 2 15:07:14 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 2 Mar 2011 20:07:14 +0000 Subject: [IPython-dev] Test failures on master In-Reply-To: <4D6E9FEC.1070009@bostream.nu> References: <4D6E9FEC.1070009@bostream.nu> Message-ID: On 2 March 2011 19:52, J?rgen Stenarson wrote: > I'm seeing some test errors and failures on master is this known? As > usual this is using windows. I believe at least some of them are windows > related. > At present, there's one known failure (at least, one that's not skipped on my machine), in IPython.core: core/tests/test_formatters.py fails with: ... ImportError: cannot import name DefaultFormatter Anything else is probably Windows related. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Wed Mar 2 15:08:12 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 2 Mar 2011 20:08:12 +0000 Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97 In-Reply-To: References: <4D6E9F5A.3050109@bostream.nu> Message-ID: (Forgot to CC list in my reply...) On 2 March 2011 19:49, J?rgen Stenarson wrote: > Anyway commit 2ccc90d68ac01145ab97 gives unicode errors for lines with a > bare string containing non-ansi characters: > > In [1]: "?" > UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in > position 1: ordinal not in range(128) > At present, any command containing non-ascii characters fails (at least for me). Can you test with my unicode issues branch: https://github.com/ipython/ipython/pull/252 Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorgen.stenarson at bostream.nu Wed Mar 2 15:27:57 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 02 Mar 2011 21:27:57 +0100 Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97 In-Reply-To: References: <4D6E9F5A.3050109@bostream.nu> Message-ID: <4D6EA84D.1020805@bostream.nu> Thomas Kluyver skrev 2011-03-02 21:08: > At present, any command containing non-ascii characters fails (at least > for me). Can you test with my unicode issues branch: > The problem with non-ascii characters disappeared but there are some test errors and failures, see below. /J?rgen ====================================================================== ERROR: Failure: SyntaxError (Non-ASCII character '\xc5' in file c:\python\extern al\ipython-takluyver\IPython\core\tests\test_compilerop.py on line 55, but no en coding declared; see http://www.python.org/peps/pep-0263.html for details (test_ compilerop.py, line 55)) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\loader.py", lin e 379, in loadTestsFromName addr.filename, addr.module) File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l ine 39, in importFromPath return self.importFromDir(dir_path, fqname) File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l ine 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "c:\python\external\ipython-takluyver\IPython\core\tests\test_compilerop. py", line 55 SyntaxError: Non-ASCII character '\xc5' in file c:\python\external\ipython-taklu yver\IPython\core\tests\test_compilerop.py on line 55, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details (test_compilerop.py, l ine 55) ====================================================================== ERROR: Failure: SyntaxError (Non-ASCII character '\xc5' in file c:\python\extern al\ipython-takluyver\IPython\core\tests\test_history.py on line 33, but no encod ing declared; see http://www.python.org/peps/pep-0263.html for details (test_his tory.py, line 33)) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\loader.py", lin e 379, in loadTestsFromName addr.filename, addr.module) File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l ine 39, in importFromPath return self.importFromDir(dir_path, fqname) File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l ine 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "c:\python\external\ipython-takluyver\IPython\core\tests\test_history.py" , line 33 SyntaxError: Non-ASCII character '\xc5' in file c:\python\external\ipython-taklu yver\IPython\core\tests\test_history.py on line 33, but no encoding declared; se e http://www.python.org/peps/pep-0263.html for details (test_history.py, line 33 ) ====================================================================== FAIL: IPython.core.tests.test_completer.test_file_completions ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\case.py", line 183, in runTest self.test(*self.arg) File "c:\python\external\ipython-takluyver\IPython\core\tests\test_completer.p y", line 152, in test_file_completions nt.assert_equal(c, names) AssertionError: [] != ['c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpd8x4nk\\foo1', 'c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpd8x4nk\\foo2'] >> raise self.failureException, \ (None or '%r != %r' % ([], ['c:\\docume~1\\jstenar\\lokala~1\\temp\\tm pd8x4nk\\foo1', 'c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpd8x4nk\\foo2'])) ====================================================================== FAIL: Test various directory handling operations. ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\case.py", line 183, in runTest self.test(*self.arg) File "c:\python\external\ipython-takluyver\IPython\core\tests\test_magic.py", line 293, in test_dirops nt.assert_equal(curpath(), ipdir) AssertionError: '/docume~1/jstenar/lokala~1/temp' != u'C:\\Documents and Setting s\\jstenar\\.ipython' >> raise self.failureException, \ (None or '%r != %r' % ('/docume~1/jstenar/lokala~1/temp', u'C:\\Docume nts and Settings\\jstenar\\.ipython')) -------------------- >> begin captured stdout << --------------------- [Error 123] Felaktig syntax f?r filnamn, katalognamn eller volymetikett: '"C:/Do cuments and Settings/jstenar/.ipython"' c:\docume~1\jstenar\lokala~1\temp --------------------- >> end captured stdout << ---------------------- ---------------------------------------------------------------------- Ran 270 tests in 2.891s FAILED (SKIP=3, errors=2, failures=2) ********************************************************************** IPython test group: IPython.extensions . ---------------------------------------------------------------------- Ran 1 test in 0.000s OK ********************************************************************** IPython test group: IPython.frontend ...... ---------------------------------------------------------------------- Ran 6 tests in 0.063s OK ********************************************************************** IPython test group: IPython.lib ....E ====================================================================== ERROR: Failure: ImportError (No module named pexpect) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\loader.py", lin e 379, in loadTestsFromName addr.filename, addr.module) File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l ine 39, in importFromPath return self.importFromDir(dir_path, fqname) File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l ine 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "c:\python\external\ipython-takluyver\IPython\lib\tests\test_irunner.py", line 15, in from IPython.lib import irunner File "c:\python\external\ipython-takluyver\IPython\lib\irunner.py", line 39, i n import pexpect ImportError: No module named pexpect From takowl at gmail.com Wed Mar 2 15:44:37 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 2 Mar 2011 20:44:37 +0000 Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97 In-Reply-To: <4D6EA84D.1020805@bostream.nu> References: <4D6E9F5A.3050109@bostream.nu> <4D6EA84D.1020805@bostream.nu> Message-ID: On 2 March 2011 20:27, J?rgen Stenarson wrote: > Thomas Kluyver skrev 2011-03-02 21:08: > > At present, any command containing non-ascii characters fails (at least > > for me). Can you test with my unicode issues branch: > > > > The problem with non-ascii characters disappeared but there are some > test errors and failures, see below. > OK, the first two are easy ones, I'd just forgotten to add the encoding declaration to the necessary files (I guess it's a platform difference that it didn't complain for me). I've pushed an update. The next two I'm not sure about - it looks like some of our directory code isn't properly platform independent. Finally, pexpect is a dependency error - it should fall back to using IPython.external.pexpect. I've also rebased the branch, so it's up to date with trunk - can I ask you to test again with that? You might have to delete your copy of the branch and refetch it. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorgen.stenarson at bostream.nu Wed Mar 2 15:59:20 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 02 Mar 2011 21:59:20 +0100 Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97 In-Reply-To: References: <4D6E9F5A.3050109@bostream.nu> <4D6EA84D.1020805@bostream.nu> Message-ID: <4D6EAFA8.1000103@bostream.nu> Thomas Kluyver skrev 2011-03-02 21:44: > > I've also rebased the branch, so it's up to date with trunk - can I ask > you to test again with that? You might have to delete your copy of the > branch and refetch it. > > Thomas Hi, these are the errors I get for the IPython.core tests /J?rgen ====================================================================== ERROR: IPython.core.tests.test_history.test_history ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\case.py", line 183, in runTest self.test(*self.arg) File "c:\python\external\ipython-takluyver\IPython\core\tests\test_history.py" , line 41, in test_history ip.reload_history() File "c:\python\external\ipython-takluyver\IPython\core\interactiveshell.py", line 1259, in reload_history self.history_manager.reload_history() File "c:\python\external\ipython-takluyver\IPython\core\history.py", line 176, in reload_history self.populate_readline_history() File "c:\python\external\ipython-takluyver\IPython\core\history.py", line 145, in populate_readline_history h = h.encode(sys.stdin.encoding or "utf-8") File "C:\Python26\lib\encodings\cp1252.py", line 12, in encode return codecs.charmap_encode(input,errors,encoding_table) UnicodeEncodeError: 'charmap' codec can't encode characters in position 6-7: cha racter maps to -------------------- >> begin captured stdout << --------------------- test c:\docume~1\jstenar\lokala~1\temp\tmp2fb59q\history.json --------------------- >> end captured stdout << ---------------------- ====================================================================== FAIL: IPython.core.tests.test_completer.test_file_completions ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\case.py", line 183, in runTest self.test(*self.arg) File "c:\python\external\ipython-takluyver\IPython\core\tests\test_completer.p y", line 152, in test_file_completions nt.assert_equal(c, names) AssertionError: [] != ['c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpo2gmyx\\foo1', 'c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpo2gmyx\\foo2'] >> raise self.failureException, \ (None or '%r != %r' % ([], ['c:\\docume~1\\jstenar\\lokala~1\\temp\\tm po2gmyx\\foo1', 'c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpo2gmyx\\foo2'])) ====================================================================== FAIL: Test various directory handling operations. ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\case.py", line 183, in runTest self.test(*self.arg) File "c:\python\external\ipython-takluyver\IPython\core\tests\test_magic.py", line 293, in test_dirops nt.assert_equal(curpath(), ipdir) AssertionError: '/python/external/ipython-takluyver/IPython' != u'C:\\Documents and Settings\\jstenar\\.ipython' >> raise self.failureException, \ (None or '%r != %r' % ('/python/external/ipython-takluyver/IPython', u 'C:\\Documents and Settings\\jstenar\\.ipython')) -------------------- >> begin captured stdout << --------------------- [Error 123] Felaktig syntax f?r filnamn, katalognamn eller volymetikett: '"C:/Do cuments and Settings/jstenar/.ipython"' C:\python\external\ipython-takluyver\IPython --------------------- >> end captured stdout << ---------------------- ---------------------------------------------------------------------- From benjaminrk at gmail.com Wed Mar 2 16:02:22 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 2 Mar 2011 13:02:22 -0800 Subject: [IPython-dev] Test failures on master In-Reply-To: References: <4D6E9FEC.1070009@bostream.nu> Message-ID: test_formatters is fixed in trunk, as of a41b73bf. The Unicode bug is the only one I currently see in IPython.core on OSX On Wed, Mar 2, 2011 at 12:07, Thomas Kluyver wrote: > On 2 March 2011 19:52, J?rgen Stenarson > wrote: >> >> I'm seeing some test errors and failures on master is this known? As >> usual this is using windows. I believe at least some of them are windows >> related. > > At present, there's one known failure (at least, one that's not skipped on > my machine), in IPython.core: core/tests/test_formatters.py fails with: > ... > ImportError: cannot import name DefaultFormatter > > Anything else is probably Windows related. > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > From benjaminrk at gmail.com Wed Mar 2 16:55:43 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 2 Mar 2011 13:55:43 -0800 Subject: [IPython-dev] Test failures on master In-Reply-To: References: <4D6E9FEC.1070009@bostream.nu> Message-ID: The same bug fixed by your unicode-issues branch, if I am not mistaken. It doesn't raise on Ubuntu in iptest, because importing gtk sets sys.defaultencoding to utf8. ====================================================================== ERROR: test_unicode (IPython.core.tests.test_inputsplitter.InputSplitterTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/minrk/dev/ip/trunk/IPython/core/tests/test_inputsplitter.py", line 367, in test_unicode self.isp.push("u'\xc3\xa9'") File "/Users/minrk/dev/ip/trunk/IPython/core/inputsplitter.py", line 381, in push self._store(lines) File "/Users/minrk/dev/ip/trunk/IPython/core/inputsplitter.py", line 614, in _store setattr(self, store, self._set_source(buffer)) File "/Users/minrk/dev/ip/trunk/IPython/core/inputsplitter.py", line 617, in _set_source return ''.join(buffer).encode(self.encoding) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2: ordinal not in range(128) ---------------------------------------------------------------------- This will still fail on Ubuntu if you run just that test alone with: nosetests -vvsx IPython/core/tests/test_inputsplitter.py -MinRK On Wed, Mar 2, 2011 at 13:38, Thomas Kluyver wrote: > On 2 March 2011 21:02, MinRK wrote: >> >> test_formatters is fixed in trunk, as of a41b73bf. ?The Unicode bug is >> the only one I currently see in IPython.core on OSX >> > > Which Unicode bug is that? I get no failures in IPython.core on Ubuntu. > > Thomas > From takowl at gmail.com Wed Mar 2 17:08:42 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 2 Mar 2011 22:08:42 +0000 Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97 In-Reply-To: <4D6EAFA8.1000103@bostream.nu> References: <4D6E9F5A.3050109@bostream.nu> <4D6EA84D.1020805@bostream.nu> <4D6EAFA8.1000103@bostream.nu> Message-ID: On 2 March 2011 20:59, J?rgen Stenarson wrote: > Hi, > > these are the errors I get for the IPython.core tests > [snip] OK, I think the first one must be trying to encode a character that you couldn't actually type at a standard Windows console. I don't know if there is a correct behaviour here. Maybe I should simply replace the characters tested with some from the upper half of cp1252. To clarify, are the other two failing only on this branch, or are they some of the failures you mentioned in trunk? Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorgen.stenarson at bostream.nu Wed Mar 2 18:05:03 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 03 Mar 2011 00:05:03 +0100 Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97 In-Reply-To: References: <4D6E9F5A.3050109@bostream.nu> <4D6EA84D.1020805@bostream.nu> <4D6EAFA8.1000103@bostream.nu> Message-ID: <4D6ECD1F.2050703@bostream.nu> Thomas Kluyver skrev 2011-03-02 23:08: > On 2 March 2011 20:59, J?rgen Stenarson > wrote: > > Hi, > > these are the errors I get for the IPython.core tests > > [snip] > > OK, I think the first one must be trying to encode a character that you > couldn't actually type at a standard Windows console. I don't know if > there is a correct behaviour here. Maybe I should simply replace the > characters tested with some from the upper half of cp1252. > > To clarify, are the other two failing only on this branch, or are they > some of the failures you mentioned in trunk? > > Thomas I believe the other two are the same as in trunk. /J?rgen From takowl at gmail.com Wed Mar 2 20:10:11 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 3 Mar 2011 01:10:11 +0000 Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97 In-Reply-To: <4D6ECD1F.2050703@bostream.nu> References: <4D6E9F5A.3050109@bostream.nu> <4D6EA84D.1020805@bostream.nu> <4D6EAFA8.1000103@bostream.nu> <4D6ECD1F.2050703@bostream.nu> Message-ID: On 2 March 2011 23:05, J?rgen Stenarson wrote: > I believe the other two are the same as in trunk. OK, we'll look at those separately. In terms of the Unicode question, can someone with more Windows experience than me fill me in: - If sys.stdin.encoding is cp1252, is it possible to enter a character outside that set at the shell at all? - If so, how can it be stored in readline so that it will match lookups including the same character? I could encode as utf-8, but I assume that that won't match things at the console if stdin is in cp1252? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Fri Mar 4 05:32:26 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 4 Mar 2011 10:32:26 +0000 Subject: [IPython-dev] Google summer of code Message-ID: Have we already, and do we want to, apply for Google summer of code projects? The deadline for mentoring organisations is now just one week away (Friday 11 March). http://www.google-melange.com/gsoc/org_app/take/gsoc_program/google/gsoc2011/orgapp Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorgen.stenarson at bostream.nu Fri Mar 4 15:00:32 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Fri, 04 Mar 2011 21:00:32 +0100 Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97 In-Reply-To: References: <4D6E9F5A.3050109@bostream.nu> <4D6EA84D.1020805@bostream.nu> <4D6EAFA8.1000103@bostream.nu> <4D6ECD1F.2050703@bostream.nu> <4D6FEA75.2060208@bostream.nu> Message-ID: <4D7144E0.4010300@bostream.nu> Thomas Kluyver skrev 2011-03-03 21:37: > On 3 March 2011 19:22, J?rgen Stenarson > wrote: > > yes it is possible to enter other character codes but you have to > use the unicode functions in the api to read them properly. It is > for the 8-bit api that the encoding is valid. > > > OK, I'm not entirely following what you mean here. If I did a = > raw_input(), and entered a non-cp1252 character, what ends up in a? Does > it mysteriously turn the output into a unicode object? Or does it > produce some odd string of bytes? > > > In pyreadline we are using the wide api and are returning unicode > strings, however I have not tested that extensively so there may be bugs > in that handling. > > OK, does that mean that we should add unicode strings to add_history, > rather than byte strings? Only I think readline in Python 2 on Linux > choked on unicode when it contained non-ascii characters. Or is there an > encoding we should use instead of cp1252? > > Thomas Hi, looking into it in more detail, pyreadline can return unicode strings but the call the hook that raw_input uses gets a regular string in return that has been encoded using .encode(pyreadline_codepage, u"replace"). I have attached a script and a screenshot of a session that demonstrates the difference between using raw_input and calling readline directly. As things are now, using raw_input you should not receive any characters outside the current encoding because they will be converted to ? before being returned to raw_input. /J?rgen -------------- next part -------------- A non-text attachment was scrubbed... Name: repl.png Type: image/png Size: 4196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: repl.py Type: application/x-python Size: 123 bytes Desc: not available URL: From takowl at gmail.com Fri Mar 4 17:38:56 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 4 Mar 2011 22:38:56 +0000 Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97 In-Reply-To: <4D7144E0.4010300@bostream.nu> References: <4D6E9F5A.3050109@bostream.nu> <4D6EA84D.1020805@bostream.nu> <4D6EAFA8.1000103@bostream.nu> <4D6ECD1F.2050703@bostream.nu> <4D6FEA75.2060208@bostream.nu> <4D7144E0.4010300@bostream.nu> Message-ID: On 4 March 2011 20:00, J?rgen Stenarson wrote: > As things are now, using raw_input you should not receive any characters > outside the current encoding because they will be converted to ? before > being returned to raw_input. > OK, thanks. So, I think the sensible thing is to just do the test with characters from the upper half of cp1252. I've tweaked the test to do that, can you pull the update and test it again? I think this means the test will fail on Windows if the code page is set to something other than cp1252. I don't see an obvious way round that, I think we'll just have to make a note that it's a known failure case. The actual code should be correct for other code pages, just not the example in the test. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Tue Mar 8 08:29:00 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 8 Mar 2011 13:29:00 +0000 Subject: [IPython-dev] Google summer of code In-Reply-To: References: Message-ID: Brief reminder about this: if we want to have summer of code projects this year, we need to apply by *this Friday*. I'd hate for us to miss it just because it dropped off the radar. Thomas On 4 March 2011 10:32, Thomas Kluyver wrote: > Have we already, and do we want to, apply for Google summer of code > projects? The deadline for mentoring organisations is now just one week away > (Friday 11 March). > > > http://www.google-melange.com/gsoc/org_app/take/gsoc_program/google/gsoc2011/orgapp > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbaker at zyasoft.com Tue Mar 8 08:40:14 2011 From: jbaker at zyasoft.com (Jim Baker) Date: Tue, 8 Mar 2011 06:40:14 -0700 Subject: [IPython-dev] Google summer of code In-Reply-To: References: Message-ID: FWIW - it would seem to me that it would be much easier to go through the PSF as the mentoring organization for SOC, given the variety of Python projects that have been sponsored in the past. In particular, given that IPython is not incidentally written in Python, but actively support Python usage and development makes it a good fit for the PSF. (This of course assumes the PSF is accepted yet again. It would seem likely.) On Tue, Mar 8, 2011 at 6:29 AM, Thomas Kluyver wrote: > Brief reminder about this: if we want to have summer of code projects this > year, we need to apply by *this Friday*. I'd hate for us to miss it just > because it dropped off the radar. > > Thomas > > > On 4 March 2011 10:32, Thomas Kluyver wrote: > >> Have we already, and do we want to, apply for Google summer of code >> projects? The deadline for mentoring organisations is now just one week away >> (Friday 11 March). >> >> >> http://www.google-melange.com/gsoc/org_app/take/gsoc_program/google/gsoc2011/orgapp >> >> Thomas >> > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Tue Mar 8 12:54:47 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 8 Mar 2011 09:54:47 -0800 Subject: [IPython-dev] Google summer of code In-Reply-To: References: Message-ID: If there is not a huge amount of momentum this year, I think sticking with the PSF for now makes sense. Has anyone talked with Arc Riley about this year. He is starting the process for other PSF projects (like sympy) and we should email him. "Arc Riley" , Brian On Tue, Mar 8, 2011 at 5:40 AM, Jim Baker wrote: > FWIW - it would seem to me that it would be much easier to go through the > PSF as the mentoring organization for SOC, given the variety of Python > projects that have been sponsored in the past. In particular, given that > IPython is not incidentally written in Python, but actively support Python > usage and development makes it a good fit for the PSF. > (This of course assumes the PSF is accepted yet again. It would seem > likely.) > > On Tue, Mar 8, 2011 at 6:29 AM, Thomas Kluyver wrote: >> >> Brief reminder about this: if we want to have summer of code projects this >> year, we need to apply by *this Friday*. I'd hate for us to miss it just >> because it dropped off the radar. >> >> Thomas >> >> On 4 March 2011 10:32, Thomas Kluyver wrote: >>> >>> Have we already, and do we want to, apply for Google summer of code >>> projects? The deadline for mentoring organisations is now just one week away >>> (Friday 11 March). >>> >>> >>> http://www.google-melange.com/gsoc/org_app/take/gsoc_program/google/gsoc2011/orgapp >>> >>> Thomas >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From fperez.net at gmail.com Tue Mar 8 15:15:35 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 8 Mar 2011 12:15:35 -0800 Subject: [IPython-dev] Google summer of code In-Reply-To: References: Message-ID: On Tue, Mar 8, 2011 at 9:54 AM, Brian Granger wrote: > If there is not a huge amount of momentum this year, I think sticking > with the PSF for now makes sense. ?Has anyone talked with Arc Riley > about this year. ?He is starting the process for other PSF projects > (like sympy) and we should email him. If we want to go for gsoc this year, I'd vote for simply using the psf, I don't think we really need to be a separate mentoring organization, we simply don't have enough available hands for that. It's not even totally clear to me that we have the bandwidth to mentor students: the core devs are stretched pretty thin as it is, and gsoc mentoring, when done right, requires a real commitment of time on the mentor's part. In the ideal case that investment pays off in the long run in terms of getting good new project members actively participating, but that's not guaranteed while the upfront cost is a given. One question is, who would be interested in participating as a student? I know some people have expressed interest before, including Kunal and Omar; I'd like to know if Thomas would like to be a student. Thomas, you've made enormous contributions to the project in a short amount of time and would thus be a perfect candidate, but I don't know how that could interfere with your studies over the summer, case in which it would be a no-go... Cheers, f From takowl at gmail.com Tue Mar 8 18:43:16 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 8 Mar 2011 23:43:16 +0000 Subject: [IPython-dev] Google Summer of Code Message-ID: Hi all, If you're a student, and you'd like to lend a hand with IPython this summer, you might want to consider applying for Google Summer of Code. If you've not come across it before, GSoC is an initiative to pay student programmers to work with open source projects. For more details, have a look at the GSoC website: http://www.google-melange.com/ There's a lot changing in IPython as we work towards 0.11, including new frontends, a new parallel computing architecture, and a Python 3 port. If you're interested, please e-mail the development list (ipython-dev at scipy.org) with a little bit about yourself, your programming experience, and any aspect of IPython you'd particularly like to work on (although we can supply ideas if you're keen but uncertain). We're currently planning to take just one student this year, so let us know why that should be you. If you know (or teach) students who might be interested in spending their summer writing Python, please forward this on to them. Thanks, Thomas Kluyver (on behalf of the core dev team) -------------- next part -------------- An HTML attachment was scrubbed... URL: From andresete.chaos at gmail.com Tue Mar 8 20:32:47 2011 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Tue, 8 Mar 2011 20:32:47 -0500 Subject: [IPython-dev] Google summer of code In-Reply-To: References: Message-ID: hi all. This year I want to apply to GSoC again, the idea is to write a web interface for ipython using ajax, based in the interface of James Gao. I am improving the James's prototype and I have many bugs fixed and many new features added, let me show you the in the git's repo https://github.com/omazapa/ipython/tree/ipajax with all ready to test this new prototype and let me show in the next days the blog with all ideas and proposal for GSoC. Prototype Features: - indentation supported - tab completion working - Shitf + Enter working to run commands - buttons for minimize code blocks - buttons for close code blocks - and so many bugs fixed If you have suggestions to my application please let met know. Thanks On Tue, Mar 8, 2011 at 3:15 PM, Fernando Perez wrote: > On Tue, Mar 8, 2011 at 9:54 AM, Brian Granger wrote: > > If there is not a huge amount of momentum this year, I think sticking > > with the PSF for now makes sense. Has anyone talked with Arc Riley > > about this year. He is starting the process for other PSF projects > > (like sympy) and we should email him. > > If we want to go for gsoc this year, I'd vote for simply using the > psf, I don't think we really need to be a separate mentoring > organization, we simply don't have enough available hands for that. > > It's not even totally clear to me that we have the bandwidth to mentor > students: the core devs are stretched pretty thin as it is, and gsoc > mentoring, when done right, requires a real commitment of time on the > mentor's part. In the ideal case that investment pays off in the long > run in terms of getting good new project members actively > participating, but that's not guaranteed while the upfront cost is a > given. > > One question is, who would be interested in participating as a > student? I know some people have expressed interest before, including > Kunal and Omar; I'd like to know if Thomas would like to be a student. > Thomas, you've made enormous contributions to the project in a short > amount of time and would thus be a perfect candidate, but I don't know > how that could interfere with your studies over the summer, case in > which it would be a no-go... > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Omar Andres Zapata Mesa Head Developer Phenomenology of Fundamental Interactions Group (Gfif) http://gfif.udea.edu.co Division of computer science Gfif Developers (Gfif Dev) http://gfifdev.udea.edu.co Systems Engineering Student Universidad de Antioquia At Medellin - Colombia Usuario Linux #490962 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Tue Mar 8 21:19:59 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 8 Mar 2011 18:19:59 -0800 Subject: [IPython-dev] Google summer of code In-Reply-To: References: Message-ID: Hi Omar, 2011/3/8 Omar Andr?s Zapata Mesa : > > If you have suggestions to my application please let met know. Working on this would be great, but there's something I mentioned to you that will come up when others review your gsoc application, and that you need to consider: completing last year's work so that the console client is fully functional on top of the zmq code. Your improvements that we merged to the logging code were a good first step, but there's still a bunch of work to do. The issue is that a second-year student is expected to have accomplished more than a first-timer. We all know that taking on a gsoc student doesn't guarantee that all the code will end up in the project, but for a student to return to a project, there needs to be clear evidence that over the previous year he did manage to contribute significantly. We'd talked about this a while ago, and as I said, the logging work is a great first step, but I think you'll need to really complete the rest of the console work. Otherwise, it will be very hard for your application to go through (remember, these will be reviewed by many others from the PSF, who have access to your entire public commit history both in your branches and in ipython). I don't want to discourage you, just to give you a realistic picture of the expectations of the program. Best, f From andresete.chaos at gmail.com Tue Mar 8 21:27:44 2011 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Tue, 8 Mar 2011 21:27:44 -0500 Subject: [IPython-dev] Google summer of code In-Reply-To: References: Message-ID: Hi Fernando. I am working in the terminal's frontend in this moment and I think I can have it ready in the next days for review. O. 2011/3/8 Fernando Perez > Hi Omar, > > 2011/3/8 Omar Andr?s Zapata Mesa : > > > > If you have suggestions to my application please let met know. > > Working on this would be great, but there's something I mentioned to > you that will come up when others review your gsoc application, and > that you need to consider: completing last year's work so that the > console client is fully functional on top of the zmq code. Your > improvements that we merged to the logging code were a good first > step, but there's still a bunch of work to do. > > The issue is that a second-year student is expected to have > accomplished more than a first-timer. We all know that taking on a > gsoc student doesn't guarantee that all the code will end up in the > project, but for a student to return to a project, there needs to be > clear evidence that over the previous year he did manage to contribute > significantly. > > We'd talked about this a while ago, and as I said, the logging work is > a great first step, but I think you'll need to really complete the > rest of the console work. Otherwise, it will be very hard for your > application to go through (remember, these will be reviewed by many > others from the PSF, who have access to your entire public commit > history both in your branches and in ipython). > > I don't want to discourage you, just to give you a realistic picture > of the expectations of the program. > > Best, > > f > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Tue Mar 8 21:29:24 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 8 Mar 2011 18:29:24 -0800 Subject: [IPython-dev] Google summer of code In-Reply-To: References: Message-ID: 2011/3/8 Omar Andr?s Zapata Mesa : > I am working in the terminal's frontend in this moment and I think I can > have it ready in the next days for review. OK, that's excellent news then! As I said, I don't want to discourage you, just to give you all the information you'll need if you want to put forward a good, competitive application. Cheers, f From fperez.net at gmail.com Tue Mar 8 21:42:38 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 8 Mar 2011 18:42:38 -0800 Subject: [IPython-dev] Google summer of code In-Reply-To: References: Message-ID: Howdy, On Fri, Mar 4, 2011 at 2:32 AM, Thomas Kluyver wrote: > Have we already, and do we want to, apply for Google summer of code > projects? The deadline for mentoring organisations is now just one week away > (Friday 11 March). > > http://www.google-melange.com/gsoc/org_app/take/gsoc_program/google/gsoc2011/orgapp BTW, if we go for the psf, the relevant page is: http://wiki.python.org/moin/SummerOfCode/2011 and we'd need to fill out this application to be a psf-umbrella project: https://spreadsheets.google.com/viewform?formkey=dHh3WFNGYzkyWWE0ZjM1eFFoUUVGWmc6MQ Cheers, f From takowl at gmail.com Sat Mar 12 13:45:27 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 12 Mar 2011 18:45:27 +0000 Subject: [IPython-dev] Prefiltering input - where and how? Message-ID: Hi all, Robert found that calling macros caused problems with my new history system, and suggested that they be expanded by prefiltering, so that the translated history stores the macro content each time it's called. My attempt to do that is here: https://github.com/takluyver/ipython/tree/expand-macro However, I ran into trouble with the execution model - it seems to compile the macro in "single" mode, so only the first line gets executed. So I peered into the execution code, and ended up somewhat confused. I'm hoping someone can clarify: - How much preprocessing is (and should be) done by IPython.core.prefilter versus IPython.core.inputsplitter? - As far as I can see in the code, only a single line statement actually gets passed to prefilter. Yet prefiltering still seems to be going on if I enter a multiline block - and I'm not quite sure how - Should prefiltering be in the frontend or the core? I'm guessing the core, but there's some prefiltering code in the terminal frontend, although I think it's dead, because: - Why does TerminalInteractiveShell have two raw_input methods defined? I'm guessing the first one is older code: can I delete it to simplify matters? It's still there in version control if we need to refer to it. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Mar 12 16:57:28 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 12 Mar 2011 13:57:28 -0800 Subject: [IPython-dev] Prefiltering input - where and how? In-Reply-To: References: Message-ID: Hi Thomas, On Sat, Mar 12, 2011 at 10:45 AM, Thomas Kluyver wrote: > Hi all, > > Robert found that calling macros caused problems with my new history system, > and suggested that they be expanded by prefiltering, so that the translated > history stores the macro content each time it's called. My attempt to do > that is here: > https://github.com/takluyver/ipython/tree/expand-macro > > However, I ran into trouble with the execution model - it seems to compile > the macro in "single" mode, so only the first line gets executed. So I > peered into the execution code, and ended up somewhat confused. I'm hoping > someone can clarify: Ah, welcome to some of our prettiest code ;) I'll do my best to explain, and any improvements on this front will be very much welcome. Things are somewhat cleaner than they used to be, but I think with one more round of work we'll have finally a fairly comprehensible system. > - How much preprocessing is (and should be) done by IPython.core.prefilter > versus IPython.core.inputsplitter? prefilter is the OLD code, going all the way back to IPython's beginning, where all processing was done in-line as the user typed it. inputsplitter was a recent attempt at rationalizing input handling, that by and large has succeeded (even if it can still use some cleanup). The idea in inputsplitter is to first apply a set of static transformations that are independent of anything in the user's namespace, and which can all be tested/validated in a standalone fashion. This includes all explicitly escaped magics and similar things, even in multiline blocks. The old prefilter code was purely line-oriented and very stateful, hence very difficult to test in isolation. > - As far as I can see in the code, only a single line statement actually > gets passed to prefilter. Yet prefiltering still seems to be going on if I > enter a multiline block - and I'm not quite sure how Yes, all multiline blocks are transformed by inputsplitter. If there's a single-line input, it does get fed to prefilter, though, since only single-line statements are allowed to execute things like magics without prefixes. The idea was: for single-line statements, we want the convenience of things like 'run foo' without the '%' prefix. But that requires checking the current namespace, so that must be done by a method of the actual engine that has the namespace, and that's what the old prefilter code does. All multiline statements are *only* processed by the inputsplitter code, which has a reasonable test suite and can be validated in isolation, as it is completely specified in terms of static transformations that do not depend on any namespace. > - Should prefiltering be in the frontend or the core? I'm guessing the core, > but there's some prefiltering code in the terminal frontend, although I > think it's dead, because: Yes, prefiltering should be done in the core, because that's where the actual namespace is. For all we know, a frontend might not even be python (i.e. JavaScript in a browser), and we don't want to add communication calls for prefiltering, I think that would be unnecessary added complexity. > - Why does TerminalInteractiveShell have two raw_input methods defined? I'm > guessing the first one is older code: can I delete it to simplify matters? > It's still there in version control if we need to refer to it. Yup, the older one is leftover, feel free to clean it. Ultimately we do want to: - improve inputsplitter further (it's still a bit convoluted, though at least well specified and tested). - shrink prefilter to the absolute minimum. In the interest of caution, when we wrote the inputsplitter code we left most of the old stuff in place, but much of that is likely now unused. There should only be a tiny amount of code that applies the dynamic transforms all in one place and nothing else. This code has been refactored but we've tiptoed around deleting anything, because it's so much at the heart of the execution loop. But it's been a few months since we've been using the new system mostly without problems, so I think now it's OK to be a bit more aggressive in removing anything you see as good cleanup candidate. I'm working this weekend on accumulated things for my day job, but feel free to ping me if you need to meet on IRC/skype for short questions on any of this, I don't want to stall you out. Thanks! f From takowl at gmail.com Sat Mar 12 19:22:56 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 13 Mar 2011 00:22:56 +0000 Subject: [IPython-dev] Prefiltering input - where and how? In-Reply-To: References: Message-ID: Thanks for explaining all that, Fernando - it's very useful. So am I right in thinking that the macro code should stay in prefilter, as it's dependent on the namespace? And that the static transformers in IPython.core.prefilter are redundant and can come out? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Mar 12 19:37:49 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 12 Mar 2011 16:37:49 -0800 Subject: [IPython-dev] Prefiltering input - where and how? In-Reply-To: References: Message-ID: On Sat, Mar 12, 2011 at 4:22 PM, Thomas Kluyver wrote: > Thanks for explaining all that, Fernando - it's very useful. So am I right > in thinking that the macro code should stay in prefilter, as it's dependent > on the namespace? And that the static transformers in IPython.core.prefilter > are redundant and can come out? Yes, from where I stand, I think that's correct. Keep in mind however that this is both core and brittle, nasty code, so tiptoe carefully. If you can think of a small test to add before making a significant change that would help validate what you're about to do, by all means do so. Thanks again for tackling the hard stuff! f From takowl at gmail.com Sat Mar 12 19:41:07 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 13 Mar 2011 00:41:07 +0000 Subject: [IPython-dev] Prefiltering input - where and how? In-Reply-To: References: Message-ID: On 13 March 2011 00:22, Thomas Kluyver wrote: > Thanks for explaining all that, Fernando - it's very useful. So am I right > in thinking that the macro code should stay in prefilter, as it's dependent > on the namespace? And that the static transformers in IPython.core.prefilter > are redundant and can come out? > Also, I see that run_one_block calls run_code with a string. Am I right in thinking that it should call run_source, which expects strings? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Mar 12 19:47:56 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 12 Mar 2011 16:47:56 -0800 Subject: [IPython-dev] Prefiltering input - where and how? In-Reply-To: References: Message-ID: On Sat, Mar 12, 2011 at 4:41 PM, Thomas Kluyver wrote: > Also, I see that run_one_block calls run_code with a string. Am I right in > thinking that it should call run_source, which expects strings? > See you on IRC where I can help out... f From fperez.net at gmail.com Sat Mar 12 19:53:15 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 12 Mar 2011 16:53:15 -0800 Subject: [IPython-dev] Prefiltering input - where and how? In-Reply-To: References: Message-ID: On Sat, Mar 12, 2011 at 4:41 PM, Thomas Kluyver wrote: > Also, I see that run_one_block calls run_code with a string. Am I right in > thinking that it should call run_source, which expects strings? > For the record in case anyone searches later, Thomas was correct but that change was already committed: https://github.com/ipython/ipython/commit/de4ba654e16782f96cab589c411fccdd9e5eb167 He was just working off an older branch. Indeed, the old use of run_code there was a bug. Good eye :) f From fperez.net at gmail.com Sat Mar 12 21:36:32 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 12 Mar 2011 18:36:32 -0800 Subject: [IPython-dev] %doctest_mode in qtconsole In-Reply-To: References: Message-ID: Hey Brian, On Sun, Jan 9, 2011 at 10:08 AM, Brian Granger wrote: > > I am updating some of flags that control pretty printing and that led > me to the %doctest_mode magic. ?Updating the version of this for the > terminal based IPython went find, but when I did the qtconsole > version, I noticed that the frontend doesn't handle the prompt mode > changes that are sent back in the payload. ?I could have sworn that > this was implemented and that %doctest_mode worked fully in the > qtconsole. ?What is the status of this? sorry, just caught up with this... No, you remember wrong: in fact, the doctest_mode magic was about the only thing we didn't correctly port over to the qt console, and precisely for this reason. Since it involves changing the prompt handling, and we've decided to make prompts a client-side thing rather than hardcode them in the kernel, it will require some design/thinking about how we want to communicate this kind of information to clients, as well as code in the Qt client to do something about it. That was pretty much the only magic we left out from functioning correctly in the Qt console, I'm afraid. Cheers, f From fperez.net at gmail.com Sun Mar 13 03:06:49 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 12 Mar 2011 23:06:49 -0800 Subject: [IPython-dev] 0.10.2.rc1 ready for testing. Message-ID: Hi everyone, while we want to get 0.11 out asap, all non-github users out there, including all distros (linux, epd, pythonxy, etc) are still using the 0.10.x series, and we'd like to ensure it's in as good shape as possible with our *very* limited manpower. I've put up at http://ipython.scipy.org/dist/testing/ the files for a release candidate for 0.10.2. I've gone through our bug tracker and applied everything that had a patch/pull request/solution that listed explicitly 0.10, so that should catch most things. I think I closed around 15 new bugs quickly, though I also managed to find this nasty bit in master/0.11 while testing: https://github.com/ipython/ipython/issues/290. If anyone wants to tackle that, by all means... Thanks to everyone who had included solutions or patches in the bug reports, I used many of those and tried to ensure proper credit in the commit messages. I'll be happy to apply any further small, self-contained, tested fixes if you have them, but we can't really embark on any major work for 0.10.2. The nasty gtk blocking problem we had is, to the best of my knowledge, fully fixed here (thanks to P. Ivanov, M. Voorhies and others who helped!). I'll leave this up for a week or so, would appreciate reports of any problems you may find. Hopefully there won't be many, as I tried to apply only clear fixes over 0.10.1, and no new features, but you never know. If all goes well, and time permitting, we can use this to cut 0.10.2 next week. This will allow the core team to focus now on merging all the remaining work and pull requests to really push 0.11 out, where all the major development of the last 18 months has gone. Cheers, f From pivanov314 at gmail.com Sun Mar 13 07:13:19 2011 From: pivanov314 at gmail.com (Paul Ivanov) Date: Sun, 13 Mar 2011 04:13:19 -0700 Subject: [IPython-dev] 0.10.2.rc1 ready for testing. In-Reply-To: References: Message-ID: <20110313111319.GU3658@ykcyc> Fernando Perez, on 2011-03-12 23:06, wrote: > The nasty gtk blocking problem we had is, to the best of my knowledge, > fully fixed here (thanks to P. Ivanov, M. Voorhies and others who > helped!). speaking of which, I feel like I'm going cross-eyed with this bug, so maybe this isn't a problem and should be considered user error (I'll sleep on it before I look at what behavior should be expected from matplotlib when the rcParam['interactive'] is set to False), but the following short little script screws up GTK threading, for me. ----- import matplotlib matplotlib.use("GTKAgg") import matplotlib.pyplot as plt #plt.interactive(True) # uncomment to fix plt.plot(range(10)) plt.show() # looks fine plt.close() plt.plot([2,1,2]) # this will timeout plt.show() # grey window, no toolbar drawn ----- I think in our testing, Mark and I only checked if the first figure worked, not the second. The above script doesn't seem to cause issues if called with -pylab (which makes me think the above just falls under user error) or when using just -wthread with matplotlib.use("WXAgg"). I just wanted to send a brief note, hopefully it'll all be clear in the morning. -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From takowl at gmail.com Sun Mar 13 12:26:04 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 13 Mar 2011 16:26:04 +0000 Subject: [IPython-dev] Multiple outputs per input line Message-ID: I realised that it's possible to get multiple outputs from a single input line. Most trivially, you can do "for a in range(5): a", to produce 5 outputs. At present, this crashes my sqlite-history branch if output logging is enabled, because it expects each output item to have a unique session and line number. In fact, the session output history doesn't really expect it either: it only stores the last result. It should be simple enough to catch the error in writing to the database, and only store the first result, or to use an SQL update statement so we only store the last result. Is that good enough for what I think is a fairly unusual case? Or do we want to work out a way of storing all the outputs from a command? Robert, logging output to the database was your suggestion, so perhaps you've got an opinion? (Of course, I can relax the restriction that session and line number must together be unique, but then getting useful information from the database becomes trickier.) Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sun Mar 13 16:56:00 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 13 Mar 2011 13:56:00 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On Sun, Mar 13, 2011 at 9:26 AM, Thomas Kluyver wrote: > I realised that it's possible to get multiple outputs from a single input > line. Most trivially, you can do "for a in range(5): a", to produce 5 > outputs. At present, this crashes my sqlite-history branch if output logging > is enabled, because it expects each output item to have a unique session and > line number. In fact, the session output history doesn't really expect it > either: it only stores the last result. > > It should be simple enough to catch the error in writing to the database, > and only store the first result, or to use an SQL update statement so we > only store the last result. Is that good enough for what I think is a fairly > unusual case? Or do we want to work out a way of storing all the outputs > from a command? Robert, logging output to the database was your suggestion, > so perhaps you've got an opinion? > > (Of course, I can relax the restriction that session and line number must > together be unique, but then getting useful information from the database > becomes trickier.) One thing we could do (that's what mathematica uses) is to simply increase the counter every time an *output* is produced. The logic does get a little more complex, but it lets us retain uniqueness throughout. What do you think? f From takowl at gmail.com Sun Mar 13 18:11:10 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 13 Mar 2011 22:11:10 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 13 March 2011 20:56, Fernando Perez wrote: > One thing we could do (that's what mathematica uses) is to simply > increase the counter every time an *output* is produced. The logic > does get a little more complex, but it lets us retain uniqueness > throughout. What do you think? > But many inputs don't produce any output, so we'd have to increment the counter on every input or output, which just feels...unwieldy. I think the numbering system we've got now, with one number per input cell, makes most sense. It means if you do "%macro thing 5-10", you know you're getting 6 commands. That said, I've never used Mathematica, so I don't know how neatly it works there. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Sun Mar 13 18:17:40 2011 From: benjaminrk at gmail.com (MinRK) Date: Sun, 13 Mar 2011 15:17:40 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: output is a separate table, right? I think I'm in favor of the input-id not being unique in the output table, and just returning a list (None if len 0, or the element if the list is length 1). -MinRK On Sun, Mar 13, 2011 at 15:11, Thomas Kluyver wrote: > On 13 March 2011 20:56, Fernando Perez wrote: >> >> One thing we could do (that's what mathematica uses) is to simply >> increase the counter every time an *output* is produced. ? The logic >> does get a little more complex, but it lets us retain uniqueness >> throughout. ?What do you think? > > But many inputs don't produce any output, so we'd have to increment the > counter on every input or output, which just feels...unwieldy. I think the > numbering system we've got now, with one number per input cell, makes most > sense. It means if you do "%macro thing 5-10", you know you're getting 6 > commands. That said, I've never used Mathematica, so I don't know how neatly > it works there. > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > From takowl at gmail.com Sun Mar 13 18:30:30 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 13 Mar 2011 22:30:30 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 13 March 2011 22:17, MinRK wrote: > output is a separate table, right? > Right. I think I'm in favor of the input-id not being unique in the output > table, and just returning a list (None if len 0, or the element if the > list is length 1). > I would still return a list for a single item, because it makes the code more consistent (e.g. you can do "\n".join(outputitems)). But if we go down that route, I'll probably serialise the list as JSON and store it in single rows - then the input and output tables can still be connected using SQL join, rather than some fancy Python logic. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Mon Mar 14 01:32:32 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 13 Mar 2011 22:32:32 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: > On Sun, Mar 13, 2011 at 9:26 AM, Thomas Kluyver wrote: >> I realised that it's possible to get multiple outputs from a single input >> line. Most trivially, you can do "for a in range(5): a", to produce 5 >> outputs. At present, this crashes my sqlite-history branch if output logging >> is enabled, because it expects each output item to have a unique session and >> line number. In fact, the session output history doesn't really expect it >> either: it only stores the last result. Our model of output is that it is a continuous stream that can happen at any moment in time and which can be completely uncorrelated with particular input lines. The history should reflect this reality. >> It should be simple enough to catch the error in writing to the database, >> and only store the first result, or to use an SQL update statement so we >> only store the last result. Is that good enough for what I think is a fairly >> unusual case? Or do we want to work out a way of storing all the outputs >> from a command? Robert, logging output to the database was your suggestion, >> so perhaps you've got an opinion? If we are going to log output, we should log everything in stream format. >> (Of course, I can relax the restriction that session and line number must >> together be unique, but then getting useful information from the database >> becomes trickier.) > > One thing we could do (that's what mathematica uses) is to simply > increase the counter every time an *output* is produced. ? The logic > does get a little more complex, but it lets us retain uniqueness > throughout. ?What do you think? I think that would get quite difficult. Mathematica's notion of output is very specific and concrete (they basically trigger a displayhook on every assignment). Our notion of "output" now is very dynamic - especially when you mix multiple frontends into the picture. Brian > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From fperez.net at gmail.com Mon Mar 14 04:11:48 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 14 Mar 2011 01:11:48 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On Sun, Mar 13, 2011 at 10:32 PM, Brian Granger wrote: > I think that would get quite difficult. ?Mathematica's notion of > output is very specific and concrete (they basically trigger a > displayhook on every assignment). ?Our notion of "output" now is very > dynamic - especially when you mix multiple frontends into the picture. > Remember, we're talking here about the outputs that get produced by the displayhook, for those we do have numbers we can track (because they stem from sys.displayhook firing). You're completely correct that we can't number display side effects, like print statements or any of the products of the new display system. But the return value of computations, which is what Out[N] contains, we can track. The logic for getting mathematica-like numbering is pretty easy: - prior to code execution, the kernel sets an offset in the display hook to 0. - on each call to displayhook, it does: execution_counter += offset offset+=1 With this, in all cases where only a single call is made to displayhook get matching numbers, but if a displayhook fires multiple times for a single input, then the counter is incremented accordingly. This would let us have always unambiguous storage of outputs by number even if multiple outputs were produced. The only change would be that in such a scenario, the next input wouldn't be 'previous+1' but instead it would be incremented by as many outputs as came out. Because Python isn't a purely functional language, we'll always have a distinction between the Out[] things that we can see go by on displayhook and other uncontrolled side-effects (prints, plots, etc). But so far, having numbered outputs for functional results has served us well, so this would simply be a matter of refining that to better handle the multi-output cases (which today we don't handle very well, as Thomas discovered). Cheers, f From fperez.net at gmail.com Mon Mar 14 04:13:13 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 14 Mar 2011 01:13:13 -0700 Subject: [IPython-dev] 0.10.2.rc1 ready for testing. In-Reply-To: <20110313111319.GU3658@ykcyc> References: <20110313111319.GU3658@ykcyc> Message-ID: Hey Paul, On Sun, Mar 13, 2011 at 4:13 AM, Paul Ivanov wrote: > Fernando Perez, on 2011-03-12 23:06, ?wrote: >> The nasty gtk blocking problem we had is, to the best of my knowledge, >> fully fixed here (thanks to P. Ivanov, M. Voorhies and others who >> helped!). > > speaking of which, I feel like I'm going cross-eyed with this bug, > so maybe this isn't a problem and should be considered user error > (I'll sleep on it before I look at what behavior should be > expected from matplotlib when the rcParam['interactive'] is set > to False), but the following short little script screws > up GTK threading, for me. > > ----- > import matplotlib > matplotlib.use("GTKAgg") > import matplotlib.pyplot as plt > #plt.interactive(True) # uncomment to fix > plt.plot(range(10)) > plt.show() # looks fine > plt.close() > plt.plot([2,1,2]) # this will timeout > plt.show() # grey window, no toolbar drawn > ----- > > I think in our testing, Mark and I only checked if the first > figure worked, not the second. The above script doesn't seem to > cause issues if called with -pylab (which makes me think the > above just falls under user error) or when using just -wthread > with matplotlib.use("WXAgg"). Keep in mind that what you describe is perfectly OK: we never expected the above to work without -pylab. So as long as things do work correctly when people do call -pylab, without any blocking or other issues, we're in the clear. Does that make sense? f From takowl at gmail.com Mon Mar 14 06:59:59 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 14 Mar 2011 10:59:59 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 14 March 2011 08:11, Fernando Perez wrote: > > This would let us have always unambiguous storage of outputs by number > even if multiple outputs were produced. The only change would be that > in such a scenario, the next input wouldn't be 'previous+1' but > instead it would be incremented by as many outputs as came out. > To my mind, the principle of least surprise suggests that inputs should be consecutively numbered, and output numbers should match up to their input numbers. That also makes it simple to later match up corresponding inputs and outputs. Of course, we could match up based on interleaving a sequence of input and output, but it seems needlessly complex. I can see how I'd implement storing multiple outputs if we want to do so - the outputs from one input command would go together in a list. If we think this is worth doing, I'll go and write it. I'm just checking whether we want the extra complexity, because I don't believe I've ever used multiple outputs until I was fiddling around yesterday. In fact, having thought about how I would do it, I'll code it up in a bit, and we can discuss a real system, rather than a hypothetical one. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Mon Mar 14 09:38:28 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 14 Mar 2011 13:38:28 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 14 March 2011 10:59, Thomas Kluyver wrote: > In fact, having thought about how I would do it, I'll code it up in a bit, > and we can discuss a real system, rather than a hypothetical one. Right, that kept me occupied over lunch. Take a look at the code: https://github.com/takluyver/ipython/commit/498d9f5596113a9817b9a2fa4a14314c14bb7439 Informal tests suggest that it's behaving as expected, but by all means pull the code and hunt for corner cases. If we're happy with this approach, I'll add some simple unit testing. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Mon Mar 14 12:39:16 2011 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 14 Mar 2011 11:39:16 -0500 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 3/14/11 8:38 AM, Thomas Kluyver wrote: > On 14 March 2011 10:59, Thomas Kluyver > wrote: > > In fact, having thought about how I would do it, I'll code it up in a bit, > and we can discuss a real system, rather than a hypothetical one. > > > Right, that kept me occupied over lunch. Take a look at the code: > https://github.com/takluyver/ipython/commit/498d9f5596113a9817b9a2fa4a14314c14bb7439 > > Informal tests suggest that it's behaving as expected, but by all means pull the > code and hunt for corner cases. If we're happy with this approach, I'll add some > simple unit testing. I really don't think we want the Out[] variable to have lists of things. That's really annoying for the most common case and would break long-standing usage. Having multiple displayhook calls is almost always an accident (e.g. usually you make a function call for its side effects even if it returns something not None), not an intentional act. I think the current behavior is perfectly fine: In [1]: for i in range(3): ...: i ...: Out[1]: 0 Out[1]: 1 Out[1]: 2 In [2]: Out[1] Out[2]: 2 That said, for the recording of displayhook outputs in *history*, we may as well record all of the the things sent to the displayhook. In the SQLite history, you can do this by just using a dummy autoincrementing primary key for the table and letting the (session, line) columns be non-unique. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From fperez.net at gmail.com Mon Mar 14 12:50:53 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 14 Mar 2011 09:50:53 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On Mon, Mar 14, 2011 at 9:39 AM, Robert Kern wrote: > I really don't think we want the Out[] variable to have lists of things. That's > really annoying for the most common case and would break long-standing usage. Totally agreed. Cheers, f From ellisonbg at gmail.com Mon Mar 14 13:01:04 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 14 Mar 2011 10:01:04 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: Hi, >> I think that would get quite difficult. ?Mathematica's notion of >> output is very specific and concrete (they basically trigger a >> displayhook on every assignment). ?Our notion of "output" now is very >> dynamic - especially when you mix multiple frontends into the picture. >> > > Remember, we're talking here about the outputs that get produced by > the displayhook, for those we do have numbers we can track (because > they stem from sys.displayhook firing). ?You're completely correct > that we can't number display side effects, like print statements or > any of the products of the new display system. ?But the return value > of computations, which is what Out[N] contains, we can track. I am a bit confused then. I thought we had removed the possibility for displayhook to be called more than once per input. I seem to remember that you removed that when you were working on the input splitter and execution logic last summer. What am I missing. I do agree that it is a bit different if we are only talking about the displayhook part of the logic. > The logic for getting mathematica-like numbering is pretty easy: > > - prior to code execution, the kernel sets an offset in the display hook to 0. > - on each call to displayhook, it does: > ?execution_counter += offset > ?offset+=1 Yep. > With this, in all cases where only a single call is made to > displayhook get matching numbers, but if a displayhook fires multiple > times for a single input, then the counter is incremented accordingly. This is definitely an unambiguous way of handling it. I have always found it a bit awkward to have Out incrementing this way in Mathematica though. > This would let us have always unambiguous storage of outputs by number > even if multiple outputs were produced. ?The only change would be that > in such a scenario, the next input wouldn't be 'previous+1' but > instead it would be incremented by as many outputs as came out. Right. > Because Python isn't a purely functional language, we'll always have a > distinction between the Out[] things that we can see go by on > displayhook and other uncontrolled side-effects (prints, plots, etc). > But so far, having numbered outputs for functional results has served > us well, so this would simply be a matter of refining that to better > handle the multi-output cases (which today we don't handle very well, > as Thomas discovered). I agree, but let's clarify why the multiple Out per In is even relevant (I thought it was impossible now). Cheers, Brian > Cheers, > > f > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From robert.kern at gmail.com Mon Mar 14 13:03:40 2011 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 14 Mar 2011 12:03:40 -0500 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 3/14/11 12:01 PM, Brian Granger wrote: > Hi, > >>> I think that would get quite difficult. Mathematica's notion of >>> output is very specific and concrete (they basically trigger a >>> displayhook on every assignment). Our notion of "output" now is very >>> dynamic - especially when you mix multiple frontends into the picture. >>> >> >> Remember, we're talking here about the outputs that get produced by >> the displayhook, for those we do have numbers we can track (because >> they stem from sys.displayhook firing). You're completely correct >> that we can't number display side effects, like print statements or >> any of the products of the new display system. But the return value >> of computations, which is what Out[N] contains, we can track. > > I am a bit confused then. I thought we had removed the possibility > for displayhook to be called more than once per input. I seem to > remember that you removed that when you were working on the input > splitter and execution logic last summer. What am I missing. I do > agree that it is a bit different if we are only talking about the > displayhook part of the logic. Well, if you removed it, it's back. Try it. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From takowl at gmail.com Mon Mar 14 13:04:34 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 14 Mar 2011 17:04:34 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: [Apologies, meant to post this to list. Thanks, Robert, for pointing it out] On 14 March 2011 16:53, Thomas Kluyver wrote: > On 14 March 2011 16:39, Robert Kern wrote: > >> I really don't think we want the Out[] variable to have lists of things. >> That's >> really annoying for the most common case and would break long-standing >> usage. >> Having multiple displayhook calls is almost always an accident (e.g. >> usually you >> make a function call for its side effects even if it returns something not >> None), not an intentional act. I think the current behavior is perfectly >> fine: >> > > At present, the Out variable in the user namespace is the same object as > the stored output history from the current session. I think the best way is > if I separate these. > > >> That said, for the recording of displayhook outputs in *history*, we may >> as well >> record all of the the things sent to the displayhook. In the SQLite >> history, you >> can do this by just using a dummy autoincrementing primary key for the >> table and >> letting the (session, line) columns be non-unique. >> > > I tried this, but it would need additional logic in Python to display the > inputs and outputs in the right sequence. I prefer the system I've written, > where (session, line) is unique, and the outputs for each command are > serialised as JSON. Inputs and outputs are conveniently paired by SQL JOIN, > and it's trivial to display them correctly. > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Mon Mar 14 13:10:22 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 14 Mar 2011 10:10:22 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: >>>> I think that would get quite difficult. ?Mathematica's notion of >>>> output is very specific and concrete (they basically trigger a >>>> displayhook on every assignment). ?Our notion of "output" now is very >>>> dynamic - especially when you mix multiple frontends into the picture. >>>> >>> >>> Remember, we're talking here about the outputs that get produced by >>> the displayhook, for those we do have numbers we can track (because >>> they stem from sys.displayhook firing). ?You're completely correct >>> that we can't number display side effects, like print statements or >>> any of the products of the new display system. ?But the return value >>> of computations, which is what Out[N] contains, we can track. >> >> I am a bit confused then. ?I thought we had removed the possibility >> for displayhook to be called more than once per input. ?I seem to >> remember that you removed that when you were working on the input >> splitter and execution logic last summer. ?What am I missing. ?I do >> agree that it is a bit different if we are only talking about the >> displayhook part of the logic. > > Well, if you removed it, it's back. Try it. I wasn't the one that removed this originally (Fernando did the work after discussions with Evan and myself), but you are right: In [2]: for i in range(5): ...: i ...: Out[2]: 0 Out[2]: 1 Out[2]: 2 Out[2]: 3 Out[2]: 4 Is this a deliberate move back to this or an unwanted regression? Cheers, Brian From takowl at gmail.com Mon Mar 14 13:20:29 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 14 Mar 2011 17:20:29 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: OK, once again, code: https://github.com/takluyver/ipython/commit/0c7eb96f95bbe19b30171d9a51262ec4a01656f0 As Robert suggests, this keeps only the last of several outputs in Out / _oh in the user namespace, while keeping all outputs to be retrieved by %hist. Again, I've done fairly superficial tests. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Mon Mar 14 13:22:49 2011 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 14 Mar 2011 12:22:49 -0500 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 3/14/11 12:04 PM, Thomas Kluyver wrote: > [Apologies, meant to post this to list. Thanks, Robert, for pointing it out] > > On 14 March 2011 16:53, Thomas Kluyver > wrote: > > On 14 March 2011 16:39, Robert Kern > wrote: > > I really don't think we want the Out[] variable to have lists of things. > That's > really annoying for the most common case and would break long-standing > usage. > Having multiple displayhook calls is almost always an accident (e.g. > usually you > make a function call for its side effects even if it returns something not > None), not an intentional act. I think the current behavior is perfectly > fine: > > > At present, the Out variable in the user namespace is the same object as the > stored output history from the current session. I think the best way is if I > separate these. > > That said, for the recording of displayhook outputs in *history*, we may > as well > record all of the the things sent to the displayhook. In the SQLite > history, you > can do this by just using a dummy autoincrementing primary key for the > table and > letting the (session, line) columns be non-unique. > > > I tried this, but it would need additional logic in Python to display the > inputs and outputs in the right sequence. I prefer the system I've written, > where (session, line) is unique, and the outputs for each command are > serialised as JSON. Inputs and outputs are conveniently paired by SQL JOIN, > and it's trivial to display them correctly. You would just ORDER BY the autoincrementing primary key. But anyways, as Brian points out, we did decide some time ago that exactly one output should go to the displayhook, and the current behavior is probably a regression. For the SQLite history, just use the last one. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From takowl at gmail.com Mon Mar 14 13:40:02 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 14 Mar 2011 17:40:02 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 14 March 2011 17:22, Robert Kern wrote: > You would just ORDER BY the autoincrementing primary key. > Indeed. And then fold together the outputs matching a single input. But I prefer it the way I've done it. But anyways, as Brian points out, we did decide some time ago that exactly > one > output should go to the displayhook, and the current behavior is probably a > regression. For the SQLite history, just use the last one. > OK. I'll leave it as is for now, because I can get the multiple outputs at a plain Python prompt, so it doesn't seem immediately "wrong". If we do remove that possibility, I'll put it back to assuming single outputs. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Mon Mar 14 14:44:01 2011 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 14 Mar 2011 13:44:01 -0500 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 3/14/11 12:20 PM, Thomas Kluyver wrote: > OK, once again, code: > https://github.com/takluyver/ipython/commit/0c7eb96f95bbe19b30171d9a51262ec4a01656f0 > > As Robert suggests, this keeps only the last of several outputs in Out / _oh in > the user namespace, while keeping all outputs to be retrieved by %hist. Again, > I've done fairly superficial tests. I'm not sure what you are doing here. Out/_oh should be storing the actual objects. The history should be storing the formatted text from the displayhook; you should not try to use repr() on those objects afterwards. That records the wrong thing. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From robert.kern at gmail.com Mon Mar 14 14:46:30 2011 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 14 Mar 2011 13:46:30 -0500 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 3/14/11 12:40 PM, Thomas Kluyver wrote: > On 14 March 2011 17:22, Robert Kern > wrote: > > You would just ORDER BY the autoincrementing primary key. > > > Indeed. And then fold together the outputs matching a single input. But I prefer > it the way I've done it. > > But anyways, as Brian points out, we did decide some time ago that exactly one > output should go to the displayhook, and the current behavior is probably a > regression. For the SQLite history, just use the last one. > > > OK. I'll leave it as is for now, because I can get the multiple outputs at a > plain Python prompt, so it doesn't seem immediately "wrong". If we do remove > that possibility, I'll put it back to assuming single outputs. I think you can consider that possibility removed. We did discuss this in the past, so I suspect that the remaining behavior is a regression. Trying to keep multiple outputs in the history seems to be adding too much complexity for no real gain. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From takowl at gmail.com Mon Mar 14 18:22:51 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 14 Mar 2011 22:22:51 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 14 March 2011 18:44, Robert Kern wrote: > I'm not sure what you are doing here. Out/_oh should be storing the actual > objects. The history should be storing the formatted text from the > displayhook; > you should not try to use repr() on those objects afterwards. That records > the > wrong thing. > That should now be what it's doing. Specifically, in displayhook, update_user_ns puts the actual object into Out[n] (and will update it on any subsequent calls, so the final output is stored). log_output then puts the text/plain representation of the object into a list of outputs, and when the execution is complete, all the outputs are stored in the database. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pivanov314 at gmail.com Tue Mar 15 12:14:41 2011 From: pivanov314 at gmail.com (Paul Ivanov) Date: Tue, 15 Mar 2011 09:14:41 -0700 Subject: [IPython-dev] 0.10.2.rc1 ready for testing. In-Reply-To: References: <20110313111319.GU3658@ykcyc> Message-ID: <20110315161441.GD3658@ykcyc> Fernando Perez, on 2011-03-14 01:13, wrote: > Keep in mind that what you describe is perfectly OK: we never expected > the above to work without -pylab. So as long as things do work > correctly when people do call -pylab, without any blocking or other > issues, we're in the clear. > > Does that make sense? It does, thanks for clarifying and helping me retain my sanity :) (-pylab works as advertised) Is running iptest still the preferred way of testing IPython? I get one Twisted related error that's probably my fault. ***************************************************************************** IPython test group: trial /home/pi/usr/local/bin/trial:4: UserWarning: Unbuilt egg for pytz [unknown version] (/usr/lib/python2.6/dist-packages) import pkg_resources Traceback (most recent call last): File "/home/pi/usr/local/bin/trial", line 4, in import pkg_resources File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 2659, in parse_requirements(__requires__), Environment() File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 546, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: Twisted==8.1.0 ***************************************************************************** because >>> import twisted >>> twisted.__version__ '10.0.0' best, -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From fperez.net at gmail.com Tue Mar 15 13:38:59 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 15 Mar 2011 10:38:59 -0700 Subject: [IPython-dev] 0.10.2.rc1 ready for testing. In-Reply-To: <20110315161441.GD3658@ykcyc> References: <20110313111319.GU3658@ykcyc> <20110315161441.GD3658@ykcyc> Message-ID: On Tue, Mar 15, 2011 at 9:14 AM, Paul Ivanov wrote: > It does, thanks for clarifying and helping me retain my sanity :) > (-pylab works as advertised) OK, thanks for checking. > Is running iptest still the preferred way of testing IPython? Yes, though I have to admit that the test suite for 0.10.x may have fallen into a bit of disrepair. I'll see if I can clean it up, but I'm seriously pressed for time and want to put what resources I have into the 0.11 work... We've kept the changes in 0.10.2 so isolated and small that hopefully no regressions have been introduced. Bad practice, I know, but I just don't have the time to maintain both branches in full, and just need to get 0.11 out asap. Thanks for your feedback! f From takowl at gmail.com Thu Mar 17 10:03:17 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 17 Mar 2011 14:03:17 +0000 Subject: [IPython-dev] Magic repeat commands Message-ID: I started looking at magic_rep, while reworking the history. It's struck me that it's not a very intuitive behaviour - it can either bring a line to the prompt, or execute code, and it overlaps with the magic_r function. So I'd like to propose a cleaner separation - let's have one magic command to repeat or rerun a command, and another to bring a line to the prompt. If we were starting with a clean slate, I would call these %repeat/%rep to run commands, and %recall/%rec to bring them to the prompt. But I think %rep is probably more often used to "recall" a line, so perhaps it would be better to leave it in this role, and call the new repeat function something like %rerun. More specifically, the recall function, whatever we call it, would have the following behaviour: - With no arguments, put the last output (_) at the prompt - If the argument is a string variable in the user namespace, put the value of that variable at the prompt (so you could recall Out[4]). I think this should be possible using eval. - If the argument specifies one or more cells in the history, join them into a single cell and put this at the prompt. (Or should we just take the first cell instead of combining them?) - Otherwise, search through the history, and recall the most recent line containing the search term. The repeat/rerun function would accept similar options and arguments to %history (except those relating to output), and would retrieve lines in the same way, except that the search option (-g) would only retrieve the most recent match. Specifying no arguments would get the cell immediately before it. These lines would then be run in exec mode (single mode for single blocks?) It makes sense to do this in my sqlite-history branch, because I need to modify these commands to work with the new history system anyway. Are there any thoughts or objections? If I separate the functions, what names would you like them to be under? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Mon Mar 21 13:50:20 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 21 Mar 2011 10:50:20 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: I know Fernando is super busy with buying a hours this week, and he is most familiar with the input splitter logic, but did anyone figure out the regression that is triggering the display hook multiple times? Cheers, Brian On Mon, Mar 14, 2011 at 3:22 PM, Thomas Kluyver wrote: > On 14 March 2011 18:44, Robert Kern wrote: >> >> I'm not sure what you are doing here. Out/_oh should be storing the actual >> objects. The history should be storing the formatted text from the >> displayhook; >> you should not try to use repr() on those objects afterwards. That records >> the >> wrong thing. > > That should now be what it's doing. Specifically, in displayhook, > update_user_ns puts the actual object into Out[n] (and will update it on any > subsequent calls, so the final output is stored). log_output then puts the > text/plain representation of the object into a list of outputs, and when the > execution is complete, all the outputs are stored in the database. > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From takowl at gmail.com Mon Mar 21 14:28:34 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 21 Mar 2011 18:28:34 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: My best guess is that it's not actually a regression - I've seen code in run_cell that ensures that only one block in a cell can fire displayhook, which could be what has been described. But it doesn't affect the situation in which that block causes displayhook to fire several times. As far as I know, the only way to achieve that would be to catch things in displayhook, append them to a list, and then display them only after computation has finished. Thomas On 21 March 2011 17:50, Brian Granger wrote: > I know Fernando is super busy with buying a hours this week, and he is > most familiar with the input splitter logic, but did anyone figure out > the regression that is triggering the display hook multiple times? > > Cheers, > > Brian > > On Mon, Mar 14, 2011 at 3:22 PM, Thomas Kluyver wrote: > > On 14 March 2011 18:44, Robert Kern wrote: > >> > >> I'm not sure what you are doing here. Out/_oh should be storing the > actual > >> objects. The history should be storing the formatted text from the > >> displayhook; > >> you should not try to use repr() on those objects afterwards. That > records > >> the > >> wrong thing. > > > > That should now be what it's doing. Specifically, in displayhook, > > update_user_ns puts the actual object into Out[n] (and will update it on > any > > subsequent calls, so the final output is stored). log_output then puts > the > > text/plain representation of the object into a list of outputs, and when > the > > execution is complete, all the outputs are stored in the database. > > > > Thomas > > > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > > > -- > Brian E. Granger, Ph.D. > Assistant Professor of Physics > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu > ellisonbg at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fernando.Perez at berkeley.edu Mon Mar 21 14:32:42 2011 From: Fernando.Perez at berkeley.edu (Fernando Perez) Date: Mon, 21 Mar 2011 11:32:42 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: Hey guys, On Mon, Mar 21, 2011 at 11:28, Thomas Kluyver wrote: > My best guess is that it's not actually a regression - I've seen code in > run_cell that ensures that only one block in a cell can fire displayhook, > which could be what has been described. But it doesn't affect the situation > in which that block causes displayhook to fire several times. As far as I > know, the only way to achieve that would be to catch things in displayhook, > append them to a list, and then display them only after computation has > finished. sorry, I can't look into this until tomorrow... Thomas, there should be code in there to prevent displayhook from firing based on the compilation mode: when code is compiled in 'single' mode, displayhook will fire, but if it's compiled in 'exec' mode, it won't. There's actually different bytecode produced by python itself based on the mode flag. I thought I had made sure that for multiline blocks we always produced 'exec' mode, but something must have slipped through the cracks... Cheers, f From ellisonbg at gmail.com Mon Mar 21 14:38:36 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 21 Mar 2011 11:38:36 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: Thomas, Can you open an issue for this regression so we can track it? Thanks! Brian On Mon, Mar 21, 2011 at 11:32 AM, Fernando Perez wrote: > Hey guys, > > On Mon, Mar 21, 2011 at 11:28, Thomas Kluyver wrote: >> My best guess is that it's not actually a regression - I've seen code in >> run_cell that ensures that only one block in a cell can fire displayhook, >> which could be what has been described. But it doesn't affect the situation >> in which that block causes displayhook to fire several times. As far as I >> know, the only way to achieve that would be to catch things in displayhook, >> append them to a list, and then display them only after computation has >> finished. > > sorry, I can't look into this until tomorrow... > > Thomas, there should be code in there to prevent displayhook from > firing based on the compilation mode: when code is compiled in > 'single' mode, displayhook will fire, but if it's compiled in 'exec' > mode, it won't. ?There's actually different bytecode produced by > python itself based on the mode flag. > > I thought I had made sure that for multiline blocks we always produced > 'exec' mode, but something must have slipped through the cracks... > > Cheers, > > f > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From takowl at gmail.com Mon Mar 21 14:39:59 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 21 Mar 2011 18:39:59 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 21 March 2011 18:32, Fernando Perez wrote: > I thought I had made sure that for multiline blocks we always produced > 'exec' mode, but something must have slipped through the cracks... > A single block is compiled in single mode, regardless of how many lines it has. If there are several blocks, the last one is compiled in single mode if it is <= 2 lines long. However, even with a single line, you can do: for a in range(5): a Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fernando.Perez at berkeley.edu Mon Mar 21 14:55:25 2011 From: Fernando.Perez at berkeley.edu (Fernando Perez) Date: Mon, 21 Mar 2011 11:55:25 -0700 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On Mon, Mar 21, 2011 at 11:39, Thomas Kluyver wrote: > A single block is compiled in single mode, regardless of how many lines it > has. If there are several blocks, the last one is compiled in single mode if > it is <= 2 lines long. Ah, yes! I remember now... > However, even with a single line, you can do: > > for a in range(5): a True. The solution is technically easy, I guess we just need to decide a policy. I'd implemented the current one thinking it was a good balance between seeing displayhook output in the most common cases and not getting multiple ones otherwise. But we can certainly revisit this. And we could go back to always compiling in single mode, if we want. Though that would trigger multiple Out[] results when running calls like matplotlib plots, that are intended for their side effects but still return a value. That was a big driver of deciding to silence things somewhat... best f From takowl at gmail.com Mon Mar 21 15:02:58 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 21 Mar 2011 19:02:58 +0000 Subject: [IPython-dev] Multiple outputs per input line In-Reply-To: References: Message-ID: On 21 March 2011 18:55, Fernando Perez wrote: > The solution is technically easy, I guess we just need to decide a > policy. I'd implemented the current one thinking it was a good > balance between seeing displayhook output in the most common cases and > not getting multiple ones otherwise. But we can certainly revisit > this. > > And we could go back to always compiling in single mode, if we want. > Though that would trigger multiple Out[] results when running calls > like matplotlib plots, that are intended for their side effects but > still return a value. That was a big driver of deciding to silence > things somewhat... > I think the current system is probably about right, in that it should show output when people expect it, and keep quiet when they don't. But it doesn't prevent multiple calls to displayhook, so although it's a fairly unusual case, we need to at least handle it gracefully. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Mon Mar 21 22:35:45 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 22 Mar 2011 02:35:45 +0000 Subject: [IPython-dev] Grab current namespace for magic commands Message-ID: At sagedays29, I've been pointed at an issue ( http://trac.sagemath.org/sage_trac/ticket/10933) where people want to use the %time magic command inside a function. However, magic_time evaluates its argument in the main user_ns namespace, not the namespace of the function. I believe it's possible to get the relevant namespace by using inspect.stack(). If we do this in interactiveshell.magic(), we can get a reference to the frame from which magic() was called, and then evaluate the code with the locals and globals of that frame. Does this sound like something worth doing, or an awkward kludge? Is there a nicer way to do this that I've overlooked? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Mon Mar 21 23:03:42 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 21 Mar 2011 20:03:42 -0700 Subject: [IPython-dev] Grab current namespace for magic commands In-Reply-To: References: Message-ID: Thomas, I think there is another issue, and that is the status of magic command in multiline input blocks. Fernando, what is the status of that type of thing? I think it works fine IIRC. > At sagedays29, I've been pointed at an issue > (http://trac.sagemath.org/sage_trac/ticket/10933) where people want to use > the %time magic command inside a function. However, magic_time evaluates its > argument in the main user_ns namespace, not the namespace of the function. I think this does make sense if we are going to allow magics to work inside functions. Probably have locals be the function's scope and globals be user_ns? > I believe it's possible to get the relevant namespace by using > inspect.stack(). If we do this in interactiveshell.magic(), we can get a > reference to the frame from which magic() was called, and then evaluate the > code with the locals and globals of that frame. Does this sound like > something worth doing, or an awkward kludge? Is there a nicer way to do this > that I've overlooked? Sounds good to me as long as multiline magics are working as expected. Cheers, Brian > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From takowl at gmail.com Tue Mar 22 12:04:13 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 22 Mar 2011 16:04:13 +0000 Subject: [IPython-dev] Grab current namespace for magic commands In-Reply-To: References: Message-ID: On 22 March 2011 03:03, Brian Granger wrote: > > I think there is another issue, and that is the status of magic > command in multiline input blocks. Fernando, what is the status of > that type of thing? Jumping in, because I've looked at the relevant code recently: explicit magic commands (%time a+b) are handled in multiline input blocks. Auto-magic (time a+b) is only handled in a single line cell, or a single line block at the end of a multi-block cell. Fernando, please correct me if that's not right, or I've missed anything out. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Thu Mar 24 22:07:53 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 25 Mar 2011 02:07:53 +0000 Subject: [IPython-dev] IPython & Unicode Message-ID: Hi J?rgen, We've merged the unicode issues branch into master, and unicode now seems to be behaving properly, at least in Linux. Can you let us know if you get unicode related issues in trunk? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Mar 25 01:36:56 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 24 Mar 2011 22:36:56 -0700 Subject: [IPython-dev] [sage-devel] Fernando Perez's talk today at Sage Days 29 In-Reply-To: References: Message-ID: Hi all, On Thu, Mar 24, 2011 at 10:16 PM, William Stein wrote: > Hi, > > Today Fernando Perez gave a very inspiring and enthusiastic talk today > at Sage Days 29 on Scientific Computing using Python, including a > historical introduction with a story about how he accidentally > unplugged the internet for the entire country of Colombia when he was > a grad student. ? You can watch the video of the talk here: > http://www.youtube.com/watch?v=1j_HxD4iLn8 Thanks for putting the video up! The slides are here: http://fperez.org/talks/1103_uwashington.pdf Cheers, f ps - for those interested, these days have been *very* productive for IPython. This page: http://wiki.sagemath.org/days29/bugs has the list of issues we've closed since Monday (50 and counting), and today we had a very good discussion with Jason Grout and others from the Sage team about IPython's messaging protocol. Many thanks to William for the invitation and support! From benjaminrk at gmail.com Mon Mar 28 14:42:56 2011 From: benjaminrk at gmail.com (MinRK) Date: Mon, 28 Mar 2011 11:42:56 -0700 Subject: [IPython-dev] GitHub Issues display Message-ID: For anyone who may be frustrated by the fact that our liberal application of labels obscures the display of the actual title of issues, I posted a tiny userstyle that simply doubles the height of the field, allowing it to fit an extra line. http://userstyles.org/styles/45768/github-more-space-for-issue-titles -MinRK From ellisonbg at gmail.com Mon Mar 28 16:00:43 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 28 Mar 2011 13:00:43 -0700 Subject: [IPython-dev] GitHub Issues display In-Reply-To: References: Message-ID: Yes! Brian On Mon, Mar 28, 2011 at 11:42 AM, MinRK wrote: > For anyone who may be frustrated by the fact that our liberal > application of labels obscures the display of the actual title of > issues, I posted a tiny userstyle that simply doubles the height of > the field, > allowing it to fit an extra line. > > http://userstyles.org/styles/45768/github-more-space-for-issue-titles > > -MinRK > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From andresete.chaos at gmail.com Tue Mar 29 10:15:35 2011 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Tue, 29 Mar 2011 09:15:35 -0500 Subject: [IPython-dev] Ipython frontend for two process Message-ID: Hi all. I am working in a terminal frontend for two process model https://github.com/omazapa/ipython/tree/frontend-logging/IPython/frontend/terminal I have some features working fine, like indentation, prompt numeration and timing in process execution. I am have problems in tab-completion, meybe some guidance help me to fix this bug. the timeline for the GSoC project delivery is very soon and maybe do not reach to get everything ready to apply, anyway I'll be working on the frontend. Thanks -- Omar Andres Zapata Mesa Universidad de Antioquia At Medellin - Colombia Usuario Linux #490962 -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Tue Mar 29 10:34:45 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 29 Mar 2011 15:34:45 +0100 Subject: [IPython-dev] Ipython frontend for two process In-Reply-To: References: Message-ID: 2011/3/29 Omar Andr?s Zapata Mesa > Hi all. > > I am working in a terminal frontend for two process model > > https://github.com/omazapa/ipython/tree/frontend-logging/IPython/frontend/terminal > I > have some features working fine, like indentation, prompt numeration and > timing in process execution. > I am have problems in tab-completion, meybe some guidance help me to fix > this bug. > When I test it, entering any command gives me the traceback below. Am I setting it up wrong? I'm installing in a virtualenv, then running python ipython/IPython/frontend/terminal/frontend.py. Thanks, Thomas ---- Traceback (most recent call last): File "ipython/IPython/frontend/terminal/frontend.py", line 270, in frontend.start() File "ipython/IPython/frontend/terminal/frontend.py", line 117, in start self.interact() File "ipython/IPython/frontend/terminal/frontend.py", line 101, in interact self._execute(self._splitter.source,False) File "ipython/IPython/frontend/terminal/frontend.py", line 136, in _execute self.handle_xreq_channel() File "ipython/IPython/frontend/terminal/frontend.py", line 141, in handle_xreq_channel if self.km.xreq_channel.was_called(): File "/home/thomas/code/virtualenvs/ipy-term-2proc/lib/python2.6/site-packages/IPython/frontend/terminal/kernelmanager.py", line 40, in was_called return self.queue.not_empty() TypeError: '_Condition' object is not callable -------------- next part -------------- An HTML attachment was scrubbed... URL: From andresete.chaos at gmail.com Tue Mar 29 11:12:04 2011 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Tue, 29 Mar 2011 10:12:04 -0500 Subject: [IPython-dev] Ipython frontend for two process In-Reply-To: References: Message-ID: Hi Thomas, Update you code, the bug was fixed. Thanks for the review. 2011/3/29 Thomas Kluyver > 2011/3/29 Omar Andr?s Zapata Mesa > >> Hi all. >> >> I am working in a terminal frontend for two process model >> >> https://github.com/omazapa/ipython/tree/frontend-logging/IPython/frontend/terminal >> I >> have some features working fine, like indentation, prompt numeration and >> timing in process execution. >> I am have problems in tab-completion, meybe some guidance help me to fix >> this bug. >> > > When I test it, entering any command gives me the traceback below. Am I > setting it up wrong? I'm installing in a virtualenv, then running python > ipython/IPython/frontend/terminal/frontend.py. > > Thanks, > Thomas > ---- > Traceback (most recent call last): > File "ipython/IPython/frontend/terminal/frontend.py", line 270, in > > frontend.start() > File "ipython/IPython/frontend/terminal/frontend.py", line 117, in start > self.interact() > File "ipython/IPython/frontend/terminal/frontend.py", line 101, in > interact > self._execute(self._splitter.source,False) > File "ipython/IPython/frontend/terminal/frontend.py", line 136, in > _execute > self.handle_xreq_channel() > File "ipython/IPython/frontend/terminal/frontend.py", line 141, in > handle_xreq_channel > if self.km.xreq_channel.was_called(): > File > "/home/thomas/code/virtualenvs/ipy-term-2proc/lib/python2.6/site-packages/IPython/frontend/terminal/kernelmanager.py", > line 40, in was_called > return self.queue.not_empty() > TypeError: '_Condition' object is not callable > > -- Omar Andres Zapata Mesa Universidad de Antioquia At Medellin - Colombia Usuario Linux #490962 -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Tue Mar 29 12:26:38 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 29 Mar 2011 17:26:38 +0100 Subject: [IPython-dev] Ipython frontend for two process In-Reply-To: References: Message-ID: 2011/3/29 Omar Andr?s Zapata Mesa > Hi Thomas, > Update you code, the bug was fixed. > Thanks for the review. > Thanks, that's working now. As for tab completion, if you look in IPython/core/completer.py, at line 865, uncomment the DEBUG = True line, and it should give you more info on what's going wrong. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Mar 30 04:25:39 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 30 Mar 2011 01:25:39 -0700 Subject: [IPython-dev] Short summary post on Sage Days visit Message-ID: Hi folks, a quick summary of last week's Sage Days work from my perspective: http://blog.fperez.org/2011/03/ipython-and-scientific-python-go-to.html Thanks again to William for the workshop! Cheers, f From takowl at gmail.com Thu Mar 31 19:25:05 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 1 Apr 2011 00:25:05 +0100 Subject: [IPython-dev] Pushed to master... Message-ID: Apologies for pushing my experimental change directly to master. I had the wrong branch checked out. I've pushed another commit to undo it - I understand that it's bad practice to remove a commit once it's been published. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: