[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Erlang + Emacs profile

From: Maxim Cournoyer
Subject: Re: Erlang + Emacs profile
Date: Sun, 05 Jul 2020 23:50:55 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hello Zelphir!

Zelphir Kaltstahl <> 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

--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)
    (string-join (mapcar
                  (lambda (line)
                    (if (string-match-p "^-module" line)
                        (setq line (concat line "\n-compile(export_all)."))
                  (split-string code-body "\n"))
--8<---------------cut here---------------end--------------->8---

In Emacs, C-h f string-join RET says it is defined in the subr-x.el

--8<---------------cut here---------------start------------->8---
string-join is a compiled Lisp function in

(string-join STRINGS &optional 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

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")),

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---
start() ->
 io:format("hello world").
--8<---------------cut here---------------end--------------->8---

Which it compiles with: erlc -o /tmp/org-babel-erlangFBLqDi

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

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

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
  start() ->
      io:format("hello world").

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:

2) Submit a PR to the ob-erlang project that fixes the above problems
--> done:



reply via email to

[Prev in Thread] Current Thread [Next in Thread]