Re: ob-haskell and changing executables?

Bruno Barbier 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

Re: ob-haskell and changing executables?

gt; 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

Re: ob-haskell and changing executables?

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

Re: ob-haskell and changing executables?

ng 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 P

Re: ob-haskell and changing executables?

ext, 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 Emac

ob-haskell and changing executables?

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

Re: [PATCH] Add tests for ob-haskell (GHCi)

Ihor Radchenko writes: > Bruno Barbier writes: > >> From 86a5443948fc84a6a412ccf49d0c537608f465a7 Mon Sep 17 00:00:00 2001 >> From: Bruno BARBIER >> Date: Fri, 18 Nov 2022 20:14:20 +0100 >> Subject: [PATCH 1/7] ob-haskell: Add tests for GHCi >> ... > &

Re: [PATCH] Add tests for ob-haskell (GHCi)

Bruno Barbier writes: > From 86a5443948fc84a6a412ccf49d0c537608f465a7 Mon Sep 17 00:00:00 2001 > From: Bruno BARBIER > Date: Fri, 18 Nov 2022 20:14:20 +0100 > Subject: [PATCH 1/7] ob-haskell: Add tests for GHCi > ... Thanks! Applied, onto main. I also added a missing def

Re: [PATCH] Add tests for ob-haskell (GHCi)

ell-initiate-session'. I am >>> not sure why you are trying to pass it here. >> >> We have the PARAMS, and, org-babel-haskell-initiate-session has a >> PARAMS arguments. So, at the API level, I think it's better to >> propagate it than to ignore it. But you're right that, tod

Re: [PATCH] Add tests for ob-haskell (GHCi)

Hi Ihor, Ihor Radchenko writes: > A few months have passed since the last activity in this thread. > Bruno, may I know if you are still interested to work on the patch? Thanks for the reminder. I'm definitely interested to closing that thread. I'll review my last changes and send my

Re: [PATCH] Add tests for ob-haskell (GHCi)

A few months have passed since the last activity in this thread. Bruno, may I know if you are still interested to work on the patch? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at

Re: [PATCH] Add tests for ob-haskell (GHCi)

Bruno Barbier writes: >> I can see that you limited the tests scope to :session blocks. >> Would it be possible to extend the existing tests to :compile yes case? >> From a glance, it does not look like you need to change much - Haskell >> behaviour should be similar with or without ghci. > >

Re: [PATCH] Add tests for ob-haskell (GHCi)

I'd like to do to improve my day to day workflow, and as I'm barely using ob-haskell, I can't promise I'll work on this any time soon. >> From 9972b926f55cb970e0b520f8726a3684118017b6 Mon Sep 17 00:00:00 2001 >> From: Ihor Radchenko >> Date: Fri, 24 Mar 2023 11:20:22 +0100 >> S

Re: [PATCH] Add tests for ob-haskell (GHCi)

023 11:26:00 +0100 > Subject: [PATCH 04/13] * testing/lisp/test-ob-haskell-ghci.el: Enable fixed I do not see PATCH 03/13 in the attachments. > From 7d66cff5cc23bb786cb2843f4326d2869512ccac Mon Sep 17 00:00:00 2001 > From: Bruno BARBIER > Date: Sat, 25 Mar 2023 10:06:44 +0100 > Sub

Re: [PATCH] Add tests for ob-haskell (GHCi)

any later version. > > Do we need the text for "part of GNU Emacs"? > I guess it doesn't harm: I added it, thanks. >> + >> +(defun test-ob-haskell-ghci--with-global-session-worker (todo) >> + "See `test-ob-haskell-ghci--with-global-session-worker'.&qu

Re: [PATCH] Add tests for ob-haskell (GHCi)

Minor remarks below regarding the patchset. Bruno Barbier writes: > From 9ef867cd2cf89e77b5c5a5a7090fd37b1702e06a Mon Sep 17 00:00:00 2001 > From: Bruno BARBIER > Date: Fri, 18 Nov 2022 20:14:20 +0100 > Subject: [PATCH 01/13] ob-haskell: Add tests for GHCi > > testing/li

Re: [PATCH] Add tests for ob-haskell (GHCi)

Hi Ihor, Sorry for the delay. Bruno Barbier writes: > Ihor Radchenko writes: > >> Bruno Barbier writes: >> >>> Note that I've changed the tests about errors; I'm now expecting >>> ob-haskell to raise errors. I'm not sure what we should expect to be

Re: [PATCH] Add tests for ob-haskell (GHCi)

Bruno Barbier writes: >> Why not simply putStrLn ("\"" ++ show it ++ "\"") ? >> > > I'm not sure I understand. I'm using the first > 'org-babel-comint-with-output' to execute the source block and save the > last value (the "it" variable). Then, I'm using a second > 'org-babel-comint-with-output'

Re: [PATCH] Add tests for ob-haskell (GHCi)

Ihor Radchenko writes: > Bruno Barbier writes: > >> Note that I've changed the tests about errors; I'm now expecting >> ob-haskell to raise errors. I'm not sure what we should expect to be >> consistent with other org babel backends. > > Errors are usually disp

Re: [PATCH] Add tests for ob-haskell (GHCi)

d work well enough, until haskell-mode > provides a way to choose the buffer name. > > I've updated the tests and the expected results. Thanks! I will provide comments inline. > Note that I've changed the tests about errors; I'm now expecting > ob-haskell to raise errors. I'm not sure

Re: [PATCH] Add tests for ob-haskell (GHCi)

Ihor Radchenko writes: > Note that setting the prompt to non-"", makes little sense - we want to > remove it anyway. Why do extra work? Oh, I didn't notice you set the prompt to "". I thought the extra work you were being done was *because* somewhere else the default was set to "λ ". I agree,

Re: [PATCH] Add tests for ob-haskell (GHCi)

and the expected results. Note that I've changed the tests about errors; I'm now expecting ob-haskell to raise errors. I'm not sure what we should expect to be consistent with other org babel backends. I also did some modifications in my initial patch in-place. Bruno [1]:https://downloads.haskell.

Re: [PATCH] Add tests for ob-haskell (GHCi)

20:14:20 +0100 Subject: [PATCH 1/4] ob-haskell: Add tests for GHCi testing/lisp/test-ob-haskell-ghci.el: New file. --- testing/lisp/test-ob-haskell-ghci.el | 428 +++ 1 file changed, 428 insertions(+) create mode 100644 testing/lisp/test-ob-haskell-ghci.el diff --git a/t

Re: [PATCH] Add tests for ob-haskell (GHCi)

ParetoOptimalDev writes: >> comint-prompt-regexp: ^[[:alnum:].*_() |λ]*> \|^λ?> >> Output: ghci| ghci| ghci| ghci| ghci| 6 >> >> Note "|". > > You can fix this by sending `set :prompt-cont ""`. Here is a > demonstration: I think you meant `:set prompt-cont ""`. It is a good idea, thanks! We

Re: [PATCH] Add tests for ob-haskell (GHCi)

I forgot to mention you can also set the prompt as well to something simple like `:set prompt "> "`. > Ihor Radchenko writes: > >> Part of the problem is that haskell-mode appears to use non-standard >> prompt: >> >> comint-prompt-regexp: ^[[:alnum:].*_() |λ]*> \|^λ?> >> Output: ghci| ghci|

Re: [PATCH] Add tests for ob-haskell (GHCi)

Ihor Radchenko writes: > Part of the problem is that haskell-mode appears to use non-standard > prompt: > > comint-prompt-regexp: ^[[:alnum:].*_() |λ]*> \|^λ?> > Output: ghci| ghci| ghci| ghci| ghci| 6 > > Note "|". You can fix this by sending `set :prompt-cont ""`. Here is a demonstration:

Re: [PATCH] Add tests for ob-haskell (GHCi)

