svaante / dape

Debug Adapter Protocol for Emacs
GNU General Public License v3.0
492 stars 33 forks source link

Shell fails to start (signals beginning-of-buffer) #141

Closed svaante closed 2 months ago

svaante commented 2 months ago

Moving issue https://github.com/microsoft/debugpy/issues/1654 from debugpy to dape @Vibrys

runInTerminal event handler signals beginning-of-buffer . nil which results in a failed request.

svaante commented 2 months ago

I suspect it has nothing to do with debugpy.

What is happening is that something is throwing (signal 'beginning-of-buffer nil) as part of setting up the shell for executing the debugged program.

To verify my hunch does the following work? Where we ignore any errors from shell-mode initialization.

(cl-defmethod dape-handle-request (conn (_command (eql runInTerminal)) arguments)
  "Handle runInTerminal requests.
Starts a new adapter CONNs from ARGUMENTS."
  (let ((default-directory
         (or (when-let ((cwd (plist-get arguments :cwd)))
               (dape--path conn cwd 'local))
             default-directory))
        (process-environment
         (or (cl-loop for (key value) on (plist-get arguments :env) by 'cddr
                      collect
                      (format "%s=%s"
                              (substring (format "%s" key) 1)
                              value))
             process-environment))
        (buffer (get-buffer-create "*dape-shell*")))
    (with-current-buffer buffer
      (ignore-errors 
          (shell-mode)
          (shell-command-save-pos-or-erase)))
    (let ((process
           (make-process :name "dape shell"
                         :buffer buffer
                         :command (append (plist-get arguments :args) nil)
                         :filter 'comint-output-filter
                         :sentinel 'shell-command-sentinel
                         :file-handler t)))
      (dape--display-buffer buffer)
      (list :processId (process-id process)))))
vibrys commented 2 months ago

In the act o despair, I've recompiled whole my elpa repo:

(byte-recompile-directory "~/.emacs.d/elpa/29.4/develop" 0 t)

that helped for the initial problem, ie: adding :console "internalConsole" as debugpy argument is no longer required.

Yes, neither shell-mode-hook nor comint-mode-hook were empty. They kept (spacemacs/force-yasnippet-off) and (spacemacs//activate-smartparens) relativelly. setting both the hooks to nil didn't help on using dape-handle-request (above) for getting the response status. Although I no longer observe beginning-of-buffer signal, I still get following error message:

* Adapter connection shutdown without successfully initializing *
Configuration:
  modes (python-mode python-ts-mode)
  ensure (lambda (config) (dape-ensure-command config) (let ((python (dape-config-get config 'command))) (unless (zerop (call-process-shell-command (format "%s -c \"import debugpy.adapter\"" python))) (user-error "%s module debugpy is not installed" python))))
  command "python"
  command-args ("-m" "debugpy.adapter" "--host" "0.0.0.0" "--port" "41615")
  port 41615
  :request "launch"
  :type "python"
  :cwd "/media/user/mmobile/Scripts/python"
  :program "/media/user/mmobile/Scripts/python/example.py"
  :args []
  :justMyCode nil
  :console "integratedTerminal"
  :showReturnValue t
  :stopOnEntry nil
  command-cwd "/media/user/mmobile/mmacs-config/spacemacs-private-layers/ccpp/"
E+00000.423: Fatal error in channel Client[1] while parsing:
             {
                 "seq": 7,
                 "type": "response",
                 "request_seq": 7,
                 "success": false,
                 "message": "Internal error",
                 "body": null
             }

             Traceback (most recent call last):
               File "/home/user/.virtualenvs/mmobile/lib/python3.8/site-packages/debugpy/common/messaging.py", line 384, in __call__
                 value = validate(value)
               File "/home/user/.virtualenvs/mmobile/lib/python3.8/site-packages/debugpy/common/json.py", line 126, in validate
                 raise ValueError("must be specified")
             ValueError: must be specified

             During handling of the above exception, another exception occurred:

             Traceback (most recent call last):
               File "/home/user/.virtualenvs/mmobile/lib/python3.8/site-packages/debugpy/common/messaging.py", line 1369, in _parse_incoming_message
                 parser(self, message_dict)
               File "/home/user/.virtualenvs/mmobile/lib/python3.8/site-packages/debugpy/common/messaging.py", line 914, in _parse
                 command = message_dict("command", str)
               File "/home/user/.virtualenvs/mmobile/lib/python3.8/site-packages/debugpy/common/messaging.py", line 390, in __call__
                 raise message.isnt_valid("{0}{1}", json.repr(key), err)
               File "/home/user/.virtualenvs/mmobile/lib/python3.8/site-packages/debugpy/common/messaging.py", line 521, in isnt_valid
                 return self.error(InvalidMessageError, *args, **kwargs)
             AttributeError: 'str' object has no attribute 'error'

             Stack where logged:
               File "/usr/lib/python3.8/threading.py", line 890, in _bootstrap
                 self._bootstrap_inner()
               File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
                 self.run()
               File "/usr/lib/python3.8/threading.py", line 870, in run
                 self._target(*self._args, **self._kwargs)
               File "/home/user/.virtualenvs/mmobile/lib/python3.8/site-packages/debugpy/common/messaging.py", line 1295, in _parse_incoming_messages
                 self._parse_incoming_message()
               File "/home/user/.virtualenvs/mmobile/lib/python3.8/site-packages/debugpy/common/messaging.py", line 1380, in _parse_incoming_message
                 log.swallow_exception(
               File "/home/user/.virtualenvs/mmobile/lib/python3.8/site-packages/debugpy/common/log.py", line 215, in swallow_exception
                 _exception(format_string, *args, **kwargs)

I'm using emacs 29.4 + spacemacs.

I'll try to remove as much configuration as possible, then see if problem still persists.

vibrys commented 2 months ago

I finally decided to go other way with this problem. I've installed dape-20240818.215258 with the following in spacemacs layer configuration:

(dape :location (recipe :fetcher github :repo "svaante/dape" :branch "master"))

then, after restarting emacs I've evaluated dape-handle-request provided above (of course I've changed shell-mode do dape-shell-mode call)

then, I've started some example python program within dape.

all works without any problem so in this particular case I don't need status message from jsonrpc. Still I have way to diagnose it for future uses if any emerge.

I think this case may be closed. dape works great!

thank you

svaante commented 2 months ago

Thanks for the update! Glad it's working now, but it's a bit disappointing we didn't find th root cause.