Re: [O] org-babel -- Improper syntax error in session mode?

[Eric Schulte]

address@hidden (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 <address@hidden> 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/