Show More
The requested changes are too big and content was truncated. Show full diff
1 | NO CONTENT: modified file |
|
NO CONTENT: modified file | ||
The requested commit or file is too big and content was truncated. Show full diff |
@@ -1,252 +1,253 b'' | |||||
1 | .. _changes: |
|
1 | .. _changes: | |
2 |
|
2 | |||
3 | ========== |
|
3 | ========== | |
4 | What's new |
|
4 | What's new | |
5 | ========== |
|
5 | ========== | |
6 |
|
6 | |||
7 | .. contents:: |
|
7 | .. contents:: | |
8 | .. |
|
8 | .. | |
9 | 1 Release 0.9 |
|
9 | 1 Release 0.9 | |
10 | 1.1 New features |
|
10 | 1.1 New features | |
11 | 1.2 Bug fixes |
|
11 | 1.2 Bug fixes | |
12 | 1.3 Backwards incompatible changes |
|
12 | 1.3 Backwards incompatible changes | |
13 | 1.4 Changes merged in from IPython1 |
|
13 | 1.4 Changes merged in from IPython1 | |
14 | 1.4.1 New features |
|
14 | 1.4.1 New features | |
15 | 1.4.2 Bug fixes |
|
15 | 1.4.2 Bug fixes | |
16 | 1.4.3 Backwards incompatible changes |
|
16 | 1.4.3 Backwards incompatible changes | |
17 | 2 Release 0.8.4 |
|
17 | 2 Release 0.8.4 | |
18 | 3 Release 0.8.2 |
|
18 | 3 Release 0.8.2 | |
19 | 4 Release 0.8.3 |
|
19 | 4 Release 0.8.3 | |
20 | 5 Older releases |
|
20 | 5 Older releases | |
21 | .. |
|
21 | .. | |
22 |
|
22 | |||
23 |
|
23 | |||
24 | Release 0.9 |
|
24 | Release 0.9 | |
25 | =========== |
|
25 | =========== | |
26 |
|
26 | |||
27 | New features |
|
27 | New features | |
28 | ------------ |
|
28 | ------------ | |
29 |
|
29 | |||
30 | * Laurent's WX application has been given a top-level script called ipython-wx, |
|
30 | * Laurent's WX application has been given a top-level script called ipython-wx, | |
31 | and it has received numerous fixes. We expect this code to be |
|
31 | and it has received numerous fixes. We expect this code to be | |
32 | architecturally better integrated with Gael's WX 'ipython widget' over the |
|
32 | architecturally better integrated with Gael's WX 'ipython widget' over the | |
33 | next few releases. |
|
33 | next few releases. | |
34 |
|
34 | |||
35 | * The Editor synchronization work by Vivian De Smedt has been merged in. This |
|
35 | * The Editor synchronization work by Vivian De Smedt has been merged in. This | |
36 | code adds a number of new editor hooks to synchronize with editors under |
|
36 | code adds a number of new editor hooks to synchronize with editors under | |
37 | Windows. |
|
37 | Windows. | |
38 |
|
38 | |||
39 | * A new, still experimental but highly functional, WX shell by Gael Varoquaux. |
|
39 | * A new, still experimental but highly functional, WX shell by Gael Varoquaux. | |
40 | This work was sponsored by Enthought, and while it's still very new, it is |
|
40 | This work was sponsored by Enthought, and while it's still very new, it is | |
41 | based on a more cleanly organized arhictecture of the various IPython |
|
41 | based on a more cleanly organized arhictecture of the various IPython | |
42 | components. We will continue to develop this over the next few releases as a |
|
42 | components. We will continue to develop this over the next few releases as a | |
43 | model for GUI components that use IPython. |
|
43 | model for GUI components that use IPython. | |
44 |
|
44 | |||
45 | * Another GUI frontend, Cocoa based (Cocoa is the OSX native GUI framework), |
|
45 | * Another GUI frontend, Cocoa based (Cocoa is the OSX native GUI framework), | |
46 | authored by Barry Wark. Currently the WX and the Cocoa ones have slightly |
|
46 | authored by Barry Wark. Currently the WX and the Cocoa ones have slightly | |
47 | different internal organizations, but the whole team is working on finding |
|
47 | different internal organizations, but the whole team is working on finding | |
48 | what the right abstraction points are for a unified codebase. |
|
48 | what the right abstraction points are for a unified codebase. | |
49 |
|
49 | |||
50 | * As part of the frontend work, Barry Wark also implemented an experimental |
|
50 | * As part of the frontend work, Barry Wark also implemented an experimental | |
51 | event notification system that various ipython components can use. In the |
|
51 | event notification system that various ipython components can use. In the | |
52 | next release the implications and use patterns of this system regarding the |
|
52 | next release the implications and use patterns of this system regarding the | |
53 | various GUI options will be worked out. |
|
53 | various GUI options will be worked out. | |
54 |
|
54 | |||
55 | * IPython finally has a full test system, that can test docstrings with |
|
55 | * IPython finally has a full test system, that can test docstrings with | |
56 | IPython-specific functionality. There are still a few pieces missing for it |
|
56 | IPython-specific functionality. There are still a few pieces missing for it | |
57 | to be widely accessible to all users (so they can run the test suite at any |
|
57 | to be widely accessible to all users (so they can run the test suite at any | |
58 | time and report problems), but it now works for the developers. We are |
|
58 | time and report problems), but it now works for the developers. We are | |
59 | working hard on continuing to improve it, as this was probably IPython's |
|
59 | working hard on continuing to improve it, as this was probably IPython's | |
60 | major Achilles heel (the lack of proper test coverage made it effectively |
|
60 | major Achilles heel (the lack of proper test coverage made it effectively | |
61 | impossible to do large-scale refactoring). |
|
61 | impossible to do large-scale refactoring). | |
62 |
|
62 | |||
63 | * The notion of a task has been completely reworked. An `ITask` interface has |
|
63 | * The notion of a task has been completely reworked. An `ITask` interface has | |
64 | been created. This interface defines the methods that tasks need to implement. |
|
64 | been created. This interface defines the methods that tasks need to implement. | |
65 | These methods are now responsible for things like submitting tasks and processing |
|
65 | These methods are now responsible for things like submitting tasks and processing | |
66 | results. There are two basic task types: :class:`IPython.kernel.task.StringTask` |
|
66 | results. There are two basic task types: :class:`IPython.kernel.task.StringTask` | |
67 | (this is the old `Task` object, but renamed) and the new |
|
67 | (this is the old `Task` object, but renamed) and the new | |
68 | :class:`IPython.kernel.task.MapTask`, which is based on a function. |
|
68 | :class:`IPython.kernel.task.MapTask`, which is based on a function. | |
69 | * A new interface, :class:`IPython.kernel.mapper.IMapper` has been defined to |
|
69 | * A new interface, :class:`IPython.kernel.mapper.IMapper` has been defined to | |
70 | standardize the idea of a `map` method. This interface has a single |
|
70 | standardize the idea of a `map` method. This interface has a single | |
71 | `map` method that has the same syntax as the built-in `map`. We have also defined |
|
71 | `map` method that has the same syntax as the built-in `map`. We have also defined | |
72 | a `mapper` factory interface that creates objects that implement |
|
72 | a `mapper` factory interface that creates objects that implement | |
73 | :class:`IPython.kernel.mapper.IMapper` for different controllers. Both |
|
73 | :class:`IPython.kernel.mapper.IMapper` for different controllers. Both | |
74 | the multiengine and task controller now have mapping capabilties. |
|
74 | the multiengine and task controller now have mapping capabilties. | |
75 | * The parallel function capabilities have been reworks. The major changes are that |
|
75 | * The parallel function capabilities have been reworks. The major changes are that | |
76 | i) there is now an `@parallel` magic that creates parallel functions, ii) |
|
76 | i) there is now an `@parallel` magic that creates parallel functions, ii) | |
77 | the syntax for mulitple variable follows that of `map`, iii) both the |
|
77 | the syntax for mulitple variable follows that of `map`, iii) both the | |
78 | multiengine and task controller now have a parallel function implementation. |
|
78 | multiengine and task controller now have a parallel function implementation. | |
79 | * All of the parallel computing capabilities from `ipython1-dev` have been merged into |
|
79 | * All of the parallel computing capabilities from `ipython1-dev` have been merged into | |
80 | IPython proper. This resulted in the following new subpackages: |
|
80 | IPython proper. This resulted in the following new subpackages: | |
81 | :mod:`IPython.kernel`, :mod:`IPython.kernel.core`, :mod:`IPython.config`, |
|
81 | :mod:`IPython.kernel`, :mod:`IPython.kernel.core`, :mod:`IPython.config`, | |
82 | :mod:`IPython.tools` and :mod:`IPython.testing`. |
|
82 | :mod:`IPython.tools` and :mod:`IPython.testing`. | |
83 | * As part of merging in the `ipython1-dev` stuff, the `setup.py` script and friends |
|
83 | * As part of merging in the `ipython1-dev` stuff, the `setup.py` script and friends | |
84 | have been completely refactored. Now we are checking for dependencies using |
|
84 | have been completely refactored. Now we are checking for dependencies using | |
85 | the approach that matplotlib uses. |
|
85 | the approach that matplotlib uses. | |
86 | * The documentation has been completely reorganized to accept the documentation |
|
86 | * The documentation has been completely reorganized to accept the documentation | |
87 | from `ipython1-dev`. |
|
87 | from `ipython1-dev`. | |
88 | * We have switched to using Foolscap for all of our network protocols in |
|
88 | * We have switched to using Foolscap for all of our network protocols in | |
89 | :mod:`IPython.kernel`. This gives us secure connections that are both encrypted |
|
89 | :mod:`IPython.kernel`. This gives us secure connections that are both encrypted | |
90 | and authenticated. |
|
90 | and authenticated. | |
91 | * We have a brand new `COPYING.txt` files that describes the IPython license |
|
91 | * We have a brand new `COPYING.txt` files that describes the IPython license | |
92 | and copyright. The biggest change is that we are putting "The IPython |
|
92 | and copyright. The biggest change is that we are putting "The IPython | |
93 | Development Team" as the copyright holder. We give more details about exactly |
|
93 | Development Team" as the copyright holder. We give more details about exactly | |
94 | what this means in this file. All developer should read this and use the new |
|
94 | what this means in this file. All developer should read this and use the new | |
95 | banner in all IPython source code files. |
|
95 | banner in all IPython source code files. | |
96 | * sh profile: ./foo runs foo as system command, no need to do !./foo anymore |
|
96 | * sh profile: ./foo runs foo as system command, no need to do !./foo anymore | |
97 | * String lists now support 'sort(field, nums = True)' method (to easily |
|
97 | * String lists now support 'sort(field, nums = True)' method (to easily | |
98 | sort system command output). Try it with 'a = !ls -l ; a.sort(1, nums=1)' |
|
98 | sort system command output). Try it with 'a = !ls -l ; a.sort(1, nums=1)' | |
99 | * '%cpaste foo' now assigns the pasted block as string list, instead of string |
|
99 | * '%cpaste foo' now assigns the pasted block as string list, instead of string | |
100 | * The ipcluster script now run by default with no security. This is done because |
|
100 | * The ipcluster script now run by default with no security. This is done because | |
101 | the main usage of the script is for starting things on localhost. Eventually |
|
101 | the main usage of the script is for starting things on localhost. Eventually | |
102 | when ipcluster is able to start things on other hosts, we will put security |
|
102 | when ipcluster is able to start things on other hosts, we will put security | |
103 | back. |
|
103 | back. | |
104 | * 'cd --foo' searches directory history for string foo, and jumps to that dir. |
|
104 | * 'cd --foo' searches directory history for string foo, and jumps to that dir. | |
105 | Last part of dir name is checked first. If no matches for that are found, |
|
105 | Last part of dir name is checked first. If no matches for that are found, | |
106 | look at the whole path. |
|
106 | look at the whole path. | |
|
107 | * '%cpaste -r' re-executes the block previously executed by cpaste. | |||
107 |
|
108 | |||
108 | Bug fixes |
|
109 | Bug fixes | |
109 | --------- |
|
110 | --------- | |
110 |
|
111 | |||
111 | * The colors escapes in the multiengine client are now turned off on win32 as they |
|
112 | * The colors escapes in the multiengine client are now turned off on win32 as they | |
112 | don't print correctly. |
|
113 | don't print correctly. | |
113 | * The :mod:`IPython.kernel.scripts.ipengine` script was exec'ing mpi_import_statement |
|
114 | * The :mod:`IPython.kernel.scripts.ipengine` script was exec'ing mpi_import_statement | |
114 | incorrectly, which was leading the engine to crash when mpi was enabled. |
|
115 | incorrectly, which was leading the engine to crash when mpi was enabled. | |
115 | * A few subpackages has missing `__init__.py` files. |
|
116 | * A few subpackages has missing `__init__.py` files. | |
116 | * The documentation is only created is Sphinx is found. Previously, the `setup.py` |
|
117 | * The documentation is only created is Sphinx is found. Previously, the `setup.py` | |
117 | script would fail if it was missing. |
|
118 | script would fail if it was missing. | |
118 | * Greedy 'cd' completion has been disabled again (it was enabled in 0.8.4) |
|
119 | * Greedy 'cd' completion has been disabled again (it was enabled in 0.8.4) | |
119 |
|
120 | |||
120 |
|
121 | |||
121 | Backwards incompatible changes |
|
122 | Backwards incompatible changes | |
122 | ------------------------------ |
|
123 | ------------------------------ | |
123 |
|
124 | |||
124 | * In ipapi, the :func:`make_user_ns` function has been replaced with |
|
125 | * In ipapi, the :func:`make_user_ns` function has been replaced with | |
125 | :func:`make_user_namespaces`, to support dict subclasses in namespace |
|
126 | :func:`make_user_namespaces`, to support dict subclasses in namespace | |
126 | creation. |
|
127 | creation. | |
127 |
|
128 | |||
128 | * :class:`IPython.kernel.client.Task` has been renamed |
|
129 | * :class:`IPython.kernel.client.Task` has been renamed | |
129 | :class:`IPython.kernel.client.StringTask` to make way for new task types. |
|
130 | :class:`IPython.kernel.client.StringTask` to make way for new task types. | |
130 | * The keyword argument `style` has been renamed `dist` in `scatter`, `gather` |
|
131 | * The keyword argument `style` has been renamed `dist` in `scatter`, `gather` | |
131 | and `map`. |
|
132 | and `map`. | |
132 | * Renamed the values that the rename `dist` keyword argument can have from |
|
133 | * Renamed the values that the rename `dist` keyword argument can have from | |
133 | `'basic'` to `'b'`. |
|
134 | `'basic'` to `'b'`. | |
134 | * IPython has a larger set of dependencies if you want all of its capabilities. |
|
135 | * IPython has a larger set of dependencies if you want all of its capabilities. | |
135 | See the `setup.py` script for details. |
|
136 | See the `setup.py` script for details. | |
136 | * The constructors for :class:`IPython.kernel.client.MultiEngineClient` and |
|
137 | * The constructors for :class:`IPython.kernel.client.MultiEngineClient` and | |
137 | :class:`IPython.kernel.client.TaskClient` no longer take the (ip,port) tuple. |
|
138 | :class:`IPython.kernel.client.TaskClient` no longer take the (ip,port) tuple. | |
138 | Instead they take the filename of a file that contains the FURL for that |
|
139 | Instead they take the filename of a file that contains the FURL for that | |
139 | client. If the FURL file is in your IPYTHONDIR, it will be found automatically |
|
140 | client. If the FURL file is in your IPYTHONDIR, it will be found automatically | |
140 | and the constructor can be left empty. |
|
141 | and the constructor can be left empty. | |
141 | * The asynchronous clients in :mod:`IPython.kernel.asyncclient` are now created |
|
142 | * The asynchronous clients in :mod:`IPython.kernel.asyncclient` are now created | |
142 | using the factory functions :func:`get_multiengine_client` and |
|
143 | using the factory functions :func:`get_multiengine_client` and | |
143 | :func:`get_task_client`. These return a `Deferred` to the actual client. |
|
144 | :func:`get_task_client`. These return a `Deferred` to the actual client. | |
144 | * The command line options to `ipcontroller` and `ipengine` have changed to |
|
145 | * The command line options to `ipcontroller` and `ipengine` have changed to | |
145 | reflect the new Foolscap network protocol and the FURL files. Please see the |
|
146 | reflect the new Foolscap network protocol and the FURL files. Please see the | |
146 | help for these scripts for details. |
|
147 | help for these scripts for details. | |
147 | * The configuration files for the kernel have changed because of the Foolscap stuff. |
|
148 | * The configuration files for the kernel have changed because of the Foolscap stuff. | |
148 | If you were using custom config files before, you should delete them and regenerate |
|
149 | If you were using custom config files before, you should delete them and regenerate | |
149 | new ones. |
|
150 | new ones. | |
150 |
|
151 | |||
151 | Changes merged in from IPython1 |
|
152 | Changes merged in from IPython1 | |
152 | ------------------------------- |
|
153 | ------------------------------- | |
153 |
|
154 | |||
154 | New features |
|
155 | New features | |
155 | ............ |
|
156 | ............ | |
156 |
|
157 | |||
157 | * Much improved ``setup.py`` and ``setupegg.py`` scripts. Because Twisted |
|
158 | * Much improved ``setup.py`` and ``setupegg.py`` scripts. Because Twisted | |
158 | and zope.interface are now easy installable, we can declare them as dependencies |
|
159 | and zope.interface are now easy installable, we can declare them as dependencies | |
159 | in our setupegg.py script. |
|
160 | in our setupegg.py script. | |
160 | * IPython is now compatible with Twisted 2.5.0 and 8.x. |
|
161 | * IPython is now compatible with Twisted 2.5.0 and 8.x. | |
161 | * Added a new example of how to use :mod:`ipython1.kernel.asynclient`. |
|
162 | * Added a new example of how to use :mod:`ipython1.kernel.asynclient`. | |
162 | * Initial draft of a process daemon in :mod:`ipython1.daemon`. This has not |
|
163 | * Initial draft of a process daemon in :mod:`ipython1.daemon`. This has not | |
163 | been merged into IPython and is still in `ipython1-dev`. |
|
164 | been merged into IPython and is still in `ipython1-dev`. | |
164 | * The ``TaskController`` now has methods for getting the queue status. |
|
165 | * The ``TaskController`` now has methods for getting the queue status. | |
165 | * The ``TaskResult`` objects not have information about how long the task |
|
166 | * The ``TaskResult`` objects not have information about how long the task | |
166 | took to run. |
|
167 | took to run. | |
167 | * We are attaching additional attributes to exceptions ``(_ipython_*)`` that |
|
168 | * We are attaching additional attributes to exceptions ``(_ipython_*)`` that | |
168 | we use to carry additional info around. |
|
169 | we use to carry additional info around. | |
169 | * New top-level module :mod:`asyncclient` that has asynchronous versions (that |
|
170 | * New top-level module :mod:`asyncclient` that has asynchronous versions (that | |
170 | return deferreds) of the client classes. This is designed to users who want |
|
171 | return deferreds) of the client classes. This is designed to users who want | |
171 | to run their own Twisted reactor |
|
172 | to run their own Twisted reactor | |
172 | * All the clients in :mod:`client` are now based on Twisted. This is done by |
|
173 | * All the clients in :mod:`client` are now based on Twisted. This is done by | |
173 | running the Twisted reactor in a separate thread and using the |
|
174 | running the Twisted reactor in a separate thread and using the | |
174 | :func:`blockingCallFromThread` function that is in recent versions of Twisted. |
|
175 | :func:`blockingCallFromThread` function that is in recent versions of Twisted. | |
175 | * Functions can now be pushed/pulled to/from engines using |
|
176 | * Functions can now be pushed/pulled to/from engines using | |
176 | :meth:`MultiEngineClient.push_function` and :meth:`MultiEngineClient.pull_function`. |
|
177 | :meth:`MultiEngineClient.push_function` and :meth:`MultiEngineClient.pull_function`. | |
177 | * Gather/scatter are now implemented in the client to reduce the work load |
|
178 | * Gather/scatter are now implemented in the client to reduce the work load | |
178 | of the controller and improve performance. |
|
179 | of the controller and improve performance. | |
179 | * Complete rewrite of the IPython docuementation. All of the documentation |
|
180 | * Complete rewrite of the IPython docuementation. All of the documentation | |
180 | from the IPython website has been moved into docs/source as restructured |
|
181 | from the IPython website has been moved into docs/source as restructured | |
181 | text documents. PDF and HTML documentation are being generated using |
|
182 | text documents. PDF and HTML documentation are being generated using | |
182 | Sphinx. |
|
183 | Sphinx. | |
183 | * New developer oriented documentation: development guidelines and roadmap. |
|
184 | * New developer oriented documentation: development guidelines and roadmap. | |
184 | * Traditional ``ChangeLog`` has been changed to a more useful ``changes.txt`` file |
|
185 | * Traditional ``ChangeLog`` has been changed to a more useful ``changes.txt`` file | |
185 | that is organized by release and is meant to provide something more relevant |
|
186 | that is organized by release and is meant to provide something more relevant | |
186 | for users. |
|
187 | for users. | |
187 |
|
188 | |||
188 | Bug fixes |
|
189 | Bug fixes | |
189 | ......... |
|
190 | ......... | |
190 |
|
191 | |||
191 | * Created a proper ``MANIFEST.in`` file to create source distributions. |
|
192 | * Created a proper ``MANIFEST.in`` file to create source distributions. | |
192 | * Fixed a bug in the ``MultiEngine`` interface. Previously, multi-engine |
|
193 | * Fixed a bug in the ``MultiEngine`` interface. Previously, multi-engine | |
193 | actions were being collected with a :class:`DeferredList` with |
|
194 | actions were being collected with a :class:`DeferredList` with | |
194 | ``fireononeerrback=1``. This meant that methods were returning |
|
195 | ``fireononeerrback=1``. This meant that methods were returning | |
195 | before all engines had given their results. This was causing extremely odd |
|
196 | before all engines had given their results. This was causing extremely odd | |
196 | bugs in certain cases. To fix this problem, we have 1) set |
|
197 | bugs in certain cases. To fix this problem, we have 1) set | |
197 | ``fireononeerrback=0`` to make sure all results (or exceptions) are in |
|
198 | ``fireononeerrback=0`` to make sure all results (or exceptions) are in | |
198 | before returning and 2) introduced a :exc:`CompositeError` exception |
|
199 | before returning and 2) introduced a :exc:`CompositeError` exception | |
199 | that wraps all of the engine exceptions. This is a huge change as it means |
|
200 | that wraps all of the engine exceptions. This is a huge change as it means | |
200 | that users will have to catch :exc:`CompositeError` rather than the actual |
|
201 | that users will have to catch :exc:`CompositeError` rather than the actual | |
201 | exception. |
|
202 | exception. | |
202 |
|
203 | |||
203 | Backwards incompatible changes |
|
204 | Backwards incompatible changes | |
204 | .............................. |
|
205 | .............................. | |
205 |
|
206 | |||
206 | * All names have been renamed to conform to the lowercase_with_underscore |
|
207 | * All names have been renamed to conform to the lowercase_with_underscore | |
207 | convention. This will require users to change references to all names like |
|
208 | convention. This will require users to change references to all names like | |
208 | ``queueStatus`` to ``queue_status``. |
|
209 | ``queueStatus`` to ``queue_status``. | |
209 | * Previously, methods like :meth:`MultiEngineClient.push` and |
|
210 | * Previously, methods like :meth:`MultiEngineClient.push` and | |
210 | :meth:`MultiEngineClient.push` used ``*args`` and ``**kwargs``. This was |
|
211 | :meth:`MultiEngineClient.push` used ``*args`` and ``**kwargs``. This was | |
211 | becoming a problem as we weren't able to introduce new keyword arguments into |
|
212 | becoming a problem as we weren't able to introduce new keyword arguments into | |
212 | the API. Now these methods simple take a dict or sequence. This has also allowed |
|
213 | the API. Now these methods simple take a dict or sequence. This has also allowed | |
213 | us to get rid of the ``*All`` methods like :meth:`pushAll` and :meth:`pullAll`. |
|
214 | us to get rid of the ``*All`` methods like :meth:`pushAll` and :meth:`pullAll`. | |
214 | These things are now handled with the ``targets`` keyword argument that defaults |
|
215 | These things are now handled with the ``targets`` keyword argument that defaults | |
215 | to ``'all'``. |
|
216 | to ``'all'``. | |
216 | * The :attr:`MultiEngineClient.magicTargets` has been renamed to |
|
217 | * The :attr:`MultiEngineClient.magicTargets` has been renamed to | |
217 | :attr:`MultiEngineClient.targets`. |
|
218 | :attr:`MultiEngineClient.targets`. | |
218 | * All methods in the MultiEngine interface now accept the optional keyword argument |
|
219 | * All methods in the MultiEngine interface now accept the optional keyword argument | |
219 | ``block``. |
|
220 | ``block``. | |
220 | * Renamed :class:`RemoteController` to :class:`MultiEngineClient` and |
|
221 | * Renamed :class:`RemoteController` to :class:`MultiEngineClient` and | |
221 | :class:`TaskController` to :class:`TaskClient`. |
|
222 | :class:`TaskController` to :class:`TaskClient`. | |
222 | * Renamed the top-level module from :mod:`api` to :mod:`client`. |
|
223 | * Renamed the top-level module from :mod:`api` to :mod:`client`. | |
223 | * Most methods in the multiengine interface now raise a :exc:`CompositeError` exception |
|
224 | * Most methods in the multiengine interface now raise a :exc:`CompositeError` exception | |
224 | that wraps the user's exceptions, rather than just raising the raw user's exception. |
|
225 | that wraps the user's exceptions, rather than just raising the raw user's exception. | |
225 | * Changed the ``setupNS`` and ``resultNames`` in the ``Task`` class to ``push`` |
|
226 | * Changed the ``setupNS`` and ``resultNames`` in the ``Task`` class to ``push`` | |
226 | and ``pull``. |
|
227 | and ``pull``. | |
227 |
|
228 | |||
228 | Release 0.8.4 |
|
229 | Release 0.8.4 | |
229 | ============= |
|
230 | ============= | |
230 |
|
231 | |||
231 | Someone needs to describe what went into 0.8.4. |
|
232 | Someone needs to describe what went into 0.8.4. | |
232 |
|
233 | |||
233 | Release 0.8.2 |
|
234 | Release 0.8.2 | |
234 | ============= |
|
235 | ============= | |
235 |
|
236 | |||
236 | * %pushd/%popd behave differently; now "pushd /foo" pushes CURRENT directory |
|
237 | * %pushd/%popd behave differently; now "pushd /foo" pushes CURRENT directory | |
237 | and jumps to /foo. The current behaviour is closer to the documented |
|
238 | and jumps to /foo. The current behaviour is closer to the documented | |
238 | behaviour, and should not trip anyone. |
|
239 | behaviour, and should not trip anyone. | |
239 |
|
240 | |||
240 | Release 0.8.3 |
|
241 | Release 0.8.3 | |
241 | ============= |
|
242 | ============= | |
242 |
|
243 | |||
243 | * pydb is now disabled by default (due to %run -d problems). You can enable |
|
244 | * pydb is now disabled by default (due to %run -d problems). You can enable | |
244 | it by passing -pydb command line argument to IPython. Note that setting |
|
245 | it by passing -pydb command line argument to IPython. Note that setting | |
245 | it in config file won't work. |
|
246 | it in config file won't work. | |
246 |
|
247 | |||
247 | Older releases |
|
248 | Older releases | |
248 | ============== |
|
249 | ============== | |
249 |
|
250 | |||
250 | Changes in earlier releases of IPython are described in the older file ``ChangeLog``. |
|
251 | Changes in earlier releases of IPython are described in the older file ``ChangeLog``. | |
251 | Please refer to this document for details. |
|
252 | Please refer to this document for details. | |
252 |
|
253 |
General Comments 0
You need to be logged in to leave comments.
Login now