Re: Erlang + Emacs profile

[Zelphir Kaltstahl]

Hi Maxim!

It took me a few days longer to get back to this.

Just to make sure I am doing this correctly: I put the:

~~~~
  (require 'org-tempo)
  (require 'ob-erlang)
  (org-babel-do-load-languages
   'org-babel-load-languages
   '((erlang . t)
     (shell . t)))
~~~~

Into the *scratch* buffer and then highlight all of it and "Evaluate and
print" (or C-j), after which a "nil" is printed in the *scratch* buffer.

Then I proceed.

On 06.07.20 05:50, Maxim Cournoyer wrote:
> Hello Zelphir!
>
> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:
>
> [...]
>
>> Then I try to run the org-mode source block hello world Erlang:
>>
>> ~~~~
>> start() ->
>>         io:format("hello world").
>> ~~~~
>>
>> Here however, I get an error logged in my *Messages* buffer:
>>
>> ~~~~
>> executing Erlang code block...
>> append-export-all: Symbol’s function definition is void: string-join
>> ~~~~
> Getting close!  I've had this error before and could workaround it (I
> forgot how). let's see...
>
> The string-join call originates from this procedure, which is in
>  ob-erlang.el:
>
> --8<---------------cut here---------------start------------->8---
> (defun append-export-all (code-body)
>   "Append -compile(export_all).  after -module line if CODE-BODY do not has 
> export line."
>   (if (export-p code-body)
>       code-body
>     (string-join (mapcar
>                 (lambda (line)
>                   (if (string-match-p "^-module" line)
>                       (setq line (concat line "\n-compile(export_all)."))
>                     line))
>                 (split-string code-body "\n"))
>      "\n")))
> --8<---------------cut here---------------end--------------->8---
>
> In Emacs, C-h f string-join RET says it is defined in the subr-x.el
> module:
>
> --8<---------------cut here---------------start------------->8---
> string-join is a compiled Lisp function in
> ‘/gnu/store/pm5kipzcpkfxspy0hhq0jnma7475hqhv-emacs-26.3/share/emacs/26.3/lisp/emacs-lisp/subr-x.el’.
>
> (string-join STRINGS &optional SEPARATOR)
>
> Join all STRINGS using SEPARATOR.
> --8<---------------cut here---------------end--------------->8---
>
> Clicking on the link to the file fails to display it.

