Can't find ob-shell?

[paulrd]

This is a copy of #7 as it was closed prematurely.

[astahlman]

Please add your troubleshooting artifacts as described in the README and I'll be happy to take a look.

[preetpalS]

I also encountered this issue. I have attached the troubling artifacts as requested in the README.

troubleshooting.org.txt

I changed the filetype to .org.txt as org filetypes are not supported in uploads.

[preetpalS]

@astahlman The mistake was on my end in my configuration. The problem was caused by trying to using the wrong name to load org babel shell script support (see commented out line of code from my config). Making the change below solved my issue.

(org-babel-do-load-languages 'org-babel-load-languages
                             '((ruby . t)
                               (emacs-lisp . t)
                               (R . t)
                               ;; (sh . t) ; WRONG, commented out, cause of this issue
                               (shell . t) ; CORRECT
                               (C . t)
                               (haskell . t)
                               (js . t)
                               (java . t)
                               (css . t)
                               (sass . t)
                               (octave . t)
                               (sql . t)
                               (sqlite . t)
                               (lisp . t)
                               (python . t)
                               )) ;; activate languages for org-babel

[astahlman]

@preetpalS Glad you got it sorted out. Thanks for updating with details on the fix, hopefully this will resolve the problem for others facing the same error (cc @paulrd).

[Fuco1]

I have the same problem. How does the subprocess load dependencies? I use Cask for my personal setup and I think the subprocess has incorrect load path and can't find org package. I have the config correct with (shell . t) in load languages.

[astahlman]

@Fuco1 The child should inherit its 'exec-path and loaded org-babel languages from the parent. The relevant code is here:

ob-async/ob-async.el

Lines 133 to 136 in 99a6f24

	(setq exec-path ',exec-path)
	(package-initialize)
	(org-babel-do-load-languages 'org-babel-load-languages ',org-babel-load-languages)
	(let ((default-directory ,default-directory))

If you attach your troubleshooting.org I can take a look.

[Fuco1]

@astahlman exec-path is only for binaries, it has nothing to do with from where emacs loads packages. That is stored in load-path variable.

I've added

(setq load-path ',load-path)

after the exec path line you mentioned and now things work.

[Fuco1]

By the way the troubleshooting.org idea is absolutely brilliant. I have no idea why every Emacs package doesn't have that. I'm going to start adding that to all of my projects! This is exactly what reproducible research is at its core and org is such a great tool for that.

[astahlman]

@Fuco1 Of course you're right about 'exec-path - my mistake. It's been a long time since I've looked at this code, but I can't remember any good reason why I omitted setting the 'load-path, as well. If you're interested in submitting a PR with your change, I'd happily accept it (see the contributing guide for instructions, if you're interested).

So glad to hear that you found troubleshooting.org useful - I hope it catches on!

[preetpalS]

Maybe problems like these (involving recreating the library user's configuration in a child Emacs process) can be avoided altogether by using threads (available in Emacs 26 (I'm using it now although it's not released yet I believe)) for the asynchronous processing. I wrote a (somewhat ugly) thread-based replacement for https://github.com/jwiegley/emacs-async/blob/15bcbf6beae65d7606f0655711159ca56f050c6b/async.el#L241. I'd be willing to contribute it to any packages that are willing to use it (by posting it into the public domain).

;; The following requires lexical binding to be activated in the file where it is defined

;; Possible replacement for existing function being used by library. It is a bit ugly though.
(defun async-start (start-func &optional finish-func)
  "`finish-func' is executed with the return values from `start-func'."
  (let* ((start-func-results nil)
         (start-func-thread (make-thread (lambda () (setq start-func-results (funcall start-func)))))
         (check-interval 3)
         (start-func-check-func
          (lambda (start-func-check-func)
            (if (thread-alive-p start-func-thread)
                (run-at-time check-interval nil start-func-check-func start-func-check-func)
              (progn
                (when (functionp finish-func)
                  (thread-join start-func-thread)
                  (funcall finish-func start-func-results)))))))
    (run-with-timer check-interval nil start-func-check-func start-func-check-func)))

;; Sample usage
(async-start (lambda () (sleep-for 14) "Hello") #'princ)

;; Emacs version information
(emacs-version) ;; "GNU Emacs 26.0.91 (build 1, x86_64-unknown-freebsd11.1, GTK+ Version 3.22.15) of 2018-01-24"

Although this idea assumes that the given start-func argument can be invoked safely in multiple threads.

[astahlman]

@preetpalS That's a very interesting idea. In addition to eliminating inconsistencies in the 'load-path, I wonder if a thread-based implementation could enable #1 (support for :session) and #13 (viewing output of running blocks).

I'd love to see a proof of concept for this idea. Unfortunately, I don't think I'll have the free time to tackle it in the near future.

[preetpalS]

@astahlman Personally I am fine with the way the library works as is, so I am not going to try to implement a proof of concept for this (although it would be great as it would make the library more efficient and it would be a great way to use the newly added threading capabilities in Emacs 26).

[preetpalS]

I created a simple proof of concept even though I said I wouldn't (it didn't take more than 10 minutes). In that proof of concept, only Emacs Lisp seems to be able to execute asynchronously with the thread based implementation of async-start. See #22.

[preetpalS]

@astahlman I made a mistake in interpreting what type of threading (its cooperative threading which means that only a single thread will execute at any given point in time) was being introduced in Emacs 26 (only one thread can run at a time). This means that my proof-of-concept does not work as expected (it only seemed to work based on the test cases that I used in my limited testing).

[astahlman]

@Fuco1 @paulrd I've just pushed (what I hope is) a fix in #27. Can you confirm whether you still see this issue on the latest revision of master? If so, can you upload your troubleshooting.org output?

[astahlman]

Closing due to inactivity.