Bruno Barbier writes: > +(ert-deftest ob-haskell/let-multilines-1 () > + "Local definitions on multiple lines." > + :expected-result :failed > + (should (equal 6 (test-ob-haskell-ghci "" " > +:{ > + let { x=2 > + ; y=3 > +

Re: [PATCH] Add tests for ob-haskell (GHCi)

Bruno Barbier writes: > Ihor Radchenko writes: > >> From a first look, random failures appear to be related to session >> initialization. > > My function 'test-ob-haskell-ghci' should protect against that; it > ensures the "*haskell*" buffer i

Re: 1 character fix to make ob-haskell compatible with table outputs

ParetoOptimalDev via "General discussions about Org-mode." writes: > Oh, great to hear it's fixed! Sorry, I was not clear. I do not know if the bug existed to start with. I just cannot reproduce on the latest main, which can be for many reasons, starting from me misunderstanding the bug, or

Re: 1 character fix to make ob-haskell compatible with table outputs

Oh, great to hear it's fixed!

Re: [PATCH] Add tests for ob-haskell (GHCi)

Hi Ihor, Ihor Radchenko writes: > From a first look, random failures appear to be related to session > initialization. My function 'test-ob-haskell-ghci' should protect against that; it ensures the "*haskell*" buffer is always new. From what I understand, this is an input b

Re: [PATCH] Add tests for ob-haskell (GHCi)

Ihor Radchenko writes: > From a first look, random failures appear to be related to session > initialization. It appears that ob-haskell is re-using sessions even > if :session is nil (default). And multiple session not allowed?? (I am > looking at `org-babel-haskell-initiate-ses

Re: [PATCH] Add tests for ob-haskell (GHCi)

Bruno Barbier writes: > All the tests will randomly fail; that is an ob-haskell bug (see > the command 'test-ob-haskell-ghci.el' to make them fail). First of all, thanks for the patch! Tests are especially welcome. >From a first look, random failures appear to be related t

[PATCH] Add tests for ob-haskell (GHCi)

Hi all, I've collected some tests about ob-haskell, using GHCi. This patch is not ready for final review. It's a preliminary version. These tests are about GHCi, and only about GHCi (that's why I named the file 'test-ob-haskell-ghci.el'). Some tests are revealing bugs; they are flagged

Re: 1 character fix to make ob-haskell compatible with table outputs

ParetoOptimalDev via "General discussions about Org-mode." writes: > For something like: > > name:tbl > #+begin_src sh > echo -e "1\t2\t3" > #+end_src > > #+RESULTS: > | 1 | 2 | 3 | > > #+begin_src haskell :var table=tbl > print table > #+end_src > > #+RESULTS: > | 1 | 2 | 3 | > > Whereas before

1 character fix to make ob-haskell compatible with table outputs

Just change the `[` and `]` to `(` and `)` respectively. List of lists aren't parsed correctly by ob-haskell, but tuples of tuples are. That means this code change I just tested works: (defun org-babel-haskell-var-to-haskell (var) "Convert an elisp value VAR into a haskell var

Re: ob-haskell

d be suboptimal. I don't know how other babel plugins work, but the way I enjoy working with ghci the most is to load in a file to ghci and then test a bunch of expressions in the repl. Maybe ob-haskell could work like this as well, with one type of block that loads the code as a file and another

Re: ob-haskell

Bottorff wrote... > I recently wimped out of trying to update ob-haskell as an official > maintainer, but I'd eventually like to get back to it -- *after *I get > some base understanding of what Haskell is (Zeno's paradox-land?) and > how the ghci works. Basically, the ghci is what it is --

ob-haskell

I recently wimped out of trying to update ob-haskell as an official maintainer, but I'd eventually like to get back to it -- *after *I get some base understanding of what Haskell is (Zeno's paradox-land?) and how the ghci works. Basically, the ghci is what it is -- tautological, but true

Re: [PATCH] Update ob-haskell from deprecated inf-haskell-mode to haskell-interactive-mode

Seth Lee writes: > Issue: compiling code in a source block that had an infinite list that > would evaluate in the ghci. All code, even with `:compile` flag set > would be run in ghci. > > Updating deprecated `inf-haskell-mode` to `haskell-interactive-mode` > solves the issue for me. > > Source

[PATCH] Update ob-haskell from deprecated inf-haskell-mode to haskell-interactive-mode

Hello, I've made a patch for `ob-haskell.el`. I'm not really an elisper, but I made a patch that seems to work on my machine. Issue: compiling code in a source block that had an infinite list that would evaluate in the ghci. All code, even with `:compile` flag set would be run in ghci. Updating

Re: [PATCH] ob-haskell: Line Continuations Mangle Block Output

l-mode... This is inf-haskell's variable. > ob-haskell shouldn't set it. Thank you for your help in all this. I couldn't find where the regex was set in the org-mode source because it wasn't coming from org-mode at all. Putting this all together suggests that the correct fix is to update the inf-hask

Re: [PATCH] ob-haskell: Line Continuations Mangle Block Output

prompts from Haskell interpreters: > + > +GHC: > + > +- 'output > + ^Prelude> EOE' > +- '^Prelude> output EOE' > +- '^Prelude| Prelude| Prelude> output EOE' > + > +Unknown Interpreter: > + > +- '^> ' > +- '^λ> '") This is inf-haskell's v

Re: [PATCH] ob-haskell: Line Continuations Mangle Block Output

revamped inf-haskell, 2017-08-26), which was included in the v17.1 release, haskell-prompt-regexp was introduced and the line above is now (setq-local comint-prompt-regexp haskell-prompt-regexp) > In ob-haskell, we set =comint-prompt-regexp= to the (undefined) > haskell-prompt plus "or

Re: [PATCH] ob-haskell: Line Continuations Mangle Block Output

Apologies, one last patch. On Sat, May 23, 2020 at 7:02 PM Nick Daly wrote: > : "^\\*?[[:upper:]][\\._[:alnum:]]*\\(?: > \\*?[[:upper:]][\\._[:alnum:]]*\\)*\\( λ\\)?> " > > =comint-prompt-regexp='s variable documentation calls out much simpler > regexps > > : "^[^>]+\\(> \\)?" This simplified

Re: [PATCH] ob-haskell: Line Continuations Mangle Block Output

ed prompts. The other patches I submitted were unnecessary. 2. The =comint-prompt-regexp= gets default values from somewhere I don't understand and can't find with a quick source grep. In ob-haskell, we set =comint-prompt-regexp= to the (undefined) haskell-prompt plus "or optional-lambda"

Re: [PATCH] ob-haskell: Line Continuations Mangle Block Output

Nick Daly writes: > Attached is an updated patch that makes output trimming work with > blocks that do and don't produce results. The old patch creates a > =let: Wrong type argument: arrayp, nil= error when evaluating blocks > that don't produce output. This necessarily incorporates yesterday's

Re: [PATCH] ob-haskell: Line Continuations Mangle Block Output

Hi Org Maintainers, Attached is an updated patch that makes output trimming work with blocks that do and don't produce results. The old patch creates a =let: Wrong type argument: arrayp, nil= error when evaluating blocks that don't produce output. This necessarily incorporates yesterday's

[PATCH] ob-haskell: Line Continuations Mangle Block Output

Hi Org Maintainers, Please see the attached patch to remove "Prelude> " and "Prelude| " line continuations from the block result output when parsing blocks that contain multi-line function declarations. This likely requires yesterday's patch to return value-type results from Haskell blocks.

Re: [O] ob-haskell evaluation needs inf-haskell but it does not exist

I setted `haskell-process-type` to 'ghci. I evaluated a simple haskell src block, but it reports I need have a `*haskell*` inferior. Then I executed command [M-x run-haskell]. Then I get error: Debugger entered--Lisp error: (wrong-type-argument stringp nil) expand-file-name(nil)

Re: [O] ob-haskell evaluation needs inf-haskell but it does not exist

"numbch...@gmail.com" writes: > I checked out your answer, I have meet all your said requirements. GHCi, > inf-haskell (after I installed package haskell-mode) and setting > `haskell-program-name`, I found there is no > `defcustom` variable option named

Re: [O] ob-haskell evaluation needs inf-haskell but it does not exist

I checked out your answer, I have meet all your said requirements. GHCi, inf-haskell (after I installed package haskell-mode) and setting `haskell-program-name`, I found there is no `defcustom` variable option named `haskell-program-name` at all. [stardiviner] GPG key ID: 47C32433

Re: [O] ob-haskell evaluation needs inf-haskell but it does not exist

I required `(require 'inf-haskell)` But have not found the command `inf-haskell` to start inferior process. [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433

Re: [O] ob-haskell evaluation needs inf-haskell but it does not exist

stardiviner writes: > When I execute the following Haskell src block: > > ``` > > #+BEGIN_SRC haskell :session :tangle "Data/Code/hello_world.hs" > main :: IO () > main = do >   putStrLn "Hello, World!" > #+END_SRC > > ``` > > It reports error: > > ``` > > Debugger

[O] ob-haskell evaluation needs inf-haskell but it does not exist

When I execute the following Haskell src block: ``` #+BEGIN_SRC haskell :session :tangle "Data/Code/hello_world.hs" main :: IO () main = do   putStrLn "Hello, World!" #+END_SRC ``` It reports error: ``` Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or

[Orgmode] Re: Bugs in ob-haskell

Hi Robin, Robin Green gree...@greenrd.org writes: I've noticed a number of bugs in ob-haskell: 1. The first time I ran my code block, the results were given as something like: Prelude [[1], [2], [3]] and of course, this isn't an org table, as it should be. I don't think the Prelude

[Orgmode] Bugs in ob-haskell

I've noticed a number of bugs in ob-haskell: 1. The first time I ran my code block, the results were given as something like: Prelude [[1], [2], [3]] and of course, this isn't an org table, as it should be. I don't think the Prelude should have been there, and I suspect a race condition