Ihor Radchenko writes:
> Applied onto main changing the commit summary to "org-babel: ...".
> This change will affect all the babel backends that use
> `org-babel-eval'.
That makes sense. Thank you for the correction!
> A small note: If stderr does not contain a trailing newline, it will
> be
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> Feel free to change it in the patch together with tests.
>
> Thank you for driving the discussion and for giving me the opportunity
> to solve the problem (and not just temporarily, but with tests). What
> do you think about the attached
Ihor Radchenko writes:
> Feel free to change it in the patch together with tests.
Thank you for driving the discussion and for giving me the opportunity
to solve the problem (and not just temporarily, but with tests). What
do you think about the attached patch?
Rudy
>From
Rudolf Adamkovič writes:
>> I do not think that it is a good idea. Code block execution may
>> involve a whole chain of blocks when expanding references. If we wipe
>> the error buffer and multiple blocks are failing, some errors may go
>> unnoticed by the user.
>
> In that case, can we prepend
Ihor Radchenko writes:
> I do not think that it make sense to display that buffer when the code
> finishes successfully. I can see this kind of behaviour
> breaking/spamming automated scripts or export---code working in the
> past may throw error output into unsuspecting users.
But the exit
Rudolf Adamkovič writes:
>>> 1. ob-shell/error-output-after-success
>>>
>>>We seem to trash error output, such as warnings, on success. I
>>>think we should not do this. Now, on the execution of "echo X
>>>&>2", Org says "Code block produced no output." But that does
>>>hold
Ihor Radchenko writes:
>> 1. ob-shell/error-output-after-success
>>
>>We seem to trash error output, such as warnings, on success. I
>>think we should not do this. Now, on the execution of "echo X
>>&>2", Org says "Code block produced no output." But that does
>>hold true.
Rudolf Adamkovič writes:
> Thank you for investigating, explaining, and also fixing the problem! I
> pulled the latest 'main' and everything works a bit, it seems.
>
> Then, to avoid walking in circles, I decided to write some tests, for I
> think shell blocks should never, never, never break
Rudolf Adamkovič writes:
> I pulled the latest 'main' and everything works a bit, it seems.
I meant to say "a bit better" not "a bit". :)
Rudy
--
"It is no paradox to say that in our most theoretical moods we may be
nearest to our most practical applications."
-- Alfred North Whitehead,
Ihor,
Thank you for investigating, explaining, and also fixing the problem! I
pulled the latest 'main' and everything works a bit, it seems.
Then, to avoid walking in circles, I decided to write some tests, for I
think shell blocks should never, never, never break in such basic ways,
let alone
Ihor Radchenko writes:
> This is actually expected. Without session, ob-shell discards results of
> src blocks that fail and display *Error* window (empty in this case).
>
> If you try
>
> #+begin_src bash :results output
> echo one > one.txt
> echo two > two.txt
> diff one.txt two.txt
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>>> I did some testing and found no issues.
>
> Update: Today I needed to run some Bash, and it seems broken.
>
> PROBLEM 1: WITHOUT A SESSION
>
>
> CONFIGURATION:
>
> Emacs 29, Org from Git
Ihor Radchenko writes:
>> I did some testing and found no issues.
Update: Today I needed to run some Bash, and it seems broken.
PROBLEM 1: WITHOUT A SESSION
CONFIGURATION:
Emacs 29, Org from Git (2f5e7103e59f06631e985d3dd39af21b5b7464ea)
REPRODUCTION STEPS:
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> See the attached tentative patch.
>> I'd appreciate some testing. Hopefully, I did not break anything.
>
> I did some testing and found no issues.
>
> Great work!
>
> Below, I include some suggestions regarding the patch.
Thanks!
Applied
Ihor Radchenko writes:
> See the attached tentative patch.
> I'd appreciate some testing. Hopefully, I did not break anything.
I did some testing and found no issues.
Great work!
Below, I include some suggestions regarding the patch.
> * lisp/ob-comint.el (org-babel-comint-with-output):
Ihor Radchenko writes:
> Rudolf Adamkovič writes:
>
>> :
>> : > > hello
>>
>> on the subsequent runs.
>>
>> Better than the new version but still wrong. :)
>
> And this is what drove me crazy during debugging. I do not understand
> the logic of all that ob-comint code.
>
> I have identified
Rudolf Adamkovič writes:
> :
> : > > hello
>
> on the subsequent runs.
>
> Better than the new version but still wrong. :)
And this is what drove me crazy during debugging. I do not understand
the logic of all that ob-comint code.
I have identified that the hang happens because Org does not
Ihor Radchenko writes:
> Is it what you actually saw in the past? I just tried with older Org
> versions on my system and the output is
>
>: [00m > > > hello
No. By "expected", I mean what I expect as a user (and what I would
assert on in a regression test as a developer).
For the record,
Rudolf Adamkovič writes:
> I noticed today that Bash source blocks with ':session" does not seem to
> work with Org 9.6-pre (3e8648775). Does anyone else have the problem?
Confirmed.
The cause is a35d16368
Author: Ihor Radchenko
ob-shell: Fix output containing strings matching
Hello,
Rudolf Adamkovič writes:
> Hello there!
>
> I noticed today that Bash source blocks with ':session" does not seem to
> work with Org 9.6-pre (3e8648775). Does anyone else have the problem?
funnily I observed something similar while generating semester projects
for my students.
Example:
20 matches
Mail list logo
