emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* ob-haskell and changing executables?
@ 2024-03-09  5:48 Laurence von Bottorff
  2024-03-09  9:30 ` Bruno Barbier
  2024-03-12 12:05 ` Ihor Radchenko
  0 siblings, 2 replies; 6+ messages in thread
From: Laurence von Bottorff @ 2024-03-09  5:48 UTC (permalink / raw)
  To: emacs-orgmode Mailinglist

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

I'm on Debian 12 and I just started using Haskell's ghcup tools, leaving
the stack tools behind, as advised these days. ghcup puts executables for
Haskell such as ghc, ghci (REPL), cabal, etc. in its ~/.ghcup/bin
directory. Next, to stop using the stack tools that have executables in
/usr/bin/ you must change your PATH to go to ~/.ghcup/bin first. But when I
try a Babel code block, ob-haskell seems to have the /usr/bin versions
hardwired somewhere and calls up the old ghci REPL. Searching through Emacs
Customize Haskell was confusing and my init only had one relevant entry
anyway, which didn't help when I changed it.

In the /usr/bin directory the Haskell execs are linked to just one specific
version. In my case /usr/bin contained symbolic links ghc -> ghc-9.0.2 and
ghci -> ghci-9.0.2. This is not great, since Haskell in the wild is
project-based, i.e., differing versions of the ghc compiler can be used in
different projects, as well as wildly diverging libraries and packages per
project. Obviously Babel can't easily take advantage of this, but Haskell
does allow "system-wide" library installs.

My solution was to simply delete the symlinks in /usr/bin and create new
ones to the ghcup tools, e.g., ghc -> ~/.ghcup/bin/ghc etc. So now it works
properly and calls up the new ghcup ghci when I do a Haskell Babel block,
but this is a kludge. No elisp master, I can't find where this /usr/bin
address is hardwired. If you've gotten this far you probably know more
about the Haskell Babel situation than you ever wanted to, but maybe you
can sniff out where this hardwire is happening.

-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borgauf@gmail.com

[-- Attachment #2: Type: text/html, Size: 2051 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ob-haskell and changing executables?
  2024-03-09  5:48 ob-haskell and changing executables? Laurence von Bottorff
@ 2024-03-09  9:30 ` Bruno Barbier
  2024-03-12 12:35   ` Ihor Radchenko
  2024-03-12 12:05 ` Ihor Radchenko
  1 sibling, 1 reply; 6+ messages in thread
From: Bruno Barbier @ 2024-03-09  9:30 UTC (permalink / raw)
  To: Laurence von Bottorff, emacs-orgmode Mailinglist


Hi Laurence,

Laurence von Bottorff <borgauf@gmail.com> writes:

> I'm on Debian 12 and I just started using Haskell's ghcup tools, leaving
> the stack tools behind, as advised these days. ghcup puts executables for
> Haskell such as ghc, ghci (REPL), cabal, etc. in its ~/.ghcup/bin
> directory. Next, to stop using the stack tools that have executables in
> /usr/bin/ you must change your PATH to go to ~/.ghcup/bin first. But when I
> try a Babel code block, ob-haskell seems to have the /usr/bin versions
> hardwired somewhere and calls up the old ghci REPL. Searching through Emacs
> Customize Haskell was confusing and my init only had one relevant entry
> anyway, which didn't help when I changed it.
>
[...]

> If you've gotten this far you probably know more
> about the Haskell Babel situation than you ever wanted to, but maybe you
> can sniff out where this hardwire is happening.

It's not hard coded (there is quite a lot of code just to guess the
right interpreter).  ob-haskell delegates the task to the
haskell-mode package; that's where you should be looking for to
configure it.

Also, if your Org file is not inside your haskell project, using the
:dir option may help haskell-mode to guess it right.

Else, did you try to customize haskell-process-type ?

There is also the option 'haskell-process-path-ghci', so, you should be
able to set the path manually too.  Or you've already forced it to
"/usr/bin/ghci" ?

Bruno


> -- 
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf@gmail.com


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ob-haskell and changing executables?
  2024-03-09  5:48 ob-haskell and changing executables? Laurence von Bottorff
  2024-03-09  9:30 ` Bruno Barbier
@ 2024-03-12 12:05 ` Ihor Radchenko
  1 sibling, 0 replies; 6+ messages in thread
From: Ihor Radchenko @ 2024-03-12 12:05 UTC (permalink / raw)
  To: Laurence von Bottorff; +Cc: emacs-orgmode Mailinglist

Laurence von Bottorff <borgauf@gmail.com> writes:

> I'm on Debian 12 and I just started using Haskell's ghcup tools, leaving
> the stack tools behind, as advised these days. ghcup puts executables for
> Haskell such as ghc, ghci (REPL), cabal, etc. in its ~/.ghcup/bin
> directory. Next, to stop using the stack tools that have executables in
> /usr/bin/ you must change your PATH to go to ~/.ghcup/bin first. But when I
> try a Babel code block, ob-haskell seems to have the /usr/bin versions
> hardwired somewhere and calls up the old ghci REPL.

They are not hardwired. May you check that PATH inside your Emacs is set
correctly? You can, for example, run
(getenv "PATH") or (shell-command-to-string "whereis ghci")

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ob-haskell and changing executables?
  2024-03-09  9:30 ` Bruno Barbier
@ 2024-03-12 12:35   ` Ihor Radchenko
  2024-03-12 13:44     ` Bruno Barbier
  0 siblings, 1 reply; 6+ messages in thread
From: Ihor Radchenko @ 2024-03-12 12:35 UTC (permalink / raw)
  To: Bruno Barbier; +Cc: Laurence von Bottorff, emacs-orgmode Mailinglist

Bruno Barbier <brubar.cs@gmail.com> writes:

>> If you've gotten this far you probably know more
>> about the Haskell Babel situation than you ever wanted to, but maybe you
>> can sniff out where this hardwire is happening.
>
> It's not hard coded (there is quite a lot of code just to guess the
> right interpreter).  ob-haskell delegates the task to the
> haskell-mode package; that's where you should be looking for to
> configure it.

