Re: ob-haskell and changing executables?

[Ihor Radchenko]

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 `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 .
Support Org development at ,
or support my work at 

Re: ob-haskell and changing executables?

[Bruno Barbier]

Hi Ihor,

Ihor Radchenko  writes:

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

Re: ob-haskell and changing executables?

[Ihor Radchenko]

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

Re: ob-haskell and changing executables?

[Ihor Radchenko]

Laurence von Bottorff  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>

Re: ob-haskell and changing executables?

[Bruno Barbier]

Hi Laurence,

Laurence von Bottorff  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
> borg...@gmail.com

ob-haskell and changing executables?

[Laurence von Bottorff]

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
borg...@gmail.com

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

[Bruno Barbier]

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
>> ...
>
> Thanks!
> Applied, onto main.
> I also added a missing defvar declaration for
> `inferior-haskell-root-dir'.

Thanks Ihor!

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

[Ihor Radchenko]

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 defvar declaration for
`inferior-haskell-root-dir'.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=91c52e2ab
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5bffb9a1e
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d6dd92d44
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b85217217
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=924c2dd83
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=36a786f7f
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3674e4024
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=eed3ac9f7

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

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

[Bruno Barbier]

Hi Ihor,

Sorry for the delay, thanks again for the ping.



Ihor Radchenko  writes:

> Bruno Barbier  writes:
>
>>>> +  (when (bufferp "*haskell*") (error "Conflicting buffer 
>>>> '*haskell*', rename it or kill it."))
>>>> +  (with-current-buffer session (rename-buffer "*haskell*")))
>>>
>>> So, you are now renaming the unique session buffer back to "*haskell*".
>>> And never rename it back to expected :session . Users might be 
>>> confused.
>>
>> I do rename it back once inf-haskell has initialized the buffer (after
>> run-haskell in the last version).
>
> A comment would help to clarify things for the readers.

Right. I've improved the comment. Thanks.


>>>> +(save-window-excursion
>>>> +  ;; We don't use `run-haskell' to not popup the buffer.
>>>> +  ;; And we protect default-directory.
>>>> +  (let ((default-directory default-directory))
>>>> +(inferior-haskell-start-process))
>>>




>> About 'default-directory', I'm not sure. Maybe the side effect is done
>> on purpose in inf-haskell.
>
> I can see the haskell-mode overrides default-directory with
> `inferior-haskell-root-dir', running ghci in that directory, if it is
> non-nil. Even with your let binding, it is calling for trouble when
> source block uses :dir header argument.
>
> Maybe we can bind `inferior-haskell-root-dir' to `default-directory'
> instead? `default-directory' is modified according to :dir by ob-core.el
> when necessary.

You may be right that we should use `inferior-haskell-root-dir' to
tell haskell-mode where to run the interpreter.  Done.



>> The function 'putStr' output the string without a newline on stdout
>> (as opposed to the function putStrLn that does add a newline).
>>
>> So, in GHCi, entering:
>>
>> putStr("4")
>> 
>> outputs "4" on stdout, then GHCi outputs the prompt, so we get:
>>
>> 4ghci> 
>>
>> In the end, 'org-babel-comint-with-output' gets this
>> 1ghci> 2ghci> 3ghci> 
>> ghci> org-babel-haskell-eoe
>> ghci> ghci>
>> 
>> and filters out everything as being GHCi prompts and the EOE.
>>
>> I'm not really expecting this to be fixed; I just wanted to record the
>> fact.
>
> We actually might be able to deal with this if we change the prompt and
> update comint-prompt-regexp to something more accurate.

I couldn't make it work by simply restricting the prompt.  I think
it's OK if character by character output doesn't work; ghci is about
line based interaction afterall.



