From vivainio at gmail.com Wed Apr 1 01:47:03 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 1 Apr 2009 08:47:03 +0300 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> Message-ID: <46cb515a0903312247y2aca8081n2ba7b52eb4b914e9@mail.gmail.com> On Wed, Apr 1, 2009 at 12:34 AM, Brian Granger wrote: > What is the status of the 4 branches that have already been reviewed, > but are in need to fixing and/or further review? I'll try to fix mine today (or this week). I've been rather busy with other stuff lately. However, my branch only has "omissions" (unittests, docs), so basically it would be safe to merge it and allow you to proceed. > Of the 3 branches that need review, which are targeted for 0.10? I don't mind if my branch doesn't get to 0.10. I'd expect most people who benefit from it to use the bzr trunk anyway. -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Wed Apr 1 02:04:19 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 1 Apr 2009 09:04:19 +0300 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> Message-ID: <46cb515a0903312304q1ac63ad6iee11fd763d92fec4@mail.gmail.com> On Wed, Apr 1, 2009 at 1:23 AM, Fernando Perez wrote: > I know we've talked a bit about this, but before we get started on > this major reorganization, let's make sure we do plan it carefully. > For better or worse, while ipython is formally 'pre 1.0' and as such, > all API changes are in principle fair game, we need to ensure we find > a good balance of practicality vs purity. ?Just like numpy kept some My thought here would be that the right way to go is extending thi IPApi, not replacing it. There is no need to remove hooks, for example. It should be possible to do everything via IPApi, including the stuff that uses InteractiveShell directly now. One important facet it providing a good api for completer (should be quite easy, actually, but would benefit from refactoring of completer). If something seems like it will break ipapi (incl. hooks), postpone it and fix something else. Code that used an underlying InteractiveShell instance can be refactored to use a (new) IPApi call, but blatant breakage of ipapi just shouldn't be necessary. > parts. ?But now that with ipdoctest in place it is *trivial* to write > tests against that functionality, it would be possible to protect the > code better with tests *before* diving in, so that at least there's a > safety net to catch us if we fall. Last time I tried writing unit tests for user facing parts, the tests caused garbage to appear on screen. I haven't bothered with the branch since. Does ipdoctest solve this problem so that it can actually be used to write unit tests for the interactive part of ipython (almost none of which is currently covered)? However, I do think that getting paid time to refactor ipython is so precious an opportunity that nothing should hold it back. The damage can be fixed later, but every delay in actually getting down to work should be avoided at all cost. -- Ville M. Vainio http://tinyurl.com/vainio From fperez.net at gmail.com Wed Apr 1 05:37:16 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 1 Apr 2009 02:37:16 -0700 Subject: [IPython-dev] Creation of .ipython directory In-Reply-To: <6ce0ac130903202148g3b7e16co3f618a5b7c58376b@mail.gmail.com> References: <6ce0ac130903202148g3b7e16co3f618a5b7c58376b@mail.gmail.com> Message-ID: Hey, sorry I never replied to this... On Fri, Mar 20, 2009 at 9:48 PM, Brian Granger wrote: > Hi, > > Previously, the only IPython command line program that used the > .ipython directory was "ipython" itself. ?Now, however, other command > line programs (ipcluster, ipcontroller, ipengine) also use the > .ipython directory. ?A user just found a bug where they ran > "ipcluster" *before* "ipython" was ever run on their system. ?Thus, > "ipcluster" couldn't find the .ipython directory and an exception was > raised. Ugly. > So, I have a question: ?where in the IPython code base is the code > that looks to see if the .ipython directory exists and then creates it > if not? iplib, around line 1115: def user_setup(self,ipythondir,rc_suffix,mode='install'): """Install the user configuration directory. Can be called when running for the first time or to upgrade the user's .ipython/ directory with the mode parameter. Valid modes are 'install' and 'upgrade'.""" http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython//iplib.py > Should this same code be called by all IPython processes that > might need the .ipython directory? That seems reasonable to me, but it needs to be made more robust: In [1]: _ip.IP.user_setup('/home/fperez/.ipython/','rc') ********************************************************************** Welcome to IPython. I will try to create a personal configuration directory where you can customize many aspects of IPython's functionality in: /home/fperez/.ipython/ Initializing from configuration /home/fperez/usr/lib/python2.5/site-packages/IPython/UserConfig WARNING: There was a problem with the installation: [Errno 17] File exists: '/home/fperez/.ipython/' Try to correct it or contact the developers if you think it's a bug. IPython will proceed with builtin defaults. Please press to start IPython. ********************************************************************** Basically, just a matter of changing it so that it can be called anytime and *it* checks whether that dir exists. Today, the code is called in ipmaker: # Create user config directory if it doesn't exist. This must be done # *after* getting the cmd line options. if not os.path.isdir(opts_all.ipythondir): IP.user_setup(opts_all.ipythondir,rc_suffix,'install') If the check was moved inside, this could safely be called at startup by others without fear of the above error message. Cheers, f From walter at livinglogic.de Wed Apr 1 05:44:15 2009 From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=) Date: Wed, 01 Apr 2009 11:44:15 +0200 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> Message-ID: <49D3376F.4090501@livinglogic.de> Brian Granger wrote: > Hi, > > Things have gone quite for a while now and I wanted to see where we > stand on getting ready for 0.10. There are 7 merge proposals listed > here: > > https://code.launchpad.net/ipython/+activereviews > > Of these 4 seem to be in process and 3 are in need of review. > > What is the status of the 4 branches that have already been reviewed, > but are in need to fixing and/or further review? > > Of the 3 branches that need review, which are targeted for 0.10? IMHO lp:~doerwalter/ipython/ipipe-fix should go into 0.10. Servus, Walter From vishal.vatsa at gmail.com Wed Apr 1 08:37:42 2009 From: vishal.vatsa at gmail.com (Vishal Vatsa) Date: Wed, 01 Apr 2009 13:37:42 +0100 Subject: [IPython-dev] Status of pre-0.10 reviews and merges References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> Message-ID: Brian Granger wrote: > * My branch does need to be reviewed and merged before 0.10. I have had a look at your branch, Looks good to me, benchmark function is fine. I am really looking fwd to the reuse furl options. I can't review the branch on launchpad since I am not a part of the group. Regards, -vishal From dsdale24 at gmail.com Wed Apr 1 11:04:05 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 1 Apr 2009 11:04:05 -0400 Subject: [IPython-dev] problems building documentation with sphinx-0.6.1 Message-ID: I upgraded to sphinx-0.6.1 this morning and ran into some trouble. I've been trying to track down the cause, attempting to build the docs for my own projects (segfaults), numpy (issues, expecting segfaults), h5py (segfaults), and now ipython (issues). As of version 0.6, a tag can be provided to sphinx-build (perhaps in a make file or python equivalent) and then we can do, for example: .. only:: html But until IPython is ready to require >sphinx-0.6, perhaps someone could patch only_directives.py so it is compatible with version 0.6 and later: === modified file 'docs/sphinxext/only_directives.py' --- docs/sphinxext/only_directives.py 2008-09-13 22:39:09 +0000 +++ docs/sphinxext/only_directives.py 2009-04-01 14:44:05 +0000 @@ -5,7 +5,10 @@ from docutils.nodes import Body, Element from docutils.writers.html4css1 import HTMLTranslator -from sphinx.latexwriter import LaTeXTranslator +try: + from sphinx.latexwriter import LaTeXTranslator +except ImportError: + from sphinx.writers.latex import LaTeXTranslator from docutils.parsers.rst import directives class html_only(Body, Element): Has anyone tried building the ipython docs lately? After applying that patch, I try to build ipython's docs and I get an error when sphinx gets to IPython/frontend/frontendbase: ------- /usr/local/src/ipython/docs/sphinxext/docscrape.py:117: UserWarning: Unknown section Result warn("Unknown section %s" % key) /usr/local/src/ipython/docs/sphinxext/docscrape.py:117: UserWarning: Unknown section Parameters: warn("Unknown section %s" % key) ------- Followed by another error, which is probably not a concern since I don't have wxpython, but I thought I would report it anyway: ------- Exception occurred:[ 22%] api/generated/IPython.frontend.wx.console_widget File "/usr/local/src/ipython/docs/sphinxext/inheritance_diagram.py", line 107, in _import_class_or_module "Could not import class or module '%s' specified for inheritance diagram" % name) ValueError: Could not import class or module 'IPython.frontend.wx.console_widget' specified for inheritance diagram The full traceback has been saved in /tmp/sphinx-err-axFWA0.log, if you want to report the issue to the author. Please also report this if it was a user error, so that a better error message can be provided next time. Send reports to sphinx-dev at googlegroups.com. Thanks! make: *** [html] Error 1 ------ Cheers, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorgen.stenarson at bostream.nu Wed Apr 1 13:37:03 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 01 Apr 2009 19:37:03 +0200 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> Message-ID: <49D3A63F.3070708@bostream.nu> Oops forgot to send this to list as well: Brian Granger skrev: > Hi, > > Things have gone quite for a while now and I wanted to see where we > stand on getting ready for 0.10. There are 7 merge proposals listed > here: > > https://code.launchpad.net/ipython/+activereviews > > Of these 4 seem to be in process and 3 are in need of review. > > What is the status of the 4 branches that have already been reviewed, > but are in need to fixing and/or further review? > I have looked at and commented on all those that do not have status "needs fixing". Some random thoughts on the refactoring process: When working on the genutils.py patch I thought that it would be nice to have smaller module files because it is somewhat difficult to navigate huge modules and sometimes it can be difficult to guess in what module I should look for some function. All uses of from xx import * should be removed. This is one refactoring that would really benefit from good test coverage. To simplify debugging I have found the following idiom useful when re-raising exceptions because it preserves the full traceback: import sys def a(): 1/0 def b(): try: a() except ZeroDivisionError, x: raise ValueError, None, sys.exc_info()[2] def c(): try: a() except ZeroDivisionError, x: raise ValueError From an interactive session after running the prop_traceback.py script: In [1]: b() --------------------------------------------------------------------------- ValueError Traceback (most recent call last) C:\python\ in () C:\python\prop_traceback.py in b() 9 def b(): 10 try: ---> 11 a() 12 except ZeroDivisionError, x: 13 raise ValueError, None, sys.exc_info()[2] C:\python\prop_traceback.py in a() 5 6 def a(): ----> 7 1/0 8 9 def b(): ValueError: In [2]: c() --------------------------------------------------------------------------- ValueError Traceback (most recent call last) C:\python\ in () C:\python\prop_traceback.py in c() 16 a() 17 except ZeroDivisionError, x: ---> 18 raise ValueError 19 20 ValueError: As you can see when calling b() we get the full traceback up to the a function unlike in c() where the traceback terminates in the except cluse. I have found this technique very useful when debugging code. I do not know in what way this will affect performance or if there are any other drawbacks in threaded code or elsewhere... /J?rgen From hans_meine at gmx.net Thu Apr 2 04:26:24 2009 From: hans_meine at gmx.net (Hans Meine) Date: Thu, 2 Apr 2009 10:26:24 +0200 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: <49D3A63F.3070708@bostream.nu> References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> <49D3A63F.3070708@bostream.nu> Message-ID: <200904021026.25876.hans_meine@gmx.net> On Wednesday 01 April 2009 19:37:03 J?rgen Stenarson wrote: > All uses of from xx import * should be removed. This is one refactoring > that would really benefit from good test coverage. You know about pyflakes, do you? It is one of my favorite discoverings and covers this refactoring step very well. HTH, Hans From ellisonbg.net at gmail.com Thu Apr 2 22:55:41 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 2 Apr 2009 19:55:41 -0700 Subject: [IPython-dev] Creation of .ipython directory In-Reply-To: References: <6ce0ac130903202148g3b7e16co3f618a5b7c58376b@mail.gmail.com> Message-ID: <6ce0ac130904021955h77fca958w5c2052b7c76cfb14@mail.gmail.com> Thanks for the reply, I am glad I asked, because it sounds like to code for this is really spread out currently. We can definitely can consolidate this. Brian On Wed, Apr 1, 2009 at 2:37 AM, Fernando Perez wrote: > Hey, > > sorry I never replied to this... > > On Fri, Mar 20, 2009 at 9:48 PM, Brian Granger wrote: >> Hi, >> >> Previously, the only IPython command line program that used the >> .ipython directory was "ipython" itself. ?Now, however, other command >> line programs (ipcluster, ipcontroller, ipengine) also use the >> .ipython directory. ?A user just found a bug where they ran >> "ipcluster" *before* "ipython" was ever run on their system. ?Thus, >> "ipcluster" couldn't find the .ipython directory and an exception was >> raised. > > Ugly. > >> So, I have a question: ?where in the IPython code base is the code >> that looks to see if the .ipython directory exists and then creates it >> if not? > > iplib, around line 1115: > > ? ?def user_setup(self,ipythondir,rc_suffix,mode='install'): > ? ? ? ?"""Install the user configuration directory. > > ? ? ? ?Can be called when running for the first time or to upgrade the user's > ? ? ? ?.ipython/ directory with the mode parameter. Valid modes are 'install' > ? ? ? ?and 'upgrade'.""" > > http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython//iplib.py > >> Should this same code be called by all IPython processes that >> might need the .ipython directory? > > That seems reasonable to me, but it needs to be made more robust: > > In [1]: _ip.IP.user_setup('/home/fperez/.ipython/','rc') > ********************************************************************** > Welcome to IPython. I will try to create a personal configuration directory > where you can customize many aspects of IPython's functionality in: > > /home/fperez/.ipython/ > Initializing from configuration > /home/fperez/usr/lib/python2.5/site-packages/IPython/UserConfig > WARNING: > > There was a problem with the installation: > [Errno 17] File exists: '/home/fperez/.ipython/' > Try to correct it or contact the developers if you think it's a bug. > IPython will proceed with builtin defaults. > Please press to start IPython. > ********************************************************************** > > Basically, just a matter of changing it so that it can be called > anytime and *it* checks whether that dir exists. ?Today, the code is > called in ipmaker: > > ? ?# Create user config directory if it doesn't exist. This must be done > ? ?# *after* getting the cmd line options. > ? ?if not os.path.isdir(opts_all.ipythondir): > ? ? ? ?IP.user_setup(opts_all.ipythondir,rc_suffix,'install') > > If the check was moved inside, this could safely be called at startup > by others without fear of the above error message. > > Cheers, > > f > From ellisonbg.net at gmail.com Thu Apr 2 23:04:09 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 2 Apr 2009 20:04:09 -0700 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> Message-ID: <6ce0ac130904022004l35ff5184u922be556c82dd2dc@mail.gmail.com> Getting caught up after a few days teaching... > Thanks for pinging back in: here we had a massive sprint for > neuroimaging.scipy.org (a single merge was over 92000 lines long, to > give you an idea of how much code we moved around :) that I'm only now > recovering again from, as grant deadlines pile up. Wow, that is a pretty big merge. Sounds like good progress though. > Over the next two weeks I'll plug back into this so we can put 0.10 > out. ?I've been thinking about the twisted bug, and I suspect it has > to do with global state. ?The ipdoctest plugin insantiates a real > ipython, and that makes some global changes. ?I wonder if those are > confusing twisted somehow. ?Can you think of anything in this > direction? The big things we need to look at are: * If ipdoctest is picking up things that should really be run as tests that are somehow using twisted, but not in an officially "good" way * If there are globals that both twisted.trial and ipdoctest is mucking with that would be a problem. * The reactor is being started twice. That is very odd, but could help us debug this. I think this will take both of us to tackle. My idea is to start disabling parts of ipdoctest, or run the test suite on small parts of the codebase to try to isolate where the problem is coming from. >> I want to get these things resolved quickly as I am being paid to work >> on IPython during April these pending merges are currently holding me >> up. ?This is because I am going to start making MAJOR changes that >> will make it extremely difficult if not impossible to merge branches >> that are children of our current "trunk." ?We don't need to release >> 0.10 for me to get started with this work, but we do need to get these >> branches merged before I branch. > > I know we've talked a bit about this, but before we get started on > this major reorganization, let's make sure we do plan it carefully. > For better or worse, while ipython is formally 'pre 1.0' and as such, > all API changes are in principle fair game, we need to ensure we find > a good balance of practicality vs purity. ?Just like numpy kept some > Numeric-inspired baggage that wasn't ideal so that users could > transition without unnecessary pain, we should keep the same ideas in > mind. ?We should obviously fix the major messes we have (ipmaker is > ridiculous, 3 config systems is crazy, etc), but we should also be > willing to tolerate small warts if they make existing user's lives > easier. I am trying to distinguish between users and developer_users. For users, I strongly agree that IPython shouldn't really change, or if it does, in a very limited manner that improves things drastically (like the config system). For developers though, we need to allow much more freedom in changing APIs. We won't be able to do the work without it. But, even there, I agree that we should only change an API when we really need to. But...,the first things I will be working on will be pretty different from the types of changes you are talking about here. Basically, I am going to do a massive module/package reorganization. A draft of the idea is this... I am going to reorganize the top-level modules into logical subpackages. I am also going to use this as an opportunity to: * Identify rotting and broken code and move it to a directory (I won't delete it....yet) where everyone can look at the code and decide if we want to revive it (with tests+docs) or simply kill it for good. * Renaming modules and packages to pep 8 style lowercase.py * Adding tests to make sure that every moved/renamed module and package is importable (yeh, tests!!!) and working. * Where it is appropriate, begin to partition large modules (iplib, genutils, etc.) into smaller more logic submodules to make them easier to refactor and work with. * For really public facing developer APIs, I will put in a compatibility layer with deprecation warnings. The only thing that will change in the actual code though will be import statements and all of this will be tested. No API changes will be combined with this reorganization work. This reorganization is needed to help us really identify and isolate the things that need to be refactored moving forward But, because this work will move *everything* around, it will be difficult to merge branches back in in an automatic way. By hand though it might not be too bad to merge things. > Part of that is communicating a plan for the breakage to everyone in > advance, so that feedback can be provided by all affected before > anything irreversible has happened. Yes, I will absolutely ask for feedback about these plans before starting. I am working on an IPEP (IPython Enhancement Proposal) that describes my plans. More details to follow soon... > Furthermore, I'd like to suggest that post 0.10 we hold a 'bug and > test weeks' (2-4 max) to see if we could do an 0.11 release where we > basically try to *only* fix existing tickets and add as many tests as > we can, before starting to do major API breakage. In theory this is a great idea. In practice this timescale will cause problems with the work I need to do. I currently have funding that ends May 1 to work on this and I need to get started immediately. It is so rare to have dedicated time and $ for this, I don't want to waste the opportunity. That is basically 4 weeks away. In reality, I think I should soon just "go for it" and help people to do their merges into my branch by hand. >?I'd love to do a lot, but my next 12 weeks are > insane: *3* grants to write, another full-week sprint to host here, > and one major conference coming up. ?I'm sure others have also hectic > schedules. I completely understand if other people are really busy and can't participate. At a minimum, I will probably need code review help and participation in discussing the details of the plans. Cheers, Brian From ellisonbg.net at gmail.com Thu Apr 2 23:06:46 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 2 Apr 2009 20:06:46 -0700 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> Message-ID: <6ce0ac130904022006i98b7c91w663d54a6feaeb004@mail.gmail.com> Vishal, >> * My branch does need to be reviewed and merged before 0.10. > I have had a look at your branch, Looks good to me, benchmark function is > fine. I am really looking fwd to the reuse furl options. Thanks for looking at this! > I can't review the branch on launchpad since I am not a part of the group. Fernando, can we add Vishal to the team? Cheers, Brian From ellisonbg.net at gmail.com Thu Apr 2 23:09:21 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 2 Apr 2009 20:09:21 -0700 Subject: [IPython-dev] Fwd: Status of pre-0.10 reviews and merges In-Reply-To: <6ce0ac130904022009x57b0652fged9ae33a2d426619@mail.gmail.com> References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> <49D3A5E2.7070802@bostream.nu> <6ce0ac130904022009x57b0652fged9ae33a2d426619@mail.gmail.com> Message-ID: <6ce0ac130904022009x3d289774kf9947826390409aa@mail.gmail.com> ---------- Forwarded message ---------- From: Brian Granger Date: Thu, Apr 2, 2009 at 8:09 PM Subject: Re: [IPython-dev] Status of pre-0.10 reviews and merges To: J?rgen Stenarson > Some random thoughts on the refactoring process: > > When working on the genutils.py patch I thought that it would be nice to > have smaller module files because it is somewhat difficult to navigate huge > modules and sometimes it can be difficult to guess in what module I should > look for some function. Yes, partitioning large modules like genutils into more logical modules is part of my reorganization plans. ?Details to follow. > All uses of from xx import * should be removed. This is one refactoring that > would really benefit from good test coverage. Definitely! > To simplify debugging I have found the following idiom useful when > re-raising exceptions because it preserves the full traceback: Yes, this type of thing is helpful. > import sys > > def a(): > ? ?1/0 > > def b(): > ? ?try: > ? ? ? a() > ? ?except ZeroDivisionError, x: > ? ? ? ?raise ValueError, None, sys.exc_info()[2] > def c(): > ? ?try: > ? ? ? a() > ? ?except ZeroDivisionError, x: > ? ? ? ?raise ValueError > > > From an interactive session after running the prop_traceback.py script: > > In [1]: b() > --------------------------------------------------------------------------- > ValueError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Traceback (most recent call last) > > C:\python\ in () > > C:\python\prop_traceback.py in b() > ? ? ?9 def b(): > ? ? 10 ? ? try: > ---> 11 ? ? ? ?a() > ? ? 12 ? ? except ZeroDivisionError, x: > ? ? 13 ? ? ? ? raise ValueError, None, sys.exc_info()[2] > > C:\python\prop_traceback.py in a() > ? ? ?5 > ? ? ?6 def a(): > ----> 7 ? ? 1/0 > ? ? ?8 > ? ? ?9 def b(): > > ValueError: > > In [2]: c() > --------------------------------------------------------------------------- > ValueError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Traceback (most recent call last) > > C:\python\ in () > > C:\python\prop_traceback.py in c() > ? ? 16 ? ? ? ?a() > ? ? 17 ? ? except ZeroDivisionError, x: > ---> 18 ? ? ? ? raise ValueError > ? ? 19 > ? ? 20 > > ValueError: > > As you can see when calling b() we get the full traceback up to the a > function unlike in c() where the traceback terminates in the except cluse. I > have found this technique very useful when debugging code. I do not know in > what way this will affect performance or if there are any other drawbacks in > threaded code or elsewhere... > > /J?rgen > From ellisonbg.net at gmail.com Thu Apr 2 23:14:46 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 2 Apr 2009 20:14:46 -0700 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: <46cb515a0903312304q1ac63ad6iee11fd763d92fec4@mail.gmail.com> References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> <46cb515a0903312304q1ac63ad6iee11fd763d92fec4@mail.gmail.com> Message-ID: <6ce0ac130904022014t1b06bd30m72ddaea402438531@mail.gmail.com> > My thought here would be that the right way to go is extending thi > IPApi, not replacing it. There is no need to remove hooks, for > example. At some level yes, but part of what we have to do is combine the APIs that we have developed in IPython.kernel.core with those of ipapi. That mashup might require more than mere "extension" But, I just need to get started with it and see how it goes. This is where code review will be _really_ important! > It should be possible to do everything via IPApi, including the stuff > that uses InteractiveShell directly now. One important facet it > providing a good api for completer (should be quite easy, actually, > but would benefit from refactoring of completer). If something seems > like it will break ipapi (incl. hooks), postpone it and fix something > else. Code that used an underlying InteractiveShell instance can be > refactored to use a (new) IPApi call, but blatant breakage of ipapi > just shouldn't be necessary. > >> parts. ?But now that with ipdoctest in place it is *trivial* to write >> tests against that functionality, it would be possible to protect the >> code better with tests *before* diving in, so that at least there's a >> safety net to catch us if we fall. I agree that the stuff in ipdoctest is very important, but at some level, the refactoring will make it much easier to test things underneath the level of the interactive terminal prompt. This will be a side effect of de-coupling the core from readline and the terminal - easier to test the small low-level components of IPython. For example we should be able to test the completer without the terminal or readline in the picture. > However, I do think that getting paid time to refactor ipython is so > precious an opportunity that nothing should hold it back. The damage > can be fixed later, but every delay in actually getting down to work > should be avoided at all cost. +1 Brian > -- > Ville M. Vainio > http://tinyurl.com/vainio > From fperez.net at gmail.com Thu Apr 2 23:22:38 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 2 Apr 2009 20:22:38 -0700 Subject: [IPython-dev] Creation of .ipython directory In-Reply-To: <6ce0ac130904021955h77fca958w5c2052b7c76cfb14@mail.gmail.com> References: <6ce0ac130903202148g3b7e16co3f618a5b7c58376b@mail.gmail.com> <6ce0ac130904021955h77fca958w5c2052b7c76cfb14@mail.gmail.com> Message-ID: On Thu, Apr 2, 2009 at 7:55 PM, Brian Granger wrote: > Thanks for the reply, I am glad I asked, because it sounds like to > code for this is really spread out currently. ?We can definitely can > consolidate this. BTW, note that in https://code.launchpad.net/~fdo.perez/ipython/trunk-dev I added already the code to fix this, and the corresponding ticket: https://bugs.launchpad.net/ipython/+bug/353003 Ready for review/merge... Cheers, f From fperez.net at gmail.com Thu Apr 2 23:24:00 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 2 Apr 2009 20:24:00 -0700 Subject: [IPython-dev] Creation of .ipython directory In-Reply-To: References: <6ce0ac130903202148g3b7e16co3f618a5b7c58376b@mail.gmail.com> <6ce0ac130904021955h77fca958w5c2052b7c76cfb14@mail.gmail.com> Message-ID: On Thu, Apr 2, 2009 at 8:22 PM, Fernando Perez wrote: > https://code.launchpad.net/~fdo.perez/ipython/trunk-dev > > I added already the code to fix this, and the corresponding ticket: > > https://bugs.launchpad.net/ipython/+bug/353003 > > Ready for review/merge... Oops, I had missed the reviews in my current avalanche of email, sorry. I'll respond there... f From ellisonbg.net at gmail.com Thu Apr 2 23:42:50 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 2 Apr 2009 20:42:50 -0700 Subject: [IPython-dev] Creation of .ipython directory In-Reply-To: References: <6ce0ac130903202148g3b7e16co3f618a5b7c58376b@mail.gmail.com> <6ce0ac130904021955h77fca958w5c2052b7c76cfb14@mail.gmail.com> Message-ID: <6ce0ac130904022042i12974eh68d035743372f8e2@mail.gmail.com> > Oops, I had missed the reviews in my current avalanche of email, sorry. Yep, just looked at it... I was really bummed that Google's automatic email AI thing turned out to be an April Fools thing. Would have been really nice ;-) > I'll respond there... > > f > From ellisonbg.net at gmail.com Fri Apr 3 01:28:50 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 2 Apr 2009 22:28:50 -0700 Subject: [IPython-dev] IPEP: Module reorganization for IPython Message-ID: <6ce0ac130904022228i5ba39dj4fa557b7a9615c1d@mail.gmail.com> Hi, I just pushed a branch that has a description of the module reorganization that I want to do in preparation to refactor parts of the IPython "core" as we call it. This reorganization will touch most of IPython and will affect virtually everyone who works on IPython. I would like to get feedback on this proposal before I start work. Let the games begin! Here is the rst source of the proposal in my branch: http://bazaar.launchpad.net/~ellisonbg/ipython/module-reorg/annotate/head%3A/docs/source/development/reorg.txt There is also a merge proposal we can use to discuss this on: https://code.launchpad.net/~ellisonbg/ipython/module-reorg/+merge/5184 Cheers, Brian From fperez.net at gmail.com Fri Apr 3 05:47:32 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 3 Apr 2009 02:47:32 -0700 Subject: [IPython-dev] iptest and the nasty twisted bug Message-ID: Hi all, I've spent hours trying to fix the interaction between twisted and ipdoctest, to no avail. I have no clue what's going on, the problem is intermittent and makes no sense to me. But what I realized is that at least us developers have a simple, if clunky, workaround so that we can run the test suite by default in a twisted-robust way, while also running with full ipdoctest support. If you now run: iptest [any options] [any submodules] it will NOT load ipdoctest but won't cause any Twisted problems. Once you're happy that you didn't break Twisted, run iptest --with-ipdoctest [any options] [any submodules] This MAY give a Twisted AlreadyCalledError exception at the end, but it will also correctly load up all of the ipython-specific tests and doctests. The above can be made easier with a trivial shell alias alias iptest2='iptest --with-ipdoctest' So that you can run iptest ... # Twisted happy iptest2 ... # ignore possible Twisted error, this checks all the rest. I know this is not ideal, but at least it does give us a way to run all the proper IPython tests and doctests. I have not the foggiest idea how that error in Twisted is occurring: I'm not a Twisted expert, and the behavior is both intermittent and, to me, nonsensical. The ipdoctest plugin in principle doesn't do anything with Twisted or any global state (its changes to global state are happening anyway even now, so that's not the problem). I'm completely puzzled by this. **** But it is CRITICAL that all developers run the full suite with --with-ipdoctest ALWAYS before committing code **** It may be annoying to have to run the test suite twice, but that's the only way we can get test coverage of ipython magics and extensions. In my branch there are already 90 more tests picked up this way, and this is only bound to grow as we add ipython-specific tests. So these MUST be always run. I'd love to find a cleaner solution, and I'm sure we will eventually. But for now, this is how it will need to be done... Cheers, f From spe.stani.be at gmail.com Fri Apr 3 09:59:56 2009 From: spe.stani.be at gmail.com (Stani) Date: Fri, 03 Apr 2009 15:59:56 +0200 Subject: [IPython-dev] Porting IPython to Blender Message-ID: <1238767196.19036.51.camel@blue> Hi All, As a decent python shell is missing in Blender, I looked for ways to interact with IPython and Blender. One way is straightforward: just run in the terminal from which Blender is started. I've blogged about it here: http://pythonide.blogspot.com/2009/03/resumable-ipython-inside-blender_31.html However in this case IPython takes over the event loop and the Blender user interface blocked. Therefore I tried another approach to run IPython inside a Blender text window. It took me a bit of digging in the IPython source code, but I finally manged to create a 'IPShellBlender'. Apart from one inconvenience (position of mouse cursor, nothing related to IPython, but purely to Blender), this works really nice. It's fun to rotate or manipulate 3d objects from the shell. Not everything of IPython is supported, as I haven't port readline to the Blender text window. However most important features are implemented such as (auto completion). I've documented everything with Sphinx. Here is a tutorial how to enable IPython inside any Blender drawing (you need to install my ar package first): http://sd-2469.dedibox.fr/ar/tutorials/ipython.html http://sd-2469.dedibox.fr/ar/pages/installation.html http://ar.stani.be These are the code documentation: http://sd-2469.dedibox.fr/ar/modules/ar.blender.bipython.html http://sd-2469.dedibox.fr/ar/modules/ar.blender.bipython.private.html The actual code can be found in the bipython module (= blender+ipython): http://bazaar.launchpad.net/~stani/ar/trunk/annotate/head% 3A/ar/blender/bipython.py At the moment Blender is working on a major rewrite for Blender 2.5. We'd like to include IPython as a default shell for IPython. The only problem is that Blender 2.5 will use python 3.0, which is not yet supported AFAIK for IPython. On the other hand I've only used some core modules, so maybe they might be available for python 3.0 sooner before all the extensions (twister, wx, qt, ...) As you might be interested, I'll give some feedback on issues I run in to. However I run through the IPython code quite quickly to study it, so I might have done some false presumptions. The main modules I used were: from IPython.Shell import IPShellEmbed from IPython import ipapi 1) I was happy to find a complete method in the IPShellEmbed, however it turned out to be useless. The IP.complete method should have an (optional) line_buffer argument. Without this many completers won?t work such as the module completer. I think my complete function complete(self, text, line_buffer) on line 624 would be a good proposal for an IPython patch. 2) Output redirection now happens by duplicating stdout and stderr to temporary files. This is not ideal. Better would be if there was a way to hook into the IPython Term instance (Term.cout, Term.cerr, ...) 3) I had to fool IPython in order to force it not to use the readline module os.environ['TERM']='dumb' 4)+5) I also needed to be able to clear and rewrite the text windows, because of two reasons: - text windows in Blender are a bit primitive so the text can't scroll with the cursor. Therefore I needed to be able to display IPython in reverse (last statement comes first) - uses might accidently damage the ipython shell These are shortcomings in the Blender Python API, which will be addressed in a future version. 4) Therefore I needed to be able to reconstruct the IPython shell at any time. Here I faced the difficulty that the prompts can only be generated for the current statement. A quick hack was to temporarily overwrite the prompt_count int the output cache, see the IPShellBlender.get_prompt() method and I needed these core modules to reconstruct prompts: from IPython.Prompts import str_safe from IPython.Itpl import ItplNS 5) The Out list caches the history of the output values. In order to redraw itself, the stdout string output is needed. Therefore the IPBlenderShell caches this. If IPython stores this somewhere, I?d like to know. I would welcome any feedback on the above four points or on my approach in general. I'm sure that more experienced IPython developers can hint many improvements. IPython is really the best shell out there, so keep up the great work! Stani From laurent.dufrechou at gmail.com Fri Apr 3 11:02:24 2009 From: laurent.dufrechou at gmail.com (Laurent Dufrechou) Date: Fri, 3 Apr 2009 17:02:24 +0200 Subject: [IPython-dev] Porting IPython to Blender In-Reply-To: <1238767196.19036.51.camel@blue> References: <1238767196.19036.51.camel@blue> Message-ID: <7ced318f0904030802q200b6871g2dbc11d0c36b128@mail.gmail.com> Hi Stani, Really interesting. For your issue can I propose a different approach? Have you taken a look at IPython/frontend or IPython/Gui/wx directory? There is various implementation of interface with wx / cocoa for example and I think you will find some interesting things in it. :) Perhpas I'm out of subjetc but,if I well understood you need control over in/out of ipython because your terminal is not fully compatible with clasical ipython output. So perhaps it will be a good idea to use for example prefilterfrontend.py or (a code that i bettter undersatnd :)) ipshell_nonblocking.py Just to give you a global idea: For example in my case, ipshell_nonblocking.py instanciate ipython0 shell and I feed it via self.IP.doExecute(lines_to_execute.encode(ENCODING)) completion is done like this: completed, possibilities = self.IP.complete(self.text_ctrl.getCurrentLine()) output is redirected to cout class parameter: self.IP = WxNonBlockingIPShell(self, <- this is aspecialized WX shell derived from nonblocking one cout = self.cout, cerr = self.cout, ask_exit_handler = self.askExitCallback) self.text_ctrl = WxConsoleView(self, self.IP.getPrompt(), intro=welcome_text, background_color=background_color) self.cout.write = self.text_ctrl.asyncWrite You can take a look at the code inside these function to see of they works. I think prefilterfrontend.py will be the starting point you need. (in /fontend/) It is a newer version that will try in the future to follow ipython1 impelmetation. Gael has written it so he is more aware about this. Using one of these class you'll be able to feed a ipython instance with your input and get output result more easily. You will not have to go inside the ipython internals becuase they manage this for you. Thus you'll have full control over your terminal.(if you've got access to your terminal display functions, if not all my text above is unusable :) ) And you'll be able not to use temporary files ;) If you still want to use IPShellEmbeded perhaps __init__ of ipshell_nonblocking.py can answer some of your question as I felt in almost the same issue.. Feel free to ask more queston :) Cheers, Laurent 2009/4/3 Stani > Hi All, > > As a decent python shell is missing in Blender, I looked for ways to > interact with IPython and Blender. One way is straightforward: just run > in the terminal from which Blender is started. I've blogged about it > here: > > http://pythonide.blogspot.com/2009/03/resumable-ipython-inside-blender_31.html > > However in this case IPython takes over the event loop and the Blender > user interface blocked. > > Therefore I tried another approach to run IPython inside a Blender text > window. It took me a bit of digging in the IPython source code, but I > finally manged to create a 'IPShellBlender'. Apart from one > inconvenience (position of mouse cursor, nothing related to IPython, but > purely to Blender), this works really nice. It's fun to rotate or > manipulate 3d objects from the shell. Not everything of IPython is > supported, as I haven't port readline to the Blender text window. > However most important features are implemented such as (auto > completion). > > I've documented everything with Sphinx. Here is a tutorial how to enable > IPython inside any Blender drawing (you need to install my ar package > first): > http://sd-2469.dedibox.fr/ar/tutorials/ipython.html > http://sd-2469.dedibox.fr/ar/pages/installation.html > http://ar.stani.be > > These are the code documentation: > http://sd-2469.dedibox.fr/ar/modules/ar.blender.bipython.html > http://sd-2469.dedibox.fr/ar/modules/ar.blender.bipython.private.html > > The actual code can be found in the bipython module (= blender+ipython): > http://bazaar.launchpad.net/~stani/ar/trunk/annotate/head% > 3A/ar/blender/bipython.py > > At the moment Blender is working on a major rewrite for Blender 2.5. > We'd like to include IPython as a default shell for IPython. The only > problem is that Blender 2.5 will use python 3.0, which is not yet > supported AFAIK for IPython. On the other hand I've only used some core > modules, so maybe they might be available for python 3.0 sooner before > all the extensions (twister, wx, qt, ...) > > As you might be interested, I'll give some feedback on issues I run in > to. However I run through the IPython code quite quickly to study it, so > I might have done some false presumptions. > > The main modules I used were: > from IPython.Shell import IPShellEmbed > from IPython import ipapi > > 1) I was happy to find a complete method in the IPShellEmbed, however it > turned out to be useless. The IP.complete method should have an > (optional) line_buffer argument. Without this many completers won?t work > such as the module completer. I think my complete function > complete(self, text, line_buffer) on line 624 would be a good proposal > for an IPython patch. > > 2) Output redirection now happens by duplicating stdout and stderr to > temporary files. This is not ideal. Better would be if there was a way > to hook into the IPython Term instance (Term.cout, Term.cerr, ...) > > 3) I had to fool IPython in order to force it not to use the readline > module os.environ['TERM']='dumb' > > 4)+5) I also needed to be able to clear and rewrite the text windows, > because of two reasons: > - text windows in Blender are a bit primitive so the text can't scroll > with the cursor. Therefore I needed to be able to display IPython in > reverse (last statement comes first) > - uses might accidently damage the ipython shell > These are shortcomings in the Blender Python API, which will be > addressed in a future version. > > 4) Therefore I needed to be able to reconstruct the IPython shell at any > time. Here I faced the difficulty that the prompts can only be generated > for the current statement. A quick hack was to temporarily overwrite the > prompt_count int the output cache, see the IPShellBlender.get_prompt() > method and I needed these core modules to reconstruct prompts: > from IPython.Prompts import str_safe > from IPython.Itpl import ItplNS > > 5) The Out list caches the history of the output values. In order to > redraw itself, the stdout string output is needed. Therefore the > IPBlenderShell caches this. If IPython stores this somewhere, I?d like > to know. > > I would welcome any feedback on the above four points or on my approach > in general. I'm sure that more experienced IPython developers can hint > many improvements. > > IPython is really the best shell out there, so keep up the great work! > > Stani > > _______________________________________________ > 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 spe.stani.be at gmail.com Fri Apr 3 12:20:18 2009 From: spe.stani.be at gmail.com (Stani) Date: Fri, 3 Apr 2009 18:20:18 +0200 Subject: [IPython-dev] Porting IPython to Blender In-Reply-To: <7ced318f0904030802q200b6871g2dbc11d0c36b128@mail.gmail.com> References: <1238767196.19036.51.camel@blue> <7ced318f0904030802q200b6871g2dbc11d0c36b128@mail.gmail.com> Message-ID: <2078a7ad0904030920v2b774476o683057edc60db1d3@mail.gmail.com> On Fri, Apr 3, 2009 at 5:02 PM, Laurent Dufrechou wrote: > Hi Stani, > Just a quick reaction before the weekend... > Really interesting. For your issue can I propose a different approach? Sure, please do! > > Have you taken a look at IPython/frontend or IPython/Gui/wx directory? No, as I am using the IPython version 0.8.4 which is now standard on Ubuntu. But using the latest version is an option too. > There is various implementation of interface with wx / cocoa for example and > I think you will find some interesting things in it. :) > > Perhpas I'm out of subjetc but,if I well understood you need control over > in/out of ipython because your terminal is not fully compatible with > clasical ipython output. > So perhaps it will be a good idea to use for example prefilterfrontend.py or > (a code that i bettter undersatnd :)) ipshell_nonblocking.py Hmm... this is using threads, which I can't use inside Blender without blocking the user interface. But thanks for your help, probably I might take some inspiration from it. Stani From fperez.net at gmail.com Fri Apr 3 13:47:15 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 3 Apr 2009 10:47:15 -0700 Subject: [IPython-dev] Another shell: pyglet! Message-ID: Hey folks, Great timing with the other Blender thread... I've just been interacting with Nicolas Rougier, the author of this cool little thing: http://www.loria.fr/~rougier/glnumpy.html It's beautiful and fast. Nicolas is using a lot of ipython internals, the kind of thing that is likely to break as our APIs evolve and we develop a stable public one. So it would be a lot easier if we were to ship this together with ipython, maintain it with the rest of the frontends, etc. I think it's still at the level of being a small useful component more than a full-fledged shell, but having it in our 'lab', with the contributions of the rest of the team, might help it grow quickly. Nicolas has made a fantastic start here, and I'd really like to see this kind of tool be available (for those who want OpenGL) out of the box with the project. Opinions? Nicolas, if this is to move forward, I just saw that your code is GPL licensed so far. IPython is all BSD, so I don't know if you'd be willing to relicense it for inclusion in IPython. Cheers, f From Nicolas.Rougier at loria.fr Fri Apr 3 13:52:08 2009 From: Nicolas.Rougier at loria.fr (Nicolas Rougier) Date: Fri, 3 Apr 2009 19:52:08 +0200 Subject: [IPython-dev] Another shell: pyglet! In-Reply-To: References: Message-ID: <25C3C027-2092-40BA-987F-65B6901F3340@loria.fr> No problem for relicensing it under BSD. Nicolas On 3 Apr, 2009, at 19:47 , Fernando Perez wrote: > Hey folks, > > Great timing with the other Blender thread... I've just been > interacting with Nicolas Rougier, the author of this cool little > thing: > > http://www.loria.fr/~rougier/glnumpy.html > > It's beautiful and fast. Nicolas is using a lot of ipython internals, > the kind of thing that is likely to break as our APIs evolve and we > develop a stable public one. So it would be a lot easier if we were > to ship this together with ipython, maintain it with the rest of the > frontends, etc. I think it's still at the level of being a small > useful component more than a full-fledged shell, but having it in our > 'lab', with the contributions of the rest of the team, might help it > grow quickly. Nicolas has made a fantastic start here, and I'd really > like to see this kind of tool be available (for those who want OpenGL) > out of the box with the project. > > Opinions? > > Nicolas, if this is to move forward, I just saw that your code is GPL > licensed so far. IPython is all BSD, so I don't know if you'd be > willing to relicense it for inclusion in IPython. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From ondrej at certik.cz Fri Apr 3 14:08:58 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Fri, 3 Apr 2009 11:08:58 -0700 Subject: [IPython-dev] Another shell: pyglet! In-Reply-To: References: Message-ID: <85b5c3130904031108p3ac99416g542ae0b867ed401@mail.gmail.com> On Fri, Apr 3, 2009 at 10:47 AM, Fernando Perez wrote: > Hey folks, > > Great timing with the other Blender thread... ?I've just been > interacting with Nicolas Rougier, the author of this cool little > thing: > > http://www.loria.fr/~rougier/glnumpy.html > > It's beautiful and fast. ?Nicolas is using a lot of ipython internals, > the kind of thing that is likely to break as our APIs evolve and we > develop a stable public one. ?So it would be a lot easier if we were > to ship this together with ipython, maintain it with the rest of the > frontends, etc. ?I think it's still at the level of being a small > useful component more than a full-fledged shell, but having it in our > 'lab', with the contributions of the rest of the team, might help it > grow quickly. ?Nicolas has made a fantastic start here, and I'd really > like to see this kind of tool be available (for those who want OpenGL) > out of the box with the project. > > Opinions? Looks good. We could then use this frontend with sympy to pretty print equations. So this frotnend would depend on pyglet. So far we were shipping pyglet with sympy, but I think we should just remove it and rather depend on it (just for plotting). Ondrej From fperez.net at gmail.com Fri Apr 3 14:10:34 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 3 Apr 2009 11:10:34 -0700 Subject: [IPython-dev] Another shell: pyglet! In-Reply-To: <25C3C027-2092-40BA-987F-65B6901F3340@loria.fr> References: <25C3C027-2092-40BA-987F-65B6901F3340@loria.fr> Message-ID: On Fri, Apr 3, 2009 at 10:52 AM, Nicolas Rougier wrote: > > No problem for relicensing it under BSD. Great! I'd like to hear the opinions of others, but I'm +1 on bringing this in under IPyhton's wing. We're too close for the next release, but unless someone objects, I'd suggest that Nicolas make a branch of IPython on launchpad where this can live. That way we can give you feedback on the branch, you'll get used to the development process, you can track what happens in trunk, add docs using sphinx, etc. Once it matures, we'll be able to merge it in then. Cheers, f From laurent.dufrechou at gmail.com Fri Apr 3 14:44:16 2009 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Fri, 3 Apr 2009 20:44:16 +0200 Subject: [IPython-dev] Porting IPython to Blender In-Reply-To: <2078a7ad0904030920v2b774476o683057edc60db1d3@mail.gmail.com> References: <1238767196.19036.51.camel@blue> <7ced318f0904030802q200b6871g2dbc11d0c36b128@mail.gmail.com> <2078a7ad0904030920v2b774476o683057edc60db1d3@mail.gmail.com> Message-ID: <49d65922.0a1ad00a.3fc4.ffffca54@mx.google.com> Hello stani, Ho, sorry, I forget to mention that threading is optional. Direct call to _execute execute in non threaded mode. Threading was a requirement because I wanted to support ctrl+c on infinite loop. (I've added this option in dev branch) Prefilterfrontend.py used by /frontend/wx/ipythonx.py do not use threading at all, and has the same mechanism. Laurent > -----Message d'origine----- > De?: Stani [mailto:spe.stani.be at gmail.com] > Envoy??: vendredi 3 avril 2009 18:20 > ??: Laurent Dufrechou > Cc?: IPython Development list > Objet?: Re: [IPython-dev] Porting IPython to Blender > > On Fri, Apr 3, 2009 at 5:02 PM, Laurent Dufrechou > wrote: > > Hi Stani, > > > Just a quick reaction before the weekend... > > > Really interesting. For your issue can I propose a different > approach? > Sure, please do! > > > > Have you taken a look at IPython/frontend or IPython/Gui/wx > directory? > No, as I am using the IPython version 0.8.4 which is now standard on > Ubuntu. But using the latest version is an option too. > > > There is various implementation of interface with wx / cocoa for > example and > > I think you will find some interesting things in it. :) > > > > Perhpas I'm out of subjetc but,if I well understood you need control > over > > in/out of ipython because your terminal is not fully compatible with > > clasical ipython output. > > So perhaps it will be a good idea to use for example > prefilterfrontend.py or > > (a code that i bettter undersatnd :)) ipshell_nonblocking.py > Hmm... this is using threads, which I can't use inside Blender without > blocking the user interface. But thanks for your help, probably I > might take some inspiration from it. > > Stani From fperez.net at gmail.com Sun Apr 5 00:23:03 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 4 Apr 2009 21:23:03 -0700 Subject: [IPython-dev] Nasty, nasty references bug Message-ID: Hi all, https://bugs.launchpad.net/ipython/+bug/269966 has proven to be a rather unpleasant little beast. I've attached here a file that explains in great detail the problem and illustrates it even without using ipyton at all. The issue, at heart, has to do with how the Python VM tears down module objects when they go out of scope. I suspect the module teardown machinery is allowed to be so aggressive (it takes a rather Jack the Ripper approach to the objects contained in a module, without any regard for their reference count) because in normal use, modules are only deleted at interpreter shutdown. By that point all politeness tends to be cast overboard and the interpreter just goes on a rampage on anything it finds in memory. IPython, as usual, finds a way to clash with this (we have a good track record of finding dark corners of Python's behavior). So basically we have the following: - if we cache all execution modules, we leak memory. For certain use patterns this can be a major problem, and it has been reported several times. - but if we don't, there are cases that become totally broken. The test script attached may seem artificial, but with matplotlib it becomes easy to get the problem. I do have two ideas on what to do, but I won't be able to try them until Monday (limited net access this weekend): - go back to having FakeModule NOT inherit from a real module. Now we have real tests and we can try to build a robust test harness for this to work without being a true module subclass. - I'm going to try to keep a single instance of the execution module, but replacing its __dict__ with a fresh one each run. This might give us all the behavior we need, without triggering the Python Module Mad Butcher. I tend to favor the latter, so I'll give it a try on Monday, once I have access to my normal computer. If anyone has any insights on this and knows the reasons behind this part of Python's internal machinery, I'm quite interested. I might also ping python-dev at least to query them for their thoughts on this. Cheers, f ps - Many thanks to Matthew Brett for his patience when I needed someone to discuss this and clarify things out. -------------- next part -------------- A non-text attachment was scrubbed... Name: modrefs.py Type: text/x-python Size: 7192 bytes Desc: not available URL: From robert.kern at gmail.com Sun Apr 5 04:50:29 2009 From: robert.kern at gmail.com (Robert Kern) Date: Sun, 05 Apr 2009 03:50:29 -0500 Subject: [IPython-dev] Using argparse for %magics Message-ID: I have updated my personal collection of %magics today: http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/kernmagic Not all of them are aimed at inclusion into IPython proper, but I think most of them would be useful as Extensions, at least. Here are all of the collected docstrings: http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/kernmagic/raw-file/tip/help.txt The recently added magics are %push_err/%pop_err for controlling numpy's error handling options via a stack. These complement %push_print/%pop_print, which control numpy's printing options the same way. %print_methods (optional alias %pm) for printing the methods of an object, grouped by the defining class. %print_traits (optional alias %pt) for printing the traits of a HasTraits object, grouped by the defining class. Crazy-useful. One thing you might want to consider for IPython proper is the mini-framework I use for parsing the arguments. I made some decorators which use argparse (now in IPython.externals, amen) to build parsers for those magics that take CLI-style --options. It's nicely declarative and makes the option parsing and help text style uniform across all of the magics. We've discussed having a standard for all of the --option-taking %magics that come with IPython, and I put this forward as an improvement over the current manual getopt code. Here is the start of one of my %magics, to demonstrate: from kernmagic.magic_arguments import magic_arguments, argument, parse_argstring @magic_arguments() @argument('-e', '--encoding', default='utf-8', help="the encoding to use for unicode objects; no effect on str objects " "[default: %(default)s]") @argument('-m', '--mode', default='wb', help="the file mode to use when opening the file for writing") @argument('variable', help="the name of the variable") @argument('filename', nargs='?', help="the filename to write [default: the variable's name]") def magic_fwrite(self, arg): """ Write text out to a file. """ args = parse_argstring(magic_fwrite, arg) if args.filename is None: args.filename = args.variable filename = os.path.expanduser(args.filename) ... Here is the generated help: In [7]: %fwrite? Type: Magic function Base Class: Namespace: IPython internal File: /Users/rkern/hg/kernmagic/kernmagic/mymagics.py Definition: %fwrite(self, arg) Docstring: %fwrite [-e ENCODING] [-m MODE] variable [filename] Write text out to a file. positional arguments: variable the name of the variable filename the filename to write [default: the variable's name] optional arguments: -e ENCODING, --encoding ENCODING the encoding to use for unicode objects; no effect on str objects [default: utf-8] -m MODE, --mode MODE the file mode to use when opening the file for writing I also have a cross-platform terminal_size() function in utils.py that should probably be made part of the ipapi (hookable by GUI frontends, of course). -- 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 Nicolas.Rougier at loria.fr Sun Apr 5 06:00:16 2009 From: Nicolas.Rougier at loria.fr (Nicolas Rougier) Date: Sun, 5 Apr 2009 12:00:16 +0200 Subject: [IPython-dev] Another shell: pyglet! In-Reply-To: References: Message-ID: <4F8582E5-4E7B-409A-BF21-D674D793D77B@loria.fr> I've created a "GLiPy" (OpenGL Ipython) project on launchpad while waiting for IPython dev team approval for a possible integration. Nicolas On 3 Apr, 2009, at 19:47 , Fernando Perez wrote: > Hey folks, > > Great timing with the other Blender thread... I've just been > interacting with Nicolas Rougier, the author of this cool little > thing: > > http://www.loria.fr/~rougier/glnumpy.html > > It's beautiful and fast. Nicolas is using a lot of ipython internals, > the kind of thing that is likely to break as our APIs evolve and we > develop a stable public one. So it would be a lot easier if we were > to ship this together with ipython, maintain it with the rest of the > frontends, etc. I think it's still at the level of being a small > useful component more than a full-fledged shell, but having it in our > 'lab', with the contributions of the rest of the team, might help it > grow quickly. Nicolas has made a fantastic start here, and I'd really > like to see this kind of tool be available (for those who want OpenGL) > out of the box with the project. > > Opinions? > > Nicolas, if this is to move forward, I just saw that your code is GPL > licensed so far. IPython is all BSD, so I don't know if you'd be > willing to relicense it for inclusion in IPython. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From Nicolas.Rougier at loria.fr Mon Apr 6 10:10:04 2009 From: Nicolas.Rougier at loria.fr (Nicolas Rougier) Date: Mon, 6 Apr 2009 16:10:04 +0200 Subject: [IPython-dev] IPython 0.9.1 and sys.stdin Message-ID: Hi, I've question regarding stdin ipython handling. If I try to run interactively the following script: import sys #import IPython class TerminalIn: def __init__(self): pass def close(self): pass flush = close def isatty(self): return True def read(self, a): return self.readline() def readline(self): return '"q"' def readlines(self): return [] def write(self, s): return None def writelines(self, l): return None sys.stdin = TerminalIn() and then type 'help()' in the console, depending on the IPython import, I get different results. If I do not include IPython, the help exists immediately (as expected) while if I import IPython, the help does not exit immediately, making me think that IPython is changing something without any kind of warning. Nicolas From ellisonbg.net at gmail.com Mon Apr 6 20:29:21 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 6 Apr 2009 17:29:21 -0700 Subject: [IPython-dev] iptest and the nasty twisted bug In-Reply-To: References: Message-ID: <6ce0ac130904061729u39281280j12108cda2c0b4ddb@mail.gmail.com> Ooops, didn't see this until now. > I've spent hours trying to fix the interaction between twisted and > ipdoctest, to no avail. ?I have no clue what's going on, the problem > is intermittent and makes no sense to me. ?But what I realized is that > at least us developers have a simple, if clunky, workaround so that we > can run ?the test suite by default in a twisted-robust way, while also > running with full ipdoctest support. We should talk at some point, I can probably help figure out what is going on. > If you now run: > > iptest [any options] [any submodules] > > it will ?NOT load ipdoctest but won't cause any Twisted problems. That is good. > Once you're happy that you didn't break Twisted, run > > iptest --with-ipdoctest [any options] [any submodules] > > This MAY give a Twisted AlreadyCalledError exception at the end, but > it will also correctly load up all of the ipython-specific tests and > doctests. I think this is a pretty good compromise for now until we can really solve the underlying problem. We need to make sure that all the devs understand this though. My only hesitance is that I don't want devs to get used to see Twisted related problems. This makes it much more difficult to detect Twisted related bug when they first show up. Let's at least keep bug report active on this. > The above can be made easier with a trivial ?shell ?alias > > alias iptest2='iptest --with-ipdoctest' > > > So that you can run > > iptest ... > # Twisted happy > iptest2 ... > # ignore possible Twisted error, this checks all the rest. > I know this is not ideal, but at least it does give us a way to run > all the proper IPython tests and doctests. ?I have not the foggiest > idea how that error in Twisted is occurring: I'm not a Twisted expert, > and the behavior is both intermittent and, to me, nonsensical. ?The > ipdoctest plugin in principle doesn't do anything with Twisted or any > global state (its changes to global state are happening anyway even > now, so that's not the problem). ?I'm completely puzzled ?by this. Yep, these things are impossible to debug. We will basically need to find the problem by simply reading the code :-) > **** But it is CRITICAL that all developers run the full suite with > --with-ipdoctest ALWAYS before committing code ?**** > > It may be annoying to have to run ?the test suite twice, but that's > the only way we can get test coverage of ipython magics and > extensions. ?In my branch there are already 90 more tests picked up > this way, and this is only bound to grow as we add ipython-specific > tests. ?So these MUST be always run. +1 on running it both ways. > I'd love to find a cleaner solution, ?and I'm sure we will eventually. > ?But for now, this is how it will need to be done... Great, thanks for working through some of this! Brian > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From fperez.net at gmail.com Tue Apr 7 13:56:16 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 7 Apr 2009 10:56:16 -0700 Subject: [IPython-dev] Nasty, nasty references bug In-Reply-To: References: Message-ID: Hi all, On Sat, Apr 4, 2009 at 9:23 PM, Fernando Perez wrote: > Hi all, > > https://bugs.launchpad.net/ipython/+bug/269966 has proven to be a > rather unpleasant little beast. > > I've attached here a file that explains in great detail the problem > and illustrates it even without using ipyton at all. ?The issue, at > heart, has to do with how the Python VM tears down module objects when > they go out of scope. ?I suspect the module teardown machinery is > allowed to be so aggressive (it takes a rather Jack the Ripper > approach to the objects contained in a module, without any regard for > their reference count) because in normal use, modules are only deleted > at interpreter shutdown. ?By that point all politeness tends to be > cast overboard and the interpreter just goes on a rampage on anything > it finds in memory. OK, this proved to be rather painful, but I think that I have something that works. I was able to add some tests to the suite that fail under this particular error, and then implemented a solution I'd thought of on Friday but hadn't had the chance to try: https://code.launchpad.net/~fdo.perez/ipython/trunk-dev It's not particularly elegant, but it's better than any alternative I can think of. I basically made the module where %run executes be created only once, but I clear its __dict__ and cache that contents on each invocation. Having that object NOT be a true module breaks inspect (and we'd have to monkeypatch it, which we've done in the past but has its own share of problems). But if it's a real module that is allowed to be deleted, then Python's Jack the Module Ripper kicks in and leaves us with broken references. So my idea was to avoid both: it's a real module, it's never deleted, but its execution namespace is cleared and cached elsewhere as a normal dict. It's a bit of a tap dance to make it all work, but I made it all internal to the object so external users (see the changes to %run) only see a civilized API. This was massively problematic, because either form of the bug was a real problem: - uncontrolled memory leak on %run - broken references on successive uses of %run I do think that now we have a real solution. Once the changes are reviewed so I can merge them, I'd appreciate everyone who is willing to run from trunk to let us know if they see any problems with heavy use of %run. I think this was the other major blocker we had (given that we also have an ugly-but-usable workaround for the ipdoctest/twisted issue). I have some urgent things at work for the next 2 days so I'll be mostly offline, but I'll do my best to review all pending branches so we can put an RC out for 0.10. Sorry this took so long, but these two bugs (the ipdoctest/twisted and the references one) were truly horrid. Cheers, f From fperez.net at gmail.com Tue Apr 7 14:11:53 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 7 Apr 2009 11:11:53 -0700 Subject: [IPython-dev] Using argparse for %magics In-Reply-To: References: Message-ID: On Sun, Apr 5, 2009 at 1:50 AM, Robert Kern wrote: > I have updated my personal collection of %magics today: > > ? http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/kernmagic > > Not all of them are aimed at inclusion into IPython proper, but I think most of > them would be useful as Extensions, at least. Here are all of the collected > docstrings: > > > http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/kernmagic/raw-file/tip/help.txt > > The recently added magics are > > ? %push_err/%pop_err for controlling numpy's error handling options via a > stack. These complement %push_print/%pop_print, which control numpy's printing > options the same way. > > ? %print_methods (optional alias %pm) for printing the methods of an object, > grouped by the defining class. > > ? %print_traits (optional alias %pt) for printing the traits of a HasTraits > object, grouped by the defining class. Crazy-useful. > > One thing you might want to consider for IPython proper is the mini-framework I > use for parsing the arguments. I made some decorators which use argparse (now in > IPython.externals, amen) to build parsers for those magics that take CLI-style > --options. It's nicely declarative and makes the option parsing and help text > style uniform across all of the magics. We've discussed having a standard for > all of the --option-taking %magics that come with IPython, and I put this > forward as an improvement over the current manual getopt code. Just an initial reply before we dive into this, since I'm going semi-offline for a couple of days. +1 to argparse for this, as long as we carry it (not as a separate dependency). I've been thinking about cleaning up the magics as part of the core reorg Brian will work on soon, and this would fit nicely into that idea. Cheers, f From robert.kern at gmail.com Tue Apr 7 14:51:38 2009 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 07 Apr 2009 13:51:38 -0500 Subject: [IPython-dev] Using argparse for %magics In-Reply-To: References: Message-ID: On 2009-04-07 13:11, Fernando Perez wrote: > +1 to argparse for this, as long as we carry it (not as a separate > dependency). You already carry it in IPython.externals. -- 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 Tue Apr 7 19:46:40 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 7 Apr 2009 16:46:40 -0700 Subject: [IPython-dev] IPython 0.9.1 and sys.stdin In-Reply-To: References: Message-ID: On Mon, Apr 6, 2009 at 7:10 AM, Nicolas Rougier wrote: > > Hi, > > I've question regarding stdin ipython handling. If I try to run > interactively the following script: > > import sys > #import IPython > > class TerminalIn: > ? ? def __init__(self): ?pass > ? ? def close(self): ? ? pass > ? ? flush = close > ? ? def isatty(self): ? ?return True > ? ? def read(self, a): ? return self.readline() > ? ? def readline(self): ?return '"q"' > ? ? def readlines(self): return [] > ? ? def write(self, s): ?return None > ? ? def writelines(self, l): return None > > sys.stdin = TerminalIn() > > and then type 'help()' in the console, depending on the IPython > import, I get different results. If I do not include IPython, the help > exists immediately (as expected) while if I import IPython, the help > does not exit immediately, making me think that IPython is changing > something without any kind of warning. Mmh, I'm not quite finding right now exactly what it is that may be changing. For one thing, ipython does load help() by itself in ipmaker, but this is just the same _Helper object that plain python uses: # Put 'help' in the user namespace try: from site import _Helper IP.user_ns['help'] = _Helper() except ImportError: warn('help() not available - check site.py') You may also try to manually make changes in genutils.py, where the system-wide Term object is created: class IOTerm: """ Term holds the file or file-like objects for handling I/O operations. These are normally just sys.stdin, sys.stdout and sys.stderr but for Windows they can can replaced to allow editing the strings before they are displayed.""" # In the future, having IPython channel all its I/O operations through # this class will make it easier to embed it into other environments which # are not a normal terminal (such as a GUI-based shell) def __init__(self,cin=None,cout=None,cerr=None): self.cin = IOStream(cin,sys.stdin) self.cout = IOStream(cout,sys.stdout) self.cerr = IOStream(cerr,sys.stderr) # Global variable to be used for all I/O Term = IOTerm() In principle this is just a wrapper, but it might be causing some side effects... Just some starting pointers, not a full solution I'm afraid. Cheers, f From Nicolas.Rougier at loria.fr Wed Apr 8 02:13:36 2009 From: Nicolas.Rougier at loria.fr (Nicolas Rougier) Date: Wed, 08 Apr 2009 08:13:36 +0200 Subject: [IPython-dev] IPython 0.9.1 and sys.stdin In-Reply-To: References: Message-ID: <1239171216.6374.1.camel@sulfur.loria.fr> Thanks, I found a work-around by first redirecting stdin and then import IPython but I did not find where exactly IPython messes with stdin. Nicolas On Tue, 2009-04-07 at 16:46 -0700, Fernando Perez wrote: > On Mon, Apr 6, 2009 at 7:10 AM, Nicolas Rougier > wrote: > > > > Hi, > > > > I've question regarding stdin ipython handling. If I try to run > > interactively the following script: > > > > import sys > > #import IPython > > > > class TerminalIn: > > def __init__(self): pass > > def close(self): pass > > flush = close > > def isatty(self): return True > > def read(self, a): return self.readline() > > def readline(self): return '"q"' > > def readlines(self): return [] > > def write(self, s): return None > > def writelines(self, l): return None > > > > sys.stdin = TerminalIn() > > > > and then type 'help()' in the console, depending on the IPython > > import, I get different results. If I do not include IPython, the help > > exists immediately (as expected) while if I import IPython, the help > > does not exit immediately, making me think that IPython is changing > > something without any kind of warning. > > Mmh, I'm not quite finding right now exactly what it is that may be > changing. For one thing, ipython does load help() by itself in > ipmaker, but this is just the same _Helper object that plain python > uses: > > # Put 'help' in the user namespace > try: > from site import _Helper > IP.user_ns['help'] = _Helper() > except ImportError: > warn('help() not available - check site.py') > > > You may also try to manually make changes in genutils.py, where the > system-wide Term object is created: > > class IOTerm: > """ Term holds the file or file-like objects for handling I/O operations. > > These are normally just sys.stdin, sys.stdout and sys.stderr but for > Windows they can can replaced to allow editing the strings before they are > displayed.""" > > # In the future, having IPython channel all its I/O operations through > # this class will make it easier to embed it into other environments which > # are not a normal terminal (such as a GUI-based shell) > def __init__(self,cin=None,cout=None,cerr=None): > self.cin = IOStream(cin,sys.stdin) > self.cout = IOStream(cout,sys.stdout) > self.cerr = IOStream(cerr,sys.stderr) > > # Global variable to be used for all I/O > Term = IOTerm() > > > In principle this is just a wrapper, but it might be causing some side > effects... > > Just some starting pointers, not a full solution I'm afraid. > > Cheers, > > f From gael.varoquaux at normalesup.org Wed Apr 8 05:02:07 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 8 Apr 2009 11:02:07 +0200 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> Message-ID: <20090408090207.GB23867@phare.normalesup.org> On Tue, Mar 31, 2009 at 02:34:53PM -0700, Brian Granger wrote: > Hi, > Things have gone quite for a while now and I wanted to see where we > stand on getting ready for 0.10. There are 7 merge proposals listed > here: > https://code.launchpad.net/ipython/+activereviews > Of these 4 seem to be in process and 3 are in need of review. > What is the status of the 4 branches that have already been reviewed, > but are in need to fixing and/or further review? > Of the 3 branches that need review, which are targeted for 0.10? I have just added my branch for review. I'd like it to be merged for 0.10. I have worked on QAing it a week ago. It probably is not perfect, and I have some time currently to act upon reviews, but I don't think it has big holes. Cheers, Ga?l From gael.varoquaux at normalesup.org Wed Apr 8 05:08:28 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 8 Apr 2009 11:08:28 +0200 Subject: [IPython-dev] Status of pre-0.10 reviews and merges (fwd) Message-ID: <20090408090828.GD23867@phare.normalesup.org> Damn, wrong reply button. ----- Forwarded message from Gael Varoquaux ----- Date: Wed, 8 Apr 2009 11:03:21 +0200 From: Gael Varoquaux To: Hans Meine Subject: Re: [IPython-dev] Status of pre-0.10 reviews and merges On Thu, Apr 02, 2009 at 10:26:24AM +0200, Hans Meine wrote: > On Wednesday 01 April 2009 19:37:03 J?rgen Stenarson wrote: > > All uses of from xx import * should be removed. This is one refactoring > > that would really benefit from good test coverage. > You know about pyflakes, do you? It is one of my favorite discoverings and > covers this refactoring step very well. +1 for pyflakes to. It rocks. I do a for file in **/*.py do pyflakes $file done every once in a while in the codebases I maintain. Ga?l ----- End forwarded message ----- From fperez.net at gmail.com Wed Apr 8 13:56:24 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 8 Apr 2009 10:56:24 -0700 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: <6ce0ac130904022006i98b7c91w663d54a6feaeb004@mail.gmail.com> References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> <6ce0ac130904022006i98b7c91w663d54a6feaeb004@mail.gmail.com> Message-ID: On Thu, Apr 2, 2009 at 8:06 PM, Brian Granger wrote: >> I can't review the branch on launchpad since I am not a part of the group. > > Fernando, can we add Vishal to the team? Sorry, I'd missed this. I'm more than happy to add Vishal, with the caveat to request that you (Vishal) do not merge into trunk at all. As we use LP more and more and we settle into a good pattern for usage, it becomes clearer to me that we can be reasonably liberal with team membership, simply because it makes code review and collaboration easier. I also don't want anyone to feel 'second class' regarding the project, after all that's the whole point of using a DVCS and the launchpad machinery. But I do want to make sure that only those who are *very* familiar with the workflow and the tools merge directly into trunk. If nothing else, because it's unfortunately far too easy to make a small mistake in how you did your merges and mess up the history, as it happened to all of us when we first transitioned to LP. So as long as new team members can assure us that you will only write to things like code reviews and specific branches where certain features may be worked on by others, letting the final pushes into trunk itself to the long-term members of the team, that's not a problem. If this ever becomes an issue we could address it by making a separate '~ipython-trunk' team only for trunk merges, but I'd rather just have an informal policy for this. Cheers, f From fperez.net at gmail.com Wed Apr 8 14:03:53 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 8 Apr 2009 11:03:53 -0700 Subject: [IPython-dev] Fwd: Status of pre-0.10 reviews and merges In-Reply-To: <6ce0ac130904022009x3d289774kf9947826390409aa@mail.gmail.com> References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> <49D3A5E2.7070802@bostream.nu> <6ce0ac130904022009x57b0652fged9ae33a2d426619@mail.gmail.com> <6ce0ac130904022009x3d289774kf9947826390409aa@mail.gmail.com> Message-ID: On Thu, Apr 2, 2009 at 8:09 PM, Brian Granger wrote: > ---------- Forwarded message ---------- > From: Brian Granger > Date: Thu, Apr 2, 2009 at 8:09 PM > Subject: Re: [IPython-dev] Status of pre-0.10 reviews and merges > To: J?rgen Stenarson > > >> Some random thoughts on the refactoring process: >> >> When working on the genutils.py patch I thought that it would be nice to >> have smaller module files because it is somewhat difficult to navigate huge >> modules and sometimes it can be difficult to guess in what module I should >> look for some function. > > Yes, partitioning large modules like genutils into more logical > modules is part of my reorganization plans. ?Details to follow. > >> All uses of from xx import * should be removed. This is one refactoring that >> would really benefit from good test coverage. > > Definitely! I should add that genutils is probably the biggest offender, and it's because it was the code I wrote earliest in ipython's history as a giant dump-bucket of everything I needed. It's also by now the *only* one from which there's ever an 'import *' in our code base. A while ago I did a first import/entanglement cleanup pass on ipython and I managed to break most of the worst hairballs we had, being left only with two things: - 'from genutils import *'. I realized there was so much of this in untested codepaths, that if I changed it to explicit imports the bugs might only appear for users in the end. Perhaps now with pyflakes we could more easily change this to something like 'import genutils as util' and let pyflakes tell us where all the problems are, I don't know (I need to get my pyflakes-fu up to speed). - Magics being bolted into the main object. This needs to go, obviously, I was just afraid to completely cut the cord (again, lack of tests). But now all magics at least refer to the shell object via self.shell rather than directly by doing self.* (which they could, since right now the magic stuff is in the main object). So cutting this particular cord shouldn't actually be that hard. I'm *so* happy to see this finally being tackled, though! Cheers, f From robert.kern at gmail.com Wed Apr 8 15:06:43 2009 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 08 Apr 2009 14:06:43 -0500 Subject: [IPython-dev] Fwd: Status of pre-0.10 reviews and merges In-Reply-To: References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> <49D3A5E2.7070802@bostream.nu> <6ce0ac130904022009x57b0652fged9ae33a2d426619@mail.gmail.com> <6ce0ac130904022009x3d289774kf9947826390409aa@mail.gmail.com> Message-ID: On 2009-04-08 13:03, Fernando Perez wrote: > - 'from genutils import *'. I realized there was so much of this in > untested codepaths, that if I changed it to explicit imports the bugs > might only appear for users in the end. Perhaps now with pyflakes we > could more easily change this to something like 'import genutils as > util' and let pyflakes tell us where all the problems are, I don't > know (I need to get my pyflakes-fu up to speed). Yes, absolutely. This is very safe unless if you have a function with the same name as a builtin (e.g. numpy.sum has bitten me in the past). -- 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 Wed Apr 8 15:22:05 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 8 Apr 2009 12:22:05 -0700 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: <6ce0ac130904022004l35ff5184u922be556c82dd2dc@mail.gmail.com> References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> <6ce0ac130904022004l35ff5184u922be556c82dd2dc@mail.gmail.com> Message-ID: On Thu, Apr 2, 2009 at 8:04 PM, Brian Granger wrote: > The big things we need to look at are: > > * If ipdoctest is picking up things that should really be run as tests > that are somehow using twisted, but not in an officially "good" way > * If there are globals that both twisted.trial and ipdoctest is > mucking with that would be a problem. > * The reactor is being started twice. ?That is very odd, but could > help us debug this. > > I think this will take both of us to tackle. ?My idea is to start > disabling parts of ipdoctest, or run the test suite on small parts of > the codebase to try to isolate where the problem is coming from. After all the time I spent on this one, I think we should for now leave it, since we have an ugly but functional workaround. Given how little explicit coupling there is between the two things, I suspect that this will require making a specific branch (to be thrown away when done) where we start deleting *tests* until we find which one is causing this. I suspect that it's not the one that raises the error but something else up the chain instead. >> I know we've talked a bit about this, but before we get started on >> this major reorganization, let's make sure we do plan it carefully. >> For better or worse, while ipython is formally 'pre 1.0' and as such, >> all API changes are in principle fair game, we need to ensure we find >> a good balance of practicality vs purity. ?Just like numpy kept some >> Numeric-inspired baggage that wasn't ideal so that users could >> transition without unnecessary pain, we should keep the same ideas in >> mind. ?We should obviously fix the major messes we have (ipmaker is >> ridiculous, 3 config systems is crazy, etc), but we should also be >> willing to tolerate small warts if they make existing user's lives >> easier. > > I am trying to distinguish between users and developer_users. ?For > users, I strongly agree that IPython shouldn't really change, or if it > does, in a very limited manner that improves things drastically (like > the config system). ?For developers though, we need to allow much more > freedom in changing APIs. ?We won't be able to do the work without it. > ?But, even there, I agree that we should only change an API when we > really need to. Yup, I'm sure in the end we actually see things very similarly. > But...,the first things I will be working on will be pretty different > from the types of changes you are talking about here. ?Basically, I am > going to do a massive module/package reorganization. ?A draft of the > idea is this... > > I am going to reorganize the top-level modules into logical > subpackages. ?I am also going to use this as an opportunity to: > > * Identify rotting and broken code and move it to a directory (I won't > delete it....yet) where everyone can look at the code and decide if we > want to revive it (with tests+docs) or simply kill it for good. > > * Renaming modules and packages to pep 8 style lowercase.py > > * Adding tests to make sure that every moved/renamed module and > package is importable (yeh, tests!!!) and working. > > * Where it is appropriate, begin to partition large modules (iplib, > genutils, etc.) into smaller more logic submodules to make them easier > to refactor and work with. > > * For really public facing developer APIs, I will put in a > compatibility layer with deprecation warnings. Big +1 to this. By the way, in the disentagling front, keep in mind my earlier comments about the biggest problems to fix being: - ipmaker/iplib: ipmaker is kind of a 'super __init__' mess that needs to disappear, folding it into iplib while making the lot be rational/comprehensible. - genutils - making magics standalone I hope these pointers help you a bit. > The only thing that will change in the actual code though will be > import statements and all of this will be tested. ?No API changes will > be combined with this reorganization work. ?This reorganization is > needed to help us really identify and isolate the things that need to > be refactored moving forward > > But, because this work will move *everything* around, it will be > difficult to merge branches back in in an automatic way. ?By hand > though it might not be too bad to merge things. > >> Part of that is communicating a plan for the breakage to everyone in >> advance, so that feedback can be provided by all affected before >> anything irreversible has happened. > > Yes, I will absolutely ask for feedback about these plans before > starting. ?I am working on an IPEP (IPython Enhancement Proposal) that > describes my plans. ?More details to follow soon... > >> Furthermore, I'd like to suggest that post 0.10 we hold a 'bug and >> test weeks' (2-4 max) to see if we could do an 0.11 release where we >> basically try to *only* fix existing tickets and add as many tests as >> we can, before starting to do major API breakage. > > In theory this is a great idea. ?In practice this timescale will cause > problems with the work I need to do. ?I currently have funding that > ends May 1 to work on this and I need to get started immediately. ?It > is so rare to have dedicated time and $ for this, I don't want to > waste the opportunity. ?That is basically 4 weeks away. ?In reality, I > think I should soon just "go for it" and help people to do their > merges into my branch by hand. No problem. Honestly we need this so badly, that it would be madness from my part to get in the way. So fire away :) One suggestion: because LP only allows code reviews from logged in users/ team members, let's have the bulk of this design discussion on list rather than on LP. I also like better having this archived on our main mailing list for searching, etc. Once we get into actual code reviews for merging, we can leave that to happen on LP. Cheers, f From ellisonbg.net at gmail.com Wed Apr 8 17:22:10 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 8 Apr 2009 14:22:10 -0700 Subject: [IPython-dev] Status of pre-0.10 reviews and merges In-Reply-To: References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> <6ce0ac130904022004l35ff5184u922be556c82dd2dc@mail.gmail.com> Message-ID: <6ce0ac130904081422m48162595q7541ca65a81fb2f9@mail.gmail.com> >> I think this will take both of us to tackle. ?My idea is to start >> disabling parts of ipdoctest, or run the test suite on small parts of >> the codebase to try to isolate where the problem is coming from. > > After all the time I spent on this one, I think we should ?for now > leave it, since we have an ugly but functional workaround. ?Given how > little explicit coupling there is between the two things, I suspect > that this will require making a specific branch (to be thrown away > when done) where we start deleting *tests* until we find which one is > causing this. ?I suspect that it's not the one that raises the error > but something else up the chain instead. Yes, let's take a break from this. >> * For really public facing developer APIs, I will put in a >> compatibility layer with deprecation warnings. > > Big +1 to this. ?By the way, in the disentagling front, keep in mind > my earlier comments about the biggest problems to fix being: I will need some help identifying the main developer APIs that need to be handled in this way. Although, I am hoping that as I dive in, it will become obvious. > - ipmaker/iplib: ipmaker is kind of a 'super __init__' mess that needs > to disappear, folding it into iplib while making the lot be > rational/comprehensible. I might wait to do this until I am tacking the issue of removing the various threading shells. > - genutils > > - making magics standalone > I hope these pointers help you a bit. Yep! >> The only thing that will change in the actual code though will be >> import statements and all of this will be tested. ?No API changes will >> be combined with this reorganization work. ?This reorganization is >> needed to help us really identify and isolate the things that need to >> be refactored moving forward >> >> But, because this work will move *everything* around, it will be >> difficult to merge branches back in in an automatic way. ?By hand >> though it might not be too bad to merge things. >> >>> Part of that is communicating a plan for the breakage to everyone in >>> advance, so that feedback can be provided by all affected before >>> anything irreversible has happened. >> >> Yes, I will absolutely ask for feedback about these plans before >> starting. ?I am working on an IPEP (IPython Enhancement Proposal) that >> describes my plans. ?More details to follow soon... >> >>> Furthermore, I'd like to suggest that post 0.10 we hold a 'bug and >>> test weeks' (2-4 max) to see if we could do an 0.11 release where we >>> basically try to *only* fix existing tickets and add as many tests as >>> we can, before starting to do major API breakage. >> >> In theory this is a great idea. ?In practice this timescale will cause >> problems with the work I need to do. ?I currently have funding that >> ends May 1 to work on this and I need to get started immediately. ?It >> is so rare to have dedicated time and $ for this, I don't want to >> waste the opportunity. ?That is basically 4 weeks away. ?In reality, I >> think I should soon just "go for it" and help people to do their >> merges into my branch by hand. > > No problem. ?Honestly we need this so badly, that it would be madness > from my part to get in the way. ?So fire away :) Cool. > One suggestion: because LP only allows code reviews from logged in > users/ team members, let's have the bulk of this design discussion on > list rather than on LP. ?I also like better having this archived on > our main mailing list for searching, etc. ?Once we get into actual > code reviews for merging, we can leave that to happen on LP. OK, that makes sense, I will try to keep the discussions here. Cheers, Brian > Cheers, > > f > From vishal.vatsa at gmail.com Thu Apr 9 08:27:53 2009 From: vishal.vatsa at gmail.com (Vishal Vatsa) Date: Thu, 09 Apr 2009 13:27:53 +0100 Subject: [IPython-dev] Status of pre-0.10 reviews and merges References: <6ce0ac130903311434k2584a94h6abc6d233e41bc4d@mail.gmail.com> <6ce0ac130904022006i98b7c91w663d54a6feaeb004@mail.gmail.com> Message-ID: Fernando Perez wrote: > Sorry, I'd missed this. I'm more than happy to add Vishal, with the > caveat to request that you (Vishal) do not merge into trunk at all. Thanks, I will keep away from trunk :) > As we use LP more and more and we settle into a good pattern for > usage, it becomes clearer to me that we can be reasonably liberal with > team membership, simply because it makes code review and collaboration > easier. I also don't want anyone to feel 'second class' regarding the > project, after all that's the whole point of using a DVCS and the > launchpad machinery. Yep DVCS is quite nice for this type of work. Regards, -vishal From prabhu at aero.iitb.ac.in Sat Apr 11 01:54:21 2009 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sat, 11 Apr 2009 11:24:21 +0530 Subject: [IPython-dev] Using argparse for %magics In-Reply-To: References: Message-ID: <49E0308D.9030602@aero.iitb.ac.in> On 04/07/09 23:41, Fernando Perez wrote: > On Sun, Apr 5, 2009 at 1:50 AM, Robert Kern wrote: >> I have updated my personal collection of %magics today: [...] > Just an initial reply before we dive into this, since I'm going > semi-offline for a couple of days. > > +1 to argparse for this, as long as we carry it (not as a separate > dependency). I've been thinking about cleaning up the magics as part > of the core reorg Brian will work on soon, and this would fit nicely > into that idea. Just my vote that it would be nice if these (the print_traits esp.) were available in the standard IPython. I also have a suggestion regarding magics in general. I always found IPython's timeit *much* more convenient than the standard timeit module. However, IPython's timeit is only usable from IPython and not from a standalone Python script. I think all magics (that are of use outside of IPython) ought to be refactored to be usable outside of the interactive IPython shell. I also think I have found a little bug(?) in the timeit magic implementation. Here is a patch (this is off the 0.9.1 release): --- Magic.py.orig 2009-04-11 11:14:49.000000000 +0530 +++ Magic.py 2009-04-11 11:15:15.000000000 +0530 @@ -1815,9 +1815,9 @@ # determine number so that 0.2 <= total time < 2.0 number = 1 for i in range(1, 10): - number *= 10 if timer.timeit(number) >= 0.2: break + number *= 10 best = min(timer.repeat(repeat, number)) / number The rationale is as follows. Lets say you have a function that takes 2 seconds to evaluate. With the original code you are going to run that function 10 times regardless of the fact that it already takes 2 seconds and with the original code, timing this will take at least 60 seconds (with repeat=3) which is way too much. Here is a simple test case: import time def f(): time.sleep(2) print "f" %timeit f() cheers, prabhu From fperez.net at gmail.com Tue Apr 14 02:19:41 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 13 Apr 2009 23:19:41 -0700 Subject: [IPython-dev] Using argparse for %magics In-Reply-To: <49E0308D.9030602@aero.iitb.ac.in> References: <49E0308D.9030602@aero.iitb.ac.in> Message-ID: Howdy, On Fri, Apr 10, 2009 at 10:54 PM, Prabhu Ramachandran wrote: > On 04/07/09 23:41, Fernando Perez wrote: >> >> On Sun, Apr 5, 2009 at 1:50 AM, Robert Kern wrote: >>> >>> I have updated my personal collection of %magics today: > > [...] >> >> Just an initial reply before we dive into this, since I'm going >> semi-offline for a couple of days. >> >> +1 to argparse for this, as long as we carry it (not as a separate >> dependency). ?I've been thinking about cleaning up the magics as part >> of the core reorg Brian will work on soon, and this would fit nicely >> into that idea. > > Just my vote that it would be nice if these (the print_traits esp.) were > available in the standard IPython. Yup. BTW, I meant 'as long as we continue to carry argparse ourselves', I was just clarifying that I'm happy to use it for the long haul... > I also have a suggestion regarding magics in general. ?I always found > IPython's timeit *much* more convenient than the standard timeit module. > ?However, IPython's timeit is only usable from IPython and not from a > standalone Python script. ?I think all magics (that are of use outside of > IPython) ought to be refactored to be usable outside of the interactive > IPython shell. Absolutely! I have a draft blueprint on my drive about magics, that's something that I hope we'll revisit very soon, as Brian makes headway into the core reorganization. What I hope we'll have is that the actual magics will be simple callable objects that can be instantiated and used anywhere, with the % syntax being just a bit of interactive sugar. In addition, I hope most of them will be very thin wrappers around regular functions and objects in the ipython library of utilities that can be used without ipython itself running. Some only make sense if ipython is active, and they will need an actual ipython at startup. Many others will actually be called *by* ipython but can be equally used on their own. I'm going to think a bit more about this spec and post it later... > > I also think I have found a little bug(?) in the timeit magic > implementation. ?Here is a patch (this is off the 0.9.1 release): > > --- Magic.py.orig ? ? ? 2009-04-11 11:14:49.000000000 +0530 > +++ Magic.py ? ?2009-04-11 11:15:15.000000000 +0530 > @@ -1815,9 +1815,9 @@ > ? ? ? ? ? ? # determine number so that 0.2 <= total time < 2.0 > ? ? ? ? ? ? number = 1 > ? ? ? ? ? ? for i in range(1, 10): > - ? ? ? ? ? ? ? ?number *= 10 > ? ? ? ? ? ? ? ? if timer.timeit(number) >= 0.2: > ? ? ? ? ? ? ? ? ? ? break > + ? ? ? ? ? ? ? ?number *= 10 > > ? ? ? ? best = min(timer.repeat(repeat, number)) / number > > The rationale is as follows. ?Lets say you have a function that takes 2 > seconds to evaluate. ?With the original code you are going to run that > function 10 times regardless of the fact that it already takes 2 seconds and > with the original code, timing this will take at least 60 seconds (with > repeat=3) which is way too much. ?Here is a simple test case: Many thanks! This has bothered me more than once but I'd never taken the time to track it down, that's great. I pushed it to my trunk, this will make its way into 0.10 (any day now :) Cheers, f From fperez.net at gmail.com Tue Apr 14 03:33:35 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 14 Apr 2009 00:33:35 -0700 Subject: [IPython-dev] problems building documentation with sphinx-0.6.1 In-Reply-To: References: Message-ID: Hi Darren, 2009/4/1 Darren Dale : > I upgraded to sphinx-0.6.1 this morning and ran into some trouble. I've been > trying to track down the cause, attempting to build the docs for my own > projects (segfaults), numpy (issues, expecting segfaults), h5py (segfaults), > and now ipython (issues). As of version 0.6, a tag can be provided to > sphinx-build (perhaps in a make file or python equivalent) and then we can > do, for example: > > .. only:: html > > But until IPython is ready to require >sphinx-0.6, perhaps someone could > patch only_directives.py so it is compatible with version 0.6 and later: Thanks a lot, I applied your patch so we can continue to build with old as well as newer versions. I pushed it to trunk right away, since it's so tiny and just for doc building (I did test it and indeed it fixes the problem with current sphinx). > Has anyone tried building the ipython docs lately? After applying that > patch, I try to build ipython's docs and I get an error when sphinx gets to > IPython/frontend/frontendbase: > > ------- > /usr/local/src/ipython/docs/sphinxext/docscrape.py:117: UserWarning: Unknown > section Result > ? warn("Unknown section %s" % key) > /usr/local/src/ipython/docs/sphinxext/docscrape.py:117: UserWarning: Unknown > section Parameters: > ? warn("Unknown section %s" % key) > ------- > > Followed by another error, which is probably not a concern since I don't > have wxpython, but I thought I would report it anyway: > > ------- > Exception occurred:[ 22%] api/generated/IPython.frontend.wx.console_widget > ? File "/usr/local/src/ipython/docs/sphinxext/inheritance_diagram.py", line > 107, in _import_class_or_module > ??? "Could not import class or module '%s' specified for inheritance > diagram" % name) > ValueError: Could not import class or module > 'IPython.frontend.wx.console_widget' specified for inheritance diagram > The full traceback has been saved in /tmp/sphinx-err-axFWA0.log, if you want > to report the issue to the author. > Please also report this if it was a user error, so that a better error > message can be provided next time. > Send reports to sphinx-dev at googlegroups.com. Thanks! > make: *** [html] Error 1 > ------ I see these too, thanks for reporting them. We need to make sure our test suite runs without dependencies, and we have test decorators for that. But I don't know how to put in conditional directives for doc builds. Any ideas? Cheers, f From fperez.net at gmail.com Tue Apr 14 03:35:30 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 14 Apr 2009 00:35:30 -0700 Subject: [IPython-dev] Using argparse for %magics In-Reply-To: References: Message-ID: On Tue, Apr 7, 2009 at 11:51 AM, Robert Kern wrote: > On 2009-04-07 13:11, Fernando Perez wrote: > >> +1 to argparse for this, as long as we carry it (not as a separate >> dependency). > > You already carry it in IPython.externals. Yes, as I mentioned elsewhere, I just meant that we should continue to carry it ourselves. Sloppy me... BTW, do you want any of this reviewed for 0.10? If so, I don't see it in your branch... https://code.launchpad.net/ipython/+activereviews Cheers, f From ellisonbg.net at gmail.com Tue Apr 14 15:02:48 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 14 Apr 2009 12:02:48 -0700 Subject: [IPython-dev] iptest memory leak on Mac Message-ID: <6ce0ac130904141202m3307bf10g38e2371c64e95f5e@mail.gmail.com> I just did a bzr pull from lp:ipython and am seeing the following memory issue on my Mac. This only occurs some of the time and I would be surprised if any of the recent merges _caused_ this. I am wondering if there is a subtle bug in the cocoa stuff that is now showing up. Barry, any thoughts on this one? Can you try to reproduce? Thanks, Brian bgranger$ iptest ..........S.........................................................................................................................................................................................................................2009-04-14 10:56:28.812 Python[85670:260f] *** _NSAutoreleaseNoPool(): Object 0x27f1510 of class NSCFDictionary autoreleased with no pool in place - just leaking Stack: (0x94d7573f 0x94c81e32 0x16e31ea 0x16e3435 0x16d9a92 0x96c7f5ba 0x16fa14e 0x15ebfd 0x129812 0x15ce6f 0x15ce6f 0x13e376 0x148f5f 0x14ae15 0x1b6d80 0x1b6f52 0x1b7024 0x129516 0x125f1e 0x1264b0 0x18e5e8 0x191173 0x13b488 0x121505 0x129e3a 0x121505 0x18a82d 0x12606f 0x121505 0x18f832 0x191173 0x18f79d 0x18f700 0x18f700 0x191173 0x18f79d 0x191173 0x13b488 0x121505 0x18fcd0 0x191173 0x13b488 0x121505 0x18fcd0 0x191173 0x13b488 0x121505 0x18fcd0 0x191173 0x13b488 0x121505 0x18fcd0 0x18f700 0x191173 0x13b488 0x121505 0x129e3a 0x121505 0x18a82d 0x1b788f 0x937ad095 0x937acf52) ............................................................................................................................................................................................S....S...SS..SSS.............E....SSS ====================================================================== ERROR: Test that object's __del__ methods are called on exit. ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/bgranger/Library/Python/2.5/site-packages/nose-0.10.4-py2.5.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/Users/bgranger/Documents/Computation/IPython/Code/ipython/IPython/tests/test_magic.py", line 85, in test_obj_del out = _ip.IP.getoutput('ipython %s' % del_file) File "/Users/bgranger/Documents/Computation/IPython/Code/ipython/IPython/iplib.py", line 694, in verbose=self.rc.system_verbose) File "/Users/bgranger/Documents/Computation/IPython/Code/ipython/IPython/genutils.py", line 411, in getoutput output = os.popen(cmd).read() IOError: [Errno 4] Interrupted system call ---------------------------------------------------------------------- Ran 450 tests in 60.574s FAILED (SKIP=11, errors=1) From fperez.net at gmail.com Tue Apr 14 17:59:26 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 14 Apr 2009 14:59:26 -0700 Subject: [IPython-dev] iptest memory leak on Mac In-Reply-To: <6ce0ac130904141202m3307bf10g38e2371c64e95f5e@mail.gmail.com> References: <6ce0ac130904141202m3307bf10g38e2371c64e95f5e@mail.gmail.com> Message-ID: On Tue, Apr 14, 2009 at 12:02 PM, Brian Granger wrote: > I just did a bzr pull from lp:ipython and am seeing the following > memory issue on my Mac. ?This only occurs some of the time and I would > be surprised if any of the recent merges _caused_ this. ?I am > wondering if there is a subtle bug in the cocoa stuff that is now > showing up. > > Barry, any thoughts on this one? ?Can you try to reproduce? Ouch. I obviously never saw those, since I don't have OSX to test on... Cheers, f From robert.kern at gmail.com Tue Apr 14 18:00:23 2009 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 14 Apr 2009 17:00:23 -0500 Subject: [IPython-dev] Using argparse for %magics In-Reply-To: References: Message-ID: <3d375d730904141500x5308d42en202eac886a442800@mail.gmail.com> On Tue, Apr 14, 2009 at 02:35, Fernando Perez wrote: > On Tue, Apr 7, 2009 at 11:51 AM, Robert Kern wrote: >> On 2009-04-07 13:11, Fernando Perez wrote: >> >>> +1 to argparse for this, as long as we carry it (not as a separate >>> dependency). >> >> You already carry it in IPython.externals. > > Yes, as I mentioned elsewhere, I just meant that we should continue to > carry it ourselves. ?Sloppy me... > > BTW, do you want ?any of this reviewed for 0.10? ?If so, ?I don't see > it in your branch... > > https://code.launchpad.net/ipython/+activereviews I wanted to float the idea before spending time integrating things into IPython. I would wait for 0.11 for most of it. There are lots of different pieces that should probably integrated at different times and in different ways. The argparse stuff should probably be done with the greater %refactor. There are some of my magics that should go into Extensions, and maybe a few that should go into the main Magic.py; integrating these before the %refactor would involve adding the magic_arguments stuff in support, but explicitly "deprecated" for external use. The terminal_size() utility could probably be added to ipapi (hookble for GUIs to override, of course) immediately. Which of my magics would you want for 0.10? and where (in Magic.py or Extensions/)? I doubt it's worth holding up 0.10 if it's getting close. -- 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 ellisonbg.net at gmail.com Tue Apr 14 19:21:52 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 14 Apr 2009 16:21:52 -0700 Subject: [IPython-dev] Tagging tickets as "Incomplete" Message-ID: <6ce0ac130904141621s31e6ed1fs2c6de40002c2a36f@mail.gmail.com> Hi, I have been going through tickets today on launchpad. One issue that I want to bring up is how we are tagging the tickets. One class of tickets that I keep running into are tickets that are neither "New" or "Confirmed" Basically, this happens when we can't reproduce the bug, bug we aren't ready to give up. I have started to tag these tickets as "Incomplete" as in "we have incomplete information so we can't do anything further. Let's try to keep the "New" category for tickets that we haven't looked at yet. Cheers, Brian From fperez.net at gmail.com Tue Apr 14 20:17:07 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 14 Apr 2009 17:17:07 -0700 Subject: [IPython-dev] Tagging tickets as "Incomplete" In-Reply-To: <6ce0ac130904141621s31e6ed1fs2c6de40002c2a36f@mail.gmail.com> References: <6ce0ac130904141621s31e6ed1fs2c6de40002c2a36f@mail.gmail.com> Message-ID: On Tue, Apr 14, 2009 at 4:21 PM, Brian Granger wrote: > Hi, > > I have been going through tickets today on launchpad. ?One issue that > I want to bring up is how we are tagging the tickets. ?One class of > tickets that I keep running into are tickets that are neither "New" or > "Confirmed" ?Basically, this happens when we can't reproduce the bug, > bug we aren't ready to give up. ?I have started to tag these tickets > as "Incomplete" as in "we have incomplete information so we can't do > anything further. > > Let's try to keep the "New" category for tickets that we haven't looked at yet. Thanks! And +1 on the approach. Cheers, f From Nicolas.Rougier at loria.fr Wed Apr 15 04:35:04 2009 From: Nicolas.Rougier at loria.fr (Nicolas Rougier) Date: Wed, 15 Apr 2009 10:35:04 +0200 Subject: [IPython-dev] glipy, OpenGL IPython terminal with numpy support Message-ID: <1239784504.4307.2.camel@sulfur.loria.fr> Hello, I've setup a launchpad glipy project: https://launchpad.net/glipy as well as a rudimentary homepage: http://webloria.loria.fr/~rougier/glipy/ for those who want to test it. It is still an early beta version and may be plenty of bugs... Nicolas From fperez.net at gmail.com Wed Apr 15 04:36:43 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Apr 2009 01:36:43 -0700 Subject: [IPython-dev] Tag and branch 0.10 soon? Message-ID: Hi all, it's easier to work off of trunk, but Brian does have a window of time right now to hack on trunk harder in terms of aggressive reorganization. I just went ahead and made an 0.10 series: https://launchpad.net/ipython/0.10 that has a release milestone as well: https://launchpad.net/ipython/+milestone/0.10 This lets us target bug reports Here's the code pending to be merged: https://code.launchpad.net/ipython/+activereviews Options: 1. we tag/branch 0.10 pretty much now and those pending reviews get retargeted for the branch. 2. tag now, but keep the reviews for trunk. 3. other ideas? My main worry with #2 is Brian's chance to do full-on reorg work, that I'd prefer to avoid delaying much further. But if the remaining merges are done in a branch and a massive amount of moving around is done, they will be effectively lost since it won't be easy to apply them into a very restructured trunk. Some of the pending stuff is pretty easy, so if people have a little bit of time, we could probably merge most of this in a couple of days. We can then get 0.10 out the door, with minimal/no loss of work for the reorganization. Then we could all provide feedback on the reorg work (I'm unlikely to do any actual major work on it, but hope to provide feedback) Thoughts? f ps - I also made 0.11 series/milestones: https://launchpad.net/ipython/0.11 https://launchpad.net/ipython/+milestone/0.11 as a placeholder. I'm thinking we might end up calling this 0.50 or something larger to indicate the api breaks and an actual move to 1.0 status though, so this should be for now considered temporary. We'll see in a few days when 0.10 is out... From fperez.net at gmail.com Wed Apr 15 04:39:16 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Apr 2009 01:39:16 -0700 Subject: [IPython-dev] glipy, OpenGL IPython terminal with numpy support In-Reply-To: <1239784504.4307.2.camel@sulfur.loria.fr> References: <1239784504.4307.2.camel@sulfur.loria.fr> Message-ID: Hi Nicolas, On Wed, Apr 15, 2009 at 1:35 AM, Nicolas Rougier wrote: > > > Hello, > > I've setup a launchpad glipy project: > https://launchpad.net/glipy > > as well as a rudimentary homepage: > http://webloria.loria.fr/~rougier/glipy/ > Great! I'm sorry not to have provided good feedback yet, I've just used up my available bandwidth for ipython on trunk/reviews/0.10 work now. This is a good place to keep it for now, but I hope that as soon as we clear the plate with the release and Brian moves the files around, we can pull your code in with a new stable structure... So I hope we won't annoy you too much by not giving enough feedback... Cheers, f From gael.varoquaux at normalesup.org Wed Apr 15 04:59:13 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 15 Apr 2009 10:59:13 +0200 Subject: [IPython-dev] Tag and branch 0.10 soon? In-Reply-To: References: Message-ID: <20090415085913.GE5058@phare.normalesup.org> On Wed, Apr 15, 2009 at 01:36:43AM -0700, Fernando Perez wrote: > Thoughts? I probably won't have any time until the week end, wrt to my pending merge. Sorry. Ga?l From gokhansever at gmail.com Wed Apr 15 08:57:03 2009 From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_SEVER?=) Date: Wed, 15 Apr 2009 07:57:03 -0500 Subject: [IPython-dev] glipy, OpenGL IPython terminal with numpy support In-Reply-To: <1239784504.4307.2.camel@sulfur.loria.fr> References: <1239784504.4307.2.camel@sulfur.loria.fr> Message-ID: <49d6b3500904150557j4c645361r1b6fc7cd6e6f14f0@mail.gmail.com> Hi Nicolas, You may need to revise the examples in /examples directory because out of 4 examples non work in my system (Fedora 10 2.6.27.19-170.2.35.fc10.i686.PAE #1 SMP Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) [GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2 IPython 0.10.bzr.r1163) Here are the error messages that I encounter: [gsever at ccn examples]$ python colorbars.py ? File "colorbars.py", line 25 ??? fig = figure(*items, height=25, cmap=colormap.IceAndFire) ????????????????????????????? ^ SyntaxError: invalid syntax [gsever at ccn examples]$ python cube.py Traceback (most recent call last): ? File "cube.py", line 121, in ??? c = cube() ? File "cube.py", line 116, in cube ??? terminal.insert(c) NameError: global name 'terminal' is not defined [gsever at ccn examples]$ python figure.py File "figure.py", line 34 fig = figure(*items, height=300, cmap=cmap) ^ SyntaxError: invalid syntax [gsever at ccn examples]$ python screenshots.py Traceback (most recent call last): File "screenshots.py", line 18, in fig = figure(z1) NameError: name 'figure' is not defined Interestingly, examples were working when I tested glipy in its very first days. Thanks for this nice tool. G?khan On Wed, Apr 15, 2009 at 3:35 AM, Nicolas Rougier wrote: > > > Hello, > > I've setup a launchpad glipy project: > https://launchpad.net/glipy > > as well as a rudimentary homepage: > http://webloria.loria.fr/~rougier/glipy/ > > > for those who want to test it. It is still an early beta version and may > be plenty of bugs... > > > Nicolas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From Nicolas.Rougier at loria.fr Wed Apr 15 09:13:43 2009 From: Nicolas.Rougier at loria.fr (Nicolas Rougier) Date: Wed, 15 Apr 2009 15:13:43 +0200 Subject: [IPython-dev] glipy, OpenGL IPython terminal with numpy support In-Reply-To: <49d6b3500904150557j4c645361r1b6fc7cd6e6f14f0@mail.gmail.com> References: <1239784504.4307.2.camel@sulfur.loria.fr> <49d6b3500904150557j4c645361r1b6fc7cd6e6f14f0@mail.gmail.com> Message-ID: <1239801223.27602.2.camel@sulfur.loria.fr> Sorry, I should have said that currently, examples are supposed to be run from within glipy: run -i examples/colorbars.py within terminal. On Wed, 2009-04-15 at 07:57 -0500, G?khan SEVER wrote: > Hi Nicolas, > > You may need to revise the examples in /examples directory because out > of 4 examples non work in my system > > (Fedora 10 2.6.27.19-170.2.35.fc10.i686.PAE #1 SMP > > Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) > [GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2 > > IPython 0.10.bzr.r1163) > > Here are the error messages that I encounter: > > > > [gsever at ccn examples]$ python colorbars.py > File "colorbars.py", line 25 > fig = figure(*items, height=25, cmap=colormap.IceAndFire) > ^ > SyntaxError: invalid syntax > > > > [gsever at ccn examples]$ python cube.py > Traceback (most recent call last): > File "cube.py", line 121, in > c = cube() > File "cube.py", line 116, in cube > terminal.insert(c) > NameError: global name 'terminal' is not defined > > > > [gsever at ccn examples]$ python figure.py > File "figure.py", line 34 > fig = figure(*items, height=300, cmap=cmap) > ^ > SyntaxError: invalid syntax > > > > [gsever at ccn examples]$ python screenshots.py > Traceback (most recent call last): > File "screenshots.py", line 18, in > fig = figure(z1) > NameError: name 'figure' is not defined > > > Interestingly, examples were working when I tested glipy in its very first days. > > Thanks for this nice tool. > > G?khan > > > On Wed, Apr 15, 2009 at 3:35 AM, Nicolas Rougier > wrote: > > > > > > Hello, > > > > I've setup a launchpad glipy project: > > https://launchpad.net/glipy > > > > as well as a rudimentary homepage: > > http://webloria.loria.fr/~rougier/glipy/ > > > > > > for those who want to test it. It is still an early beta version and may > > be plenty of bugs... > > > > > > Nicolas > > > > _______________________________________________ > > 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 From gokhansever at gmail.com Wed Apr 15 09:25:55 2009 From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_SEVER?=) Date: Wed, 15 Apr 2009 08:25:55 -0500 Subject: [IPython-dev] glipy, OpenGL IPython terminal with numpy support In-Reply-To: <1239801223.27602.2.camel@sulfur.loria.fr> References: <1239784504.4307.2.camel@sulfur.loria.fr> <49d6b3500904150557j4c645361r1b6fc7cd6e6f14f0@mail.gmail.com> <1239801223.27602.2.camel@sulfur.loria.fr> Message-ID: <49d6b3500904150625r5db8211ch293207ac960ad69f@mail.gmail.com> Hmm, I got a blackscreen when I try to run glipy, therefore couldn't test any of the examples. Have you tested your copy with a dev branch of IPython 0.10? Please see the screenshot: http://img15.imageshack.us/img15/4876/glipyscreenshot.png G?khan On Wed, Apr 15, 2009 at 8:13 AM, Nicolas Rougier wrote: > > Sorry, I should have said that currently, examples are supposed to be > run from within glipy: > > run -i examples/colorbars.py within terminal. > > > > > On Wed, 2009-04-15 at 07:57 -0500, G?khan SEVER wrote: >> Hi Nicolas, >> >> You may need to revise the examples in /examples directory because out >> of 4 examples non work in my system >> >> (Fedora 10 2.6.27.19-170.2.35.fc10.i686.PAE #1 SMP >> >> Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) >> [GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2 >> >> IPython 0.10.bzr.r1163) >> >> Here are the error messages that I encounter: >> >> >> >> [gsever at ccn examples]$ python colorbars.py >> ? File "colorbars.py", line 25 >> ? ? fig = figure(*items, height=25, cmap=colormap.IceAndFire) >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >> SyntaxError: invalid syntax >> >> >> >> [gsever at ccn examples]$ python cube.py >> Traceback (most recent call last): >> ? File "cube.py", line 121, in >> ? ? c = cube() >> ? File "cube.py", line 116, in cube >> ? ? terminal.insert(c) >> NameError: global name 'terminal' is not defined >> >> >> >> [gsever at ccn examples]$ python figure.py >> ? File "figure.py", line 34 >> ? ? fig = figure(*items, height=300, cmap=cmap) >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >> SyntaxError: invalid syntax >> >> >> >> [gsever at ccn examples]$ python screenshots.py >> Traceback (most recent call last): >> ? File "screenshots.py", line 18, in >> ? ? fig = figure(z1) >> NameError: name 'figure' is not defined >> >> >> Interestingly, examples were working when I tested glipy in its very first days. >> >> Thanks for this nice tool. >> >> G?khan >> >> >> On Wed, Apr 15, 2009 at 3:35 AM, Nicolas Rougier >> wrote: >> > >> > >> > Hello, >> > >> > I've setup a launchpad glipy project: >> > https://launchpad.net/glipy >> > >> > as well as a rudimentary homepage: >> > http://webloria.loria.fr/~rougier/glipy/ >> > >> > >> > for those who want to test it. It is still an early beta version and may >> > be plenty of bugs... >> > >> > >> > Nicolas >> > >> > _______________________________________________ >> > 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 > > From Nicolas.Rougier at loria.fr Wed Apr 15 09:50:04 2009 From: Nicolas.Rougier at loria.fr (Nicolas Rougier) Date: Wed, 15 Apr 2009 15:50:04 +0200 Subject: [IPython-dev] glipy, OpenGL IPython terminal with numpy support In-Reply-To: <49d6b3500904150625r5db8211ch293207ac960ad69f@mail.gmail.com> References: <1239784504.4307.2.camel@sulfur.loria.fr> <49d6b3500904150557j4c645361r1b6fc7cd6e6f14f0@mail.gmail.com> <1239801223.27602.2.camel@sulfur.loria.fr> <49d6b3500904150625r5db8211ch293207ac960ad69f@mail.gmail.com> Message-ID: <1239803404.17432.1.camel@sulfur.loria.fr> I've not yet tested with ipython 0.10, I was waiting for the official release. Could you test 'glipy -p' to run a regular python shell instead and see if it works ? Nicolas On Wed, 2009-04-15 at 08:25 -0500, G?khan SEVER wrote: > Hmm, > > I got a blackscreen when I try to run glipy, therefore couldn't test > any of the examples. Have you tested your copy with a dev branch of > IPython 0.10? > > Please see the screenshot: > > http://img15.imageshack.us/img15/4876/glipyscreenshot.png > > G?khan > > On Wed, Apr 15, 2009 at 8:13 AM, Nicolas Rougier > wrote: > > > > Sorry, I should have said that currently, examples are supposed to be > > run from within glipy: > > > > run -i examples/colorbars.py within terminal. > > > > > > > > > > On Wed, 2009-04-15 at 07:57 -0500, G?khan SEVER wrote: > >> Hi Nicolas, > >> > >> You may need to revise the examples in /examples directory because out > >> of 4 examples non work in my system > >> > >> (Fedora 10 2.6.27.19-170.2.35.fc10.i686.PAE #1 SMP > >> > >> Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) > >> [GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2 > >> > >> IPython 0.10.bzr.r1163) > >> > >> Here are the error messages that I encounter: > >> > >> > >> > >> [gsever at ccn examples]$ python colorbars.py > >> File "colorbars.py", line 25 > >> fig = figure(*items, height=25, cmap=colormap.IceAndFire) > >> ^ > >> SyntaxError: invalid syntax > >> > >> > >> > >> [gsever at ccn examples]$ python cube.py > >> Traceback (most recent call last): > >> File "cube.py", line 121, in > >> c = cube() > >> File "cube.py", line 116, in cube > >> terminal.insert(c) > >> NameError: global name 'terminal' is not defined > >> > >> > >> > >> [gsever at ccn examples]$ python figure.py > >> File "figure.py", line 34 > >> fig = figure(*items, height=300, cmap=cmap) > >> ^ > >> SyntaxError: invalid syntax > >> > >> > >> > >> [gsever at ccn examples]$ python screenshots.py > >> Traceback (most recent call last): > >> File "screenshots.py", line 18, in > >> fig = figure(z1) > >> NameError: name 'figure' is not defined > >> > >> > >> Interestingly, examples were working when I tested glipy in its very first days. > >> > >> Thanks for this nice tool. > >> > >> G?khan > >> > >> > >> On Wed, Apr 15, 2009 at 3:35 AM, Nicolas Rougier > >> wrote: > >> > > >> > > >> > Hello, > >> > > >> > I've setup a launchpad glipy project: > >> > https://launchpad.net/glipy > >> > > >> > as well as a rudimentary homepage: > >> > http://webloria.loria.fr/~rougier/glipy/ > >> > > >> > > >> > for those who want to test it. It is still an early beta version and may > >> > be plenty of bugs... > >> > > >> > > >> > Nicolas > >> > > >> > _______________________________________________ > >> > 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 > > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From jorgen.stenarson at bostream.nu Wed Apr 15 14:18:30 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 15 Apr 2009 20:18:30 +0200 Subject: [IPython-dev] Testcrash on trunk Message-ID: <49E624F6.4020502@bostream.nu> I'm getting this crash using trunk (rev1163). Anyone else see this? It worked fine with (rev1163). /J?rgen C:\Python25\Lib\site-packages\IPython\tests>iptest E ====================================================================== ERROR: Failure: ImportError (cannot import name Release) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\python25\lib\site-packages\nose-0.11.0.dev_r0-py2.5.egg\nose\loader.p y", line 364, in loadTestsFromName addr.filename, addr.module) File "C:\python25\lib\site-packages\nose-0.11.0.dev_r0-py2.5.egg\nose\importer .py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "C:\python25\lib\site-packages\nose-0.11.0.dev_r0-py2.5.egg\nose\importer .py", line 82, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "C:\Python25\Lib\site-packages\IPython\__init__.py", line 63, in from IPython import Release # do it explicitly so pydoc can see it - pydoc b ug ImportError: cannot import name Release ---------------------------------------------------------------------- Ran 1 test in 0.000s FAILED (errors=1) From jorgen.stenarson at bostream.nu Wed Apr 15 14:37:58 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 15 Apr 2009 20:37:58 +0200 Subject: [IPython-dev] Testcrash on trunk In-Reply-To: <49E624F6.4020502@bostream.nu> References: <49E624F6.4020502@bostream.nu> Message-ID: <49E62986.7010700@bostream.nu> J?rgen Stenarson skrev: > I'm getting this crash using trunk (rev1163). Anyone else see this? > It worked fine with (rev1163). > > /J?rgen Ooops I confused the revision numbers. The latest revision that seems to work for me is 1159. The trunk revision I tried first was 1166. /J?rgen From fperez.net at gmail.com Wed Apr 15 14:50:18 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Apr 2009 11:50:18 -0700 Subject: [IPython-dev] Testcrash on trunk In-Reply-To: <49E62986.7010700@bostream.nu> References: <49E624F6.4020502@bostream.nu> <49E62986.7010700@bostream.nu> Message-ID: On Wed, Apr 15, 2009 at 11:37 AM, J?rgen Stenarson wrote: > J?rgen Stenarson skrev: >> I'm getting this crash using trunk (rev1163). Anyone else see this? >> It worked fine with (rev1163). >> >> /J?rgen > Ooops I confused the revision numbers. The latest revision that seems to > work for me is 1159. The trunk revision I tried first was 1166. No, I don't see this at all, no matter how I run the suite. But Ville reported seeing very few tests when he updated one of his branches, I wonder if these are related. Perhaps you could try to use the --pdb-failures option to debug it a little to collect more info? I'm quite puzzled... Cheers, f From jorgen.stenarson at bostream.nu Wed Apr 15 15:09:53 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 15 Apr 2009 21:09:53 +0200 Subject: [IPython-dev] Testcrash on trunk In-Reply-To: References: <49E624F6.4020502@bostream.nu> <49E62986.7010700@bostream.nu> Message-ID: <49E63101.3010102@bostream.nu> Fernando Perez skrev: > On Wed, Apr 15, 2009 at 11:37 AM, J?rgen Stenarson > wrote: >> J?rgen Stenarson skrev: >>> I'm getting this crash using trunk (rev1163). Anyone else see this? >>> It worked fine with (rev1163). >>> >>> /J?rgen >> Ooops I confused the revision numbers. The latest revision that seems to >> work for me is 1159. The trunk revision I tried first was 1166. > > No, I don't see this at all, no matter how I run the suite. But Ville > reported seeing very few tests when he updated one of his branches, I > wonder if these are related. > > Perhaps you could try to use the --pdb-failures option to debug it a > little to collect more info? I'm quite puzzled... > I tried this and just end up in the at the ordinary shellprompt i.e. no pdb. That error on import smells like a circular import problem. I have tried adding "import IPython.Release" at the top of the iptest script and that line runs just fine so it seems that something happens in iptest.main that makes this failure. C:\python\external\ipython-trunk\IPython\tests>iptest --pdb-failures E ====================================================================== ERROR: Failure: ImportError (cannot import name Release) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\python25\lib\site-packages\nose-0.11.0.dev_r596-py2.5.egg\nose\loader .py", line 362, in loadTestsFromName addr.filename, addr.module) File "c:\python25\lib\site-packages\nose-0.11.0.dev_r596-py2.5.egg\nose\import er.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "c:\python25\lib\site-packages\nose-0.11.0.dev_r596-py2.5.egg\nose\import er.py", line 82, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "c:\python\external\ipython-trunk\IPython\__init__.py", line 63, in from IPython import Release # do it explicitly so pydoc can see it - pydoc b ug ImportError: cannot import name Release ---------------------------------------------------------------------- Ran 1 test in 0.000s FAILED (errors=1) C:\python\external\ipython-trunk\IPython\tests> From fperez.net at gmail.com Wed Apr 15 15:31:06 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Apr 2009 12:31:06 -0700 Subject: [IPython-dev] Testcrash on trunk In-Reply-To: <49E63101.3010102@bostream.nu> References: <49E624F6.4020502@bostream.nu> <49E62986.7010700@bostream.nu> <49E63101.3010102@bostream.nu> Message-ID: Hey, On Wed, Apr 15, 2009 at 12:09 PM, J?rgen Stenarson wrote: > "c:\python25\lib\site-packages\nose-0.11.0.dev_r596-py2.5.egg\nose\loader > .py", line 362, in loadTestsFromName I see you're using a dev version of nose, I'm using 0.10.4. I'll try this and see if it makes a difference, but I need to run now, I won't be back for a few hours. If in the meantime you could check to see if the problem is still present for you with nose 0.10.4, that would be great. I'm very puzzled, no matter what I do I can't reproduce it, so I can't debug it... Cheers, f From jorgen.stenarson at bostream.nu Wed Apr 15 16:24:01 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 15 Apr 2009 22:24:01 +0200 Subject: [IPython-dev] Testcrash on trunk In-Reply-To: References: <49E624F6.4020502@bostream.nu> <49E62986.7010700@bostream.nu> <49E63101.3010102@bostream.nu> Message-ID: <49E64261.50002@bostream.nu> Fernando Perez skrev: > If in the meantime you could check to see if the problem is still > present for you with nose 0.10.4, that would be great. unfortunately it didn't work. I'll try it on another computer tomorrow. C:\python\external\ipython-trunk\IPython\tests>iptest E ====================================================================== ERROR: Failure: AttributeError ('module' object has no attribute 'Release') ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\python25\lib\site-packages\nose-0.10.4-py2.5.egg\nose\loader.py", lin e 364, in loadTestsFromName addr.filename, addr.module) File "c:\python25\lib\site-packages\nose-0.10.4-py2.5.egg\nose\importer.py", l ine 39, in importFromPath return self.importFromDir(dir_path, fqname) File "c:\python25\lib\site-packages\nose-0.10.4-py2.5.egg\nose\importer.py", l ine 82, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "c:\python\external\ipython-trunk\IPython\__init__.py", line 64, in import IPython.Release as Release AttributeError: 'module' object has no attribute 'Release' ---------------------------------------------------------------------- Ran 1 test in 0.016s FAILED (errors=1) C:\python\external\ipython-trunk\IPython\tests> From laurent.dufrechou at gmail.com Wed Apr 15 16:47:33 2009 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Wed, 15 Apr 2009 22:47:33 +0200 Subject: [IPython-dev] Testcrash on trunk In-Reply-To: References: <49E624F6.4020502@bostream.nu> <49E62986.7010700@bostream.nu> <49E63101.3010102@bostream.nu> Message-ID: <49e647ec.25e2660a.3353.5f5b@mx.google.com> Same bug here. C:\Users\ldufrechou\Desktop\Ipython-dev\ipython-trunk\IPython\tests>iptest E ====================================================================== ERROR: Failure: ImportError (cannot import name Release) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\python25\lib\site-packages\nose\loader.py", line 364, in loadTestsFromName addr.filename, addr.module) File "C:\python25\lib\site-packages\nose\importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "C:\python25\lib\site-packages\nose\importer.py", line 82, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "C:\Users\ldufrechou\Desktop\Ipython-dev\ipython-trunk\IPython\__init__.py", line 63, in from IPython import Release # do it explicitly so pydoc can see it - pydoc bug ImportError: cannot import name Release ---------------------------------------------------------------------- Ran 1 test in 0.002s FAILED (errors=1) ############## C:\Users\ldufrechou\Desktop\Ipython-dev\ipython-trunk\IPython\tests>nosetest s --version nosetests-script.py version 0.10.4 ############## Hey interesting: C:\Users\ldufrechou\Desktop\Ipython-dev\ipython-trunk\IPython\tests>nosetest s .................EEE..ESSS ====================================================================== ERROR: Failure: NameError (name '_ip' is not defined) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\python25\lib\site-packages\nose\loader.py", line 364, in loadTestsFromName addr.filename, addr.module) File "C:\python25\lib\site-packages\nose\importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "C:\python25\lib\site-packages\nose\importer.py", line 84, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "C:\Users\ldufrechou\Desktop\Ipython-dev\ipython-trunk\IPython\tests\test_ip lib.py", line 31, in ip = _ip # This is the ipapi instance NameError: name '_ip' is not defined ====================================================================== ERROR: IPython.tests.test_magic.test_rehashx ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\python25\lib\site-packages\nose\case.py", line 182, in runTest self.test(*self.arg) File "C:\Users\ldufrechou\Desktop\Ipython-dev\ipython-trunk\IPython\tests\test_ma gic.py", line 21, in test_rehashx _ip.IP.alias_table.clear() NameError: global name '_ip' is not defined ====================================================================== ERROR: Test that object's __del__ methods are called on exit. ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\python25\lib\site-packages\nose\case.py", line 182, in runTest self.test(*self.arg) File "C:\Users\ldufrechou\Desktop\Ipython-dev\ipython-trunk\IPython\tests\test_ma gic.py", line 85, in test_obj_del out = _ip.IP.getoutput('ipython %s' % del_file) NameError: global name '_ip' is not defined ====================================================================== ERROR: test suite ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\python25\lib\site-packages\nose\suite.py", line 154, in run self.setUp() File "C:\python25\lib\site-packages\nose\suite.py", line 180, in setUp if not self: File "C:\python25\lib\site-packages\nose\suite.py", line 65, in __nonzero__ test = self.test_generator.next() File "C:\python25\lib\site-packages\nose\loader.py", line 221, in generate for test in g(): File "C:\Users\ldufrechou\Desktop\Ipython-dev\ipython-trunk\IPython\testing\decor ators.py", line 178, in skipper_gen for x in f(*args, **kwargs): File "C:\Users\ldufrechou\Desktop\Ipython-dev\ipython-trunk\IPython\tests\test_ma gic.py", line 114, in test_numpy_clear_array_undec _ip.ex('import numpy as np') NameError: global name '_ip' is not defined ---------------------------------------------------------------------- Ran 22 tests in 1.090s ###################### Thus on very fresh install of ipython.(trunk rev 1166) > -----Message d'origine----- > De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev- > bounces at scipy.org] De la part de Fernando Perez > Envoy??: mercredi 15 avril 2009 21:31 > ??: J?rgen Stenarson > Cc?: IPython-dev List > Objet?: Re: [IPython-dev] Testcrash on trunk > > Hey, > > On Wed, Apr 15, 2009 at 12:09 PM, J?rgen Stenarson > wrote: > > > "c:\python25\lib\site-packages\nose-0.11.0.dev_r596- > py2.5.egg\nose\loader > > .py", line 362, in loadTestsFromName > > I see you're using a dev version of nose, I'm using 0.10.4. I'll try > this and see if it makes a difference, but I need to run now, I won't > be back for a few hours. > > If in the meantime you could check to see if the problem is still > present for you with nose 0.10.4, that would be great. > > I'm very puzzled, no matter what I do I can't reproduce it, so I can't > debug it... > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From ellisonbg.net at gmail.com Wed Apr 15 17:16:44 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 15 Apr 2009 14:16:44 -0700 Subject: [IPython-dev] Testing headaches Message-ID: <6ce0ac130904151416s6a3ba6f3n576cd445c1def82c@mail.gmail.com> Hi, As we settle into the new workflow (code reviews, etc.) one of the biggest things that keeps getting us is that our testing system seems very easy to break in really wierd ways. This is different from not having tests or having tests that simply fail. In our case, we are seeing a number of things that actually break the test suite itself: * Both Ville and Jorgen have seens really odd things in the last few days. * I am seeing a nasty memory leak that is intermittent on OS X. * Twisted and nose are somehow very unhappy with each other. * Sometimes tests rely on dependencies (wx, twisted, etc.). Those tests get run on systems that don't have the deps and they fail with ImportError. I have tried to add code that tests for dependencies, but these keep creeping in. The problem with this is that the person who finds the problem is not the person who wrote the code or tests. Part of the difficulty with all of these things is that debugging them is HELL. Often times it is difficult to even begin to see where the problem is coming from. I am wondering what we can do to make our testing framework more robust. We need an approach that can run tests in a more isolated manner so we immediately know where such problems are coming from. Also, we need to come up with a uniform and consistent way of handling dependencies in tests. Thoughts? Brian From laurent.dufrechou at gmail.com Wed Apr 15 17:47:17 2009 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Wed, 15 Apr 2009 23:47:17 +0200 Subject: [IPython-dev] Testing headaches In-Reply-To: <6ce0ac130904151416s6a3ba6f3n576cd445c1def82c@mail.gmail.com> References: <6ce0ac130904151416s6a3ba6f3n576cd445c1def82c@mail.gmail.com> Message-ID: <49e655ed.0af5660a.0428.7aed@mx.google.com> Hello, Just a stupid thought. How about a simple top level test script? It test if modules are present and if version are OK. Depending on the result, it propose a menu that run tests related to different parts. Ex: wx,twisted present, no qt. 0/core test 1/wx test 2/twisted related test Note: missing test: - qt test: missing qt-4.5 depedency Perhaps this is a dumb approach, but it has the advantage to allows us to better handle which test will be run. And dumb user like me will know what he is testing. And he/I will not complain because test fails stupidly :) Another advantage is that you can do more test before launching test to check is installed system is conform to what test needs. And thus explain ti the user possible cuase of a failure (bad nose version etc....) That's the easy part, sure you will say me that some part needs wx+twisted :) how do you do in this case... Laurent > -----Message d'origine----- > De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev- > bounces at scipy.org] De la part de Brian Granger > Envoy??: mercredi 15 avril 2009 23:17 > ??: IPython Development list > Objet?: [IPython-dev] Testing headaches > > Hi, > > As we settle into the new workflow (code reviews, etc.) one of the > biggest things that keeps getting us is that our testing system seems > very easy to break in really wierd ways. This is different from not > having tests or having tests that simply fail. In our case, we are > seeing a number of things that actually break the test suite itself: > > * Both Ville and Jorgen have seens really odd things in the last few > days. > * I am seeing a nasty memory leak that is intermittent on OS X. > * Twisted and nose are somehow very unhappy with each other. > * Sometimes tests rely on dependencies (wx, twisted, etc.). Those > tests get run on systems that don't have the deps and they fail with > ImportError. I have tried to add code that tests for dependencies, > but these keep creeping in. The problem with this is that the person > who finds the problem is not the person who wrote the code or tests. > > Part of the difficulty with all of these things is that debugging them > is HELL. Often times it is difficult to even begin to see where the > problem is coming from. > > I am wondering what we can do to make our testing framework more > robust. We need an approach that can run tests in a more isolated > manner so we immediately know where such problems are coming from. > Also, we need to come up with a uniform and consistent way of handling > dependencies in tests. > > Thoughts? > > Brian > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From gokhansever at gmail.com Wed Apr 15 18:08:15 2009 From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_SEVER?=) Date: Wed, 15 Apr 2009 17:08:15 -0500 Subject: [IPython-dev] Documentation build error (for rev1163) Message-ID: <49d6b3500904151508s286946cew3da14a7a40e0e699@mail.gmail.com> Hello, Could somebody check whether the docs from the latest main devel branch are succesfully being compiled? I am getting the errors given below: Thanks. python do_sphinx.py No builder selected, using default: html Sphinx v0.5, building html loading pickled environment... not found building [html]: targets for 162 source files that are out of date updating environment: 162 added, 0 changed, 0 removed reading sources... api/generated/IPython.ColorANSI api/generated/IPython.ConfigLoader api/generated/IPython.CrashHandler api/generated/IPython.DPyGetOpt api/generated/IPython.Debugger api/generated/IPython.Itpl api/generated/IPython.Logger api/generated/IPython.Magic api/generated/IPython.OInspect api/generated/IPython.OutputTrap api/generated/IPython.Prompts api/generated/IPython.PyColorize api/generated/IPython.Shell api/generated/IPython.UserConfig.ipy_user_conf api/generated/IPython.background_jobs api/generated/IPython.completer api/generated/IPython.config.api api/generated/IPython.config.cutils api/generated/IPython.deep_reload api/generated/IPython.demo api/generated/IPython.dtutils api/generated/IPython.excolors api/generated/IPython.external.Itpl api/generated/IPython.external.argparse api/generated/IPython.external.configobj api/generated/IPython.external.guid api/generated/IPython.external.mglob api/generated/IPython.external.path api/generated/IPython.external.pretty api/generated/IPython.external.simplegeneric api/generated/IPython.external.validate api/generated/IPython.frontend.asyncfrontendbase Exception occurred: File "/home/gsever/Desktop/python-repo/ipython/docs/sphinxext/inheritance_diagram.py", line 107, in _import_class_or_module "Could not import class or module '%s' specified for inheritance diagram" % name) ValueError: Could not import class or module 'IPython.frontend.asyncfrontendbase' specified for inheritance diagram The full traceback has been saved in /tmp/sphinx-err-RIZaJC.log, if you want to report the issue to the author. Please also report this if it was a user error, so that a better error message can be provided next time. Send reports to sphinx-dev at googlegroups.com. Thanks! Sphinx v0.5, building latex loading pickled environment... not found building [latex]: all documents updating environment: 162 added, 0 changed, 0 removed reading sources... api/generated/IPython.ColorANSI api/generated/IPython.ConfigLoader api/generated/IPython.CrashHandler api/generated/IPython.DPyGetOpt api/generated/IPython.Debugger api/generated/IPython.Itpl api/generated/IPython.Logger api/generated/IPython.Magic api/generated/IPython.OInspect api/generated/IPython.OutputTrap api/generated/IPython.Prompts api/generated/IPython.PyColorize api/generated/IPython.Shell api/generated/IPython.UserConfig.ipy_user_conf api/generated/IPython.background_jobs api/generated/IPython.completer api/generated/IPython.config.api api/generated/IPython.config.cutils api/generated/IPython.deep_reload api/generated/IPython.demo api/generated/IPython.dtutils api/generated/IPython.excolors api/generated/IPython.external.Itpl api/generated/IPython.external.argparse api/generated/IPython.external.configobj api/generated/IPython.external.guid api/generated/IPython.external.mglob api/generated/IPython.external.path api/generated/IPython.external.pretty api/generated/IPython.external.simplegeneric api/generated/IPython.external.validate api/generated/IPython.frontend.asyncfrontendbase Exception occurred: File "/home/gsever/Desktop/python-repo/ipython/docs/sphinxext/inheritance_diagram.py", line 107, in _import_class_or_module "Could not import class or module '%s' specified for inheritance diagram" % name) ValueError: Could not import class or module 'IPython.frontend.asyncfrontendbase' specified for inheritance diagram The full traceback has been saved in /tmp/sphinx-err-uQDDFE.log, if you want to report the issue to the author. Please also report this if it was a user error, so that a better error message can be provided next time. Send reports to sphinx-dev at googlegroups.com. Thanks! Traceback (most recent call last): File "/home/gsever/Desktop/python-repo/ipython/docs/do_sphinx.py", line 52, in for line in fileinput.FileInput('manual.cls',inplace=1): File "/usr/lib/python2.5/fileinput.py", line 253, in next line = self.readline() File "/usr/lib/python2.5/fileinput.py", line 322, in readline os.rename(self._filename, self._backupfilename) OSError: [Errno 2] No such file or directory -- G?khan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed Apr 15 18:15:38 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 15 Apr 2009 15:15:38 -0700 Subject: [IPython-dev] Testing headaches In-Reply-To: <49e655ed.0af5660a.0428.7aed@mx.google.com> References: <6ce0ac130904151416s6a3ba6f3n576cd445c1def82c@mail.gmail.com> <49e655ed.0af5660a.0428.7aed@mx.google.com> Message-ID: <6ce0ac130904151515x23fac6f8gb86f999e0ec07f30@mail.gmail.com> Yes, this is the type of thing that I am actually starting to think about: * Have a top level test runner that looks at a subpackage (how?) to see its deps. * The top level test runner tests the deps. * If the deps are there, it runs the tests of the subpackage in a ***separate process*** * Iterate though all IPython subpackages. Or we could make it interactive. This approach would better isolate the testing of different package. I think having things run in different processes is really important due to all the nasty stuff we are seeing. Brian On Wed, Apr 15, 2009 at 2:47 PM, Laurent Dufr?chou wrote: > Hello, > Just a stupid thought. How about a simple top level test script? > It test if modules are present and if version are OK. > Depending on the result, it propose a menu that run tests related to > different parts. > Ex: wx,twisted present, no qt. > > 0/core test > 1/wx ?test > 2/twisted related test > > Note: missing test: > - qt test: missing qt-4.5 depedency > > Perhaps this is a dumb approach, but it has the advantage to allows us to > better handle which test will be run. > And dumb user like me will know what he is testing. And he/I will not > complain because test fails stupidly :) > Another advantage is that you can do more test before launching test to > check is installed system is conform to what test needs. And thus explain ti > the user possible cuase of a failure (bad nose version etc....) > > That's the easy part, sure you will say me that some part needs wx+twisted > :) how do you do in this case... > > Laurent > >> -----Message d'origine----- >> De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev- >> bounces at scipy.org] De la part de Brian Granger >> Envoy??: mercredi 15 avril 2009 23:17 >> ??: IPython Development list >> Objet?: [IPython-dev] Testing headaches >> >> Hi, >> >> As we settle into the new workflow (code reviews, etc.) one of the >> biggest things that keeps getting us is that our testing system seems >> very easy to break in really wierd ways. ?This is different from not >> having tests or having tests that simply fail. ?In our case, we are >> seeing a number of things that actually break the test suite itself: >> >> * Both Ville and Jorgen have seens really odd things in the last few >> days. >> * I am seeing a nasty memory leak that is intermittent on OS X. >> * Twisted and nose are somehow very unhappy with each other. >> * Sometimes tests rely on dependencies (wx, twisted, etc.). ?Those >> tests get run on systems that don't have the deps and they fail with >> ImportError. ?I have tried to add code that tests for dependencies, >> but these keep creeping in. ?The problem with this is that the person >> who finds the problem is not the person who wrote the code or tests. >> >> Part of the difficulty with all of these things is that debugging them >> is HELL. ?Often times it is difficult to even begin to see where the >> problem is coming from. >> >> I am wondering what we can do to make our testing framework more >> robust. ?We need an approach that can run tests in a more isolated >> manner so we immediately know where such problems are coming from. >> Also, we need to come up with a uniform and consistent way of handling >> dependencies in tests. >> >> Thoughts? >> >> Brian >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > From ellisonbg.net at gmail.com Wed Apr 15 20:22:52 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 15 Apr 2009 17:22:52 -0700 Subject: [IPython-dev] Tag and branch 0.10 soon? In-Reply-To: References: Message-ID: <6ce0ac130904151722s5b6c485ft41b111495c1a5f61@mail.gmail.com> > Here's the code pending to be merged: > > https://code.launchpad.net/ipython/+activereviews After I did a few things, we are down to just 4 branches that need to be merged before 0.19. Here is the big picture: * 1 branch is Gael's. Hopefully Laurent can review it and Gael can finish this up soon. * 2 branches are Ville's. Both need some fixes and further work. * One branch is Tom's. It looks like this branch will be tagged as "Work in Progress" and targeted for 0.11. This means we are close!!! However, there are a few more bugs that need to be targeted for 0.10.... *Please go through the bug list on launchpad and see if there are bugs related to 0.10. If so, please target them to the 0.10 milestone. That was we can see what needs to be done before the release. > Options: > > 1. we tag/branch 0.10 pretty much now and those pending reviews get > retargeted for the branch. > 2. tag now, but keep the reviews for trunk. > > 3. other ideas? I have a few more bugs to fix before 0.10. Thus, if Ville and Gael can get their branches into shape in the next few days, I say we wait a bit longer. Ville and Gael, can we finish this up by next Monday? Then, we can tag 0.10. But, if it looks like they are going to go longer than that, we should still tag 0.10 so I can get started, but they will have to merged into the 0.10 branch and later with trunk which will be changing quickly! How does that sound? We are getting close, but all the testing problems are a little disconcerting ;-( Brian > My main worry with #2 is Brian's chance to do full-on reorg work, that > I'd prefer to avoid delaying much further. ?But if the remaining > merges are done in a branch and a massive amount of moving around is > done, they will be effectively lost since it won't be easy to apply > them into a very restructured trunk. > > Some of the pending stuff is pretty easy, so if people have a little > bit of time, we could probably merge most of this in a couple of days. > ?We can then get 0.10 out the door, with minimal/no loss of work for > the reorganization. ?Then we could all provide feedback on the reorg > work (I'm unlikely to do any actual major work on it, but hope to > provide feedback) > > Thoughts? > > f > > > ps - I also made 0.11 series/milestones: > > https://launchpad.net/ipython/0.11 > https://launchpad.net/ipython/+milestone/0.11 > > as a placeholder. ?I'm thinking we might end up calling this 0.50 or > something larger to indicate the api breaks and an actual move to 1.0 > status though, so this should be for now considered temporary. ?We'll > see in a few days when 0.10 is out... > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From gael.varoquaux at normalesup.org Thu Apr 16 01:27:53 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 16 Apr 2009 07:27:53 +0200 Subject: [IPython-dev] Tag and branch 0.10 soon? In-Reply-To: <6ce0ac130904151722s5b6c485ft41b111495c1a5f61@mail.gmail.com> References: <6ce0ac130904151722s5b6c485ft41b111495c1a5f61@mail.gmail.com> Message-ID: <20090416052753.GD3274@phare.normalesup.org> On Wed, Apr 15, 2009 at 05:22:52PM -0700, Brian Granger wrote: > Ville and Gael, can we finish this up by next Monday? I should be able to reschedule some other tasks and do my fixes Saturday or Sunday. I would be interested in a review from Laurent, before, or after my fixes. Cheers, Ga?l From ellisonbg.net at gmail.com Thu Apr 16 01:47:13 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 15 Apr 2009 22:47:13 -0700 Subject: [IPython-dev] Tag and branch 0.10 soon? In-Reply-To: <20090416052753.GD3274@phare.normalesup.org> References: <6ce0ac130904151722s5b6c485ft41b111495c1a5f61@mail.gmail.com> <20090416052753.GD3274@phare.normalesup.org> Message-ID: <6ce0ac130904152247v19c509bcw1d27788ad90a2bf0@mail.gmail.com> Gael, Great and many thanks. It looks like we have some significant problems with our test suite that are going to take a few days to resolve anyways. Cheers, Brian On Wed, Apr 15, 2009 at 10:27 PM, Gael Varoquaux wrote: > On Wed, Apr 15, 2009 at 05:22:52PM -0700, Brian Granger wrote: >> Ville and Gael, can we finish this up by next Monday? > > I should be able to reschedule some other tasks and do my fixes Saturday > or Sunday. I would be interested in a review from Laurent, before, or > after my fixes. > > Cheers, > > Ga?l > From prabhu at aero.iitb.ac.in Thu Apr 16 02:29:11 2009 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Thu, 16 Apr 2009 11:59:11 +0530 Subject: [IPython-dev] Testing headaches In-Reply-To: <6ce0ac130904151515x23fac6f8gb86f999e0ec07f30@mail.gmail.com> References: <6ce0ac130904151416s6a3ba6f3n576cd445c1def82c@mail.gmail.com> <49e655ed.0af5660a.0428.7aed@mx.google.com> <6ce0ac130904151515x23fac6f8gb86f999e0ec07f30@mail.gmail.com> Message-ID: <49E6D037.70907@aero.iitb.ac.in> On 04/16/09 03:45, Brian Granger wrote: > Yes, this is the type of thing that I am actually starting to think about: > > * Have a top level test runner that looks at a subpackage (how?) to > see its deps. > * The top level test runner tests the deps. > * If the deps are there, it runs the tests of the subpackage in a > ***separate process*** > * Iterate though all IPython subpackages. Or we could make it interactive. > > This approach would better isolate the testing of different package. > I think having things run in different processes is really important > due to all the nasty stuff we are seeing. Let me just add that I've been bitten enough by the run-all-tests-in-one-go approach that all test runners take (nosetests especially) that I "lost it" on one of the threads on enthought-dev and ranted like crazy. It does help to be able to run each test file in a separate process so different pieces don't stomp on each other. It also mimics what we usually do when developing -- testing the particular test file and once its done run the full suite. It makes it much easier to isolate issues and not have to worry about unpredictable and hard-to-debug side effects. Robert Kern pointed out that nosepipe lets you run each test case in a separate process. http://pypi.python.org/pypi/nosepipe/ This also opens up the possibility of doing parallel testing on multiple cores. cheers, prabhu From gael.varoquaux at normalesup.org Thu Apr 16 03:00:39 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 16 Apr 2009 09:00:39 +0200 Subject: [IPython-dev] Tag and branch 0.10 soon? In-Reply-To: <6ce0ac130904152247v19c509bcw1d27788ad90a2bf0@mail.gmail.com> References: <6ce0ac130904151722s5b6c485ft41b111495c1a5f61@mail.gmail.com> <20090416052753.GD3274@phare.normalesup.org> <6ce0ac130904152247v19c509bcw1d27788ad90a2bf0@mail.gmail.com> Message-ID: <20090416070039.GA10698@phare.normalesup.org> On Wed, Apr 15, 2009 at 10:47:13PM -0700, Brian Granger wrote: > Great and many thanks. It looks like we have some significant > problems with our test suite that are going to take a few days to > resolve anyways. I am happy you guys are tackling these issues. I remember running into them when trying to test the hacky 'PrefilterFrontEnd', which combines IPython0 and IPython1. It was not a pleasant experience. For what it's worth, in Mayavi, due to side effect with nose, we ended up having a test suite runner, that calls several instances of nose (using "mayavi2 -t", in the latest release, which is very convenient to instruct new users on how to test. Ga?l From jorgen.stenarson at bostream.nu Thu Apr 16 12:43:13 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 16 Apr 2009 18:43:13 +0200 Subject: [IPython-dev] Testing headaches In-Reply-To: <6ce0ac130904151416s6a3ba6f3n576cd445c1def82c@mail.gmail.com> References: <6ce0ac130904151416s6a3ba6f3n576cd445c1def82c@mail.gmail.com> Message-ID: <49E76021.9050305@bostream.nu> Brian Granger skrev: > > * Both Ville and Jorgen have seens really odd things in the last few days. > * I am seeing a nasty memory leak that is intermittent on OS X. > * Twisted and nose are somehow very unhappy with each other. > * Sometimes tests rely on dependencies (wx, twisted, etc.). Those > tests get run on systems that don't have the deps and they fail with > ImportError. I have tried to add code that tests for dependencies, > but these keep creeping in. The problem with this is that the person > who finds the problem is not the person who wrote the code or tests. A related issue is the problems with architecture and python version dependent bugs. /J?rgen From jorgen.stenarson at bostream.nu Thu Apr 16 13:55:28 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 16 Apr 2009 19:55:28 +0200 Subject: [IPython-dev] Testcrash on trunk In-Reply-To: <49E64261.50002@bostream.nu> References: <49E624F6.4020502@bostream.nu> <49E62986.7010700@bostream.nu> <49E63101.3010102@bostream.nu> <49E64261.50002@bostream.nu> Message-ID: <49E77110.4020607@bostream.nu> J?rgen Stenarson skrev: > Fernando Perez skrev: >> If in the meantime you could check to see if the problem is still >> present for you with nose 0.10.4, that would be great. > > unfortunately it didn't work. I'll try it on another computer tomorrow. > I have tried it on another computer running python 2.4 and that works. It also works on this computer under pyhton2.4. I'll see if it can be some setup_tools thing, there are quite a few package in my 2.5 install but not so many under 2.4. /J?rgen From jorgen.stenarson at bostream.nu Thu Apr 16 14:05:10 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 16 Apr 2009 20:05:10 +0200 Subject: [IPython-dev] ipy_user_conf is imported when running iptest Message-ID: <49E77356.6090700@bostream.nu> I have seen that the users own ipy_user_conf is imported when running iptest. I guess this could cause some differences in the testing environment between different users. Shall I add a bug on launchpad for this? /J?rgen From jorgen.stenarson at bostream.nu Thu Apr 16 14:25:22 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 16 Apr 2009 20:25:22 +0200 Subject: [IPython-dev] Testcrash on trunk In-Reply-To: <49E77110.4020607@bostream.nu> References: <49E624F6.4020502@bostream.nu> <49E62986.7010700@bostream.nu> <49E63101.3010102@bostream.nu> <49E64261.50002@bostream.nu> <49E77110.4020607@bostream.nu> Message-ID: <49E77812.30101@bostream.nu> J?rgen Stenarson skrev: > J?rgen Stenarson skrev: >> Fernando Perez skrev: >>> If in the meantime you could check to see if the problem is still >>> present for you with nose 0.10.4, that would be great. >> unfortunately it didn't work. I'll try it on another computer tomorrow. >> > > I have tried it on another computer running python 2.4 and that works. > It also works on this computer under pyhton2.4. I'll see if it can be > some setup_tools thing, there are quite a few package in my 2.5 install > but not so many under 2.4. > After cleaning out all easy_installed packages but nose everything works as it should. And I get a clean run of the tests. /J?rgen From jorgen.stenarson at bostream.nu Thu Apr 16 15:02:23 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 16 Apr 2009 21:02:23 +0200 Subject: [IPython-dev] More iptest weirdness Message-ID: <49E780BF.4010707@bostream.nu> Running iptest in IPython/tests works fine but if I specify a specific testfile then it crashes the same way as yesterday. Furthermore the doctest functions in test_magic do not run. I can delete them and the same number of tests are reported. /J?rgen E ====================================================================== ERROR: Failure: ImportError (cannot import name Release) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\python25\lib\site-packages\nose-0.10.4-py2.5.egg\nose\loader.py", line 364, in loadTestsFromName addr.filename, addr.module) File "c:\python25\lib\site-packages\nose-0.10.4-py2.5.egg\nose\importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "c:\python25\lib\site-packages\nose-0.10.4-py2.5.egg\nose\importer.py", line 82, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "c:\python\external\ipython-trunk\IPython\__init__.py", line 63, in from IPython import Release # do it explicitly so pydoc can see it - pydoc bug ImportError: cannot import name Release ---------------------------------------------------------------------- Ran 1 test in 0.000s FAILED (errors=1) From fperez.net at gmail.com Fri Apr 17 04:03:56 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 17 Apr 2009 01:03:56 -0700 Subject: [IPython-dev] More iptest weirdness In-Reply-To: <49E780BF.4010707@bostream.nu> References: <49E780BF.4010707@bostream.nu> Message-ID: On Thu, Apr 16, 2009 at 12:02 PM, J?rgen Stenarson wrote: > Running iptest in IPython/tests works fine but if I specify a specific > testfile then it crashes the same way as yesterday. Is this before or after your easy_install cleanup? I'm wondering > > Furthermore the doctest functions in test_magic do not run. I can delete > them and the same number of tests are reported. That's because of the recent de-activation of ipdoctest by default. I now have alias iptest2='iptest --with-ipdoctest' and I run both iptest and iptest2. Brian found out that nose has been effectively lying to us about the Twisted tests. And for a number of reasons, it's obvious we're going to have to move to process-isolated tests. Ultimately we'll probably use trial (twisted's test runner) in its own process to run all the twisted cases, and nose, possibly with nosepipe, to run other tests with per-process isolation for things like GUI toolkit tests (since it's never a good idea to have in the same process Qt3, Qt4, GTK, Wx and Cocoa instantiated :) We're going to have to solve this testing mess correctly and robustly. Cheers, f From fperez.net at gmail.com Fri Apr 17 04:08:08 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 17 Apr 2009 01:08:08 -0700 Subject: [IPython-dev] Testcrash on trunk In-Reply-To: <49E77812.30101@bostream.nu> References: <49E624F6.4020502@bostream.nu> <49E62986.7010700@bostream.nu> <49E63101.3010102@bostream.nu> <49E64261.50002@bostream.nu> <49E77110.4020607@bostream.nu> <49E77812.30101@bostream.nu> Message-ID: On Thu, Apr 16, 2009 at 11:25 AM, J?rgen Stenarson wrote: > After cleaning out all easy_installed packages but nose everything works as > it should. And I get a clean run of the tests. Mmh... Any chance part of this ongoing saga could then be a setuptools thing? Since I absolutely avoid *ever* using easy_install, I have almost none of its pollution, except for packages whose default setup.py loads setuptools automatically. I will refrain from jumping to conclusions on this, but I'd really like to know if this problem is related to setuptools... The behavior was completely incomprehensible, and your easy_install cleanup seems to point in that direction, but that's not enough evidence to convict it. Unfortunately ;) Cheers, f From jorgen.stenarson at bostream.nu Fri Apr 17 14:07:01 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Fri, 17 Apr 2009 20:07:01 +0200 Subject: [IPython-dev] More iptest weirdness In-Reply-To: References: <49E780BF.4010707@bostream.nu> Message-ID: <49E8C545.4060909@bostream.nu> Fernando Perez skrev: > On Thu, Apr 16, 2009 at 12:02 PM, J?rgen Stenarson > wrote: >> Running iptest in IPython/tests works fine but if I specify a specific >> testfile then it crashes the same way as yesterday. > > Is this before or after your easy_install cleanup? I'm wondering After /J?rgen From jorgen.stenarson at bostream.nu Fri Apr 17 14:51:48 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Fri, 17 Apr 2009 20:51:48 +0200 Subject: [IPython-dev] More iptest weirdness In-Reply-To: References: <49E780BF.4010707@bostream.nu> Message-ID: <49E8CFC4.5030001@bostream.nu> Fernando Perez skrev: > > alias iptest2='iptest --with-ipdoctest' > > and I run both iptest and iptest2. > Tried this and got more annoying errors. A weird crash in IPython.tests.test_iplib.test_user_setup. It seems the tempdirectory that has been created and verified as existing can not be found by shutil.rmtree. Very strange... There are also a bunch of failures due to missing dependencies, see attachment. /J?rgen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: testresult.txt URL: From ondrej at certik.cz Fri Apr 17 19:00:36 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Fri, 17 Apr 2009 16:00:36 -0700 Subject: [IPython-dev] Testing headaches In-Reply-To: <6ce0ac130904151515x23fac6f8gb86f999e0ec07f30@mail.gmail.com> References: <6ce0ac130904151416s6a3ba6f3n576cd445c1def82c@mail.gmail.com> <49e655ed.0af5660a.0428.7aed@mx.google.com> <6ce0ac130904151515x23fac6f8gb86f999e0ec07f30@mail.gmail.com> Message-ID: <85b5c3130904171600l2feb9c62x6810259723408505@mail.gmail.com> On Wed, Apr 15, 2009 at 3:15 PM, Brian Granger wrote: > Yes, this is the type of thing that I am actually starting to think about: > > * Have a top level test runner that looks at a subpackage (how?) to > see its deps. > * The top level test runner tests the deps. > * If the deps are there, it runs the tests of the subpackage in a > ***separate process*** in py.test and also sympy tests if you define a variable "disabled=True" in the top level namespace of the test file, the file will not be tested. So a typical code looks like this: ----- try: from numpy import array, matrix, ndarray import numpy except ImportError: disabled = True # lots of numpy tests ------------ From fperez.net at gmail.com Thu Apr 23 02:42:30 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 22 Apr 2009 23:42:30 -0700 Subject: [IPython-dev] Tag and branch 0.10 soon? In-Reply-To: <20090416070039.GA10698@phare.normalesup.org> References: <6ce0ac130904151722s5b6c485ft41b111495c1a5f61@mail.gmail.com> <20090416052753.GD3274@phare.normalesup.org> <6ce0ac130904152247v19c509bcw1d27788ad90a2bf0@mail.gmail.com> <20090416070039.GA10698@phare.normalesup.org> Message-ID: Howdy, On Thu, Apr 16, 2009 at 12:00 AM, Gael Varoquaux wrote: > On Wed, Apr 15, 2009 at 10:47:13PM -0700, Brian Granger wrote: >> Great and many thanks. ?It looks like we have some significant >> problems with our test suite that are going to take a few days to >> resolve anyways. > > I am happy you guys are tackling these issues. I remember running into > them when trying to test the hacky 'PrefilterFrontEnd', which combines > IPython0 and IPython1. It was not a pleasant experience. Yup. In fact, right now in the 'bugfix' branch, it turns out that I've finally understood that the things you did are precisely what's causing a raft of bizarre errors :) But note that I'm *not* faulting you: the hacks you have in there were unfortunately necessary, given the similarity of IPython's internals to the hairballs my cat has been puking now that the weather is warming up and she's shedding fur... > For what it's worth, in Mayavi, due to side effect with nose, we ended up > having a test suite runner, that calls several instances of nose (using > "mayavi2 -t", in the latest release, which is very convenient to instruct > new users on how to test. Yup, I'm on the same exact path now. I'm going to bed now, but I hope to report progress on this tomorrow. I think I have all the pieces, either on my box or in my head. As long as I can get a few hours of uninterrupted work in tomorrow, we might have something up and running (we have to also factor Twisted into the picture, but overall I think we'll be fine). Stay tuned... f From gael.varoquaux at normalesup.org Thu Apr 23 02:55:48 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 23 Apr 2009 08:55:48 +0200 Subject: [IPython-dev] Tag and branch 0.10 soon? In-Reply-To: References: <6ce0ac130904151722s5b6c485ft41b111495c1a5f61@mail.gmail.com> <20090416052753.GD3274@phare.normalesup.org> <6ce0ac130904152247v19c509bcw1d27788ad90a2bf0@mail.gmail.com> <20090416070039.GA10698@phare.normalesup.org> Message-ID: <20090423065548.GA11074@phare.normalesup.org> On Wed, Apr 22, 2009 at 11:42:30PM -0700, Fernando Perez wrote: > I am happy you guys are tackling these issues. I remember running into > > them when trying to test the hacky 'PrefilterFrontEnd', which combines > > IPython0 and IPython1. It was not a pleasant experience. > Yup. In fact, right now in the 'bugfix' branch, it turns out that > I've finally understood that the things you did are precisely what's > causing a raft of bizarre errors :) ROTFL. Keep me posted on the 'right' way to do things. I am not really proud of this code. Ga?l From fperez.net at gmail.com Thu Apr 23 14:59:10 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 23 Apr 2009 11:59:10 -0700 Subject: [IPython-dev] Tag and branch 0.10 soon? In-Reply-To: <20090423065548.GA11074@phare.normalesup.org> References: <6ce0ac130904151722s5b6c485ft41b111495c1a5f61@mail.gmail.com> <20090416052753.GD3274@phare.normalesup.org> <6ce0ac130904152247v19c509bcw1d27788ad90a2bf0@mail.gmail.com> <20090416070039.GA10698@phare.normalesup.org> <20090423065548.GA11074@phare.normalesup.org> Message-ID: Howdy, On Wed, Apr 22, 2009 at 11:55 PM, Gael Varoquaux wrote: > On Wed, Apr 22, 2009 at 11:42:30PM -0700, Fernando Perez wrote: > ?> I am happy you guys are tackling these issues. I remember running into >> > them when trying to test the hacky 'PrefilterFrontEnd', which combines >> > IPython0 and IPython1. It was not a pleasant experience. > >> Yup. ?In fact, right now in the 'bugfix' branch, it turns out that >> I've finally understood that the things you did are precisely what's >> causing a raft of bizarre errors :) > > ROTFL. Keep me posted on the 'right' way to do things. I am not really > proud of this code. Well, as I said, there's nothing to be ashamed of on your part, you did what you had to do to make it work. The 'right' way to do this will come when in the refactoring, we isolate ipython instances correctly so they don't have global side effects all over the place like they do now. At that point the hacks you had to resort to, and which cause massive problems in the test suite, will just become unnecessary. So no worries, if anyone's at fault here, it's me for years :) Cheers, f From fperez.net at gmail.com Thu Apr 23 18:38:27 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 23 Apr 2009 15:38:27 -0700 Subject: [IPython-dev] Tag and branch 0.10 soon? In-Reply-To: References: <6ce0ac130904151722s5b6c485ft41b111495c1a5f61@mail.gmail.com> <20090416052753.GD3274@phare.normalesup.org> <6ce0ac130904152247v19c509bcw1d27788ad90a2bf0@mail.gmail.com> <20090416070039.GA10698@phare.normalesup.org> <20090423065548.GA11074@phare.normalesup.org> Message-ID: Hi all, On Thu, Apr 23, 2009 at 11:59 AM, Fernando Perez wrote: > Well, as I said, there's nothing to be ashamed of on your part, you > did what you had to do to make it work. ?The 'right' way to do this > will come when in the refactoring, we isolate ipython instances > correctly so they don't have global side effects all over the place > like they do now. ?At that point the hacks you had to resort to, and > which cause massive problems in the test suite, will just become > unnecessary. OK, here's a first stab at this: https://code.launchpad.net/~fdo.perez/ipython/brian-bugfixes Brian has already merged a bunch of stuff, and I'm building on top of that. Now there's a new test runner (ugly, I know, but a clean solution will be for later...) called 'iptestall', that for now I'm not even putting a public script for. But if you cd to the testing/ subdir, you can run: uqbar[testing]> ./iptestall.py ***************************************************************************** IPython test set: kernel ... ---------------------------------------------------------------------- Ran 3 tests in 0.014s OK [...] ***************************************************************************** Ran 10 test sets in 37.278s OK ### I'm not parsing the output of each subprocess so we lose the total test count, but that can be fixed later. At least this has the benefit of being much more robust. For now I added the modules and packages to be scanned by hand, it could be automated later though I'm not sure it's worth automating (more brittleness). I tried to do something very simple but that would *just work*. If a test fail, you get this kind of message (I broke one deliberately): ***************************************************************************** Ran 10 test sets in 36.350s ERROR - 1 out of 10 test sets failed. ---------------------------------------- Runner failed: tests You may wish to rerun this one individually, with: iptest -v IPython.tests And you can now run that one by hand with the old iptest that gives you access to --pdb and all the nose goodies. If the trial one is the one with an error, the printed message will show that too. Cheers, f From ellisonbg.net at gmail.com Sat Apr 25 19:10:25 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sat, 25 Apr 2009 16:10:25 -0700 Subject: [IPython-dev] Please help test ipython trunk Message-ID: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> Hi, After a few weeks of work, we have just merged a massive branch into the ipython trunk. Because of the massive numbers of changes that have been merged in, we really need some help testing out IPython before we cut a 0.10 release (we are basically done merging in things for 0.10, more on that in a separate email thread). Here is how you can help: 1. Get the latest trunk bzr branch lp:ipython 2. Install and run the test suite: iptest 3. Try out lots of things to see if anything is broken 4. Report back Thanks! Brian From gokhansever at gmail.com Sat Apr 25 19:43:20 2009 From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_SEVER?=) Date: Sat, 25 Apr 2009 18:43:20 -0500 Subject: [IPython-dev] Please help test ipython trunk In-Reply-To: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> Message-ID: <49d6b3500904251643r48613acfre66d017e2ca19f67@mail.gmail.com> Hi, A quick question: I installed IPython using python setupegg.py develop command. After seeing your email I did bzr pull. My shell shows: All changes applied successfully. Now on revision 1169. But when I launch IPython it says: IPython 0.10.bzr.r1163 -- An enhanced Interactive Python. What is wrong with this? G?khan On Sat, Apr 25, 2009 at 6:10 PM, Brian Granger wrote: > Hi, > > After a few weeks of work, we have just merged a massive branch into > the ipython trunk. Because of the massive numbers of changes that > have been merged in, we really need some help testing out IPython > before we cut a 0.10 release (we are basically done merging in things > for 0.10, more on that in a separate email thread). Here is how you > can help: > > 1. Get the latest trunk > > bzr branch lp:ipython > > 2. Install and run the test suite: > > iptest > > 3. Try out lots of things to see if anything is broken > > 4. Report back > > Thanks! > > Brian > _______________________________________________ > 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 dsdale24 at gmail.com Sat Apr 25 20:10:27 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Sat, 25 Apr 2009 20:10:27 -0400 Subject: [IPython-dev] Please help test ipython trunk In-Reply-To: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> Message-ID: Hi Brian, On Sat, Apr 25, 2009 at 7:10 PM, Brian Granger wrote: > Hi, > > After a few weeks of work, we have just merged a massive branch into > the ipython trunk. Because of the massive numbers of changes that > have been merged in, we really need some help testing out IPython > before we cut a 0.10 release (we are basically done merging in things > for 0.10, more on that in a separate email thread). Here is how you > can help: > > 1. Get the latest trunk > > bzr branch lp:ipython > > 2. Install and run the test suite: > > iptest > > 3. Try out lots of things to see if anything is broken > > 4. Report back > I was just reinstalling 64-bit Jaunty on a dual core laptop when I saw your email. I updated my branch, installed and first ran "python setupegg.py nosetests" which yielded: EEEEE...E.S..S..E.S...SS..SSS.................S......SSS.S.S.Could not open file for safe execution. I know the tests are supposed to be run with iptest, I was just curious. When I run with iptest I get a number of errors because I haven't installed twisted: Failure: ImportError (No module named zope.interface) ... ERROR Failure: ImportError (No module named twisted.python) ... ERROR Failure: ImportError (No module named twisted.python) ... ERROR Failure: ImportError (No module named twisted.python) ... ERROR Failure: ImportError (No module named twisted.trial) ... ERROR Failure: ImportError (No module named twisted.python) ... ERROR Failure: ImportError (No module named twisted.python) ... ERROR Failure: ImportError (No module named twisted.python) ... ERROR I installed the libraries needed for parallel operation, and got a few errors from iptest: FAILED (failures=3) ***************************************************************************** IPython test set: trial Traceback (most recent call last): File "/usr/lib/python2.6/dist-packages/twisted/python/usage.py", line 241, in parseOptions self.postOptions() File "/usr/lib/python2.6/dist-packages/twisted/scripts/trial.py", line 293, in postOptions self['reporter'] = self._loadReporterByName(self['reporter']) File "/usr/lib/python2.6/dist-packages/twisted/scripts/trial.py", line 279, in _loadReporterByName for p in plugin.getPlugins(itrial.IReporter): File "/usr/lib/python2.6/dist-packages/twisted/plugin.py", line 200, in getPlugins allDropins = getCache(package) --- --- File "/usr/lib/python2.6/dist-packages/twisted/plugin.py", line 179, in getCache dropinPath.setContent(pickle.dumps(dropinDotCache)) File "/usr/lib/python2.6/dist-packages/twisted/python/filepath.py", line 623, in setContent f = sib.open('w') File "/usr/lib/python2.6/dist-packages/twisted/python/filepath.py", line 433, in open return open(self.path, mode+'b') exceptions.IOError: [Errno 13] Permission denied: '/usr/lib/python2.6/dist-packages/twisted/plugins/dropin.cache.new' --------- and: testStrictDict ... ERROR: An unexpected error occurred while tokenizing input The following traceback may be corrupted or invalid The error message is: ('EOF in multi-line statement', (37, 0)) -------- Finally, I ran the following: $ iptest -v IPython.frontend /usr/lib/python2.6/dist-packages/foolscap/banana.py:2: DeprecationWarning: the sets module is deprecated import struct, sets, time /usr/lib/python2.6/dist-packages/foolscap/vocab.py:2: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha Check that is_complete works. ... ok Tests line completion heuristic. ... ok Tests line completion heuristic. ... ok Tests line completion heuristic. ... ok IPython.frontend.tests.test_prefilterfrontend.test_capture ... ok IPython.frontend.tests.test_prefilterfrontend.test_completion_equal ... FAIL IPython.frontend.tests.test_prefilterfrontend.test_completion_indexing ... FAIL IPython.frontend.tests.test_prefilterfrontend.test_completion_parenthesis ... ok IPython.frontend.tests.test_prefilterfrontend.test_completion_simple ... ok IPython.frontend.tests.test_prefilterfrontend.test_execution ... FAIL IPython.frontend.tests.test_prefilterfrontend.test_help ... ok IPython.frontend.tests.test_prefilterfrontend.test_magic ... ok IPython.frontend.tests.test_prefilterfrontend.test_multiline ... ok A simple test to see if we can execute a process and get the output. ... ok Checks that we can send characters on stdin to the process. ... ok Check that we can kill a process, and its subprocess. ... ok ====================================================================== FAIL: IPython.frontend.tests.test_prefilterfrontend.test_completion_equal ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/python-support/python2.6/nose/case.py", line 182, in runTest self.test(*self.arg) File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 82, in my_func out = func() File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 241, in test_completion_equal assert_equal(f.input_buffer, 'a=1.__') AssertionError: 'a=1.' != 'a=1.__' >> raise self.failureException, \ (None or '%r != %r' % ('a=1.', 'a=1.__')) ====================================================================== FAIL: IPython.frontend.tests.test_prefilterfrontend.test_completion_indexing ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/python-support/python2.6/nose/case.py", line 182, in runTest self.test(*self.arg) File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 82, in my_func out = func() File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 231, in test_completion_indexing assert_equal(f.input_buffer, 'a[0].__') AssertionError: 'a[0].' != 'a[0].__' >> raise self.failureException, \ (None or '%r != %r' % ('a[0].', 'a[0].__')) ====================================================================== FAIL: IPython.frontend.tests.test_prefilterfrontend.test_execution ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/python-support/python2.6/nose/case.py", line 182, in runTest self.test(*self.arg) File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 82, in my_func out = func() File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 103, in test_execution assert_equal(out_value, '1\n') AssertionError: '>print(1)\n1\n' != '1\n' >> raise self.failureException, \ (None or '%r != %r' % ('>print(1)\n1\n', '1\n')) ---------------------------------------------------------------------- Ran 16 tests in 0.209s FAILED (failures=3) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Sat Apr 25 23:19:28 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sat, 25 Apr 2009 20:19:28 -0700 Subject: [IPython-dev] Please help test ipython trunk In-Reply-To: References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> Message-ID: <6ce0ac130904252019o67b3d736gd6d4b84c2a083916@mail.gmail.com> Darren, Thanks for running this. As you can see, our testing stuff is a mess right now. Due to some subtle things about nose and Twisted, you definitely need to use iptest to run our test suite. See below for a few specific comments though > I installed the libraries needed for parallel operation, and got a few > errors from iptest: > > FAILED (failures=3) > ***************************************************************************** > IPython test set: trial > Traceback (most recent call last): > ? File "/usr/lib/python2.6/dist-packages/twisted/python/usage.py", line 241, > in > parseOptions > > self.postOptions() > ? File "/usr/lib/python2.6/dist-packages/twisted/scripts/trial.py", line > 293, in > postOptions > ??? self['reporter'] = > self._loadReporterByName(self['reporter']) > ? File "/usr/lib/python2.6/dist-packages/twisted/scripts/trial.py", line > 279, in > _loadReporterByName > ??? for p in > plugin.getPlugins(itrial.IReporter): > ? File "/usr/lib/python2.6/dist-packages/twisted/plugin.py", line 200, in > getPlugins > ??? allDropins = > getCache(package) > --- > --- > ? File "/usr/lib/python2.6/dist-packages/twisted/plugin.py", line 179, in > getCache > > dropinPath.setContent(pickle.dumps(dropinDotCache)) > ? File "/usr/lib/python2.6/dist-packages/twisted/python/filepath.py", line > 623, in > setContent > ??? f = > sib.open('w') > ? File "/usr/lib/python2.6/dist-packages/twisted/python/filepath.py", line > 433, in > open > ??? return open(self.path, > mode+'b') > exceptions.IOError: [Errno 13] Permission denied: > '/usr/lib/python2.6/dist-packages/twisted/plugins/dropin.cache.new' This (in my opinion, although the twisted devs disagree) is a bug in twisted. The first time you run twisted after installation it has to be run with sudo. Just do: $ sudo trial # wait a while # sudo rm _trial_temp Then retry iptest: $ iptest And the twisted tests should run using trial. > and: > > ??? testStrictDict ... ERROR: An unexpected error occurred while tokenizing > input > The following traceback may be corrupted or > invalid > The error message is: ('EOF in multi-line statement', (37, 0)) > -------- We know about this one. > Finally, I ran the following: > > $ iptest -v IPython.frontend > /usr/lib/python2.6/dist-packages/foolscap/banana.py:2: DeprecationWarning: > the sets module is > deprecated > ? import struct, sets, > time > /usr/lib/python2.6/dist-packages/foolscap/vocab.py:2: DeprecationWarning: > the sha module is deprecated; use the hashlib module > instead > ? import > sha > Check that is_complete works. ... > ok > Tests line completion heuristic. ... > ok > Tests line completion heuristic. ... > ok > Tests line completion heuristic. ... > ok > IPython.frontend.tests.test_prefilterfrontend.test_capture ... > ok > IPython.frontend.tests.test_prefilterfrontend.test_completion_equal ... > FAIL > IPython.frontend.tests.test_prefilterfrontend.test_completion_indexing ... > FAIL > IPython.frontend.tests.test_prefilterfrontend.test_completion_parenthesis > ... ok > IPython.frontend.tests.test_prefilterfrontend.test_completion_simple ... > ok > IPython.frontend.tests.test_prefilterfrontend.test_execution ... > FAIL > IPython.frontend.tests.test_prefilterfrontend.test_help ... > ok > IPython.frontend.tests.test_prefilterfrontend.test_magic ... > ok > IPython.frontend.tests.test_prefilterfrontend.test_multiline ... > ok > A simple test to see if we can execute a process and get the output. ... > ok > Checks that we can send characters on stdin to the process. ... > ok > Check that we can kill a process, and its subprocess. ... > ok > > ====================================================================== > FAIL: IPython.frontend.tests.test_prefilterfrontend.test_completion_equal > ---------------------------------------------------------------------- > Traceback (most recent call last): > ? File "/var/lib/python-support/python2.6/nose/case.py", line 182, in > runTest > ??? self.test(*self.arg) > ? File > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > line 82, in my_func > ??? out = > func() > ? File > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > line 241, in test_completion_equal > ??? assert_equal(f.input_buffer, 'a=1.__') > AssertionError: 'a=1.' != 'a=1.__' >>>? raise self.failureException, \ > ????????? (None or '%r != %r' % ('a=1.', 'a=1.__')) > > > ====================================================================== > FAIL: IPython.frontend.tests.test_prefilterfrontend.test_completion_indexing > ---------------------------------------------------------------------- > Traceback (most recent call last): > ? File "/var/lib/python-support/python2.6/nose/case.py", line 182, in > runTest > ??? self.test(*self.arg) > ? File > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > line 82, in my_func > ??? out = func() > ? File > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > line 231, in test_completion_indexing > ??? assert_equal(f.input_buffer, 'a[0].__') > AssertionError: 'a[0].' != 'a[0].__' >>>? raise self.failureException, \ > ????????? (None or '%r != %r' % ('a[0].', 'a[0].__')) > > > ====================================================================== > FAIL: IPython.frontend.tests.test_prefilterfrontend.test_execution > ---------------------------------------------------------------------- > Traceback (most recent call last): > ? File "/var/lib/python-support/python2.6/nose/case.py", line 182, in > runTest > ??? self.test(*self.arg) > ? File > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > line 82, in my_func > ??? out = func() > ? File > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > line 103, in test_execution > ??? assert_equal(out_value, '1\n') > AssertionError: '>print(1)\n1\n' != '1\n' >>>? raise self.failureException, \ > ????????? (None or '%r != %r' % ('>print(1)\n1\n', '1\n')) Thanks, we are having lots of trouble with this test module. Thought we got it solved, but I guess not. Thanks! Brian From gael.varoquaux at normalesup.org Sun Apr 26 08:30:50 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 26 Apr 2009 14:30:50 +0200 Subject: [IPython-dev] Please help test ipython trunk In-Reply-To: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> Message-ID: <20090426123050.GB31240@phare.normalesup.org> On Sat, Apr 25, 2009 at 04:10:25PM -0700, Brian Granger wrote: > After a few weeks of work, we have just merged a massive branch into > the ipython trunk. Because of the massive numbers of changes that > have been merged in, we really need some help testing out IPython > before we cut a 0.10 release (we are basically done merging in things > for 0.10, more on that in a separate email thread). Here is how you > can help: > 1. Get the latest trunk > bzr branch lp:ipython > 2. Install and run the test suite: > iptest Everything passes here. Thanks for your work. Ga?l From dsdale24 at gmail.com Sun Apr 26 08:59:52 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Sun, 26 Apr 2009 08:59:52 -0400 Subject: [IPython-dev] Please help test ipython trunk In-Reply-To: <6ce0ac130904252019o67b3d736gd6d4b84c2a083916@mail.gmail.com> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> <6ce0ac130904252019o67b3d736gd6d4b84c2a083916@mail.gmail.com> Message-ID: Hi Brian, On Sat, Apr 25, 2009 at 11:19 PM, Brian Granger wrote: > Darren, > > Thanks for running this. As you can see, our testing stuff is a mess > right now. Due to some subtle things about nose and Twisted, you > definitely need to use iptest to run our test suite. In that case, I suggest raising an error if setupegg.py finds nosetests in sys.argv, since running that command seems to yield a zombie ipython process that has to be stopped with ctrl-z. > See below for a > few specific comments though > > > I installed the libraries needed for parallel operation, and got a few > > errors from iptest: > > > > FAILED (failures=3) > > > ***************************************************************************** > > IPython test set: trial > > Traceback (most recent call last): > > File "/usr/lib/python2.6/dist-packages/twisted/python/usage.py", line > 241, > > in > > parseOptions > > > > self.postOptions() > > File "/usr/lib/python2.6/dist-packages/twisted/scripts/trial.py", line > > 293, in > > postOptions > > self['reporter'] = > > self._loadReporterByName(self['reporter']) > > File "/usr/lib/python2.6/dist-packages/twisted/scripts/trial.py", line > > 279, in > > _loadReporterByName > > for p in > > plugin.getPlugins(itrial.IReporter): > > File "/usr/lib/python2.6/dist-packages/twisted/plugin.py", line 200, in > > getPlugins > > allDropins = > > getCache(package) > > --- > > --- > > File "/usr/lib/python2.6/dist-packages/twisted/plugin.py", line 179, in > > getCache > > > > dropinPath.setContent(pickle.dumps(dropinDotCache)) > > File "/usr/lib/python2.6/dist-packages/twisted/python/filepath.py", > line > > 623, in > > setContent > > f = > > sib.open('w') > > File "/usr/lib/python2.6/dist-packages/twisted/python/filepath.py", > line > > 433, in > > open > > return open(self.path, > > mode+'b') > > exceptions.IOError: [Errno 13] Permission denied: > > '/usr/lib/python2.6/dist-packages/twisted/plugins/dropin.cache.new' > > This (in my opinion, although the twisted devs disagree) is a bug in > twisted. The first time you run twisted after installation it has to > be run with sudo. Just do: > > $ sudo trial > # wait a while > # sudo rm _trial_temp > > Then retry iptest: > > $ iptest > > And the twisted tests should run using trial. > The first time I tried, it had no effect. I ran "sudo trial ipython" instead and then it got better. > > and: > > > > testStrictDict ... ERROR: An unexpected error occurred while > tokenizing > > input > > The following traceback may be corrupted or > > invalid > > The error message is: ('EOF in multi-line statement', (37, 0)) > > -------- > > We know about this one. > > > Finally, I ran the following: > > > > $ iptest -v IPython.frontend > > /usr/lib/python2.6/dist-packages/foolscap/banana.py:2: > DeprecationWarning: > > the sets module is > > deprecated > > import struct, sets, > > time > > /usr/lib/python2.6/dist-packages/foolscap/vocab.py:2: DeprecationWarning: > > the sha module is deprecated; use the hashlib module > > instead > > import > > sha > > Check that is_complete works. ... > > ok > > Tests line completion heuristic. ... > > ok > > Tests line completion heuristic. ... > > ok > > Tests line completion heuristic. ... > > ok > > IPython.frontend.tests.test_prefilterfrontend.test_capture ... > > ok > > IPython.frontend.tests.test_prefilterfrontend.test_completion_equal ... > > FAIL > > IPython.frontend.tests.test_prefilterfrontend.test_completion_indexing > ... > > FAIL > > IPython.frontend.tests.test_prefilterfrontend.test_completion_parenthesis > > ... ok > > IPython.frontend.tests.test_prefilterfrontend.test_completion_simple ... > > ok > > IPython.frontend.tests.test_prefilterfrontend.test_execution ... > > FAIL > > IPython.frontend.tests.test_prefilterfrontend.test_help ... > > ok > > IPython.frontend.tests.test_prefilterfrontend.test_magic ... > > ok > > IPython.frontend.tests.test_prefilterfrontend.test_multiline ... > > ok > > A simple test to see if we can execute a process and get the output. ... > > ok > > Checks that we can send characters on stdin to the process. ... > > ok > > Check that we can kill a process, and its subprocess. ... > > ok > > > > ====================================================================== > > FAIL: IPython.frontend.tests.test_prefilterfrontend.test_completion_equal > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File "/var/lib/python-support/python2.6/nose/case.py", line 182, in > > runTest > > self.test(*self.arg) > > File > > > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > > line 82, in my_func > > out = > > func() > > File > > > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > > line 241, in test_completion_equal > > assert_equal(f.input_buffer, 'a=1.__') > > AssertionError: 'a=1.' != 'a=1.__' > >>> raise self.failureException, \ > > (None or '%r != %r' % ('a=1.', 'a=1.__')) > > > > > > ====================================================================== > > FAIL: > IPython.frontend.tests.test_prefilterfrontend.test_completion_indexing > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File "/var/lib/python-support/python2.6/nose/case.py", line 182, in > > runTest > > self.test(*self.arg) > > File > > > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > > line 82, in my_func > > out = func() > > File > > > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > > line 231, in test_completion_indexing > > assert_equal(f.input_buffer, 'a[0].__') > > AssertionError: 'a[0].' != 'a[0].__' > >>> raise self.failureException, \ > > (None or '%r != %r' % ('a[0].', 'a[0].__')) > > > > > > ====================================================================== > > FAIL: IPython.frontend.tests.test_prefilterfrontend.test_execution > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File "/var/lib/python-support/python2.6/nose/case.py", line 182, in > > runTest > > self.test(*self.arg) > > File > > > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > > line 82, in my_func > > out = func() > > File > > > "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", > > line 103, in test_execution > > assert_equal(out_value, '1\n') > > AssertionError: '>print(1)\n1\n' != '1\n' > >>> raise self.failureException, \ > > (None or '%r != %r' % ('>print(1)\n1\n', '1\n')) > > Thanks, we are having lots of trouble with this test module. Thought > we got it solved, but I guess not. Thanks! I updated this morning and ran iptest again. I see this towards the beginning: ====================================================================== FAIL: IPython.frontend.tests.test_prefilterfrontend.test_completion_equal ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/python-support/python2.6/nose/case.py", line 182, in runTest self.test(*self.arg) File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 82, in my_func out = func() File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 241, in test_completion_equal assert_equal(f.input_buffer, 'a=1.__') AssertionError: 'a=1.' != 'a=1.__' >> raise self.failureException, \ (None or '%r != %r' % ('a=1.', 'a=1.__')) ====================================================================== FAIL: IPython.frontend.tests.test_prefilterfrontend.test_completion_indexing ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/python-support/python2.6/nose/case.py", line 182, in runTest self.test(*self.arg) File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 82, in my_func out = func() File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 231, in test_completion_indexing assert_equal(f.input_buffer, 'a[0].__') AssertionError: 'a[0].' != 'a[0].__' >> raise self.failureException, \ (None or '%r != %r' % ('a[0].', 'a[0].__')) ====================================================================== FAIL: IPython.frontend.tests.test_prefilterfrontend.test_execution ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/python-support/python2.6/nose/case.py", line 182, in runTest self.test(*self.arg) File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 82, in my_func out = func() File "/home/darren/Projects/ipython/IPython/frontend/tests/test_prefilterfrontend.py", line 103, in test_execution assert_equal(out_value, '1\n') AssertionError: '>print(1)\n1\n' != '1\n' >> raise self.failureException, \ (None or '%r != %r' % ('>print(1)\n1\n', '1\n')) And a lots of these later on: /home/darren/Projects/ipython/IPython/kernel/error.py:127: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 No other errors to report. Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorgen.stenarson at bostream.nu Sun Apr 26 09:08:09 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Sun, 26 Apr 2009 15:08:09 +0200 Subject: [IPython-dev] Please help test ipython trunk In-Reply-To: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> Message-ID: <49F45CB9.8090306@bostream.nu> Brian Granger skrev: > Hi, > > After a few weeks of work, we have just merged a massive branch into > the ipython trunk. Because of the massive numbers of changes that > have been merged in, we really need some help testing out IPython > before we cut a 0.10 release (we are basically done merging in things > for 0.10, more on that in a separate email thread). Here is how you > can help: > > 1. Get the latest trunk > > bzr branch lp:ipython > > 2. Install and run the test suite: > > iptest > I get a total crash before any tests are run. The windows error is a File not found error. /J?rgen C:\python\external\ipython-trunk\IPython>python ..\scripts\iptest ***************************************************************************** IPython test set: tests Traceback (most recent call last): File "..\scripts\iptest", line 8, in iptest.main() File "c:\python\external\ipython-trunk\IPython\testing\iptest.py", line 291, in main run_iptestall() File "c:\python\external\ipython-trunk\IPython\testing\iptest.py", line 262, in run_iptestall res = runner.run() File "c:\python\external\ipython-trunk\IPython\testing\iptest.py", line 190, in run return subprocess.call(self.call_args) File "C:\Python25\lib\subprocess.py", line 444, in call return Popen(*popenargs, **kwargs).wait() File "C:\Python25\lib\subprocess.py", line 594, in __init__ errread, errwrite) File "C:\Python25\lib\subprocess.py", line 816, in _execute_child startupinfo) WindowsError: [Error 2] Det g?r inte att hitta filen From gael.varoquaux at normalesup.org Sun Apr 26 10:09:13 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 26 Apr 2009 16:09:13 +0200 Subject: [IPython-dev] merge request (was: Re: Please help test ipython trunk) In-Reply-To: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> Message-ID: <20090426140913.GD31240@phare.normalesup.org> On Sat, Apr 25, 2009 at 04:10:25PM -0700, Brian Granger wrote: > After a few weeks of work, we have just merged a massive branch into > the ipython trunk. Because of the massive numbers of changes that > have been merged in, we really need some help testing out IPython > before we cut a 0.10 release (we are basically done merging in things > for 0.10, more on that in a separate email thread). Hey, Brian, you are probably going to hate me for this, but could you please merge in a tiny bug fix for the wx frontends. I discovered a 'miss-interaction' while playing a bit with the terminal to check it was OK for release. It is in the key-handling code, so it is a nightmare to test, and I don't catch these bugs without smoke testing. It is revision 1172 of my branch, and it is really a tiny bug fix. Hopefully, this is not going to add too much work to the release process. Cheers, Ga?l From prabhu at aero.iitb.ac.in Sun Apr 26 12:34:32 2009 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sun, 26 Apr 2009 22:04:32 +0530 Subject: [IPython-dev] merge request In-Reply-To: <20090426140913.GD31240@phare.normalesup.org> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> <20090426140913.GD31240@phare.normalesup.org> Message-ID: <49F48D18.6050503@aero.iitb.ac.in> Gael Varoquaux wrote: > On Sat, Apr 25, 2009 at 04:10:25PM -0700, Brian Granger wrote: >> After a few weeks of work, we have just merged a massive branch into >> the ipython trunk. Because of the massive numbers of changes that >> have been merged in, we really need some help testing out IPython >> before we cut a 0.10 release (we are basically done merging in things >> for 0.10, more on that in a separate email thread). > > Hey, Brian, you are probably going to hate me for this, but could you > please merge in a tiny bug fix for the wx frontends. I discovered a > 'miss-interaction' while playing a bit with the terminal to check it was > OK for release. It is in the key-handling code, so it is a nightmare to > test, and I don't catch these bugs without smoke testing. It is revision > 1172 of my branch, and it is really a tiny bug fix. Hopefully, this is > not going to add too much work to the release process. Is this the lack of a newline when you do something like print "hello" on the frontend? On Mayavi with lp:ipython and the wx frontend I get this: In [1]: print "hello"hello In [2]: Strangely enough this doesn't happen with ipythonx. Not sure this is an IPython issue or a mayavi one. cheers, prabhu From gael.varoquaux at normalesup.org Sun Apr 26 13:41:05 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 26 Apr 2009 19:41:05 +0200 Subject: [IPython-dev] merge request In-Reply-To: <49F48D18.6050503@aero.iitb.ac.in> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> <20090426140913.GD31240@phare.normalesup.org> <49F48D18.6050503@aero.iitb.ac.in> Message-ID: <20090426174105.GG31240@phare.normalesup.org> On Sun, Apr 26, 2009 at 10:04:32PM +0530, Prabhu Ramachandran wrote: > Is this the lack of a newline when you do something like > > print "hello" > > on the frontend? > > On Mayavi with lp:ipython and the wx frontend I get this: No, this is because we are using a custom subclass of the IPython frontend in Mayavi that is incompatible with the current IPython frontend. The problem is that this class was written by Vibha to add features to the IPython frontend (namely continuation lines) by monkey patching it. I have added the corresponding feature to the main IPython frontend, but as a result the custom subclass is partly broken. Vibha and I are aware of this issue, and we'll have to discuss what the right way to avoid problems is. Maybe a check on IPython's version number. Sorry for these issues. The last edition of the IPython frontend was not terribly mature, and resulting to monkey patching it was not an ideal solution :(. Ga?l From ben_holroyd_1 at hotmail.com Mon Apr 27 07:58:36 2009 From: ben_holroyd_1 at hotmail.com (Ben Holroyd) Date: Mon, 27 Apr 2009 11:58:36 +0000 Subject: [IPython-dev] magic for getting exit status Message-ID: I'm posting this after being advised to get other peoples feedback on a bug report on launch pad. https://bugs.launchpad.net/ipython/+bug/365553 What I'm suggesting is basically something similar to $? in bash to get the exit status, both for magic functions, and normal programs run through the shell. At the moment there isn't a way of checking if a magic function successfully did what it was supposed to, and no way of returning an exit status without it displaying on screen. example: i wrote a magic to cd to a directory and ls its contents (cdl), the obvious way would be to use the existing cd command, except you can't test if its run successfully. I know you can use the subprocess or commands module to get exit codes but its not straight forward and has the disadvantage that you can't check after the fact if a program exited successfully. Any thoughts? _________________________________________________________________ Share your photos with Windows Live Photos ? Free. http://clk.atdmt.com/UKM/go/134665338/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cohen at lpta.in2p3.fr Tue Apr 28 06:04:44 2009 From: cohen at lpta.in2p3.fr (Cohen-Tanugi Johann) Date: Tue, 28 Apr 2009 12:04:44 +0200 Subject: [IPython-dev] Please help test ipython trunk In-Reply-To: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> Message-ID: <49F6D4BC.6080208@lpta.in2p3.fr> hello, on failure in frontend : ====================================================================== FAIL: IPython.frontend.tests.test_prefilterfrontend.test_completion_equal ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/nose/case.py", line 202, in runTest self.test(*self.arg) File "/usr/lib/python2.5/site-packages/IPython/frontend/tests/test_prefilterfrontend.py", line 82, in my_func out = func() File "/usr/lib/python2.5/site-packages/IPython/frontend/tests/test_prefilterfrontend.py", line 241, in test_completion_equal assert_equal(f.input_buffer, 'a=1.__') AssertionError: 'a=1.' != 'a=1.__' and one in tests: FAIL: Test that object's __del__ methods are called on exit. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/nose/case.py", line 202, in runTest self.test(*self.arg) File "/usr/lib/python2.5/site-packages/IPython/tests/test_magic.py", line 69, in test_obj_del nt.assert_equals(out,'obj_del.py: object A deleted') AssertionError: '\x1b[?1034hobj_del.py: object A deleted' != 'obj_del.py: object A deleted' My system is a linux box, and here is the fingerprint of my python install: ============================================================================ BUILDING IPYTHON python: 2.5.1 (r251:54863, Jul 10 2008, 17:24:48) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] platform: linux2 OPTIONAL DEPENDENCIES Zope.Interface: yes Twisted: 8.1.0 Foolscap: 0.2.8 OpenSSL: 0.6 sphinx: 0.3 pygments: 0.10 nose: 0.10.0 pexpect: 2.3 bye, Johann Brian Granger wrote: > Hi, > > After a few weeks of work, we have just merged a massive branch into > the ipython trunk. Because of the massive numbers of changes that > have been merged in, we really need some help testing out IPython > before we cut a 0.10 release (we are basically done merging in things > for 0.10, more on that in a separate email thread). Here is how you > can help: > > 1. Get the latest trunk > > bzr branch lp:ipython > > 2. Install and run the test suite: > > iptest > > 3. Try out lots of things to see if anything is broken > > 4. Report back > > Thanks! > > Brian > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg.net at gmail.com Tue Apr 28 12:01:16 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Apr 2009 09:01:16 -0700 Subject: [IPython-dev] Please help test ipython trunk In-Reply-To: <49F6D4BC.6080208@lpta.in2p3.fr> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> <49F6D4BC.6080208@lpta.in2p3.fr> Message-ID: <6ce0ac130904280901k73163febwadc4828619e9b6a3@mail.gmail.com> Thanks! We know about these and have tickets on them, but it is great to have more data points. Brian On Tue, Apr 28, 2009 at 3:04 AM, Cohen-Tanugi Johann wrote: > hello, > on failure in frontend : > ====================================================================== > FAIL: IPython.frontend.tests.test_prefilterfrontend.test_completion_equal > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/usr/lib/python2.5/site-packages/nose/case.py", line 202, in runTest > ? self.test(*self.arg) > ?File > "/usr/lib/python2.5/site-packages/IPython/frontend/tests/test_prefilterfrontend.py", > line 82, in my_func > ? out = func() > ?File > "/usr/lib/python2.5/site-packages/IPython/frontend/tests/test_prefilterfrontend.py", > line 241, in test_completion_equal > ? assert_equal(f.input_buffer, 'a=1.__') > AssertionError: 'a=1.' != 'a=1.__' > > and one in tests: > FAIL: Test that object's __del__ methods are called on exit. > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/usr/lib/python2.5/site-packages/nose/case.py", line 202, in runTest > ? self.test(*self.arg) > ?File "/usr/lib/python2.5/site-packages/IPython/tests/test_magic.py", line > 69, in test_obj_del > ? nt.assert_equals(out,'obj_del.py: object A deleted') > AssertionError: '\x1b[?1034hobj_del.py: object A deleted' != 'obj_del.py: > object A deleted' > > My system is a linux box, and here is the fingerprint of my python install: > ============================================================================ > BUILDING IPYTHON > ? ? ? ? ? ? ? python: 2.5.1 (r251:54863, Jul 10 2008, 17:24:48) ?[GCC > ? ? ? ? ? ? ? ? ? ? ? 4.1.2 20070925 (Red Hat 4.1.2-33)] > ? ? ? ? ? ? platform: linux2 > > OPTIONAL DEPENDENCIES > ? ? ? Zope.Interface: yes > ? ? ? ? ? ? ?Twisted: 8.1.0 > ? ? ? ? ? ? Foolscap: 0.2.8 > ? ? ? ? ? ? ?OpenSSL: 0.6 > ? ? ? ? ? ? ? sphinx: 0.3 > ? ? ? ? ? ? pygments: 0.10 > ? ? ? ? ? ? ? ? nose: 0.10.0 > ? ? ? ? ? ? ?pexpect: 2.3 > > > bye, > Johann > > Brian Granger wrote: >> >> Hi, >> >> After a few weeks of work, we have just merged a massive branch into >> the ipython trunk. ?Because of the massive numbers of changes that >> have been merged in, we really need some help testing out IPython >> before we cut a 0.10 release (we are basically done merging in things >> for 0.10, more on that in a separate email thread). ?Here is how you >> can help: >> >> 1. ?Get the latest trunk >> >> bzr branch lp:ipython >> >> 2. ?Install and run the test suite: >> >> iptest >> >> 3. ?Try out lots of things to see if anything is broken >> >> 4. ?Report back >> >> Thanks! >> >> Brian >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > From debian at sp.or.at Tue Apr 28 13:15:53 2009 From: debian at sp.or.at (Stephan Peijnik) Date: Tue, 28 Apr 2009 19:15:53 +0200 Subject: [IPython-dev] Missing manual pages Message-ID: <1240938953.16190.3.camel@sp-desktop.sp-local> Hello, As I haven't seen any progress for the bug report [0] I confirmed I wanted to let you know that I wrote a few manual pages for ipython 0.9.1 whilst packaging for Debian and filed a bug report afterwards. Seeing that 0.10 is coming near I wanted to ask whether it would make sense to include these manual pages? As noted in the bug report the manpages can be obtained here [1]. -- Stephan [0] https://bugs.launchpad.net/ipython/+bug/291143 [1] http://svn.debian.org/viewsvn/python-modules/packages/ipython/trunk/debian/ From ellisonbg.net at gmail.com Tue Apr 28 15:36:57 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Apr 2009 12:36:57 -0700 Subject: [IPython-dev] Missing manual pages In-Reply-To: <1240938953.16190.3.camel@sp-desktop.sp-local> References: <1240938953.16190.3.camel@sp-desktop.sp-local> Message-ID: <6ce0ac130904281236k2785da88jf5688bd5d61f0697@mail.gmail.com> Thanks for pinging us on this ticket. I just changed the status to confirmed and critical and targeted it for the upcoming 0.10 release. Also, thanks for doing the work of writing the man pages! Brian On Tue, Apr 28, 2009 at 10:15 AM, Stephan Peijnik wrote: > Hello, > > As I haven't seen any progress for the bug report [0] I confirmed I > wanted to let you know that I wrote a few manual pages for ipython 0.9.1 > whilst packaging for Debian and filed a bug report afterwards. > > Seeing that 0.10 is coming near I wanted to ask whether it would make > sense to include these manual pages? > > As noted in the bug report the manpages can be obtained here [1]. > > -- Stephan > > [0] https://bugs.launchpad.net/ipython/+bug/291143 > [1] > http://svn.debian.org/viewsvn/python-modules/packages/ipython/trunk/debian/ > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From cburns at berkeley.edu Tue Apr 28 17:14:59 2009 From: cburns at berkeley.edu (Christopher Burns) Date: Tue, 28 Apr 2009 14:14:59 -0700 Subject: [IPython-dev] Please help test ipython trunk In-Reply-To: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> References: <6ce0ac130904251610g10b507aaic8d900388877b43b@mail.gmail.com> Message-ID: <764e38540904281414q1232e20aqa61904b738e34955@mail.gmail.com> On Sat, Apr 25, 2009 at 4:10 PM, Brian Granger wrote: > 1. Get the latest trunk > > bzr branch lp:ipython > > 2. Install and run the test suite: > > iptest I got three errors, all in the cocoa_frontend (or it's test mod). All other tests passed or skipped. Chris ====================================================================== ERROR: Failure: TypeError (objc_ivar() takes at least 1 argument (0 given)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/cburns/local/lib/python2.5/site-packages/nose-0.10.4-py2.5.egg/nose/loader.py", line 364, in loadTestsFromName addr.filename, addr.module) File "/Users/cburns/local/lib/python2.5/site-packages/nose-0.10.4-py2.5.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/Users/cburns/local/lib/python2.5/site-packages/nose-0.10.4-py2.5.egg/nose/importer.py", line 84, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/Users/cburns/src/ipython-trunk/IPython/frontend/cocoa/cocoa_frontend.py", line 73, in class Cell(NSObject): File "/Users/cburns/src/ipython-trunk/IPython/frontend/cocoa/cocoa_frontend.py", line 79, in Cell blockNumber = objc.ivar().unsigned_long() TypeError: objc_ivar() takes at least 1 argument (0 given) ====================================================================== ERROR: Failure: TypeError (objc_ivar() takes at least 1 argument (0 given)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/cburns/local/lib/python2.5/site-packages/nose-0.10.4-py2.5.egg/nose/loader.py", line 364, in loadTestsFromName addr.filename, addr.module) File "/Users/cburns/local/lib/python2.5/site-packages/nose-0.10.4-py2.5.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/Users/cburns/local/lib/python2.5/site-packages/nose-0.10.4-py2.5.egg/nose/importer.py", line 84, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/Users/cburns/src/ipython-trunk/IPython/frontend/cocoa/tests/test_cocoa_frontend.py", line 28, in from IPython.frontend.cocoa.cocoa_frontend import IPythonCocoaController File "/Users/cburns/src/ipython-trunk/IPython/frontend/cocoa/cocoa_frontend.py", line 73, in class Cell(NSObject): File "/Users/cburns/src/ipython-trunk/IPython/frontend/cocoa/cocoa_frontend.py", line 79, in Cell blockNumber = objc.ivar().unsigned_long() TypeError: objc_ivar() takes at least 1 argument (0 given) [ERROR]: IPython.frontend.cocoa.tests.test_cocoa_frontend Traceback (most recent call last): File "/Users/cburns/local/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-i386.egg/twisted/trial/runner.py", line 547, in loadPackage module = modinfo.load() File "/Users/cburns/local/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-i386.egg/twisted/python/modules.py", line 380, in load return self.pathEntry.pythonPath.moduleLoader(self.name) File "/Users/cburns/local/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-i386.egg/twisted/python/modules.py", line 618, in moduleLoader return self._moduleLoader(modname) File "/Users/cburns/local/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-i386.egg/twisted/python/reflect.py", line 426, in namedAny topLevelPackage = _importAndCheckStack(trialname) File "/Users/cburns/local/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-i386.egg/twisted/python/reflect.py", line 377, in _importAndCheckStack return __import__(importName) File "/Users/cburns/src/ipython-trunk/IPython/frontend/cocoa/tests/test_cocoa_frontend.py", line 28, in from IPython.frontend.cocoa.cocoa_frontend import IPythonCocoaController File "/Users/cburns/src/ipython-trunk/IPython/frontend/cocoa/cocoa_frontend.py", line 73, in class Cell(NSObject): File "/Users/cburns/src/ipython-trunk/IPython/frontend/cocoa/cocoa_frontend.py", line 79, in Cell blockNumber = objc.ivar().unsigned_long() exceptions.TypeError: objc_ivar() takes at least 1 argument (0 given)