Show More
@@ -274,7 +274,7 b' that provide specialized magics. These typically require additional software' | |||
|
274 | 274 | to run and must be manually loaded via ``%load_ext <extension name>``, but are |
|
275 | 275 | extremely useful. The following extensions are provided: |
|
276 | 276 | |
|
277 |
Cython magics (extension :ref:` |
|
|
277 | **Cython magics (extension :ref:`cythonmagic <extensions_cythonmagic>`)** | |
|
278 | 278 | This extension provides magics to automatically build and compile Python |
|
279 | 279 | extension modules using the Cython_ language. You must install Cython |
|
280 | 280 | separately, as well as a C compiler, for this to work. The examples |
@@ -289,7 +289,7 b' Cython magics (extension :ref:`octavemagic <extensions_cythonmagic>`)' | |||
|
289 | 289 | |
|
290 | 290 | .. _cython: http://cython.org |
|
291 | 291 | |
|
292 | Octave magics (extension :ref:`octavemagic <extensions_octavemagic>`) | |
|
292 | **Octave magics (extension :ref:`octavemagic <extensions_octavemagic>`)** | |
|
293 | 293 | This extension provides several magics that support calling code written in |
|
294 | 294 | the Octave_ language for numerical computing. You can execute single-lines |
|
295 | 295 | or whole blocks of Octave code, capture both output and figures inline |
@@ -309,8 +309,7 b' Octave magics (extension :ref:`octavemagic <extensions_octavemagic>`)' | |||
|
309 | 309 | .. _oct2py: http://pypi.python.org/pypi/oct2py |
|
310 | 310 | .. _h5py: http://code.google.com/p/h5py |
|
311 | 311 | |
|
312 | ||
|
313 | R magics (extension :ref:`rmagic <extensions_rmagic>`) | |
|
312 | **R magics (extension :ref:`rmagic <extensions_rmagic>`)** | |
|
314 | 313 | This extension provides several magics that support calling code written in |
|
315 | 314 | the R_ language for statistical data analysis. You can execute |
|
316 | 315 | single-lines or whole blocks of R code, capture both output and figures |
@@ -370,7 +369,12 b' attribute is ignored. :ghpull:`1529`.' | |||
|
370 | 369 | Improvements to the Qt console |
|
371 | 370 | ------------------------------ |
|
372 | 371 | |
|
373 | * changes for easier integration into other projects such as Spyder_. | |
|
372 | The Qt console continues to receive improvements and refinements, despite the | |
|
373 | fact that it is by now a fairly mature and robust component. Lots of small | |
|
374 | polish has gone into it, here are a few highlights: | |
|
375 | ||
|
376 | * A number of changes were made to the underlying code for easier integration | |
|
377 | into other projects such as Spyder_ (:ghpull:`2007`, :ghpull:`2024`). | |
|
374 | 378 | |
|
375 | 379 | * Improved menus with a new Magic menu that is organized by magic groups (this |
|
376 | 380 | was made possible by the reorganization of the magic system |
@@ -379,7 +383,7 b' Improvements to the Qt console' | |||
|
379 | 383 | * Allow for restarting kernels without clearing the qtconsole, while leaving a |
|
380 | 384 | visible indication that the kernel has restarted. :ghpull:`1681`. |
|
381 | 385 | |
|
382 | * Allow the native display of jpeg image in the qtconsole. :ghpull:`1643`. | |
|
386 | * Allow the native display of jpeg images in the qtconsole. :ghpull:`1643`. | |
|
383 | 387 | |
|
384 | 388 | .. _spyder: https://code.google.com/p/spyderlib |
|
385 | 389 | |
@@ -410,7 +414,6 b' of the internal execution parts:' | |||
|
410 | 414 | :align: center |
|
411 | 415 | :target: ../_static/ipy_013_par_tb.png |
|
412 | 416 | |
|
413 | ||
|
414 | 417 | The parallel tools now default to using ``NoDB`` as the storage backend for |
|
415 | 418 | intermediate results. This means that the default usage case will have a |
|
416 | 419 | significantly reduced memory footprint, though certain advanced features are |
@@ -421,7 +424,7 b' other actions with complex display. The ``px`` magic has now both line and cell' | |||
|
421 | 424 | modes, and in cell mode finer control has been added about how to collate |
|
422 | 425 | output from multiple engines. :ghpull:`1768`. |
|
423 | 426 | |
|
424 |
|
|
|
427 | There have also been incremental improvements to the SSH launchers: | |
|
425 | 428 | |
|
426 | 429 | * add to_send/fetch steps for moving connection files around. |
|
427 | 430 | |
@@ -431,13 +434,8 b' Incremental improvements to SSH launchers:' | |||
|
431 | 434 | |
|
432 | 435 | This makes the SSHLauncher usable on machines without shared filesystems. |
|
433 | 436 | |
|
434 | When sending files, the destination directory must *already exist* - that is, | |
|
435 | `ipython profile create` may be necessary on the remote system, before the | |
|
436 | security dir exists for putting the connection file the first | |
|
437 | time. :ghpull:`1634`. | |
|
438 | ||
|
439 | Add sugar methods/properties to AsyncResult that are generically useful | |
|
440 | (:ghpull:`1548`): | |
|
437 | A number of 'sugar' methods/properties were added to AsyncResult that are | |
|
438 | quite useful (:ghpull:`1548`) for everday work: | |
|
441 | 439 | |
|
442 | 440 | * ``ar.wall_time`` = received - submitted |
|
443 | 441 | * ``ar.serial_time`` = sum of serial computation time |
@@ -446,9 +444,9 b' Add sugar methods/properties to AsyncResult that are generically useful' | |||
|
446 | 444 | * ``len(ar)`` = # of tasks |
|
447 | 445 | * ``ar.wait_interactive()``: prints progress |
|
448 | 446 | |
|
449 |
Added :meth:`.Client.spin_thread` / :meth:`~.Client.stop_spin_thread` for |
|
|
450 |
spin in a background thread, to keep zmq queue clear. This can be used |
|
|
451 | ensure that timing information is as accurate as possible (at the cost of | |
|
447 | Added :meth:`.Client.spin_thread` / :meth:`~.Client.stop_spin_thread` for | |
|
448 | running spin in a background thread, to keep zmq queue clear. This can be used | |
|
449 | to ensure that timing information is as accurate as possible (at the cost of | |
|
452 | 450 | having a background thread active). |
|
453 | 451 | |
|
454 | 452 | Set TaskScheduler.hwm default to 1 instead of 0. 1 has more |
@@ -461,17 +459,48 b' behavior will be less surprising to new users. :ghpull:`1294`.' | |||
|
461 | 459 | Kernel/Engine unification |
|
462 | 460 | ------------------------- |
|
463 | 461 | |
|
464 | :ghpull:`1640` | |
|
465 | ||
|
466 | Add :func:`IPython.embed_kernel()` as a public API. | |
|
467 | Embedding an IPython kernel in an application is useful when you want to use | |
|
468 | IPython.embed() but don't have a terminal attached on stdin and stdout. | |
|
469 | ||
|
470 | :func:`IPython.parallel.bind_kernel` allows you to promote Engines to listening Kernels, | |
|
471 | and connect QtConsoles directly to an Engine and debug it directly. | |
|
472 | ||
|
473 | This also means that Engines are now fully IPython, allowing access to magics, | |
|
474 | etc. in your parallel execution. | |
|
462 | This is mostly work 'under the hood', but it is actually a *major* achievement | |
|
463 | for the project that has deep implications in the long term: at last, we have | |
|
464 | unified the main object that execute as the user's interactive shell (which | |
|
465 | we refer to as the *IPython kernel*) with the objects that run in all the | |
|
466 | worker nodes of the parallel computing facilities (the *IPython engines*). | |
|
467 | Ever since the first implementation of IPython's parallel code back in 2006, we | |
|
468 | had wanted to have these two roles be played by the same machinery, but a | |
|
469 | number of technical reasons had prevented that from being true. | |
|
470 | ||
|
471 | In this release we have now merged them, and this has a number of important | |
|
472 | consequences: | |
|
473 | ||
|
474 | * It is possible to connect any of our clients (qtconsole or terminal console) | |
|
475 | to any individual parallel engine, with the *exact* behavior of working at a | |
|
476 | 'regular' IPython console/qtconsole. This makes debugging, plotting, etc. in | |
|
477 | parallel scenarios vastly easier. | |
|
478 | ||
|
479 | * Parallel engines can always execute arbitrary 'IPython code', that is, code | |
|
480 | that has magics, shell extensions, etc. In combination with the ``%%px`` | |
|
481 | magics, it is thus extremely natural for example to send to all engines a | |
|
482 | block of Cython or R code to be executed via the new Cython and R magics. For | |
|
483 | example, this snippet would send the R block to all active engines in a | |
|
484 | cluster:: | |
|
485 | ||
|
486 | %%px | |
|
487 | %%R | |
|
488 | ... R code goes here | |
|
489 | ||
|
490 | * It is possible to embed not only an interactive shell with the | |
|
491 | :func:`IPython.embed` call as always, but now you can also embed a *kernel* | |
|
492 | with :func:``IPython.embed_kernel()`. Embedding an IPython kernel in an | |
|
493 | application is useful when you want to use :func:`IPython.embed` but don't | |
|
494 | have a terminal attached on stdin and stdout. | |
|
495 | ||
|
496 | * The new :func:`IPython.parallel.bind_kernel` allows you to promote Engines to | |
|
497 | listening Kernels, and connect QtConsoles directly to an Engine and debug it | |
|
498 | directly. | |
|
499 | ||
|
500 | In addition, having a single core object through our entire architecture also | |
|
501 | makes the project conceptually cleaner, easier to maintain and more robust. | |
|
502 | This took a lot of work to get in place, but we are thrilled to have this major | |
|
503 | piece of architecture finally where we'd always wanted it to be. | |
|
475 | 504 | |
|
476 | 505 | |
|
477 | 506 | Official Public API |
General Comments 0
You need to be logged in to leave comments.
Login now