>>>> Subject: [PATCH 11/13] lisp/ob-haskell.el: Fix how to use sessions
>>>>
>>>> +  (org-babel-haskell-with-session
>>>
>>> This kind of names are usually dedicated to macro calls. But
>>> `org-babel-haskell-with-session' is instead a function. I think a macro
>>> will be better. And you will be able to get rid of unnecessary lambda.
>>
>> That looks kind of complicated just to avoid one lambda in one call.
>> But, as I couldn't find a better name, I've translated it into a
>> macro.
>
> I think you misunderstood what I meant.
> See the attached diff on top of your patches that simplifies things a
> bit.
> diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
...
>  (defmacro org-babel-haskell-with-session (session-symbol params  body)
>"Get the session identified by PARAMS and run BODY with it.
.. 
> +  `(let* ((params ,params)
> +  (sn (cdr (assq :session params)))
> +  (session (org-babel-haskell-initiate-session sn params))
> +  (,session-symbol session)
> +  (one-shot (equal sn "none")))
> + (unwind-protect
> + (progn ,@body)

I don't think it's correct to create local variables like this in a
macro: we need to use uninterned symbols, else we may capture caller
variables (params, sn, session and one-shot).

I personnaly find it easier when I keep my macros as short as
possible, and, to do any non-trivial work in a function: easier to
read, to modify and to debug.




>>>> -(let ((buffer (org-babel-haskell-initiate-session session)))
>>>> +(let ((buffer (org-babel-haskell-initiate-session session params)))
>>>
>>> PARAMS argument is ignored by `org-babel-haskell-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

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

[Bruno Barbier]

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

Thank you for your patience,

Bruno.

> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

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

[Ihor Radchenko]

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 ,
or support my work at 

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

[Ihor Radchenko]

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.
>
> Except for one line expressions, GHCi inputs and haskell modules are
> two different things.  I doubt there will be much to share; that's why
> I've focused from the start on GHCi only.

Fair point. I thought that the differences are less significant.

>>> +(sleep-for 0.25)
>>> +;; Disable secondary prompt.
>>
>> It would be useful to explain the purpose of disabling the secondary
>> prompt in the source code comment itself, not just in the commit
>> message. It will improve readability.
>
> Are you reviewing your own improvements ? :-)

Sure. Why not :3 Nobody guaranteed that my code is free of errors.

> Fixed. I've copied/pasted your explanation in the code.

Thanks!

>> Also, session may be a killed buffer object. It is still a buffer, but
>> not usable. See `buffer-live-p'.
>
> By construction, if 'session' is a buffer, then, it is a live buffer.

You are probably right. Even though killed buffer objects may appear in
Elisp (28.10 Killing Buffers), their buffer names should be nil, and thus
they cannot be returned by `get-buffer'.

>>> +  (when (bufferp "*haskell*") (error "Conflicting buffer 
>>> '*haskell*', rename it or kill it."))
>>> +  (with-current-buffer session (rename-buffer "*haskell*")))
>>
>> So, you are now renaming the unique session buffer back to "*haskell*".
>> And never rename it back to expected :session . Users might be 
>> confused.
>
> I do rename it back once inf-haskell has initialized the buffer (after
> run-haskell in the last version).

A comment would help to clarify things for the readers.

>>> +(save-window-excursion
>>> +  ;; We don't use `run-haskell' to not popup the buffer.
>>> +  ;; And we protect default-directory.
>>> +  (let ((default-directory default-directory))
>>> +(inferior-haskell-start-process))
>>
>> This is a workaround for a nasty side effect of running
>> `inferior-haskell-start-process'. We should report this to haskell-mode
>> developers, leaving appropriate comment in the code.
>
> About 'run-haskell', I reverted my change: we're inside a
> 'save-window-excursion', which looks like the standard way to get rid
> of unwanted popups (like ob-shell does).
>
> About 'default-directory', I'm not sure. Maybe the side effect is done
> on purpose in inf-haskell.

I can see the haskell-mode overrides default-directory with
`inferior-haskell-root-dir', running ghci in that directory, if it is
non-nil. Even with your let binding, it is calling for trouble when
source block uses :dir header argument.

Maybe we can bind `inferior-haskell-root-dir' to `default-directory'
instead? `default-directory' is modified according to :dir by ob-core.el
when necessary.

> The function 'putStr' output the string without a newline on stdout
> (as opposed to the function putStrLn that does add a newline).
>
> So, in GHCi, entering:
>
> putStr("4")
> 
> outputs "4" on stdout, then GHCi outputs the prompt, so we get:
>
> 4ghci> 
>
> In the end, 'org-babel-comint-with-output' gets this
> 1ghci> 2ghci> 3ghci> 
> ghci> org-babel-haskell-eoe
> ghci> ghci>
> 
> and filters out everything as being GHCi prompts and the EOE.
>
> I'm not really expecting this to be fixed; I just wanted to record the
> fact.

We actually might be able to deal with this if we change the prompt and
update comint-prompt-regexp to something more accurate.

>>> Subject: [PATCH 11/13] lisp/ob-haskell.el: Fix how to use sessions
>>>
>>> +  (org-babel-haskell-with-session
>>
>> This kind of names are usually dedicated to macro calls. But
>> `org-babel-haskell-with-session' is instead a function. I think a macro
>> will be better. And you will be able to get rid of unnecessary lambda.
>
> That looks kind of complicated just to avoid one lambda in one call.
> But, as I couldn't find a better name, I've translated it into a
> macro.

I think you misunderstood what I meant.
See the attached diff on top of your patches that simplifies things a
bit.

diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
index cd930266c..a8240d02b 100644
--- a/lisp/ob-haskell.el
+++ b/lisp/ob-haskell.el
@@ -77,31 +77,28 @@ (defcustom org-babel-haskell-compiler "ghc"
 (defconst org-babel-header-args:haskell '((compile . :any))
   "Haskell-specific header arguments.")
 
-
-(defun org-babel-haskell-with-session--worker (params todo)
-  "See `org-babel-haskell-with-session'."
-  (let* ((sn (cdr (assq :session params)))
- (session (org-babel-haskell-initiate-session sn params))
- (one-shot (equal sn "none")))
-(unwind-protect
-(funcall todo session)
-  (when (and one-shot (buffer-live-p 

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

[Bruno Barbier]

Hi Ihor,

Thanks for the review.


Ihor Radchenko  writes:
> 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.


Except for one line expressions, GHCi inputs and haskell modules are
two different things.  I doubt there will be much to share; that's why
I've focused from the start on GHCi only.

As I've a lot of other things that 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
>> Subject: [PATCH 02/13] org-babel-haskell-initiate-session: Remove secondary
>>  prompt
>>
>> * lisp/ob-haskell.el (org-babel-haskell-initiate-session): Set
>> secondary prompt to "".  If we do not do this, org-comint may treat
>> secondary prompts as a part of output.
>
>> +(sleep-for 0.25)
>> +;; Disable secondary prompt.
>
> It would be useful to explain the purpose of disabling the secondary
> prompt in the source code comment itself, not just in the commit
> message. It will improve readability.

Are you reviewing your own improvements ? :-)

Fixed. I've copied/pasted your explanation in the code.



>> From 352d18399961fedc45cc2d64007016426e1ecd40 Mon Sep 17 00:00:00 2001
>> From: Ihor Radchenko 
>> Date: Fri, 24 Mar 2023 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.

Sorry. I forgot it the first time. The email, after handling the
comments from Ruijie Yu, had it though.



>> From 7d66cff5cc23bb786cb2843f4326d2869512ccac Mon Sep 17 00:00:00 2001
>> From: Bruno BARBIER 
>> Date: Sat, 25 Mar 2023 10:06:44 +0100
>> Subject: [PATCH 06/13] ob-haskell: Implement sessions
>>
>> +  (unless session-name
>> +;; As haskell-mode is using the buffer name "*haskell*", we stay
>> +;; away from it.
>> +(setq session-name (generate-new-buffer-name "*ob-haskell*")))
>> +  (let ((session (get-buffer session-name)))
>
> session is not a buffer or nil, if no buffer named session-name exists.

The argument SESSION-NAME must be a string or nil (I added a test to
make clear that it must be a string).  Thus, session will either be nil or
a live buffer.



>> +(save-window-excursion
>> +  (or (org-babel-comint-buffer-livep session)
>
> Below, (org-babel-comint-buffer-livep session) is nil, which implies
> either that session is nil, does not exist, not live, or does not have a
> process attached.

ok. So, in our case, session is either nil, or it's a live buffer
without an attached process.

>
>> +  (let ((inferior-haskell-buffer session))
>> +(when (and (bufferp session) (not 
>> (org-babel-comint-buffer-livep session)))
>
> (not (org-babel-comint-buffer-livep session)) is always t here.

Right. I removed the test. Thanks.


> Also, session may be a killed buffer object. It is still a buffer, but
> not usable. See `buffer-live-p'.

By construction, if 'session' is a buffer, then, it is a live buffer.


>
>> +  (when (bufferp "*haskell*") (error "Conflicting buffer 
>> '*haskell*', rename it or kill it."))
>> +  (with-current-buffer session (rename-buffer "*haskell*")))
>
> So, you are now renaming the unique session buffer back to "*haskell*".
> And never rename it back to expected :session . Users might be 
> confused.

I do rename it back once inf-haskell has initialized the buffer (after
run-haskell in the last version).


>> +(save-window-excursion
>> +  ;; We don't use `run-haskell' to not popup the buffer.
>> +  ;; And we protect default-directory.
>> +  (let ((default-directory default-directory))
>> +(inferior-haskell-start-process))
>
> This is a workaround for a nasty side effect of running
> `inferior-haskell-start-process'. We should report this to haskell-mode
> developers, leaving appropriate comment in the code.

About 'run-haskell', I reverted my change: we're inside a
'save-window-excursion', which looks like the standard way to get rid
of unwanted popups (like ob-shell does).

About 'default-directory', I'm not sure. Maybe the side effect is done
on purpose in inf-haskell.



>
>> +  (sleep-for 0.25)
>> +   

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

[Ihor Radchenko]

Bruno Barbier  writes:

> Let me know if you see further improvement before pushing this.

Thanks for the update!

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.

> From 9972b926f55cb970e0b520f8726a3684118017b6 Mon Sep 17 00:00:00 2001
> From: Ihor Radchenko 
> Date: Fri, 24 Mar 2023 11:20:22 +0100
> Subject: [PATCH 02/13] org-babel-haskell-initiate-session: Remove secondary
>  prompt
>
> * lisp/ob-haskell.el (org-babel-haskell-initiate-session): Set
> secondary prompt to "".  If we do not do this, org-comint may treat
> secondary prompts as a part of output.

> +(sleep-for 0.25)
> +;; Disable secondary prompt.

It would be useful to explain the purpose of disabling the secondary
prompt in the source code comment itself, not just in the commit
message. It will improve readability.

> From 352d18399961fedc45cc2d64007016426e1ecd40 Mon Sep 17 00:00:00 2001
> From: Ihor Radchenko 
> Date: Fri, 24 Mar 2023 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
> Subject: [PATCH 06/13] ob-haskell: Implement sessions
>
> +  (unless session-name
> +;; As haskell-mode is using the buffer name "*haskell*", we stay
> +;; away from it.
> +(setq session-name (generate-new-buffer-name "*ob-haskell*")))
> +  (let ((session (get-buffer session-name)))

session is not a buffer or nil, if no buffer named session-name exists.

> +(save-window-excursion
> +  (or (org-babel-comint-buffer-livep session)

Below, (org-babel-comint-buffer-livep session) is nil, which implies
either that session is nil, does not exist, not live, or does not have a
process attached.

> +  (let ((inferior-haskell-buffer session))
> +(when (and (bufferp session) (not (org-babel-comint-buffer-livep 
> session)))

(not (org-babel-comint-buffer-livep session)) is always t here.
Also, session may be a killed buffer object. It is still a buffer, but
not usable. See `buffer-live-p'.

> +  (when (bufferp "*haskell*") (error "Conflicting buffer 
> '*haskell*', rename it or kill it."))
> +  (with-current-buffer session (rename-buffer "*haskell*")))

So, you are now renaming the unique session buffer back to "*haskell*".
And never rename it back to expected :session . Users might be confused.

> +(save-window-excursion
> +  ;; We don't use `run-haskell' to not popup the buffer.
> +  ;; And we protect default-directory.
> +  (let ((default-directory default-directory))
> +(inferior-haskell-start-process))

This is a workaround for a nasty side effect of running
`inferior-haskell-start-process'. We should report this to haskell-mode
developers, leaving appropriate comment in the code.

> +  (sleep-for 0.25)
> +  (setq session inferior-haskell-buffer)
> +  (with-current-buffer session (rename-buffer session-name))

This generally looks like a brittle workaround for inner workings of
haskell-mode. I recommend sending an email to haskell-mode devs,
requesting multiple session support. Otherwise, this whole code
eventually be broken.

> Subject: [PATCH 10/13] * testing/lisp/test-ob-haskell-ghci.el: Test output
>  without EOL
> ...
> +(ert-deftest ob-haskell/output-without-eol-1 ()
> +  "Cannot get output from incomplete lines, when entered line by line."
> +  :expected-result :failed
> +  (should (equal "123"
> + (test-ob-haskell-ghci ":results output" "
> +  putStr(\"1\")
> +  putStr(\"2\")
> +  putStr(\"3\")
> +  putStr(\"\\n\")
> +"

May you explain more about this bug?

> Subject: [PATCH 11/13] lisp/ob-haskell.el: Fix how to use sessions
>
> +  (org-babel-haskell-with-session

This kind of names are usually dedicated to macro calls. But
`org-babel-haskell-with-session' is instead a function. I think a macro
will be better. And you will be able to get rid of unnecessary lambda.

> +   params
> +   (lambda (session)
> + (cl-labels
> + ((csend (txt)
> +  (eom ()
> +  (with-output (todo)

When using `cl-labels', please prefer longer, more descriptive function
names. These functions do not have a docstring and I now am left
guessing and reading the function code repeatedly to unders

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

[Bruno Barbier]

Ruijie Yu  writes:

> Minor remarks below regarding the patchset.
>
> Bruno Barbier  writes:
>
>> +;; Copyright (c) 2023  Free Software Foundation, Inc.
>
> lisp/org.el has only a single space, so probably single space here as well.

Done.

>> +
>> +;; Authors: Bruno BARBIER 
>> +
>> +;; This program is free software; you can redistribute it and/or modify
>> +;; it under the terms of the GNU General Public License as published by
>> +;; the Free Software Foundation, either version 3 of the License, or
>> +;; (at your option) 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'."
>
> This docstring doesn't say much and only refers to itself.  Maybe
> explain what it does?  (Or now that I look at it, potentially you wanted
> to refer to the macro `test-ob-haskell-ghci-with-global-session'
> instead.)

I've rewritten that function later ... which made the documentation even worse 
:-)
I've fixed it, thanks.


>
>> +(defun test-ob-haskell-ghci (args content  preamble unprotected)
>> +  "Execute the code block CONTENT in a new GHCi session; return the result.
>> +Add ARGS to the code block argument line.  Insert PREAMBLE
>> +before the code block.  When UNPROTECTED is non-nil, don't control
>> +which session is used (i.e. don't call
>> +`test-ob-haskell-ghci--with-global-session-worker')."
>> +  (when (listp content)
>> +(setq content (string-join content "\n")))
>> +  (unless preamble
>> +(setq preamble ""))
>> +  (let ((todo  (lambda ()
>
> One space.

AFAICS, the last version has only one space here.


>> +
>> + Not define  errors
>> +;;

> Single space?

It was an invisible 'd' actually; I repainted in black :-)
Thanks.


Thank you for your review,

Bruno

>From 136878a096eb9f459e97da6617f94ba84085db9b 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/lisp/test-ob-haskell-ghci.el: New file.
---
 testing/lisp/test-ob-haskell-ghci.el | 454 +++
 1 file changed, 454 insertions(+)
 create mode 100644 testing/lisp/test-ob-haskell-ghci.el

diff --git a/testing/lisp/test-ob-haskell-ghci.el b/testing/lisp/test-ob-haskell-ghci.el
new file mode 100644
index 0..4023873de
--- /dev/null
+++ b/testing/lisp/test-ob-haskell-ghci.el
@@ -0,0 +1,454 @@
+;;; test-ob-haskell-ghci.el --- tests for ob-haskell.el GHCi  -*- lexical-binding: t; -*-
+
+;; Copyright (c) 2023 Free Software Foundation, Inc.
+;; Authors: Bruno BARBIER 
+
+;; This file is part of GNU Emacs.
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+;;
+
+ Useful references
+;;
+;;  - https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html
+;;  - GHCi manual: https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html
+ FIXME: Random failures
+;;
+;; To increase the chances of failure when running tests, you can use this command line:
+;;
+;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty & done) 2>&1 | grep FAILED
+;;
+
+ Status
+;;
+;; All the tests should succeed (except for random failures); those
+;; flagged with ":expected-result :failed" are known
+;; limitations/bugs.  Tested with (2023-03-18):
+;;
+;; | emacs-version |  29.0.60 |
+;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
+;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
+;; | ghci  |9.0.2 |
+
+
+;;; Code:
+;;
+
+(require 'org-test "../testing/org-test")
+(org-test-for-executable "ghci")
+(unless (featurep 'haskell-mode)
+  (signal 'missing-test-dependency "haskell-mode"))
+
+
+;;; Helpers
+;;
+
+(defun test-ob-haskell-ghci--with-global-session-worker (todo)
+  "See `test-ob-haskell-ghci--with-global-session-worker'."
+  (

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

[General discussions about Org-mode.]

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/lisp/test-ob-haskell-ghci.el: New file.
> ---
>  testing/lisp/test-ob-haskell-ghci.el | 453 +++
>  1 file changed, 453 insertions(+)
>  create mode 100644 testing/lisp/test-ob-haskell-ghci.el
>
> diff --git a/testing/lisp/test-ob-haskell-ghci.el 
> b/testing/lisp/test-ob-haskell-ghci.el
> new file mode 100644
> index 0..aba94d73f
> --- /dev/null
> +++ b/testing/lisp/test-ob-haskell-ghci.el
> @@ -0,0 +1,453 @@
> +;;; test-ob-haskell-ghci.el --- tests for ob-haskell.el GHCi  -*- 
> lexical-binding: t; -*-
> +
> +;; Copyright (c) 2023  Free Software Foundation, Inc.

lisp/org.el has only a single space, so probably single space here as well.

> +
> +;; Authors: Bruno BARBIER 
> +
> +;; This program is free software; you can redistribute it and/or modify
> +;; it under the terms of the GNU General Public License as published by
> +;; the Free Software Foundation, either version 3 of the License, or
> +;; (at your option) any later version.

Do we need the text for "part of GNU Emacs"?

> +
> +;; This program is distributed in the hope that it will be useful,
> +;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +;; GNU General Public License for more details.
> +
> +;; You should have received a copy of the GNU General Public License
> +;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
> +
> +;;; Commentary:
> +;;
> +
> + Useful references
> +;;
> +;;  - https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html
> +;;  - GHCi manual: 
> https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html
> + FIXME: Random failures
> +;;
> +;; To increase the chances of failure when running tests, you can use this 
> command line:
> +;;
> +;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 
> 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty 
> & done) 2>&1 | grep FAILED
> +;;

Wanted to say something here, but then realized that you deleted this
portion in a later commit.

> +
> + Status
> +;;
> +;; All the tests should succeed (except for random failures); those
> +;; flagged with ":expected-result :failed" are known
> +;; limitations/bugs.  Tested with (2023-03-18):
> +;;
> +;; | emacs-version |  29.0.60 |
> +;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
> +;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
> +;; | ghci  |9.0.2 |
> +
> +
> +;;; Code:
> +;;
> +
> +(require 'org-test "../testing/org-test")
> +(org-test-for-executable "ghci")
> +(unless (featurep 'haskell-mode)
> +  (signal 'missing-test-dependency "haskell-mode"))
> +
> +
> +;;; Helpers
> +;;
> +
> +(defun test-ob-haskell-ghci--with-global-session-worker (todo)
> +  "See `test-ob-haskell-ghci--with-global-session-worker'."

This docstring doesn't say much and only refers to itself.  Maybe
explain what it does?  (Or now that I look at it, potentially you wanted
to refer to the macro `test-ob-haskell-ghci-with-global-session'
instead.)

> +(defun test-ob-haskell-ghci (args content  preamble unprotected)
> +  "Execute the code block CONTENT in a new GHCi session; return the result.
> +Add ARGS to the code block argument line.  Insert PREAMBLE
> +before the code block.  When UNPROTECTED is non-nil, don't control
> +which session is used (i.e. don't call
> +`test-ob-haskell-ghci--with-global-session-worker')."
> +  (when (listp content)
> +(setq content (string-join content "\n")))
> +  (unless preamble
> +(setq preamble ""))
> +  (let ((todo  (lambda ()

One space.

> + Data tables
> +;;
> +
> +(ert-deftest ob-haskell/int-table-data ()
> +  "From worg: int-table-data."
> +  (should (equal 10 (test-ob-haskell-ghci ":var t=int-table-data"
> +  "sum [sum r | r <- t]"
> +      "#+name: int-table-data
> +| 1 | 2 |
> +| 3 | 4 |"
> +
> +(ert-deftest ob-haskell/float-table-data ()
> +  "From worg: float-table-data."
> +  (should (equal 11.0 (test-ob-haskell-ghci ":var t=float-table-data"
> +  

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

[Bruno Barbier]

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
>>> consistent with other org babel backends.
>>
>> Errors are usually displayed separately, using
>> `org-babel-eval-error-notify'.
>
> I'll see what can be done with GHCi and use this if possible.

Unfortunately, no progress on this.  And I don't really have time to
work on this.



>>> +;; To increase the chances of failure when running tests, you can use this 
>>> command line:
>>> +;;
..
>>> +;; | ghci  |9.0.2 |
>>
>> You can probably remove this.
>
> Definitely. I'll do. Thanks.

Done.



>>> +  (when (and session-name (string= session-name "none"))
>>> +(setq session-name nil))
>>> +  (unless session-name
>>> +;; As haskell-mode is using the buffer name "*haskell*", we stay
>>> +;; away from it.
>>> +(setq session-name (generate-new-buffer-name "*ob-haskell*")))
>>
>> This will make ob-haskell spawn a separate ghci process buffer every
>> single time a user runs non-session src block. And the buffer is not
>> closed after getting the result.

> Very good point!
>
> I will update this to use the same buffer named "*ob-haskell*" when the
> user doesn't set the session name.  I guess it's consistent with other
> org-babel backends.

I've changed the way session works. 'ob-haskell' should now destroy
temporary sessions.  Thanks again for spotting that mistake.


Let me know if you see further improvement before pushing this.

Thanks,

Bruno


>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/lisp/test-ob-haskell-ghci.el: New file.
---
 testing/lisp/test-ob-haskell-ghci.el | 453 +++
 1 file changed, 453 insertions(+)
 create mode 100644 testing/lisp/test-ob-haskell-ghci.el

diff --git a/testing/lisp/test-ob-haskell-ghci.el b/testing/lisp/test-ob-haskell-ghci.el
new file mode 100644
index 0..aba94d73f
--- /dev/null
+++ b/testing/lisp/test-ob-haskell-ghci.el
@@ -0,0 +1,453 @@
+;;; test-ob-haskell-ghci.el --- tests for ob-haskell.el GHCi  -*- lexical-binding: t; -*-
+
+;; Copyright (c) 2023  Free Software Foundation, Inc.
+
+;; Authors: Bruno BARBIER 
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+;;
+
+ Useful references
+;;
+;;  - https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html
+;;  - GHCi manual: https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html
+ FIXME: Random failures
+;;
+;; To increase the chances of failure when running tests, you can use this command line:
+;;
+;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty & done) 2>&1 | grep FAILED
+;;
+
+ Status
+;;
+;; All the tests should succeed (except for random failures); those
+;; flagged with ":expected-result :failed" are known
+;; limitations/bugs.  Tested with (2023-03-18):
+;;
+;; | emacs-version |  29.0.60 |
+;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
+;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
+;; | ghci  |9.0.2 |
+
+
+;;; Code:
+;;
+
+(require 'org-test "../testing/org-test")
+(org-test-for-executable "ghci")
+(unless (featurep 'haskell-mode)
+  (signal 'missing-test-dependency "haskell-mode"))
+
+
+;;; Helpers
+;;
+
+(defun test-ob-haskell-ghci--with-global-session-worker (todo)
+  "See `test-ob-haskell-ghci--with-global-session-worker'."
+  (when (get-buffer "*haskell*")
+(error "A buffer named '*haskell*' exists.  Can't safely test haskell blocks"))
+  (unwind-protect (funcall todo)
+;; Kill the "*haskell*" buffer to not pollute other tests.
+(when-l

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

[Ihor Radchenko]

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' to make sure the output of this one
> contains only the last value. If I display "it" in the first block, I
> will not be able to differentiate between some output, previous values
> and the last value. And, printing "org-babel-haskell-eoe" updates the
> "it" variable (the last value becoming "()"), so I have to store the
> real "it" somewhere.

I see. I missed that `it' gets updated because of eoe indicator.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Bruno Barbier]

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 displayed separately, using
> `org-babel-eval-error-notify'.

I'll see what can be done with GHCi and use this if possible.
Thanks.


>> +;; To increase the chances of failure when running tests, you can use this 
>> command line:
>> +;;
>> +;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 
>> 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty 
>> & done) 2>&1 | grep FAILED
>> +;;
>> +
>> + Status
>> +;;
>> +;; All the tests should succeed (except for random failures); those
>> +;; flagged with ":expected-result :failed" are known
>> +;; limitations/bugs.  Tested with (2023-03-18):
>> +;;
>> +;; | emacs-version |  29.0.60 |
>> +;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
>> +;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
>> +;; | ghci  |9.0.2 |
>
> You can probably remove this.

Definitely. I'll do. Thanks.



>> +(`value (org-babel-comint-with-output
>> +(session org-babel-haskell-eoe nil full-body)
>> +  (insert "__LAST_VALUE_IMPROBABLE_NAME__=()::()\n")
>> +  (comint-send-input nil t)
>> +  (insert full-body)
>> +  (comint-send-input nil t)
>> +  (insert "__LAST_VALUE_IMPROBABLE_NAME__=it\n")
>> +  (comint-send-input nil t)
>> +  (insert (concat "putStrLn (\"\\\"\" ++ " 
>> org-babel-haskell-eoe " ++ \"\\\"\")\n"))
>
> 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' to make sure the output of this one
contains only the last value. If I display "it" in the first block, I
will not be able to differentiate between some output, previous values
and the last value. And, printing "org-babel-haskell-eoe" updates the
"it" variable (the last value becoming "()"), so I have to store the
real "it" somewhere.

Am I missing something ?

>> +  (when (and session-name (string= session-name "none"))
>> +(setq session-name nil))
>> +  (unless session-name
>> +;; As haskell-mode is using the buffer name "*haskell*", we stay
>> +;; away from it.
>> +(setq session-name (generate-new-buffer-name "*ob-haskell*")))
>
> This will make ob-haskell spawn a separate ghci process buffer every
> single time a user runs non-session src block. And the buffer is not
> closed after getting the result.

Very good point!

I will update this to use the same buffer named "*ob-haskell*" when the
user doesn't set the session name.  I guess it's consistent with other
org-babel backends.



Thank you very much for the review and you help!

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>

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

[Ihor Radchenko]

Bruno Barbier  writes:

> About :results output vs :results value, I decided to use the "it"
> variable, i.e. to ask GHCi what was the last value (see [1]).
>
> About sessions, I decided to rename the buffer as you suggested. That's
> a partial workaround that should 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 what we should expect to be
> consistent with other org babel backends.

Errors are usually displayed separately, using
`org-babel-eval-error-notify'.

> +;; To increase the chances of failure when running tests, you can use this 
> command line:
> +;;
> +;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 
> 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty 
> & done) 2>&1 | grep FAILED
> +;;
> +
> + Status
> +;;
> +;; All the tests should succeed (except for random failures); those
> +;; flagged with ":expected-result :failed" are known
> +;; limitations/bugs.  Tested with (2023-03-18):
> +;;
> +;; | emacs-version |  29.0.60 |
> +;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
> +;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
> +;; | ghci  |9.0.2 |

You can probably remove this.

> +(`value (org-babel-comint-with-output
> + (session org-babel-haskell-eoe nil full-body)
> +  (insert "__LAST_VALUE_IMPROBABLE_NAME__=()::()\n")
> +  (comint-send-input nil t)
> +  (insert full-body)
> +  (comint-send-input nil t)
> +  (insert "__LAST_VALUE_IMPROBABLE_NAME__=it\n")
> +  (comint-send-input nil t)
> +  (insert (concat "putStrLn (\"\\\"\" ++ " 
> org-babel-haskell-eoe " ++ \"\\\"\")\n"))

Why not simply putStrLn ("\"" ++ show it ++ "\"") ?

> +  (when (and session-name (string= session-name "none"))
> +(setq session-name nil))
> +  (unless session-name
> +;; As haskell-mode is using the buffer name "*haskell*", we stay
> +;; away from it.
> +(setq session-name (generate-new-buffer-name "*ob-haskell*")))

This will make ob-haskell spawn a separate ghci process buffer every
single time a user runs non-session src block. And the buffer is not
closed after getting the result.

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

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

[ParetoOptimalDev]

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, do whatever is less work and more normalized here.

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

[Bruno Barbier]

Ihor Radchenko  writes:

> I investigated further and now applied a set of patches that improves
> prompt filtering in org-comint.
> ..

Thanks Ihor.

I don't get random failures anymore.  And thanks for fixing the tests
that were incorrect.

Thanks Pareto for mentioning the possibiliy to customize GHCi prompts.



> The remaining tests fall into two categories:
> 1. Tests trying to test :results value vs. :results output in sessions.
> 2. Tests trying to test for multiple sessions not interfering each
>other.

About :results output vs :results value, I decided to use the "it"
variable, i.e. to ask GHCi what was the last value (see [1]).

About sessions, I decided to rename the buffer as you suggested. That's
a partial workaround that should work well enough, until haskell-mode
provides a way to choose the buffer name.

I've updated the tests 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.org/ghc/latest/docs/users_guide/ghci.html#the-it-variable

>From 46e8fa78574908a15fe6eb82a2cca5d2f537c78e 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

testing/lisp/test-ob-haskell-ghci.el: New file.
---
 testing/lisp/test-ob-haskell-ghci.el | 453 +++
 1 file changed, 453 insertions(+)
 create mode 100644 testing/lisp/test-ob-haskell-ghci.el

diff --git a/testing/lisp/test-ob-haskell-ghci.el b/testing/lisp/test-ob-haskell-ghci.el
new file mode 100644
index 0..aba94d73f
--- /dev/null
+++ b/testing/lisp/test-ob-haskell-ghci.el
@@ -0,0 +1,453 @@
+;;; test-ob-haskell-ghci.el --- tests for ob-haskell.el GHCi  -*- lexical-binding: t; -*-
+
+;; Copyright (c) 2023  Free Software Foundation, Inc.
+
+;; Authors: Bruno BARBIER 
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+;;
+
+ Useful references
+;;
+;;  - https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html
+;;  - GHCi manual: https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html
+ FIXME: Random failures
+;;
+;; To increase the chances of failure when running tests, you can use this command line:
+;;
+;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty & done) 2>&1 | grep FAILED
+;;
+
+ Status
+;;
+;; All the tests should succeed (except for random failures); those
+;; flagged with ":expected-result :failed" are known
+;; limitations/bugs.  Tested with (2023-03-18):
+;;
+;; | emacs-version |  29.0.60 |
+;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
+;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
+;; | ghci  |9.0.2 |
+
+
+;;; Code:
+;;
+
+(require 'org-test "../testing/org-test")
+(org-test-for-executable "ghci")
+(unless (featurep 'haskell-mode)
+  (signal 'missing-test-dependency "haskell-mode"))
+
+
+;;; Helpers
+;;
+
+(defun test-ob-haskell-ghci--with-global-session-worker (todo)
+  "See `test-ob-haskell-ghci--with-global-session-worker'."
+  (when (get-buffer "*haskell*")
+(error "A buffer named '*haskell*' exists.  Can't safely test haskell blocks"))
+  (unwind-protect (funcall todo)
+;; Kill the "*haskell*" buffer to not pollute other tests.
+(when-let ((hb (get-buffer "*haskell*")))
+  (with-current-buffer hb
+    (let ((kill-buffer-query-functions nil)
+  (kill-buffer-hook nil))
+  (kill-buffer hb))
+
+(defmacro test-ob-haskell-ghci-with-global-session ( body)
+  "Eval BODY in a new session, then destroy the session.
+The library ob-haskell doesn't implement session yet.  It will
+always use a buffer named \"*haskell*\".  We kill that buffer
+after the source block execution.  To be safe, we fail if such a
+buffer already exists."
+  `(test-ob-haskell-ghci--with-global-session-worker (lambda () ,@body)))
+
+(defun test-ob-haskell-ghci (args content  pream

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

[Ihor Radchenko]

Ihor Radchenko  writes:

> We can try the attached patch. Yet another edge case in comint, it
> appears.

I investigated further and now applied a set of patches that improves
prompt filtering in org-comint.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a8a516ba330fe8c435334030ffbe371b8c80c877
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=866ed1a3c5c37cad243085f9a8fa904970e4d614

Further, I tried to incorporate Pareto's suggestion about secondary
prompt and cleaned up the original GHCi tests.

With the attached set of patches (first one is Bruno's original patch),
I get all the tests reliably passing, except the tests left as
:expected-result failed.

The remaining tests fall into two categories:
1. Tests trying to test :results value vs. :results output in sessions.
2. Tests trying to test for multiple sessions not interfering each
   other.

The first category of tests fails because `org-babel-interpret-haskell'
simply cannot distinguish between :results value and :results output.
Someone familiar with GHC should handle this problem. For example, by
wrapping :results output code in such a way that output is discarded in
the GHCi comint buffer.

The second category of tests fails because haskell-mode uses a fixed
"*haskell*" comint buffer name. As I suggested in another message, a
viable approach could be renaming the original "*haskell*" buffer to
something else in `org-babel-haskell-initiate-session'. Again, someone
more familiar with haskell-mode should judge if such option is truly
viable.

>From 1273b5b415fa420e718645452bc75bc7a9407af5 Mon Sep 17 00:00:00 2001
Message-Id: <1273b5b415fa420e718645452bc75bc7a9407af5.1679653723.git.yanta...@posteo.net>
From: Bruno BARBIER 
Date: Fri, 18 Nov 2022 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/testing/lisp/test-ob-haskell-ghci.el b/testing/lisp/test-ob-haskell-ghci.el
new file mode 100644
index 0..4b1e4669b
--- /dev/null
+++ b/testing/lisp/test-ob-haskell-ghci.el
@@ -0,0 +1,428 @@
+;;; test-ob-haskell-ghci.el --- tests for ob-haskell.el GHCi  -*- lexical-binding: t; -*-
+
+;; Copyright (c) 2023  Free Software Foundation, Inc.
+
+;; Authors: Bruno BARBIER 
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+;;
+
+ Useful references
+;;
+;;  - https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html
+
+ FIXME: Random failures
+;;
+;; To increase the chances of failure when running tests, you can use this command line:
+;;
+;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty & done) 2>&1 | grep FAILED
+;;
+
+ Status
+;;
+;; All the tests should succeed (except for random failures); those
+;; flagged with ":expected-result :failed" are known
+;; limitations/bugs.  Tested with (2023-03-18):
+;;
+;; | emacs-version |  29.0.60 |
+;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
+;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
+;; | ghci  |9.0.2 |
+
+
+;;; Code:
+;;
+
+(require 'org-test "../testing/org-test")
+(org-test-for-executable "ghci")
+(unless (featurep 'haskell-mode)
+  (signal 'missing-test-dependency "haskell-mode"))
+
+
+;;; Helpers
+;;
+
+(defun test-ob-haskell-ghci--with-global-session-worker (todo)
+  "See `test-ob-haskell-ghci--with-global-session-worker'."
+  (when (get-buffer "*haskell*")
+(error "A buffer named '*haskell*' exists.  Can't safely test haskell blocks"))
+  (unwind-protect (funcall todo)
+;; Kill the "*haskell*" buffer to not pollute other tests.
+(when-let ((hb (get-buffer "*haskell*")))
+  (with-current-buffer hb
+    (let ((kill-buffer-query-functions nil)
+  (kill-buffer-hook nil))
+  (kill-buffer hb))
+
+(defmacro test-ob-haskell-ghci-with-global-session ( body)
+  "Eval BODY in a new session, then destroy the session.
+The library 

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

[Ihor Radchenko]

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 use similar approach in ob-shell.

Note that setting the prompt to non-"", makes little sense - we want to
remove it anyway. Why do extra work?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[ParetoOptimalDev]

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| ghci| ghci| ghci| 6
>>
>> Note "|".
>
> You can fix this by sending `set :prompt-cont ""`. Here is a
> demonstration:
>
> GHCi, version 9.0.2: https://www.haskell.org/ghc/  :? for help
> ghci> ghci> :set prompt-cont ""
> ghci> :{
> let { x = 2
> ; y = 3
> }
> in x*y
> :}
> 6
> ghci> 

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

[ParetoOptimalDev]

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:

GHCi, version 9.0.2: https://www.haskell.org/ghc/  :? for help
ghci> ghci> :set prompt-cont ""
ghci> :{
let { x = 2
; y = 3
}
in x*y
:}
6
ghci> 

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

[Ihor Radchenko]

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
> + }
> + in x*y
> +:}
> +"

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

We may want to either report this upstream or modify
`org-babel-interpret-haskell' further where it extends
`comint-prompt-regexp'.

> +(ert-deftest ob-haskell/ghci-info ()
> +  "The ghci meta command ':info' ."
> +  (should (equal "repeat :: a -> [a]-- Defined in ‘GHC.List’"
> + (test-ob-haskell-ghci ":results output" ":info repeat"

On my system, the output contains different number of spaces in
"[a]-- ". It appears to be system-dependent. Looks like test's
fault.

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

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

[Ihor Radchenko]

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 is always new.  From what I understand,
> this is an input buffering problem: inputs are not full lines.

I see.

We can try the attached patch. Yet another edge case in comint, it
appears.

>From 2bdcec1e1f9a3ce0314d182a4c50887e8ec80a17 Mon Sep 17 00:00:00 2001
Message-Id: <2bdcec1e1f9a3ce0314d182a4c50887e8ec80a17.1679480064.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 22 Mar 2023 11:12:30 +0100
Subject: [PATCH] org-babel-comint-with-output: Handle agglomerated prompts
 better

* lisp/ob-comint.el (org-babel-comint-with-output): Consider that
comint can sometimes agglomerate multiple prompts together even within
a single output increment as passed to
`comint-output-filter-functions'.

Example in GHC comint buffer:

GHCi, version 9.0.2: https://www.haskell.org/ghc/  :? for help
ghci> ghci> :{
main :: IO ()
main = putStrLn "Hello World!"
:}

main
"org-babel-haskell-eoe"
ghci| ghci| ghci| ghci> ghci> Hello World!
ghci> "org-babel-haskell-eoe"
ghci>
---
 lisp/ob-comint.el | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-comint.el b/lisp/ob-comint.el
index 54bf5127e..e167d911b 100644
--- a/lisp/ob-comint.el
+++ b/lisp/ob-comint.el
@@ -91,7 +91,16 @@ (defmacro org-babel-comint-with-output (meta  body)
   ;; trailing newline.  Use more reliable
   ;; match to split the output later.
   (replace-regexp-in-string
-   comint-prompt-regexp
+   ;; Sometimes, we get multiple agglomerated
+   ;; prompts together in a single output:
+   ;; "prompt prompt prompt output"
+   ;; Remove them progressively, so that
+   ;; possible "^" in the prompt regexp gets to
+   ;; work as we remove the heading prompt
+   ;; instance.
+   (if (string-prefix-p "^" comint-prompt-regexp)
+   (format "^\\(%s\\)+" (substring comint-prompt-regexp 1))
+ comint-prompt-regexp)
,org-babel-comint-prompt-separator
text
 		 comint-output-filter-functions))
-- 
2.39.1


>> 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-session', which ignores session
>> parameter completely).
>
> From what I understood, the buffer "*haskell*" is coming from
> haskell-mode. And, to make it work might require some changes there too.

>From my reading of haskell-mode, it seems to be safe if we simply rename
Haskell process buffer upon session initialization.

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

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

[Ihor Radchenko]

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 maybe me using
different GHC version.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[General discussions about Org-mode.]

Oh, great to hear it's fixed!

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

[Bruno Barbier]

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 buffering problem: inputs are not full lines.

> 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-session', which ignores session
> parameter completely).

>From what I understood, the buffer "*haskell*" is coming from
haskell-mode. And, to make it work might require some changes there too.

Thanks for having a look,
Let me know,


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>

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

[Ihor Radchenko]

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-session', which ignores session
> parameter completely).

Lawrence, may you please take a look at this thread?

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

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

[Ihor Radchenko]

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 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-session', which ignores session
parameter completely).

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

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

[Bruno Barbier]

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 with:

:expected-result :failed


All the tests will randomly fail; that is an ob-haskell bug (see
the command 'test-ob-haskell-ghci.el' to make them fail).


Some tests might be questionable, revealing more design choices and/or
backend capabilities than the expected behavior.


Solving the random failure bug should be a priority, in my opinion, as
it makes the testing process unreliable.  Adding support for sessions
would also be a good thing, so that one test doesn't contaminate others.


FTR, here are the tools that I have used:

| emacs-version |  29.0.60 |
| org-version   | main@4cad6c8ea (Mar 16 2023) |
| haskell-mode  | master@20d4e23 (Mar 4  2023) |
| ghci  |9.0.2 |



Bruno

>From c085fac2fcb429f7e643df8e4fff3a4ae1665d07 Mon Sep 17 00:00:00 2001
From: Bruno BARBIER 
Date: Fri, 18 Nov 2022 20:14:20 +0100
Subject: [PATCH] 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/testing/lisp/test-ob-haskell-ghci.el b/testing/lisp/test-ob-haskell-ghci.el
new file mode 100644
index 0..4b1e4669b
--- /dev/null
+++ b/testing/lisp/test-ob-haskell-ghci.el
@@ -0,0 +1,428 @@
+;;; test-ob-haskell-ghci.el --- tests for ob-haskell.el GHCi  -*- lexical-binding: t; -*-
+
+;; Copyright (c) 2023  Free Software Foundation, Inc.
+
+;; Authors: Bruno BARBIER 
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+;;
+
+ Useful references
+;;
+;;  - https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html
+
+ FIXME: Random failures
+;;
+;; To increase the chances of failure when running tests, you can use this command line:
+;;
+;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty & done) 2>&1 | grep FAILED
+;;
+
+ Status
+;;
+;; All the tests should succeed (except for random failures); those
+;; flagged with ":expected-result :failed" are known
+;; limitations/bugs.  Tested with (2023-03-18):
+;;
+;; | emacs-version |  29.0.60 |
+;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
+;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
+;; | ghci  |9.0.2 |
+
+
+;;; Code:
+;;
+
+(require 'org-test "../testing/org-test")
+(org-test-for-executable "ghci")
+(unless (featurep 'haskell-mode)
+  (signal 'missing-test-dependency "haskell-mode"))
+
+
+;;; Helpers
+;;
+
+(defun test-ob-haskell-ghci--with-global-session-worker (todo)
+  "See `test-ob-haskell-ghci--with-global-session-worker'."
+  (when (get-buffer "*haskell*")
+(error "A buffer named '*haskell*' exists.  Can't safely test haskell blocks"))
+  (unwind-protect (funcall todo)
+;; Kill the "*haskell*" buffer to not pollute other tests.
+(when-let ((hb (get-buffer "*haskell*")))
+  (with-current-buffer hb
+(let ((kill-buffer-query-functions nil)
+  (kill-buffer-hook nil))
+  (kill-buffer hb))
+
+(defmacro test-ob-haskell-ghci-with-global-session ( body)
+  "Eval BODY in a new session, then destroy the session.
+The library ob-haskell doesn't implement session yet.  It will
+always use a buffer named \"*haskell*\".  We kill that buffer
+after the source block execution.  To be safe, we fail if such a
+buffer already exists."
+  `(test-ob-haskell-ghci--with-global-session-worker (lambda () ,@body)))
+
+(defun test-ob-haskell-ghci (args content  preamble unprotected)
+  "Execute the code block CONTENT in a new GHCi session; return the result.
+Add ARGS to the code block argument line.  Insert PREAMBLE
+before the code block.  When UNPROTECTED is non-nil, don't control
+which session is used (i.e. don't call
+`test-ob-ha

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

[Ihor Radchenko]

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 it would not print the table out because it isn't parsed 
> correctly.

The table is parsed and printed correctly on the latest main.
I use GHC 9.0.2-r3.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[General discussions about Org-mode.]

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 variable.
The elisp VAR is converted to a string of haskell source code
specifying a variable of the same value."
  (if (listp var)
  (concat "(" (mapconcat #'org-babel-haskell-var-to-haskell var ", ") ")")
(format "%S" var)))

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 it would not print the table out because it isn't parsed 
correctly.

Re: ob-haskell

[Leo]

Lawrence Bottorff  writes:

> Enclosing code in :{ ... :} is fairly good -- again you can type this in at
> the REPL prompt and see how it works -- however, there are gotchas.
>

I don't think I understand what the problem is with :{ ... :}. Doing
this manually has worked pretty well for me.

>
> What would be nice is if a C-c C-c inside a block could somehow act as
> though the ghci were being sent a regular  *.hs buffer in haskell-mode --
> and that, of course, cumulatively. C-' creates a decent haskell-mode
> environment, BTW, so some form of a babel block to haskell-mode connection
> does exist
>

This makes a lot of sense in many cases. One case that I think it might
be suboptimal in is when I have a heavy computation that generates
some data. Then I would want to try to do a bunch of things to that data
which means that reloading everything would 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 block
that just sends the code to the repl. There are some problems here that
needs to be sorted out though. For example should each block of the
former type be loaded in its own module or should all of the code blocks
be loaded in the same module? 


/A sporadic user of ob-haskell

Re: ob-haskell

[Ken Mankoff]

Hi Lawrence,

This isn't a method for official language support, but I've had success with 
entirely unsupported REPLs and ob-screen. A .screenrc can launch the REPL, and 
then Org ob-screen just sends each line to the buffer. It works OK for me.

  -k.

On 2021-01-02 at 13:44 -08, Lawrence 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 -- tautological,
> but true. And that means when ob-haskell does nothing but dump the
> contents of a babel code block into ghci, it's no better than if the
> user had typed in into the REPL line-by-line. A quick run-down:
>
> :set +m supposedly alerts ghci that a multi-line expression is coming, will
> come; but typically, it doesn't infer this very well.
>
> Enclosing code in :{ ... :} is fairly good -- again you can type this in at
> the REPL prompt and see how it works -- however, there are gotchas.
>
> a plain block:
>
> #+begin_src haskell
> ...code...
> #+end_src
>
> is okay when you only have a one-liner to evaluate. But again, ob-haskell
> seems to do nothing but take the block contents and dump it to the ghci
> REPL as though the user had typed it in line-by-line, Enter, Enter...
>
> What would be nice is if a C-c C-c inside a block could somehow act as
> though the ghci were being sent a regular  *.hs buffer in haskell-mode --
> and that, of course, cumulatively. C-' creates a decent haskell-mode
> environment, BTW, so some form of a babel block to haskell-mode connection
> does exist
>
> So am I on the right track? It's obvious at this point raw dumps into the
> REPL aren't optimal, i.e., are fraught. What is, e.g., geiser doing
> that ob-haskell isn't?
>
> LB
>
> PS: Eventually, I'll try to glean some hints from the Jupyter Haskell
> <https://github.com/gibiansky/IHaskell> effort.
>
> PPS: GHCI User's Guide
> <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html>
> doesn't
> really tell me anything other than yes, ob-haskell is raw-dumping into an
> environment that isn't designed to play nice with babel.

ob-haskell

[Lawrence Bottorff]

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.
And that means when ob-haskell does nothing but dump the contents of a
babel code block into ghci, it's no better than if the user had typed in
into the REPL line-by-line. A quick run-down:

:set +m supposedly alerts ghci that a multi-line expression is coming, will
come; but typically, it doesn't infer this very well.

Enclosing code in :{ ... :} is fairly good -- again you can type this in at
the REPL prompt and see how it works -- however, there are gotchas.

a plain block:

#+begin_src haskell
...code...
#+end_src

is okay when you only have a one-liner to evaluate. But again, ob-haskell
seems to do nothing but take the block contents and dump it to the ghci
REPL as though the user had typed it in line-by-line, Enter, Enter...

What would be nice is if a C-c C-c inside a block could somehow act as
though the ghci were being sent a regular  *.hs buffer in haskell-mode --
and that, of course, cumulatively. C-' creates a decent haskell-mode
environment, BTW, so some form of a babel block to haskell-mode connection
does exist

So am I on the right track? It's obvious at this point raw dumps into the
REPL aren't optimal, i.e., are fraught. What is, e.g., geiser doing
that ob-haskell isn't?

LB

PS: Eventually, I'll try to glean some hints from the Jupyter Haskell
<https://github.com/gibiansky/IHaskell> effort.

PPS: GHCI User's Guide
<https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html>
doesn't
really tell me anything other than yes, ob-haskell is raw-dumping into an
environment that isn't designed to play nice with babel.

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

[Kyle Meyer]

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 blocks flagged to compile will compile in a temp file, and
> those flagged otherwise will be run interactively. This is the
> intended behaviour.
>
> Patch attached.

Thanks for the patch.

> Subject: [PATCH] ob-haskell.el: Update deprecated functions
>
> * lisp/ob-haskell.el: Update to haskell-interactive-mode from inf-haskell-mode
>
> Deprecated commands from inf-haskell mode would send source blocks
> flagged to compile to the interpreter instead of compiling in a temp
> file.
>
> TINYCHANGE

I admit that I don't really have a good understanding of the situation
but...

> ---
>  lisp/ob-haskell.el | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
> index 84e2d6c42..01d658615 100644
> --- a/lisp/ob-haskell.el
> +++ b/lisp/ob-haskell.el
> @@ -43,9 +43,9 @@
>  (require 'comint)
>  
>  (declare-function haskell-mode "ext:haskell-mode" ())
> -(declare-function run-haskell "ext:inf-haskell" ( arg))
> +(declare-function run-haskell "ext:haskell-interactive-mode" ( arg))
>  (declare-function inferior-haskell-load-file
> -   "ext:inf-haskell" ( reload))
> +   "ext:haskell-process-load-file" ( reload))
>  (declare-function org-entry-get "org" (pom property  inherit 
> literal-nil))

... I'm confused that the patch consists solely of modifying
declare-function calls.  While that can appease the Emacs byte-compiler,
I'm not seeing how it could relate to the problem you describe.

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

[Seth Lee]

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 deprecated `inf-haskell-mode` to `haskell-interactive-mode` solves the 
issue for me.

Source blocks flagged to compile will compile in a temp file, and those flagged 
otherwise will be run interactively. This is the intended behaviour.

Patch attached.

0001-ob-haskell.el-Update-deprecated-functions.patch
Description: Binary data

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

[Nick Daly]

Hi Kyle, thank you again for your help and analysis.  In summary,
org-mode needs no patches, but inf-haskell's comint-prompt-regexp
needs updates.  I'll follow up with the inf-haskell maintainers.



> inf-haskell used to set comint-prompt-regexp in the body of
> inferior-haskell-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-haskell regex to handle "Prelude| " correctly in the
first place.

I believe it's possible to compress the current inf-haskell regexp
from this:

(setq-local comint-prompt-regexp
;; Why the backslash in [\\._[:alnum:]]?
"^\\*?[[:upper:]][\\._[:alnum:]]*\\(?:
\\*?[[:upper:]][\\._[:alnum:]]*\\)*\\( λ\\)?> \\|^λ?> $")

Down into this, without any significant loss of fidelity.  We really
don't care about any characters at the start of the line before the
final "> ".

(setq-local comint-prompt-regexp "^[[:alnum:].*_() |λ]*> ")

This seems useful because, as I discovered this morning, importing
modules mangles the prompt further:

Prelude> import Data.Time
Prelude Data.Time> :m + Data.Time.Clock
Prelude Data.Time Data.Time.Clock>

The testing data that this configuration correctly parsed is attached
for reference.

I'll figure out where to submit that patch to, and send it off.  It's
a single line change that shouldn't require any assignment papers.

Thanks again,
Nick
Prelude> import Data.Time
Prelude Data.Time> :m + Data.Time.Clock
Prelude Data.Time Data.Time.Clock> scanl (+) 0 [1,2,3,4]
"org-babel-haskell-eoe"
[0,1,3,6,10]
Prelude Data.Time Data.Time.Clock> "org-babel-haskell-eoe"
Prelude Data.Time Data.Time.Clock> :{
flip' :: (a -> b -> c) -> (b -> a -> c)
flip' f = \x y -> f y x
:}
"org-babel-haskell-eoe"
Prelude Data.Time Data.Time.Clock| Prelude Data.Time Data.Time.Clock| Prelude 
Data.Time Data.Time.Clock| Prelude Data.Time Data.Time.Clock> 
"org-babel-haskell-eoe"
Prelude Data.Time Data.Time.Clock> :{
sum' :: (Num a) => [a] -> a
sum' xs = foldl (\ acc x -> acc + x) 0 xs
:}
sum' [1,2,3,4] == 10
"org-babel-haskell-eoe"
Prelude Data.Time Data.Time.Clock| Prelude Data.Time Data.Time.Clock| Prelude 
Data.Time Data.Time.Clock| Prelude Data.Time Data.Time.Clock> True
Prelude Data.Time Data.Time.Clock> "org-babel-haskell-eoe"
Prelude Data.Time Data.Time.Clock> :{
sum' :: (Num a) => [a] -> a
sum' xs = foldl (\ acc x -> acc + x) 0 xs
:}
print "hi"
"org-babel-haskell-eoe"
Prelude Data.Time Data.Time.Clock| Prelude Data.Time Data.Time.Clock| Prelude 
Data.Time Data.Time.Clock| Prelude Data.Time Data.Time.Clock> "hi"
Prelude Data.Time Data.Time.Clock> "org-babel-haskell-eoe"
Prelude Data.Time Data.Time.Clock>

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

[Kyle Meyer]

Nick Daly writes:

> 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 patch breaks one case that I'd forgotten about: the
> true one-liner, where the output displays before the "Prelude> "
> prompt even appears.
>
> #+BEGIN_SRC haskell
> [... several examples ... ]

Thanks for the nice examples.  It'd be great to eventually include at
least some of them as tests.

> diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
> index bea162528..6ac34f2f5 100644
> --- a/lisp/ob-haskell.el
> +++ b/lisp/ob-haskell.el
> @@ -56,15 +56,27 @@

For the next iteration, could you send a patch generated by
git-format-patch?  See <https://orgmode.org/worg/org-contribute.html>.

Please also consider signing copyright papers, but I suspect the
ob-haskell.el changes will end up being few enough lines that they can
be accepted as a TINYCHANGE.

>  (defvar org-babel-haskell-eoe "\"org-babel-haskell-eoe\"")
>  
> -(defvar haskell-prompt-regexp)
> +(defvar haskell-prompt-regexp "^\\(\\*?[[:upper:]][\\._[:alnum:]]*\\(?: 
> \\*?[[:upper:]][\\._[:alnum:]]*\\)*\\( λ\\)?[|>] \\)*"
> +  "Filter out prompts from Haskell interpreters:
> +
> +GHC:
> +
> +- 'output
> +   ^Prelude> EOE'
> +- '^Prelude> output EOE'
> +- '^Prelude| Prelude| Prelude> output EOE'
> +
> +Unknown Interpreter:
> +
> +- '^> '
> +- '^λ> '")

This is inf-haskell's variable.  ob-haskell shouldn't set it.  The
original (defvar haskell-prompt-regexp) just silenced the bytecompiler.
If ob-haskell needs to tweak comint-prompt-regexp to deal with the
"^Prelude| Prelude| Prelude" above, it should done without overwriting
an inf-haskell value.

As touched on in my other email, there's also the issue of compatibility
with versions of haskell mode before v17.1 that lack a
haskell-prompt-regexp.  I believe this is why you're seeing the
undefined errors.

So, I dunno.  I'm not a ob-haskell user or a really a Babel user.  But
in my view it'd be cleaner to just leave inferior-haskell-mode's
comint-prompt-regexp alone and strip the "Prelude| Prelude| ..."  once
the output comes out of org-babel-comint-with-output.  It's hacky and
error-prone, but I don't think it's so different than what
org-babel-comint-with-output already does.

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

[Kyle Meyer]

Nick Daly writes:

> After a bit of tinkering, I realized there are two things going on
> here, only one of which I fully understand:
>
> 1. My core functional issue is that =comint-prompt-regexp= isn't set
>up to handle the "Prelude| " entries or the repeated 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.

Here's what I can gather.  inf-haskell used to set comint-prompt-regexp
in the body of inferior-haskell-mode.  Here's an example from 11d6abf
(2017-08-24):

  (setq-local comint-prompt-regexp
;; Why the backslash in [\\._[:alnum:]]?
"^\\*?[[:upper:]][\\._[:alnum:]]*\\(?: 
\\*?[[:upper:]][\\._[:alnum:]]*\\)*\\( λ\\)?> \\|^λ?> $")

In ca94d81 (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 optional-lambda":

With a haskell-mode after the commit I point to above, it shouldn't be
undefined at the time we set comint-prompt-regexp because
org-babel-interpret-haskell loads inf-haskell before that.

However, I'm confused why Org's b46787743 (Fix ob-haskell.el to work
with custom ghci prompts, 2017-12-02) added the λ bit (author of that
patch cc'd).  As far as I can tell, that is a part of
inferior-haskell-mode's default comint-prompt-regexp and has been since
28997b2 (Add support for popular "λ> " prompt to inf-haskell,
2013-07-04).

You've sent an updated patch in a follow-up message, so I'll continue
there...

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

[Nick Daly]

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 patch breaks one case that I'd forgotten about: the
true one-liner, where the output displays before the "Prelude> "
prompt even appears.

#+BEGIN_SRC haskell
scanl (+) 0 [1,2,3,4]
#+END_SRC

#+BEGIN_EXAMPLE
Prelude> scanl (+) 0 [1,2,3,4]
"org-babel-haskell-eoe"
[0,1,3,6,10]
Prelude> "org-babel-haskell-eoe"
Prelude>
#+END_EXAMPLE

This latest patch updates the original (more complicated) regexp that
works with this out-of-order output.  This should display the expected
result in all known cases:

One liners:

#+BEGIN_SRC haskell
scanl (+) 0 [1,2,3,4]
#+END_SRC

#+RESULTS:
| 0 | 1 | 3 | 6 | 10 |

Silent multi-line blocks:

#+BEGIN_SRC haskell :results silent
:{
flip' :: (a -> b -> c) -> (b -> a -> c)
flip' f = \x y -> f y x
:}
#+END_SRC

Multi-line blocks with value results:

#+BEGIN_SRC haskell
:{
sum' :: (Num a) => [a] -> a
sum' xs = foldl (\ acc x -> acc + x) 0 xs
:}
sum' [1,2,3,4] == 10
#+END_SRC

#+RESULTS:
: True

Multi-line blocks with output results:

#+BEGIN_SRC haskell :results output
:{
sum' :: (Num a) => [a] -> a
sum' xs = foldl (\ acc x -> acc + x) 0 xs
:}
print "hi"
#+END_SRC

#+RESULTS:
:
: hi

Thanks again for your time,
Nick
diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
index bea162528..6ac34f2f5 100644
--- a/lisp/ob-haskell.el
+++ b/lisp/ob-haskell.el
@@ -56,15 +56,27 @@
 
 (defvar org-babel-haskell-eoe "\"org-babel-haskell-eoe\"")
 
-(defvar haskell-prompt-regexp)
+(defvar haskell-prompt-regexp "^\\(\\*?[[:upper:]][\\._[:alnum:]]*\\(?: \\*?[[:upper:]][\\._[:alnum:]]*\\)*\\( λ\\)?[|>] \\)*"
+  "Filter out prompts from Haskell interpreters:
+
+GHC:
+
+- 'output
+   ^Prelude> EOE'
+- '^Prelude> output EOE'
+- '^Prelude| Prelude| Prelude> output EOE'
+
+Unknown Interpreter:
+
+- '^> '
+- '^λ> '")
 
 (defun org-babel-execute:haskell (body params)
   "Execute a block of Haskell code."
   (require 'inf-haskell)
   (add-hook 'inferior-haskell-hook
 (lambda ()
-  (setq-local comint-prompt-regexp
-  (concat haskell-prompt-regexp "\\|^λ?> "
+  (setq-local comint-prompt-regexp haskell-prompt-regexp)))
   (let* ((session (cdr (assq :session params)))
  (result-type (cdr (assq :result-type params)))
  (full-body (org-babel-expand-body:generic

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

[Nick Daly]

Hi Kyle, thanks for the thoughtful analysis.

On Wed, May 20, 2020 at 12:51 AM Kyle Meyer  wrote:
> So it looks like the member call above is returning nil because the
> prompt markers are corrupting the element.  If that's the case, it seems
> like the output cleansing should happen upstream of that call.
>
> What do you think?

After a bit of tinkering, I realized there are two things going on
here, only one of which I fully understand:

1. My core functional issue is that =comint-prompt-regexp= isn't set
   up to handle the "Prelude| " entries or the repeated 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":

  (defvar haskell-prompt-regexp)

  (defun org-babel-execute:haskell (body params) ...
  (setq-local comint-prompt-regexp
(concat haskell-prompt-regexp "\\|^λ?> "

That causes an evaluation error that prevents the first source block
evaluation but, strangely, that also results in this mess in the
*haskell* buffer on subsequent evaluations:

: "^\\*?[[:upper:]][\\._[:alnum:]]*\\(?:
\\*?[[:upper:]][\\._[:alnum:]]*\\)*\\( λ\\)?> "

=comint-prompt-regexp='s variable documentation calls out much simpler
regexps that do basically the same thing as the one above and handles
the repeated "Prelude| " entries.  This one is based off the Canonical
Lisp example:

: "^[^>\n]+\\(> \\)?"

I've attached a patch against git master that results in fewer
undefined variable errors and depends less default-variable magic.
Now, =haskell-prompt-regexp= and =comint-prompt-regexp= are explicitly
set using defaults that can be M-x customized, and the default value
handles the repeated "Prelude| " entries without breaking the original
"λ> " prompt handling.

Thanks,
Nick
diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
index bea162528..893e4220c 100644
--- a/lisp/ob-haskell.el
+++ b/lisp/ob-haskell.el
@@ -56,15 +56,25 @@
 
 (defvar org-babel-haskell-eoe "\"org-babel-haskell-eoe\"")
 
-(defvar haskell-prompt-regexp)
+(defvar haskell-prompt-regexp "^[^>\n]*\\(> \\)?"
+  "Filter out prompts from Haskell interpreters:
+
+GHC:
+
+- '^Prelude> '
+- '^Prelude| Prelude| Prelude> '
+
+Unknown Interpreter:
+
+- '^> '
+- '^λ> '")
 
 (defun org-babel-execute:haskell (body params)
   "Execute a block of Haskell code."
   (require 'inf-haskell)
   (add-hook 'inferior-haskell-hook
 (lambda ()
-  (setq-local comint-prompt-regexp
-  (concat haskell-prompt-regexp "\\|^λ?> "
+  (setq-local comint-prompt-regexp haskell-prompt-regexp)))
   (let* ((session (cdr (assq :session params)))
  (result-type (cdr (assq :result-type params)))
  (full-body (org-babel-expand-body:generic

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

[Kyle Meyer]

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

Thanks for the patch.

> diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
> index bea162528..cb581fe3b 100644
> --- a/lisp/ob-haskell.el
> +++ b/lisp/ob-haskell.el
> @@ -83,12 +83,16 @@
> (cdr (member org-babel-haskell-eoe
> (reverse (mapcar #'org-trim raw)))
>  (org-babel-reassemble-table
> - (let ((result
> + (let* ((result
>  (pcase result-type
>(`output (mapconcat #'identity (reverse results) "\n"))
> -  (`value (car results)
> +  (`value (car results
> +(result
> + (if (stringp result)
> + (replace-regexp-in-string "Prelude[|>] " "" result)
> +   result)))

Oy, it's pretty nasty that those leak through.  I know ob-python (and
probably other languages) also suffers from similar brittleness.  It'd
be nice of course to figure out how to prevent the prompts leakage in
the first place, but, short of that, I think we should at least make the
regexp stricter so that it matches just the start of the string.

And that (stringp result) check is for the same reason as the one from
your first patch from yesterday which is now included ...

> (org-babel-result-cond (cdr (assq :result-params params))
> -  result (org-babel-script-escape result)))
> +  result (if (stringp result) (org-babel-script-escape result

... here.  I believe result is nil in the problematic case, so this
could be

(and result (org-babel-script-escape result))

However, based on stepping through the example in your patch from
yesterday, I think these two issues might be more closely related than
you realize.  In the

(cdr (member org-babel-haskell-eoe
 (reverse (mapcar #'org-trim raw

bit visible as a context line above, this is what I see for raw when I
step through org-babel-execute:haskell:

("Prelude| Prelude| Prelude| Prelude> \"org-babel-haskell-eoe\"" "")

So it looks like the member call above is returning nil because the
prompt markers are corrupting the element.  If that's the case, it seems
like the output cleansing should happen upstream of that call.

What do you think?

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

[Nick Daly]

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.

Thanks for your time,
Nick


Multi-line function declarations with output still work fine.

#+BEGIN_SRC haskell
  :{
  chain :: (Integral a) => a -> [a]
  chain 1 = [1]
  chain n
  | even n = n:chain (n `div` 2)
  | odd n  = n:chain (n*3 + 1)
  :}
  chain 10
#+END_SRC

#+RESULTS:
| 10 | 5 | 16 | 8 | 4 | 2 | 1 |


Silent declaration-only blocks correctly evaluate silently.

#+BEGIN_SRC haskell :results silent
  :{
  flip' :: (a -> b -> c) -> (b -> a -> c)
  flip' f = \x y -> f y x
  :}
#+END_SRC


Single-line function calls also return the expected results.

#+name: flip'-hello
#+BEGIN_SRC haskell
  flip' zip [1,2,3,4,5,6] "hello"
#+END_SRC

#+RESULTS: flip'-hello
| h | 1 |
| e | 2 |
| l | 3 |
| l | 4 |
| o | 5 |
diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
index bea162528..cb581fe3b 100644
--- a/lisp/ob-haskell.el
+++ b/lisp/ob-haskell.el
@@ -83,12 +83,16 @@
 			  (cdr (member org-babel-haskell-eoe
(reverse (mapcar #'org-trim raw)))
 (org-babel-reassemble-table
- (let ((result
+ (let* ((result
 (pcase result-type
   (`output (mapconcat #'identity (reverse results) "\n"))
-  (`value (car results)
+  (`value (car results
+(result
+ (if (stringp result)
+ (replace-regexp-in-string "Prelude[|>] " "" result)
+   result)))
(org-babel-result-cond (cdr (assq :result-params params))
-	 result (org-babel-script-escape result)))
+	 result (if (stringp result) (org-babel-script-escape result
  (org-babel-pick-name (cdr (assq :colname-names params))
 			  (cdr (assq :colname-names params)))
  (org-babel-pick-name (cdr (assq :rowname-names params))

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

[Nick Daly]

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.  This patch applies cleanly against the org-mode master.

#+name: chain-ecm
#+BEGIN_SRC haskell
  :{
  chain :: (Integral a) => a -> [a]
  chain 1 = [1]
  chain n
  | even n = n:chain (n `div` 2)
  | odd n  = n:chain (n*3 + 1)
  :}
  chain 10
#+END_SRC

Results without patch:
: Prelude| Prelude| Prelude| Prelude| Prelude| Prelude| Prelude>
[10,5,16,8,4,2,1]

Results with patch:
: | 10 | 5 | 16 | 8 | 4 | 2 | 1 |

Thank you for your time,
Nick
--- lisp/ob-haskell.el
+++ lisp/ob-haskell.el
@@ -84,9 +84,11 @@
(reverse (mapcar #'org-trim raw)))
 (org-babel-reassemble-table
  (let ((result
-(pcase result-type
-  (`output (mapconcat #'identity (reverse results) "\n"))
-  (`value (car results)
+	(replace-regexp-in-string
+	 "Prelude[|>] " ""
+ (pcase result-type
+   (`output (mapconcat #'identity (reverse results) "\n"))
+   (`value (car results))
(org-babel-result-cond (cdr (assq :result-params params))
 	 result (if (stringp result) (org-babel-script-escape result
  (org-babel-pick-name (cdr (assq :colname-names params))

Diff finished.  Sun May 17 14:26:21 2020

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

[numbch...@gmail.com]

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)
  locate-dominating-file(nil "cabal.sandbox.config")
  haskell-process-type()
  haskell-program-name-with-args()
  inferior-haskell-start-process()
  inferior-haskell-process()
  run-haskell()
  funcall-interactively(run-haskell)
  call-interactively(run-haskell record nil)
  command-execute(run-haskell record)
  #f(compiled-function (cmd) #)("run-haskell")
  ivy-call()
  ivy-read("M-x " [special-lispy-clone
  
  counsel-M-x()
  funcall-interactively(counsel-M-x)
  call-interactively(counsel-M-x nil nil)
  command-execute(counsel-M-x)

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Wed, Nov 15, 2017 at 11:35 PM, Nick Dokos  wrote:

> "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 `haskell-program-name` at all.
>
> You probably need to set haskell-process-type to ghci. If that works,
> please let me know and I'll update the answer on SO.
>
> >
> > [stardiviner] GPG key ID: 47C32433
> > IRC(freeenode): stardiviner Twitter:  @numbchild
> > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
> > Blog: http://stardiviner.github.io/
> >
> > On Wed, Nov 15, 2017 at 9:17 PM, numbch...@gmail.com <
> numbch...@gmail.com> wrote:
> >
> > 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
> > Blog: http://stardiviner.github.io/
> >
> > On Mon, Nov 13, 2017 at 11:43 PM, Nick Dokos 
> wrote:
> >
> > 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 entered--Lisp error: (file-missing "Cannot open load
> file" "No
> > > such file or directory" "inf-haskell")
> > >   require(inf-haskell)
> >
> > See my answer to this SO question:
> >
> >   https://stackoverflow.com/questions/42081379/how-to-set-
> up-org-babel-for-haskell-with-stack
> >
> > for some details on setting up the environment.
> >
> > --
> > Nick
> >
>
> --
> Nick
>
>
>

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

[Nick Dokos]

"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 `haskell-program-name` at all.

You probably need to set haskell-process-type to ghci. If that works, please 
let me know and I'll update the answer on SO.

>
> [stardiviner]     GPG key ID: 47C32433
> IRC(freeenode): stardiviner     Twitter:  @numbchild
> Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
> Blog: http://stardiviner.github.io/
>
> On Wed, Nov 15, 2017 at 9:17 PM, numbch...@gmail.com  
> wrote:
>
> 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
> Blog: http://stardiviner.github.io/
>
> On Mon, Nov 13, 2017 at 11:43 PM, Nick Dokos  wrote:
>
> 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 entered--Lisp error: (file-missing "Cannot open load file" 
> "No
> > such file or directory" "inf-haskell")
> >   require(inf-haskell)
>
> See my answer to this SO question:
>
>   
> https://stackoverflow.com/questions/42081379/how-to-set-up-org-babel-for-haskell-with-stack
>
> for some details on setting up the environment.
>
> --
> Nick
>

-- 
Nick

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

[numbch...@gmail.com]

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
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Wed, Nov 15, 2017 at 9:17 PM, numbch...@gmail.com 
wrote:

> 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
> Blog: http://stardiviner.github.io/
>
> On Mon, Nov 13, 2017 at 11:43 PM, Nick Dokos  wrote:
>
>> 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 entered--Lisp error: (file-missing "Cannot open load file" "No
>> > such file or directory" "inf-haskell")
>> >   require(inf-haskell)
>>
>> See my answer to this SO question:
>>
>>   https://stackoverflow.com/questions/42081379/how-to-set-up-
>> org-babel-for-haskell-with-stack
>>
>> for some details on setting up the environment.
>>
>> --
>> Nick
>>
>>
>>
>

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

[numbch...@gmail.com]

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
Blog: http://stardiviner.github.io/

On Mon, Nov 13, 2017 at 11:43 PM, Nick Dokos  wrote:

> 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 entered--Lisp error: (file-missing "Cannot open load file" "No
> > such file or directory" "inf-haskell")
> >   require(inf-haskell)
>
> See my answer to this SO question:
>
>   https://stackoverflow.com/questions/42081379/how-to-set-
> up-org-babel-for-haskell-with-stack
>
> for some details on setting up the environment.
>
> --
> Nick
>
>
>

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

[Nick Dokos]

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 entered--Lisp error: (file-missing "Cannot open load file" "No
> such file or directory" "inf-haskell")
>   require(inf-haskell)

See my answer to this SO question:

  
https://stackoverflow.com/questions/42081379/how-to-set-up-org-babel-for-haskell-with-stack

for some details on setting up the environment.

-- 
Nick

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

[stardiviner]

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 directory" "inf-haskell")
  require(inf-haskell)
  org-babel-haskell-initiate-session(nil ((:colname-names)
(:rowname-names) (:result-params "replace") (:result-type . value)
(:results . "replace") (:exports . "code") (:cache . "no") (:noweb .
"no") (:hlines . "no") (:padlines . "no") (:session) (:tangle .
"Data/Code/hello_world.hs")))
  org-babel-execute:haskell("main :: IO ()\nmain = do\n  putStrLn
\"Hello, World!\"" ((:colname-names) (:rowname-names) (:result-params
"replace") (:result-type . value) (:results . "replace") (:exports .
"code") (:cache . "no") (:noweb . "no") (:hlines . "no") (:padlines .
"no") (:session) (:tangle . "Data/Code/hello_world.hs")))
  org-babel-execute-src-block(nil ("haskell" "main :: IO ()\nmain =
do\n  putStrLn \"Hello, World!\"" ((:colname-names) (:rowname-names)
(:result-params "replace") (:result-type . value) (:results . "replace")
(:exports . "code") (:tangle . "Data/Code/hello_world.hs") (:session)
(:padlines . "no") (:hlines . "no") (:noweb . "no") (:cache . "no")) ""
nil 1127 "(ref:%s)"))
  org-ctrl-c-ctrl-c(nil)
  funcall-interactively(org-ctrl-c-ctrl-c nil)
  call-interactively(org-ctrl-c-ctrl-c nil nil)
  command-execute(org-ctrl-c-ctrl-c)
```   

[Orgmode] Re: Bugs in ob-haskell

[Eric Schulte]

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  should have been there, and I suspect a
 race condition, because after I immediately did C-c C-c again, the
 results changed to a table.


Yes, the very first execution in a new session can sometimes lead to
such problems as the session warms up.


 2. Looking at ob-haskell.el, it seems like Haskell strings are
 converted into text by removing leading and trailing double
 quotes. However, if there are double quote characters inside the
 string, they will be escaped with a backslash when printed, and they
 will presumably need to be unescaped. (Haven't tested this though.)


This problem (if there was one, it sounds as though you did not check)
is now fixed by a quoting fix applied to a number of languages including
Haskell.


 3. Ordinary Haskell lists can't have values of different types inside
 them, at least not without some sort of wrapper. But if you have a
 number and a string in your table, ob-haskell will try to make an
 impossible list with a number and a string in it. My preferred
 solution to this bug would be to force all list items to strings (at
 least, if there are any strings at all in the input table or list).


I would disagree that this is a bug.  True, Haskell does not allow lists
of mixed types, so then the user shouldn't pass in lists of mixed types,
and if they do, Haskell will spit out a warning.  I find this behavior
more clear and straightforward than the proposed behavior of having
Babel automatically fix your list by converting all elements to
strings.  The user can do that explicitly themselves using something
like the following (could be added to your LOB to make this process even
easier).

#+tblname: mixed-table
| 1 | first  |
| 2 | second |
| 3 | third  |
| 4 | fourth | 

#+source: rec-string-wrap
#+begin_src emacs-lisp :var data=mixed-table
  (defun rec-string-wrap (in)
(if (listp in) (mapcar #'rec-string-wrap in) (format %S in)))
  (rec-string-wrap data)
#+end_src

#+begin_src haskell :var tbl=rec-string-wrap(data=mixed-table)
  map head tbl
#+end_src

#+results:
| 1 | 2 | 3 | 4 |


 4. What's worse is, if ob-haskell makes an error in setting your input
 variables, like the error in the previous paragraph, and this is not
 the first run of that code block and you haven't changed the variable
 names, the error arising from the let command will simply be ignored
 silently by ob-haskell! The previous value of the variable will be
 used instead. At least, that is what happens to me.


This is an effect of how variables work in the interactive Haskell
session, previous values are not overwritten by erroneous assignment to
the same variable name.  Changing this behavior is beyond the scope of
the babel integration.  That said it would be great if the Haskell
integration allowed for executing code blocks using an external Haskell
process in stead of the interactive session, unfortunately this is
currently not implemented and would presumably require some simple
monadic wrapper to output results from the execution in a format which
could be captured and brought back into Emacs.

As always patches are welcome.

-- Eric

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Bugs in ob-haskell

[Robin Green]

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,
because after I immediately did C-c C-c again, the results changed to a table.

2. Looking at ob-haskell.el, it seems like Haskell strings are converted into 
text
by removing leading and trailing double quotes. However, if there are double 
quote
characters inside the string, they will be escaped with a backslash when 
printed,
and they will presumably need to be unescaped. (Haven't tested this though.)

3. Ordinary Haskell lists can't have values of different types inside them, at 
least
not without some sort of wrapper. But if you have a number and a string in your
table, ob-haskell will try to make an impossible list with a number and a 
string in
it. My preferred solution to this bug would be to force all list items to 
strings
(at least, if there are any strings at all in the input table or list).

4. What's worse is, if ob-haskell makes an error in setting your input 
variables,
like the error in the previous paragraph, and this is not the first run of that
code block and you haven't changed the variable names, the error arising from 
the
let command will simply be ignored silently by ob-haskell! The previous value
of the variable will be used instead. At least, that is what happens to me.

Regards,
-- 
Robin Green

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode