t...@tsdye.com (Thomas S. Dye) writes: > Aloha Herb, > > I think a note to that effect belongs here: > http://orgmode.org/manual/session.html#session > > Perhaps the behavior related to session persistence could be described > there, as well. > > Examples are probably best left to the language-specific documentation, > such as it is, at http://orgmode.org/worg/org-contrib/babel/languages/ > > Note that there is no language-specific documentation for Python yet. >
Yes, these pages would benefit greatly from more documentation. > > Is it the case that the Ruby and Perl interpreters won't run code that > does run in non-session mode? > No, Python and Haskell are the only two languages of which I am aware of any difference between interactive and normal evaluation. Best -- Eric > > All the best, > Tom > > Herbert Sitz <hs...@nwlink.com> writes: > >> Thomas S. Dye <tsd <at> tsdye.com> writes: >>> >>> Aloha Herbert, >>> >>> I think you're right about the potential to improve the documentation. >>> That's an on-going process. Could you suggest some specific changes? >>> >>> All the best, >>> Tom >> >> Tom -- >> >> I would suggest just adding specific warnings that session-based evaluation >> may >> throw syntax errors with valid code. >> >> Here's what Org manual says regarding :session evaluation with :results >> output': >> >> "The code is passed to the interpreter running as an interactive Emacs >> inferior >> process. The result returned is the concaOrg tenation of the sequence of >> (text) >> output from the interactive interpreter. Notice that this is not necessarily >> the >> same as what would be sent to STDOUT if the same code were passed to a >> non-interactive interpreter running as an external process. . . ." >> [http://orgmode.org/manual/Results-of-evaluation.html#Results-of-evaluation] >> >> All that needs to be added is a warning: >> >> "IMPORTANT: Note that Org provides only a thin wrapper around a language's >> interactive shell, so valid code that executes properly in non-session mode >> may >> fail in :session mode. This is because Org feeds the lines in a :session >> block >> to the interactive interpreter exactly as written. In come cases the lines >> may >> require special formatting in the source block to be executed properly in the >> interactive shell. For example: . . . " >> >> I think the above issue should be moot for some of the main interpreted >> languages (viz., Python, Perl, Ruby) where there are various ways to execute >> a >> block of code non-interactively despite being in the interactive shell. >> (One of >> those methods is the example I gave in previous message.) In that case >> identical code will run the same whether it's in an interactive-interpreter >> session or not. It seems to me that switching to that approach for languages >> that support it should both (1) simplify the Org Babel code, and (2) provide >> Org >> users with more flexibility and power. >> >> Also, it seems the real power of :session evaluation is to share state >> between >> Org/Babel source code blocks, not merely to act as a kind of Org-internal >> scratchpad. As a user trying to take advantage of that state-sharing power I >> would generally want my Org document exports to start from fresh sessions. >> That >> is, I would write my :session blocks so that they depended on results of code >> run in previous :session blocks, BUT I would want the first :session block to >> start with a fresh session,with a known state. So on export I would >> generally >> want any existing named session to be closed and restarted anew for an >> Org export. >> >> I hope that all makes sense. I should say I'm not a big Babel user, and I >> could >> easily be misunderstanding something. But it seems this is the way the >> :session-based stuff should work, when possible. >> >> -- Herb >> >> >> -- Eric Schulte http://cs.unm.edu/~eschulte/