(Note: For me it opens the file, not sure, whether this is important. It
shows the definition:

~~~~
(defsubst string-join (strings &optional separator)
  "Join all STRINGS using SEPARATOR."
  (mapconcat 'identity strings separator))
~~~~

)

> After some head
> scratching, it turns out that Emacs calls out to 'sh' and 'gzip' to
> uncompress the 'subr.el.gz' file, and failing to do so 'string-join' is
> undefined.  That's a bug in our Emacs package, it should just work even
> when ran in a container, at least for such core functionality.
>
> For now, using 'guix environment -m manifest.scm --pure --ad-hoc bash
> gzip' gets us passed this road block.  Unfortunately doing the above
> steps still fail to produce the "hello world" result in a pure
> environment.

For me there is a different result (added newlines for readability):

~~~~
$ guix environment -m manifest.scm --pure --ad-hoc bash gzip

The following derivation will be built:
   /gnu/store/3fsqf52sgr0mm271szmb24knvwr47frx-profile.drv
The following profile hooks will be built:
   /gnu/store/4i8zy7adnskvbsfm8za29vb8nmqlds9f-gtk-im-modules.drv
   /gnu/store/7jdkqh3zhjlhc6wmb2qnnh6ysc1c3nbs-ca-certificate-bundle.drv
   /gnu/store/g31dq1fn90h2mdfvpb55i02r73sgrf0h-info-dir.drv
   /gnu/store/ikm4rinvywb7qapi6sqxb9yq3kj7mqjv-manual-database.drv
   /gnu/store/j3ks6l39bpj6svlrmap0s4smjz44iwbq-glib-schemas.drv
   /gnu/store/m6ki0x4p25sh4x9wzzgy8lxkwkysfk8a-xdg-desktop-database.drv
   /gnu/store/ygkd5q4d4m7a6lp86lm2b65md2by7r2r-xdg-mime-database.drv
   /gnu/store/zf9kfkm1ihqg3xcbw5xp2f59243da9z2-fonts-dir.drv
   /gnu/store/zq1rvhmxnrkr9cdpavdy05dpfdww044q-gtk-icon-themes.drv
building CA certificate bundle...
building fonts directory...
generating GLib schema cache...
creating GTK+ icon theme cache...
building cache files for GTK+ input methods...
building directory of Info manuals...
building database for manual pages...
building XDG desktop file cache...
building XDG MIME database...
building profile with 7 packages...
Command 'lesspipe' is available in the following places
 * /bin/lesspipe
 * /usr/bin/lesspipe
The command could not be located because '/bin:/usr/bin' is not included in the 
PATH environment variable.
lesspipe: command not found
Command 'dircolors' is available in '/usr/bin/dircolors'
The command could not be located because '/usr/bin' is not included in the PATH 
environment variable.
dircolors: command not found
Command 'ls' is available in '/bin/ls'
The command could not be located because '/bin' is not included in the PATH 
environment variable.
ls: command not found

$ which emacs 

Command 'which' is available in the following places
 * /bin/which
 * /usr/bin/which
The command could not be located because '/bin:/usr/bin' is not included in the 
PATH environment variable.
which: command not found

$ emacs -Q
~~~~

And Emacs starts up just like before, but still I get the same error
about string-join being void.

> Time to C-u C-M-x (edebug) org-babel-execute-src-block and see where the
> it stumbles, given the lack of error message.

I guess the rest has only a chance of working once I get around the
string-join issue, but I still tried as follows.

For me when pressing C-u C-M-x, the part C-M-x is not a defined key
combination and it shows in the *Messages* buffer:

~~~~
C-M-x is undefined
~~~~

So I ran edebug in the "Eval :" minibuffer pressing C-S-: (control,
shift, colon) and writing there "edebug" and pressing the return key.
Then the *Backtrace* buffer shows up, so that seems to have worked.

However, next problem is to run `org-babel-execute-src-block`. When I
try it in the M-x thing, it claims that `org-babel-execute-src-block` is
void. I think it does not work inside the *Backtrace* buffer and I need
to be in the buffer, where org-mode runs. However,  when I move the
cursor into that buffer, an try to run `org-babel-execute-src-block`
there, I am back to the string-join error.

> Everything looks fine until line 704 in ob-core.el:
>
>                   (let ((r (funcall cmd body params)))
>
> Where cmd, body and params are bound to org-babel-execute:erlang,
> "start() ->\n io:format(\"hello world\")." and ((:colname-names)
> (:rowname-names) (:result-params "replace") (:result-type . value)
> (:results . "replace") (:exports . "code") (:session . "none") (:cache
> . "no") (:noweb . "no") (:hlines . "no") (:tangle . "no")),
> respectively.
>
> C-h f org-babel-execute:erlang RET allows us to navigate to its
> definition, which we instrument for Edebug (C-u C-M-x) then run the
> entry-point M-x org-babel-execute-src-block again.
>
> The function saves the following script to a file named ".erc" under a
> temporary directory, with the following content:
>
> --8<---------------cut here---------------start------------->8---
> -module().
> -compile(export_all).
> start() ->
>  io:format("hello world").
> --8<---------------cut here---------------end--------------->8---
>
> Which it compiles with: erlc -o /tmp/org-babel-erlangFBLqDi
> /tmp/org-babel-erlangFBLqDi/.erl
>
> The file name is made by concatenating the module name (specified with
> -module line or a :module code block parameter), which we didn't specify
> here so it is nil.
>
> It seems that a nil module name is not valid in erlang. the
> -module(). doesn't compile and the file name '.erl' seems to cause
> problems too.  ob-erlang should probably choose a default module name
> when the user doesn't care to specify one instead of producing broken
> code.
>
> The workaround is to define a module name as explained on the ob-erlang
>  home page:
>
> #+BEGIN_SRC erlang :module tryerlang
> start() ->
>       io:format("hello world").
> #+END_SRC
>
> Except there's a bug in ob-erlang and this also fails (it still produces
> a -module(). line).
>
> Instead, define it yourself:
>
> #+begin_src erlang
>   -module(m).
>   start() ->
>       io:format("hello world").
> #+end_src
OK I added that to my source block.
> This works.
>
> I'll take two actions following this:
>
> 1) Create a Guix bug against our Emacs package: installing bash and gzip
> should not be necessary in a container just so that Emacs is able to
> load core modules --> done: http://issues.guix.gnu.org/issue/42224
>
> 2) Submit a PR to the ob-erlang project that fixes the above problems
> --> done: https://github.com/xfwduke/ob-erlang/pull/2.
>
> HTH!
>
> Maxim

Thanks for doing those 2 things and taking the time to write that response.

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl