Re: Erlang + Emacs profile

[Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>]

Hey Maxim!

Wow, thanks for the notes on how to debug the problem as well as looking
into it.

I'll try to do the same debugging later myself, to learn how to do that
and perhaps in the future know what to look for.

Regards,
Zelphir

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.  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.
>
> 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.
>
> 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
>
> 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

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