Re: emacs-jupyter does not send result form babel block

[Rafael]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

>> On Sat, Sep 4, 2021 at 4:22 PM Rafael <rvf0068@gmail.com> wrote:
>>
>>>
>>> I am using emacs-jupyter (https://github.com/nnicandro/emacs-jupyter),
>>> and I have just noticed that results from a block are not sent to
>>> another block. I think it has to do with this issue
>>> https://github.com/nnicandro/emacs-jupyter/issues/222. Can somebody
>>> suggest a workaround? (I actually want to use the output from a kernel
>>> different from python, but since the problem happens also with the python
>>> kernel I'm using it as an example).
>>>
>>>   #+name: atest
>>>   #+begin_src jupyter-python :session test
>>> 1+1
>>>   #+end_src
>>>
>>>   #+RESULTS: graphst
>>>   : 2
>>>
>>>   #+begin_src python :var adjs=atest
>>> adjs
>>>   #+end_src
>>>
>>>   #+RESULTS
>>   : nil
>>
>>
>
> I think this is a bug in jupyter-org-client.el in this function:
>
> (defun jupyter-org--add-result (req result)
>   (cond
>    ((jupyter-org-request-silent-p req)
>     (unless (equal (jupyter-org-request-silent-p req) "none")
>       (message "%s" (org-element-interpret-data result))))
>    ((jupyter-org-request-async-p req)
>     (jupyter-org--clear-request-id req)
>     (jupyter-org--do-insert-result req result))
>    (t
>     (push result (jupyter-org-request-results req)))))
>
> The problem is that when the jupyter block is executed to define the
> variable in the python header, it is run with a "silent" results param. The
> function above is responsible for adding the results to the
> jupyter-org-request struct, and here when it sees the results are silent,
> it does not do that, so the results are nil, which is why you see what you
> see.
>
> I don't think that behavior is correct. It isn't quite right to just remove
> the first block though, at least in this case. The result in this function
> is already structured as a fixed-width results element intended to be
> interpreted as a results string, and not the numeric value returned. So the
> fix is probably upstream from this.
>
> I am not sure what the fix is for this. The code path from C-cC-c to
> executing the code, handling the request to the kernel, getting results and
> to the output is very hard to follow for me. I would post an issue at
> https://github.com/nnicandro/emacs-jupyter/issues.

Thanks for your answer and sorry for not following up. There is already
an issue about this which has been open since March 2020, see
https://github.com/nnicandro/emacs-jupyter/issues/222.