From fperez at colorado.edu Wed Apr 16 19:03:00 2003 From: fperez at colorado.edu (Fernando Perez) Date: Wed, 16 Apr 2003 17:03:00 -0600 Subject: [IPython-dev] Mailing lists indexed at gmane Message-ID: <3E9DE124.8080309@colorado.edu> Hi all, after a suggestion by Jacek Generowicz, someone (not me) sent in a request for indexing the ipython lists at gmane. I didn't do it but I'm perfectly happy with it, so thanks to whoever did it. For those not familiar with the service, http://gmane.org provides a mailing list to news bridge, which allows you to follow the ipython lists with a news reader. Cheers, Fernando. From fperez at colorado.edu Thu Apr 17 01:50:12 2003 From: fperez at colorado.edu (Fernando Perez) Date: Wed, 16 Apr 2003 23:50:12 -0600 Subject: [IPython-dev] Re: Refactoring of bdist_wininst (PATCH) In-Reply-To: <003d01c28a9a$3dcb8560$e301340a@cyberhigh.fcoe.k12.ca.us> References: <003d01c28a9a$3dcb8560$e301340a@cyberhigh.fcoe.k12.ca.us> Message-ID: <3E9E4094.7030802@colorado.edu> Hi Cory, > Done. install command will now work with distutils 1.02; bdist_wininst > --install-script=ipython_post_install.py will also work with distutils > 1.03. I finally got around to implementing your patches for Windows installation (sorry for the huge delay). I work under RedHat 8.0, and I can get the wininst target to build me a nice .exe installer, but unfortunately it doesn't seem to execute the post-install script at all. If I run the setup.py from inside the zip target, it's ok: the post-installer gets loaded via regular python code, just as it did before. But under distutils 1.0.3 (the one which comes with python 2.2.1), I can't seem to use the --install-script option. I even looked at the distutils sources for the bdist_wininst command, and such an option is just not recognized. I really liked the Windows real executable installer, so I'd love to close this last gap, but I have no idea at this point how to specify an additional script to be run at the end of the install. Any pointers? Thanks for any help, f. ps. I've cc'd the ipython mailing list, and if you remain interested in ipython I'd suggest you join it. I prefer to keep the discussions on list, since they get archived and others can also contribute ideas. The new ipython homepage and mailing list urls are: http://ipython.scipy.org/ http://scipy.net/mailman/listinfo/ipython-dev http://scipy.net/mailman/listinfo/ipython-user From cdodt at fcoe.k12.ca.us Thu Apr 17 10:32:56 2003 From: cdodt at fcoe.k12.ca.us (Cory Dodt) Date: Thu, 17 Apr 2003 07:32:56 -0700 Subject: [IPython-dev] RE: Refactoring of bdist_wininst (PATCH) In-Reply-To: <3E9E4094.7030802@colorado.edu> Message-ID: <000c01c304ee$3cb79e60$e901340a@cyberhigh.fcoe.k12.ca.us> Distutils 1.0.3 is not included with Python 2.2 :-). You either have to get it from Distutils CVS or from Python 2.3. Either one of those should give you the --install-script option. Let me know how it goes! C -----Original Message----- From: Fernando Perez [mailto:fperez at colorado.edu] Sent: Wednesday, April 16, 2003 10:50 PM To: Cory Dodt; ipython-dev at scipy.net Subject: Re: Refactoring of bdist_wininst (PATCH) > > But under distutils 1.0.3 (the one which comes with python 2.2.1), I can't > seem to use the --install-script option. I even looked at the distutils > sources for the bdist_wininst command, and such an option is just not > recognized. From fperez at colorado.edu Thu Apr 17 11:01:30 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu, 17 Apr 2003 09:01:30 -0600 Subject: [IPython-dev] RE: Refactoring of bdist_wininst (PATCH) In-Reply-To: <000c01c304ee$3cb79e60$e901340a@cyberhigh.fcoe.k12.ca.us> References: <000c01c304ee$3cb79e60$e901340a@cyberhigh.fcoe.k12.ca.us> Message-ID: <3E9EC1CA.3060800@colorado.edu> Cory Dodt wrote: > Distutils 1.0.3 is not included with Python 2.2 :-). You either have to > get it from Distutils CVS or from Python 2.3. Either one of those > should give you the --install-script option. Well, then they need to fix their version strings: Python 2.2.1 (#1, Aug 30 2002, 12:15:30) Type "copyright", "credits" or "license" for more information. IPython 0.2.15pre4 -- An enhanced Interactive Python. ? -> Introduction to IPython's features. @magic -> Information about IPython's 'magic' @ functions. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [1]: import distutils In [2]: distutils.__version__ Out[2]: '1.0.3' At any rate, I beleive you that the install-script option is _not_ in the distutils which comes with python 2.2.1, whatever version it is. So I'll go fetch out the CVS code and see how it goes. Thanks for the info. Cheers, f From fperez at colorado.edu Thu Apr 17 14:43:47 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu, 17 Apr 2003 12:43:47 -0600 Subject: [IPython-dev] [Fwd: [ANN] A new IPython is out. Version: 0.2.15pre4] Message-ID: <3E9EF5E3.8080100@colorado.edu> Hi all, I've just put out a new pre-release, because recently a fair amount of changes have been made, and a few of those are rather critical bugs. In particular, for first time users ipython could damage binary files in their home directory, and for Gnuplot users, using hardcopy() would send 21 copies of each plot to their printer! Many other smaller changes are listed below in the NEWS file appended at the end. I think very soon I want to put out the current code with version number 0.4, indicating a reasonably stable codebase which I think has matured quite a bit. Any objections? There are a few minor tasks remaining before that, which I'll discussed in a separate email cc-ed to a few specific targets :) I am now including again source and binary rpms by default (besides tar.gz and zip sources). Andrea Riciputi is doing the same for Fink users at http://fink.sourceforge.net/pdb/package.php/ipython. (Andrea, could you please update the url to http://ipython.scipy.org? Thanks). Jack Moffit is offering Debian packages at http://packages.debian.org/unstable/python/ipython.html and Enjoy! Best, f. -------- Original Message -------- Subject: [ANN] A new IPython is out. Version: 0.2.15pre4 Date: Thu, 17 Apr 2003 12:33:47 -0600 From: Fernando Perez To: fperez at colorado.edu Changes between the last two releases (major or minor) Note that this is an auto-generated diff of the ChangeLogs 2003-04-17 *** Released version 0.2.15pre4 2003-04-17 Fernando Perez * setup.py (scriptfiles): Split windows-specific stuff over to a separate file, in an attempt to have a Windows GUI installer. That didn't work, but part of the groundwork is done. * IPython/UserConfig/ipythonrc: Added M-i, M-o and M-I for indent/unindent with 4 spaces. Particularly useful in combination with the new auto-indent option. 2003-04-16 Fernando Perez * IPython/Magic.py: various replacements of self.rc for self.shell.rc. A lot more remains to be done to fully disentangle this class from the main Shell class. * IPython/GnuplotRuntime.py: added checks for mouse support so that we don't try to enable it if the current gnuplot doesn't really support it. Also added checks so that we don't try to enable persist under Windows (where Gnuplot doesn't recognize the option). * IPython/iplib.py (InteractiveShell.interact): Added optional auto-indenting code, after a patch by King C. Shu . It's off by default because it doesn't get along well with pasting indented code. If I ever figure out how to make that part go well, it will become on by default. * IPython/Prompts.py (Prompt1.auto_rewrite): Fixed bug which would crash ipython if there was an unmatched '%' in the user's prompt string. Reported by Thorsten Kampe . * IPython/iplib.py (InteractiveShell.interact): removed the ability to ask the user whether he wants to crash or not at the 'last line' exception handler. Calling functions at that point changes the stack, and the error reports would have incorrect tracebacks. * IPython/Magic.py (Magic.magic_page): Added new @page magic, to pass through a peger a pretty-printed form of any object. After a contribution by Olivier Aubert 2003-04-14 Fernando Perez * IPython/iplib.py (InteractiveShell.user_setup): Fixed bug where all files in ~ would be modified at first install (instead of ~/.ipython). This could be potentially disastrous, as the modification (make line-endings native) could damage binary files. 2003-04-10 Fernando Perez * IPython/iplib.py (InteractiveShell.handle_help): Modified to handle only lines which are invalid python. This now means that lines like 'x=1 #?' execute properly. Thanks to Jeffery Collins for the bug report. 2003-04-01 Fernando Perez * IPython/iplib.py (InteractiveShell.showtraceback): Fixed bug where failing to set sys.last_traceback would crash pdb.pm(). Thanks to Jeffery D. Collins for the bug report. 2003-03-25 Fernando Perez * IPython/Magic.py (Magic.magic_prun): rstrip() output of profiler before printing it (it had a lot of spurious blank lines at the end). * IPython/Gnuplot2.py (Gnuplot.hardcopy): fixed bug where lpr output would be sent 21 times! Obviously people don't use this too often, or I would have heard about it. 2003-03-24 Fernando Perez * setup.py (scriptfiles): renamed the data_files parameter from 'base' to 'data' to fix rpm build issues. Thanks to Ralf Ahlbrink for the patch. 2003-03-20 Fernando Perez * IPython/genutils.py (error): added error() and fatal() functions. From fperez at colorado.edu Thu Apr 17 15:12:21 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu, 17 Apr 2003 13:12:21 -0600 Subject: [IPython-dev] ToDo for 0.4.0 Message-ID: <3E9EFC95.7040309@colorado.edu> Hi all, I'd like to put out a list of things (small) I'd like to do before relabeling the current code as 0.4.0. In the past few months I think most key bugs have been squashed and IPython's user base seems to be growing, so I have a certain trust that nothing too ugly lurks underneath (besides, I use it every day myself). After 0.4, and now that we have a decent CVS setup in place, it might be feasible to start rewriting some of the infrastructure with an eye for integration with pycrust. I've cc-ed some people who in the past have dealt with some of these issues, but all hands are always welcome. If people are bothered by this, I can stop and use the list only. I only do this occasionally if I want some people specifically not to miss a message, since most of us tend to ignore mailing list traffic when busy. Here are the things I see as low-hanging fruit before calling the code 0.4: - Finish X/Emacs stuff. This requires a small amount of work on my part (cleaning up the internal history) and some from Alex. Mainly, I'd need Alex to double-check the manual because a lot of stuff there in the emacs section is outdated. And we'd need to decide whether to package the *.el files with ipython or not. - Man pages. Jack wrote some man pages for Debian, I'd like to get those into the main distro. Right now ipython has 'ipython --help', but it's always nice to have real man pages. After these two things, I see the next two as lower priority (could be done during the life of 0.4.x): - rlcompleter2: If the filename completion is finished, I'd REALLY want to include support for it within ipython. This is Holger's baby, and it's quite impressive. - Windows installer: I spend several hours trying to build a proper Windows GUI installer, and failed. I can get the thing to build, but I can not figure out how to have the post-install script do all it needs to do. The problem is that the script gets run from path\to\python\Scripts, and it has no idea of where all the files it wants to copy are to begin with. When it runs from an unzipped directory, it's fine: all relevant files are in the doc/ subdir from the zipball, so life is good. But once the GUI thing moves it over elsewhere, how is it going to know where the original files were? Each time I summon the courage to boot into Windows I end up failing miserably with seemingly simple tasks. I'm sure all these things can be done, I'm just fairly incompetent with Windows issues and I simply don't have the time (nor the interest, to be honest ;) to learn. So anyone who can help with Windows issues is welcome to jump in. Otherwise ipython will continue to only have .zip distribution for Windows in the future [not to mention other bugs in that platform which I haven't the foggiest idea how to solve :( ] Best regards, and thanks to all for your help so far. f. From fperez at colorado.edu Thu Apr 17 19:40:41 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu, 17 Apr 2003 17:40:41 -0600 Subject: [IPython-dev] New bug tracker for IPython Message-ID: <3E9F3B79.7070005@colorado.edu> Hi all, I just wanted to let you know that, thanks to Enthought's Joe Cooper, ipython now has a shiny new bug tracker at: http://www.scipy.net/roundup/ipython I'd like to strongly encourage everyone to use this in the future for tracking bugs instead of email, as it allows me to have a far better organized control over bugs. If IPython crashes and generates a crash report automatically, you can just upload the file as a new bug into the tracker. For the time being I'm leaving anonymous posting open, just to lower as much as possible the barrier of entry. But I hope you login before submitting a report, as otherwise it will be impossible for me to ask for further details about a bug if I need them. Best regards, and a big thank you to Joe Cooper for this, Fernando. From fperez at colorado.edu Thu Apr 17 19:49:47 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu, 17 Apr 2003 17:49:47 -0600 Subject: [IPython-dev] Re: iPython on Windows In-Reply-To: References: Message-ID: <3E9F3D9B.8040807@colorado.edu> Hi David, my apologies for the long delay in replying, I'm trying to catch up on email. By the way, I'm cc-ing the list because now that ipyhton has proper mailing lists, I'm trying to keep all discussions going on there. You can find links to the lists at ipython's new home, http://ipython.scipy.org David LeBlanc wrote: > What do you think of the idea of making iPython use the python curses > module on Unixen/Linuxen and PDCurses on the other platforms it supports, > including Unixen/Linuxen, OS/2 (like that matters anymore ;)) and Windows? > Thanks to an enquiry on python-dev, I was sent a python wrapper for > PDCurses 2.4. > > If this is something you're not interested in, what are the prospects of > creating an IO wrapper for iPython such that all iPython's IO are done via > this "iPythonIO" class, which could then be twiggled to use it's existing > scheme or curses or whatever? Well, I tend to be -1 on the idea of curses support for a simple reason: it looks complicated, I don't have much time for it, and right now I'm more looking into integrating IPython with PyCrust (from WxPython) for fancier features. My view is that ipython will remain a command-line tool, but with suitable refactoring it should be possible to 'plug' it into PyCrust as its interpreter shell (and benefit from PyCrust's graphical features). > > If you are in any way amenable to this idea, I would be interested in > helping out, at least to the extent of getting a curses style IO working on > Windows using PDCurses (and would hope that you could find room in your > distro directory for a "wincurses.zip" file). OTOH, if someone is willing to pitch in the necessary effort and we can have curses support when in a terminal, GREAT! It's simply more than I can handle now, but there is a priori no reason why it couldn't be done so that ipython could function: - as today, in environments lacking curses. - with fancy multi-line editing and whatnot if curses is available - optionally plugged into PyCrust for a graphical environment. Proper modularity of the design is the key to achieve this. I certainly can't do all that, but I'd more than welcome any efforts from others. I took a long time to respond to your message, partly because I wanted to settle things over at ipython's new home, get the mailing lists and bug tracker going, etc. But now that we have a proper setup it's far easier to coordinate work with other developers. > WRT the readline issue(s), it could be that iPython either just needs to > realize that readline is already pre-installed earlier in the python > loading, or maybe Gonnerman's readline can be dynamically loaded. It might > also require living with a restricted subset of readline functionality/live > with his platform defaults. The attached file is his > site-packages/readline.py, which pyhthon seems to understand it's supposed > to load on startup of the interpreter by virtue of it's presence in > site-packages (temporarily renamed to readline.py.save to avoid the > bouncing iPython problem). A fast look suggests that parse_and_bind being > no-oped might be a problem for iPython - but OTOH, some of the bindings > (for history at least) seem to be hard coded into his readline. Looks like > you need readline.set-completer() too, which is also a no-op. FWIW, > Gonnerman's readline installs a .pyd that does the keyboard hook and > reflects all the readline calls etc. back into python (the attached file), > so I think it would be easy to add these, but that could just be me talking > out of ignorance. (NB, I renamed readline.py.save to xreadline.py and > confirmed that it can be dynamically loaded ("import xreadline as > readline") instead of at startup.) I'm sure we could work on checking things so that Gonnerman's readline doesn't crash. Even limited readline support under windows would be a huge boost. But these are Windows issues, and as I've said before here, my time for working on Windows is nearly zero. Again, all help/patches from users will be more than welcome. I hope you can join in the mailing list and can jump into the ipython effort! Best regards, f. From Kasper.Souren at ircam.fr Tue Apr 29 14:17:05 2003 From: Kasper.Souren at ircam.fr (Kasper Souren) Date: Tue, 29 Apr 2003 18:17:05 +0000 Subject: [IPython-dev] possible feature request: auto-run Message-ID: <200304291817.05898.Kasper.Souren@ircam.fr> Hi! I just had a little idea for a new IPython feature. I don't know if it's feasible, but it seems quite useful: auto-run .py files. Suppose you are editing a .py file (say test.py) and you're also working in ipython to check out the changes you made. Currently you need to do a "run test" every time you changed something. Now instead of doing the run yourself, IPython could look out for changes in certain files (like test.py) and rerun those files for you. Of course there is at least one big problem with this: what to do if the file causes some errors. So now I'm interested in your reactions. :) bye, Kasper From fperez at colorado.edu Tue Apr 29 17:41:40 2003 From: fperez at colorado.edu (Fernando Perez) Date: Tue, 29 Apr 2003 15:41:40 -0600 Subject: [IPython-dev] possible feature request: auto-run In-Reply-To: <200304291817.05898.Kasper.Souren@ircam.fr> References: <200304291817.05898.Kasper.Souren@ircam.fr> Message-ID: <3EAEF194.5030709@colorado.edu> Kasper Souren wrote: > Hi! > > I just had a little idea for a new IPython feature. I don't know if it's > feasible, but it seems quite useful: auto-run .py files. > > Suppose you are editing a .py file (say test.py) and you're also working in > ipython to check out the changes you made. Currently you need to do a "run > test" every time you changed something. Now instead of doing the run > yourself, IPython could look out for changes in certain files (like test.py) > and rerun those files for you. > > Of course there is at least one big problem with this: what to do if the file > causes some errors. > > So now I'm interested in your reactions. :) Well, I don't see this going in. The effort/benefit ratio is really quite poor, IMHO. For this to work, you'd need to set up a magic function which handles a table of registered functions to watch for changes, and poll them periodically. Since you don't want to interfere with the rest of ipython, you'll need to make it live in its own thread, or put it into a hook somewhere which gets executed at fixed events (more on this later). It's rather complicated to get it right, and considering that python gives you macros, it seems pointless: In [1]: run test.py foo In [2]: macro x 1 Macro `x` created. To execute, type its name (without quotes). Macro contents: __IP.magic_run ("test.py") In [3]: x Out[3]: Executing Macro... foo *** file test was changed here In [4]: x Out[4]: Executing Macro... bar So you can make this a one-letter operation trivially. Considering that you can also: - edit your files using @edit, which automatically executes them, - run ipython within emacs, which gives you a single key acess to executing a file, it seems like we already have this problem fairly well solved. But if you _really_ insist, feel free to add to your _prefilter function something which checks for changes in files and runs them. See the tutorial profile example for details. This way would be fairly easy to implement and you can keep it active in your default profile. I don't want this in the mainline code for now because if it goes in, I have to maintain it :) But feel free to write your own with _prefilter and test it for a while. If it works well, we can put it in the public wiki contributions area (said wiki doesn't exist yet, but we can create one for users to share ipython snippets easily). Sorry to discourage you, but an architectural overhaul of ipython is just a much more important use of my very limited resources right now. Best, Fernando. From Kasper.Souren at ircam.fr Tue Apr 29 18:48:10 2003 From: Kasper.Souren at ircam.fr (Kasper Souren) Date: Tue, 29 Apr 2003 22:48:10 +0000 Subject: [IPython-dev] possible feature request: auto-run In-Reply-To: <3EAEF194.5030709@colorado.edu> References: <200304291817.05898.Kasper.Souren@ircam.fr> <3EAEF194.5030709@colorado.edu> Message-ID: <200304292248.10994.Kasper.Souren@ircam.fr> > It's rather complicated to get it right, and considering that python gives > you macros, it seems pointless: I never really used Matlab for longer than 15 minutes, but it seemed to me that Matlab does this. The reason it can do it, is probably because its language is so simple. It's also not a feature I really need, it's more that it would be a nice thing to have it just because Matlab can do it. (It would be one little step closer to Python world domination ;) XQs me if I'm wrong, but for me it seemed that Matlab normally has one function in one file, and if you call a function it justs picks the file with that name. So that's the reason it works there... I think this auto-run idea is a bit more apropriate for .py's that don't really do something when they are ran. So for files that contain a bunch of functions and classes. > Sorry to discourage you, but an architectural overhaul of ipython is just a > much more important use of my very limited resources right now. Maybe you can keep the idea somewhere in the back of your mind when working on the reconstruction. bye, Kasper