Only for sessions. For src blocks with :session none, we directly call
`org-babel-haskell-compiler'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ob-haskell and changing executables?
  2024-03-12 12:35   ` Ihor Radchenko
@ 2024-03-12 13:44     ` Bruno Barbier
  2024-03-12 14:51       ` Ihor Radchenko
  0 siblings, 1 reply; 6+ messages in thread
From: Bruno Barbier @ 2024-03-12 13:44 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Laurence von Bottorff, emacs-orgmode Mailinglist


Hi Ihor,

Ihor Radchenko <yantar92@posteo.net> writes:

> Bruno Barbier <brubar.cs@gmail.com> writes:
>
>>> If you've gotten this far you probably know more
>>> about the Haskell Babel situation than you ever wanted to, but maybe you
>>> can sniff out where this hardwire is happening.
>>
>> It's not hard coded (there is quite a lot of code just to guess the
>> right interpreter).  ob-haskell delegates the task to the
>> haskell-mode package; that's where you should be looking for to
>> configure it.
>
> Only for sessions. For src blocks with :session none, we directly call
> `org-babel-haskell-compiler'.

Good point.  I didn't check that execution path (probably because I
assumed the OP was speaking only about GHCi).

But, from what I see (function `org-babel-execute:haskell'), for
Haskell, we switch to the compiler only if explicitly requested
(':compile' option is "yes").  If not, we use the interpreter for both
with and without sessions.

Am I missing something ?

Thanks,

Bruno


>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ob-haskell and changing executables?
  2024-03-12 13:44     ` Bruno Barbier
@ 2024-03-12 14:51       ` Ihor Radchenko
  0 siblings, 0 replies; 6+ messages in thread
From: Ihor Radchenko @ 2024-03-12 14:51 UTC (permalink / raw)
  To: Bruno Barbier; +Cc: Laurence von Bottorff, emacs-orgmode Mailinglist

Bruno Barbier <brubar.cs@gmail.com> writes:

>> Only for sessions. For src blocks with :session none, we directly call
>> `org-babel-haskell-compiler'.
>
> Good point.  I didn't check that execution path (probably because I
> assumed the OP was speaking only about GHCi).
>
> But, from what I see (function `org-babel-execute:haskell'), for
> Haskell, we switch to the compiler only if explicitly requested
> (':compile' option is "yes").  If not, we use the interpreter for both
> with and without sessions.
>
> Am I missing something ?

Looks like you are right.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-03-12 14:48 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-09  5:48 ob-haskell and changing executables? Laurence von Bottorff
2024-03-09  9:30 ` Bruno Barbier
2024-03-12 12:35   ` Ihor Radchenko
2024-03-12 13:44     ` Bruno Barbier
2024-03-12 14:51       ` Ihor Radchenko
2024-03-12 12:05 ` Ihor Radchenko

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).