all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: help-guix@gnu.org
Subject: Re: Erlang + Emacs profile
Date: Tue, 7 Jul 2020 12:23:01 +0200	[thread overview]
Message-ID: <c2cd3425-3955-3550-ca57-7a56f94dd499@posteo.de> (raw)
In-Reply-To: <877dvhl2sg.fsf@gmail.com>

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



  reply	other threads:[~2020-07-07 10:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23 22:49 Erlang + Emacs profile Zelphir Kaltstahl
2020-06-24 20:29 ` Maxim Cournoyer
2020-06-25 19:25   ` Zelphir Kaltstahl
2020-06-28  4:41     ` Maxim Cournoyer
2020-06-29  8:50     ` zimoun
2020-06-29 19:37       ` Zelphir Kaltstahl
2020-06-29 20:24         ` Ricardo Wurmus
2020-06-29 20:37           ` Zelphir Kaltstahl
2020-06-29 20:49         ` zimoun
2020-06-29 21:12           ` Zelphir Kaltstahl
2020-06-29 22:08             ` zimoun
2020-06-29 20:26   ` Zelphir Kaltstahl
2020-06-30 18:34   ` Zelphir Kaltstahl
2020-06-30 18:41   ` Zelphir Kaltstahl
2020-07-06  3:50     ` Maxim Cournoyer
2020-07-07 10:23       ` Zelphir Kaltstahl [this message]
2020-07-07 15:55         ` Maxim Cournoyer
2020-07-16 21:34       ` Zelphir Kaltstahl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c2cd3425-3955-3550-ca57-7a56f94dd499@posteo.de \
    --to=zelphirkaltstahl@posteo.de \
    --cc=help-guix@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.