emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* ocaml babel no longer works?
@ 2013-02-08 14:23 Alan Schmitt
  2013-02-09 12:06 ` Alan Schmitt
  0 siblings, 1 reply; 12+ messages in thread
From: Alan Schmitt @ 2013-02-08 14:23 UTC (permalink / raw)
  To: emacs-orgmode

Hello,

I recently updated org-mode (from git), and ocaml source code is no
longer recognized. If I have a very simple file, like this:

#+BEGIN_SRC ocaml
let x = 2 in x
#+END_SRC

I don't get syntax highlighting, and trying to evaluate it result in an
error:

Evaluate this ocaml code block on your system? (y or n)  y
executing Ocaml code block...
face-spec-choose: Wrong type argument: listp, class

I do have ocaml set up for babel (and it worked until I upgraded):

;;;; active Babel languages
(org-babel-do-load-languages
 'org-babel-load-languages
 '((ocaml . t)
	 (gnuplot . t)
	 (R . t)
	 (js . t)
   (ditaa . t)
   (perl . t)
   ))

Did something recently change to break this?

Thanks,

Alan

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

* Re: ocaml babel no longer works?
  2013-02-08 14:23 ocaml babel no longer works? Alan Schmitt
@ 2013-02-09 12:06 ` Alan Schmitt
  2013-02-09 21:09   ` Eric Schulte
  0 siblings, 1 reply; 12+ messages in thread
From: Alan Schmitt @ 2013-02-09 12:06 UTC (permalink / raw)
  To: emacs-orgmode

Alan Schmitt writes:

> Hello,
>
> I recently updated org-mode (from git), and ocaml source code is no
> longer recognized. If I have a very simple file, like this:
>
> #+BEGIN_SRC ocaml
> let x = 2 in x
> #+END_SRC
>
> I don't get syntax highlighting, and trying to evaluate it result in an
> error:
>
> Evaluate this ocaml code block on your system? (y or n)  y
> executing Ocaml code block...
> face-spec-choose: Wrong type argument: listp, class

I have found the problem: I was missing a new line at the end of the
#+END_SRC.

Unfortunately the evaluation of the code does not work with recent
tuareg. I first had to add:

(defalias 'tuareg-run-caml 'tuareg-run-ocaml)

to my configuration file. But even with this it gets stuck saying
"executing Ocaml code block..." until I ctrl-G it. I'll try to see what
is happening. Any suggestion as how to debug this?

Thanks,

Alan

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

* Re: ocaml babel no longer works?
  2013-02-09 12:06 ` Alan Schmitt
@ 2013-02-09 21:09   ` Eric Schulte
  2013-02-09 21:17     ` Sebastien Vauban
  2013-02-11 21:23     ` Alan Schmitt
  0 siblings, 2 replies; 12+ messages in thread
From: Eric Schulte @ 2013-02-09 21:09 UTC (permalink / raw)
  To: Alan Schmitt; +Cc: emacs-orgmode

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Alan Schmitt writes:
>
>> Hello,
>>
>> I recently updated org-mode (from git), and ocaml source code is no
>> longer recognized. If I have a very simple file, like this:
>>
>> #+BEGIN_SRC ocaml
>> let x = 2 in x
>> #+END_SRC
>>
>> I don't get syntax highlighting, and trying to evaluate it result in an
>> error:
>>
>> Evaluate this ocaml code block on your system? (y or n)  y
>> executing Ocaml code block...
>> face-spec-choose: Wrong type argument: listp, class
>
> I have found the problem: I was missing a new line at the end of the
> #+END_SRC.
>
> Unfortunately the evaluation of the code does not work with recent
> tuareg. I first had to add:
>
> (defalias 'tuareg-run-caml 'tuareg-run-ocaml)
>
> to my configuration file.

Hey Alan,

Thanks for looking into this.  I've applied a patch to ob-ocaml.el which
should handle the two different tuareg execution functions.

> But even with this it gets stuck saying "executing Ocaml code
> block..." until I ctrl-G it. I'll try to see what is happening. Any
> suggestion as how to debug this?
>

I would recommend evaluating first org-babel-execute:ocaml then possibly
org-babel-prep-session:ocaml in "edebug" mode.  This can be done by
running `eval-defun' on these functions with a prefix argument, or
equivalently doing "M-: (eval-defun t)".

I would guess this is due to a change in tuareg mode.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

* Re: ocaml babel no longer works?
  2013-02-09 21:09   ` Eric Schulte
@ 2013-02-09 21:17     ` Sebastien Vauban
  2013-02-11 21:23     ` Alan Schmitt
  1 sibling, 0 replies; 12+ messages in thread
From: Sebastien Vauban @ 2013-02-09 21:17 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi Eric,

Eric Schulte wrote:
> Alan Schmitt <alan.schmitt-o/5/jSaJEHk+NdeTPqioyti2O/JbrIOy@public.gmane.org> writes:
>> I have found the problem: I was missing a new line at the end of the
>> #+END_SRC.
>>
>> Unfortunately the evaluation of the code does not work with recent
>> tuareg. I first had to add:
>>
>> (defalias 'tuareg-run-caml 'tuareg-run-ocaml)
>>
>> to my configuration file.
>>
>> But even with this it gets stuck saying "executing Ocaml code
>> block..." until I ctrl-G it. I'll try to see what is happening. Any
>> suggestion as how to debug this?
>
> I would recommend evaluating first org-babel-execute:ocaml then possibly
> org-babel-prep-session:ocaml in "edebug" mode.  This can be done by
> running `eval-defun' on these functions with a prefix argument, or
> equivalently doing "M-: (eval-defun t)".

Or, even shorted, C-u C-M-x with point somewhere in the defun.

Best regards,
  Seb

-- 
Sebastien Vauban

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

* Re: ocaml babel no longer works?
  2013-02-09 21:09   ` Eric Schulte
  2013-02-09 21:17     ` Sebastien Vauban
@ 2013-02-11 21:23     ` Alan Schmitt
  2013-02-13 16:24       ` Eric Schulte
  1 sibling, 1 reply; 12+ messages in thread
From: Alan Schmitt @ 2013-02-11 21:23 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode

Hello,

Eric Schulte writes:

> Thanks for looking into this.  I've applied a patch to ob-ocaml.el which
> should handle the two different tuareg execution functions.

Thanks a lot.

About the thing "getting stuck", I made some progress. My error was that
I did not add ";;" at the end of my ocaml phrase, which resulted in an
error in the toplevel:

#+begin_quote
        Objective Caml version 3.12.1

# let x = 2 in x
"org-babel-ocaml-eoe";;
  Characters 13-14:
  let x = 2 in x
               ^
Error: This expression is not a function; it cannot be applied
#+end_quote

As you see, it's trying to apply the 'x' to the "oeo" thing. My guess is
that babel waits until seeing this special string before sending the
result back. By the way, this allows for some fun things, like this:

#+BEGIN_SRC ocaml
let f x = () in f
#+END_SRC

make babel stuck because the interpreter is in this state:

#+begin_quote
# let f x = () in f
"org-babel-ocaml-eoe";;
  - : unit = ()
#+end_quote

So I have a suggestion and two feature requests.

The suggestion: instead of appending '"org-babel-ocaml-eoe";;' to the
code, how simply put ';;' (which will make sure everything is flushed)
then detect the toplevel is done by seeing the string '# ' at the
beginning of the line? Would there be an issue with the fact that this
line does not have a newline? If so, an alternative suggestion would be
to use the longer ';; "org-babel-ocaml-eoe";;' which makes sure the
phrase in the input won't interact with the marker.

The first feature requests: if there is an error, could it be parsed?
(It probably always start with 'Error: '). Then the error could be put
in the result block, instead of waiting for the marker that will never
appear.

The second feature request: I want to use this for my ocaml lab classes
(I'm thinking of giving them an org file they have to complete by
writing the caml code). Could it be possible to have an option for the
full output of the compiler (and not just the result) to be printed? I
see it does it when it does not recognize the type of the output. So I
guess such an option would be applied to either
org-babel-ocaml-parse-output or the place where it's called.

Thanks a lot for any suggestion as how to implement this. I think I see
how to do the second one (except I don't know how to add a configuration
variable to toggle it). I have no idea about the first one, though.

Alan

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

* Re: ocaml babel no longer works?
  2013-02-11 21:23     ` Alan Schmitt
@ 2013-02-13 16:24       ` Eric Schulte
  2013-02-14  7:40         ` Alan Schmitt
  2013-05-02  9:49         ` Alan Schmitt
  0 siblings, 2 replies; 12+ messages in thread
From: Eric Schulte @ 2013-02-13 16:24 UTC (permalink / raw)
  To: Alan Schmitt; +Cc: emacs-orgmode, Eric Schulte

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Hello,
>
> Eric Schulte writes:
>
>> Thanks for looking into this.  I've applied a patch to ob-ocaml.el which
>> should handle the two different tuareg execution functions.
>
> Thanks a lot.
>
> About the thing "getting stuck", I made some progress. My error was that
> I did not add ";;" at the end of my ocaml phrase, which resulted in an
> error in the toplevel:
>
> #+begin_quote
>         Objective Caml version 3.12.1
>
> # let x = 2 in x
> "org-babel-ocaml-eoe";;
>   Characters 13-14:
>   let x = 2 in x
>                ^
> Error: This expression is not a function; it cannot be applied
> #+end_quote
>
> As you see, it's trying to apply the 'x' to the "oeo" thing. My guess is
> that babel waits until seeing this special string before sending the
> result back. By the way, this allows for some fun things, like this:
>
> #+BEGIN_SRC ocaml
> let f x = () in f
> #+END_SRC
>
> make babel stuck because the interpreter is in this state:
>
> #+begin_quote
> # let f x = () in f
> "org-babel-ocaml-eoe";;
>   - : unit = ()
> #+end_quote
>
> So I have a suggestion and two feature requests.
>
> The suggestion: instead of appending '"org-babel-ocaml-eoe";;' to the
> code, how simply put ';;' (which will make sure everything is flushed)
> then detect the toplevel is done by seeing the string '# ' at the
> beginning of the line? Would there be an issue with the fact that this
> line does not have a newline? If so, an alternative suggestion would be
> to use the longer ';; "org-babel-ocaml-eoe";;' which makes sure the
> phrase in the input won't interact with the marker.
>

You can customize the `org-babel-ocaml-eoe-output' and
`org-babel-ocaml-eoe-indicator' variables so that they match the above.
If this proves generally useful then I'd be happy to admit this change
to the core.

>
> The first feature requests: if there is an error, could it be parsed?
> (It probably always start with 'Error: '). Then the error could be put
> in the result block, instead of waiting for the marker that will never
> appear.
>

In `org-babel-execute:ocaml' first the `raw' variable is assigned to the
raw output of the ocaml session, it is then parsed into the `clean'
variable.  Between these two steps it should be possible to check for an
error string and possibly raise an error with
`org-babel-eval-error-notify'.

>
> The second feature request: I want to use this for my ocaml lab classes
> (I'm thinking of giving them an org file they have to complete by
> writing the caml code). Could it be possible to have an option for the
> full output of the compiler (and not just the result) to be printed? I
> see it does it when it does not recognize the type of the output. So I
> guess such an option would be applied to either
> org-babel-ocaml-parse-output or the place where it's called.
>

I would think adding a ":results verbatim" header argument would
suffice, but perhaps this is not the case.

>
> Thanks a lot for any suggestion as how to implement this. I think I see
> how to do the second one (except I don't know how to add a configuration
> variable to toggle it). I have no idea about the first one, though.
>

I hope these pointers are useful.  I apologize for not being able to
take a look at this myself, but I'm simply too busy.  ob-ocaml could
certainly use some attention, and I hope that if you do make
improvements you consider contributing them back to Org-mode.  In
general other more mature language modes should serve as a guide to most
implementation questions.

Cheers,

>
> Alan

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

* Re: ocaml babel no longer works?
  2013-02-13 16:24       ` Eric Schulte
@ 2013-02-14  7:40         ` Alan Schmitt
  2013-02-14 17:34           ` Eric Schulte
  2013-05-02  9:49         ` Alan Schmitt
  1 sibling, 1 reply; 12+ messages in thread
From: Alan Schmitt @ 2013-02-14  7:40 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode

Hi Eric,

Eric Schulte writes:

>> The suggestion: instead of appending '"org-babel-ocaml-eoe";;' to the
>> code, how simply put ';;' (which will make sure everything is flushed)
>> then detect the toplevel is done by seeing the string '# ' at the
>> beginning of the line? Would there be an issue with the fact that this
>> line does not have a newline? If so, an alternative suggestion would be
>> to use the longer ';; "org-babel-ocaml-eoe";;' which makes sure the
>> phrase in the input won't interact with the marker.
>>
>
> You can customize the `org-babel-ocaml-eoe-output' and
> `org-babel-ocaml-eoe-indicator' variables so that they match the above.
> If this proves generally useful then I'd be happy to admit this change
> to the core.

I'll have a look at it (as soon as my European grant deadline as
passed). The one thing I don't know about org-babel-comint-with-output
is the following: what does it do with the last line if it does not have
a carriage return? (After running a command, the toplevel outputs '# '
with no carriage return. Will it be part of the returned string?)

> I hope these pointers are useful.

They definitely are. As ocaml is not only my language of choice but one
I have the chance of teaching, I'll clearly look into this.

Thanks again,

Alan

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

* Re: ocaml babel no longer works?
  2013-02-14  7:40         ` Alan Schmitt
@ 2013-02-14 17:34           ` Eric Schulte
  0 siblings, 0 replies; 12+ messages in thread
From: Eric Schulte @ 2013-02-14 17:34 UTC (permalink / raw)
  To: Alan Schmitt; +Cc: emacs-orgmode, Eric Schulte

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Hi Eric,
>
> Eric Schulte writes:
>
>>> The suggestion: instead of appending '"org-babel-ocaml-eoe";;' to the
>>> code, how simply put ';;' (which will make sure everything is flushed)
>>> then detect the toplevel is done by seeing the string '# ' at the
>>> beginning of the line? Would there be an issue with the fact that this
>>> line does not have a newline? If so, an alternative suggestion would be
>>> to use the longer ';; "org-babel-ocaml-eoe";;' which makes sure the
>>> phrase in the input won't interact with the marker.
>>>
>>
>> You can customize the `org-babel-ocaml-eoe-output' and
>> `org-babel-ocaml-eoe-indicator' variables so that they match the above.
>> If this proves generally useful then I'd be happy to admit this change
>> to the core.
>
> I'll have a look at it (as soon as my European grant deadline as
> passed).

Great.

> The one thing I don't know about org-babel-comint-with-output is the
> following: what does it do with the last line if it does not have a
> carriage return? (After running a command, the toplevel outputs '# '
> with no carriage return. Will it be part of the returned string?)
>

This prompt should not be returned as ob-comint-w/output handles things
like removing echo'd inputs, prompts etc...  However, although I'm still
writing OCaml fairly regularly I removed tuareg during a recent hard
drive switch in favor of the default caml-mode, so I can't test this
directly with an OCaml code block (another reason why I'm excited at the
prospect of someone else's eyes on ob-caml).

>
>> I hope these pointers are useful.
>
> They definitely are. As ocaml is not only my language of choice but one
> I have the chance of teaching, I'll clearly look into this.
>
> Thanks again,
>
> Alan
>

Cheers,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

* Re: ocaml babel no longer works?
  2013-02-13 16:24       ` Eric Schulte
  2013-02-14  7:40         ` Alan Schmitt
@ 2013-05-02  9:49         ` Alan Schmitt
  2013-05-03 15:57           ` Eric Schulte
  2013-05-06  6:20           ` Alan Schmitt
  1 sibling, 2 replies; 12+ messages in thread
From: Alan Schmitt @ 2013-05-02  9:49 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode

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

Hello,

I'm resurrecting this old thread as I've made some progress but I
still have questions.

Eric Schulte writes:

>> The suggestion: instead of appending '"org-babel-ocaml-eoe";;' to the
>> code, how simply put ';;' (which will make sure everything is flushed)
>> then detect the toplevel is done by seeing the string '# ' at the
>> beginning of the line? Would there be an issue with the fact that this
>> line does not have a newline? If so, an alternative suggestion would be
>> to use the longer ';; "org-babel-ocaml-eoe";;' which makes sure the
>> phrase in the input won't interact with the marker.
>>
>
> You can customize the `org-babel-ocaml-eoe-output' and
> `org-babel-ocaml-eoe-indicator' variables so that they match the above.
> If this proves generally useful then I'd be happy to admit this change
> to the core.

I did this very tiny change and it makes interacting with the top-level
much nicer as one can forget putting ';;'. Here is a tiny diff, which I
can commit if you agree with the change. (As I've added other changes
while writing this email, I attach a proper patch as well for all the
changes.)

,----
| diff --git a/lisp/ob-ocaml.el b/lisp/ob-ocaml.el
| index 6a83908..e5ad447 100644
| --- a/lisp/ob-ocaml.el
| +++ b/lisp/ob-ocaml.el
| @@ -63,7 +63,7 @@
|                   (session org-babel-ocaml-eoe-output t full-body)
|                 (insert
|                  (concat
| -                 (org-babel-chomp full-body)"\n"org-babel-ocaml-eoe-indicator))
| +                 (org-babel-chomp full-body)";;\n"org-babel-ocaml-eoe-indicator))
|                 (tuareg-interactive-send-input)))
|          (clean
|           (car (let ((re (regexp-quote org-babel-ocaml-eoe-output)) out)
`----

>> The second feature request: I want to use this for my ocaml lab classes
>> (I'm thinking of giving them an org file they have to complete by
>> writing the caml code). Could it be possible to have an option for the
>> full output of the compiler (and not just the result) to be printed? I
>> see it does it when it does not recognize the type of the output. So I
>> guess such an option would be applied to either
>> org-babel-ocaml-parse-output or the place where it's called.
>
> I would think adding a ":results verbatim" header argument would
> suffice, but perhaps this is not the case.

Unfortunately this does not seem to work. I've finally managed to
understand how the code work, and here is a patch to solve this. The
idea is that we do not trim the type information if verbatim is
specified.

,----
| @@ -74,10 +74,13 @@
|                                          (progn (setq out t) nil))))
|                                    (mapcar #'org-babel-trim (reverse raw))))))))
|      (org-babel-reassemble-table
| -     (let ((raw (org-babel-trim clean)))
| -       (org-babel-result-cond (cdr (assoc :result-params params))
| -        ;; strip type information from output
| -        (if (string-match "= \\(.+\\)$" raw) (match-string 1 raw) raw)
| +     (let ((raw (org-babel-trim clean))
| +          (result-params (cdr (assoc :result-params params))))
| +       (org-babel-result-cond result-params
| +        ;; strip type information from output unless verbatim is specified
| +        (if (and (not (member "verbatim" result-params))
| +                 (string-match "= \\(.+\\)$" raw))
| +            (match-string 1 raw) raw)
|          (org-babel-ocaml-parse-output raw)))
|       (org-babel-pick-name
|        (cdr (assoc :colname-names params)) (cdr (assoc :colnames params)))
`----

Finally I found a bug with `org-babel-ocaml-parse-output': if the type
returned by the toplevel was something like "int -> int = <fun>", then
the matching against "int" would be triggered, and the conversion of
"<fun>" to an integer would result in "0". To solve this, I made the
regexp more precise as the value returned by the toplevel is:
(identifier | -) : type = value
where the identifier cannot have the ':' character.

Here is the corresponding diff:

,----
| @@ -113,7 +116,7 @@
|  (defun org-babel-ocaml-parse-output (output)
|    "Parse OUTPUT.
|  OUTPUT is string output from an ocaml process."
| -  (let ((regexp "%s = \\(.+\\)$"))
| +  (let ((regexp "[^:]+ : %s = \\(.+\\)$"))
|      (cond
|       ((string-match (format regexp "string") output)
|        (org-babel-read (match-string 1 output)))
`----

Hopefully this will be helpful.

Alan


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Babel-ocaml-Fix-the-interaction-with-the-toplevel.patch --]
[-- Type: text/x-patch, Size: 2336 bytes --]

From 9fad60e4a30ce8de779866fabfe1c66e3ffef000 Mon Sep 17 00:00:00 2001
From: Alan Schmitt <alan.schmitt@polytechnique.org>
Date: Thu, 2 May 2013 11:46:27 +0200
Subject: [PATCH] Babel ocaml: Fix the interaction with the toplevel

* lisp/ob-ocaml.el (org-babel-execute:ocaml): Always append ";;" at the end of
the expression before sending it to the toplevel.
(org-babel-execute:ocaml): Do not remove the type information if "verbatim" is a
results parameter of the code block.
(org-babel-ocaml-parse-output): Make sure the complete type is taken into
account when matching against known types.
---
 lisp/ob-ocaml.el | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/lisp/ob-ocaml.el b/lisp/ob-ocaml.el
index 6a83908..03500bb 100644
--- a/lisp/ob-ocaml.el
+++ b/lisp/ob-ocaml.el
@@ -63,7 +63,7 @@
 		  (session org-babel-ocaml-eoe-output t full-body)
 		(insert
 		 (concat
-		  (org-babel-chomp full-body)"\n"org-babel-ocaml-eoe-indicator))
+		  (org-babel-chomp full-body)";;\n"org-babel-ocaml-eoe-indicator))
 		(tuareg-interactive-send-input)))
 	 (clean
 	  (car (let ((re (regexp-quote org-babel-ocaml-eoe-output)) out)
@@ -74,10 +74,13 @@
 					 (progn (setq out t) nil))))
 				   (mapcar #'org-babel-trim (reverse raw))))))))
     (org-babel-reassemble-table
-     (let ((raw (org-babel-trim clean)))
-       (org-babel-result-cond (cdr (assoc :result-params params))
-	 ;; strip type information from output
-	 (if (string-match "= \\(.+\\)$" raw) (match-string 1 raw) raw)
+     (let ((raw (org-babel-trim clean))
+	   (result-params (cdr (assoc :result-params params))))
+       (org-babel-result-cond result-params
+	 ;; strip type information from output unless verbatim is specified
+	 (if (and (not (member "verbatim" result-params))
+		  (string-match "= \\(.+\\)$" raw))
+	     (match-string 1 raw) raw)
 	 (org-babel-ocaml-parse-output raw)))
      (org-babel-pick-name
       (cdr (assoc :colname-names params)) (cdr (assoc :colnames params)))
@@ -113,7 +116,7 @@
 (defun org-babel-ocaml-parse-output (output)
   "Parse OUTPUT.
 OUTPUT is string output from an ocaml process."
-  (let ((regexp "%s = \\(.+\\)$"))
+  (let ((regexp "[^:]+ : %s = \\(.+\\)$"))
     (cond
      ((string-match (format regexp "string") output)
       (org-babel-read (match-string 1 output)))
-- 
1.8.2.1


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

* Re: ocaml babel no longer works?
  2013-05-02  9:49         ` Alan Schmitt
@ 2013-05-03 15:57           ` Eric Schulte
  2013-05-07  7:56             ` Alan Schmitt
  2013-05-06  6:20           ` Alan Schmitt
  1 sibling, 1 reply; 12+ messages in thread
From: Eric Schulte @ 2013-05-03 15:57 UTC (permalink / raw)
  To: Alan Schmitt; +Cc: emacs-orgmode

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Hello,
>
> I'm resurrecting this old thread as I've made some progress but I
> still have questions.
>
> Eric Schulte writes:
>
>>> The suggestion: instead of appending '"org-babel-ocaml-eoe";;' to the
>>> code, how simply put ';;' (which will make sure everything is flushed)
>>> then detect the toplevel is done by seeing the string '# ' at the
>>> beginning of the line? Would there be an issue with the fact that this
>>> line does not have a newline? If so, an alternative suggestion would be
>>> to use the longer ';; "org-babel-ocaml-eoe";;' which makes sure the
>>> phrase in the input won't interact with the marker.
>>>
>>
>> You can customize the `org-babel-ocaml-eoe-output' and
>> `org-babel-ocaml-eoe-indicator' variables so that they match the above.
>> If this proves generally useful then I'd be happy to admit this change
>> to the core.
>
> I did this very tiny change and it makes interacting with the top-level
> much nicer as one can forget putting ';;'. Here is a tiny diff, which I
> can commit if you agree with the change. (As I've added other changes
> while writing this email, I attach a proper patch as well for all the
> changes.)
>
> ,----
> | diff --git a/lisp/ob-ocaml.el b/lisp/ob-ocaml.el
> | index 6a83908..e5ad447 100644
> | --- a/lisp/ob-ocaml.el
> | +++ b/lisp/ob-ocaml.el
> | @@ -63,7 +63,7 @@
> |                   (session org-babel-ocaml-eoe-output t full-body)
> |                 (insert
> |                  (concat
> | -                 (org-babel-chomp full-body)"\n"org-babel-ocaml-eoe-indicator))
> | +                 (org-babel-chomp full-body)";;\n"org-babel-ocaml-eoe-indicator))
> |                 (tuareg-interactive-send-input)))
> |          (clean
> |           (car (let ((re (regexp-quote org-babel-ocaml-eoe-output)) out)
> `----
>
>>> The second feature request: I want to use this for my ocaml lab classes
>>> (I'm thinking of giving them an org file they have to complete by
>>> writing the caml code). Could it be possible to have an option for the
>>> full output of the compiler (and not just the result) to be printed? I
>>> see it does it when it does not recognize the type of the output. So I
>>> guess such an option would be applied to either
>>> org-babel-ocaml-parse-output or the place where it's called.
>>
>> I would think adding a ":results verbatim" header argument would
>> suffice, but perhaps this is not the case.
>
> Unfortunately this does not seem to work. I've finally managed to
> understand how the code work, and here is a patch to solve this. The
> idea is that we do not trim the type information if verbatim is
> specified.
>
> ,----
> | @@ -74,10 +74,13 @@
> |                                          (progn (setq out t) nil))))
> |                                    (mapcar #'org-babel-trim (reverse raw))))))))
> |      (org-babel-reassemble-table
> | -     (let ((raw (org-babel-trim clean)))
> | -       (org-babel-result-cond (cdr (assoc :result-params params))
> | -        ;; strip type information from output
> | -        (if (string-match "= \\(.+\\)$" raw) (match-string 1 raw) raw)
> | +     (let ((raw (org-babel-trim clean))
> | +          (result-params (cdr (assoc :result-params params))))
> | +       (org-babel-result-cond result-params
> | +        ;; strip type information from output unless verbatim is specified
> | +        (if (and (not (member "verbatim" result-params))
> | +                 (string-match "= \\(.+\\)$" raw))
> | +            (match-string 1 raw) raw)
> |          (org-babel-ocaml-parse-output raw)))
> |       (org-babel-pick-name
> |        (cdr (assoc :colname-names params)) (cdr (assoc :colnames params)))
> `----
>
> Finally I found a bug with `org-babel-ocaml-parse-output': if the type
> returned by the toplevel was something like "int -> int = <fun>", then
> the matching against "int" would be triggered, and the conversion of
> "<fun>" to an integer would result in "0". To solve this, I made the
> regexp more precise as the value returned by the toplevel is:
> (identifier | -) : type = value
> where the identifier cannot have the ':' character.
>
> Here is the corresponding diff:
>
> ,----
> | @@ -113,7 +116,7 @@
> |  (defun org-babel-ocaml-parse-output (output)
> |    "Parse OUTPUT.
> |  OUTPUT is string output from an ocaml process."
> | -  (let ((regexp "%s = \\(.+\\)$"))
> | +  (let ((regexp "[^:]+ : %s = \\(.+\\)$"))
> |      (cond
> |       ((string-match (format regexp "string") output)
> |        (org-babel-read (match-string 1 output)))
> `----
>
> Hopefully this will be helpful.
>

Hi Alan,

I think each of these patches in an improvement over the existing
behavior.  Please do apply them all.

Thanks!

>
> Alan
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

* Re: ocaml babel no longer works?
  2013-05-02  9:49         ` Alan Schmitt
  2013-05-03 15:57           ` Eric Schulte
@ 2013-05-06  6:20           ` Alan Schmitt
  1 sibling, 0 replies; 12+ messages in thread
From: Alan Schmitt @ 2013-05-06  6:20 UTC (permalink / raw)
  To: Eric Schulte, emacs-orgmode

Hello,

I've been using this patch for the last few days and I have not found
any issue with it. Can I apply it?

Thanks,

Alan

Alan Schmitt writes:

> Hello,
>
> I'm resurrecting this old thread as I've made some progress but I
> still have questions.
>
> Eric Schulte writes:
>
>>> The suggestion: instead of appending '"org-babel-ocaml-eoe";;' to the
>>> code, how simply put ';;' (which will make sure everything is flushed)
>>> then detect the toplevel is done by seeing the string '# ' at the
>>> beginning of the line? Would there be an issue with the fact that this
>>> line does not have a newline? If so, an alternative suggestion would be
>>> to use the longer ';; "org-babel-ocaml-eoe";;' which makes sure the
>>> phrase in the input won't interact with the marker.
>>>
>>
>> You can customize the `org-babel-ocaml-eoe-output' and
>> `org-babel-ocaml-eoe-indicator' variables so that they match the above.
>> If this proves generally useful then I'd be happy to admit this change
>> to the core.
>
> I did this very tiny change and it makes interacting with the top-level
> much nicer as one can forget putting ';;'. Here is a tiny diff, which I
> can commit if you agree with the change. (As I've added other changes
> while writing this email, I attach a proper patch as well for all the
> changes.)
>
> ,----
> | diff --git a/lisp/ob-ocaml.el b/lisp/ob-ocaml.el
> | index 6a83908..e5ad447 100644
> | --- a/lisp/ob-ocaml.el
> | +++ b/lisp/ob-ocaml.el
> | @@ -63,7 +63,7 @@
> |                   (session org-babel-ocaml-eoe-output t full-body)
> |                 (insert
> |                  (concat
> | -                 (org-babel-chomp full-body)"\n"org-babel-ocaml-eoe-indicator))
> | +                 (org-babel-chomp full-body)";;\n"org-babel-ocaml-eoe-indicator))
> |                 (tuareg-interactive-send-input)))
> |          (clean
> |           (car (let ((re (regexp-quote org-babel-ocaml-eoe-output)) out)
> `----
>
>>> The second feature request: I want to use this for my ocaml lab classes
>>> (I'm thinking of giving them an org file they have to complete by
>>> writing the caml code). Could it be possible to have an option for the
>>> full output of the compiler (and not just the result) to be printed? I
>>> see it does it when it does not recognize the type of the output. So I
>>> guess such an option would be applied to either
>>> org-babel-ocaml-parse-output or the place where it's called.
>>
>> I would think adding a ":results verbatim" header argument would
>> suffice, but perhaps this is not the case.
>
> Unfortunately this does not seem to work. I've finally managed to
> understand how the code work, and here is a patch to solve this. The
> idea is that we do not trim the type information if verbatim is
> specified.
>
> ,----
> | @@ -74,10 +74,13 @@
> |                                          (progn (setq out t) nil))))
> |                                    (mapcar #'org-babel-trim (reverse raw))))))))
> |      (org-babel-reassemble-table
> | -     (let ((raw (org-babel-trim clean)))
> | -       (org-babel-result-cond (cdr (assoc :result-params params))
> | -        ;; strip type information from output
> | -        (if (string-match "= \\(.+\\)$" raw) (match-string 1 raw) raw)
> | +     (let ((raw (org-babel-trim clean))
> | +          (result-params (cdr (assoc :result-params params))))
> | +       (org-babel-result-cond result-params
> | +        ;; strip type information from output unless verbatim is specified
> | +        (if (and (not (member "verbatim" result-params))
> | +                 (string-match "= \\(.+\\)$" raw))
> | +            (match-string 1 raw) raw)
> |          (org-babel-ocaml-parse-output raw)))
> |       (org-babel-pick-name
> |        (cdr (assoc :colname-names params)) (cdr (assoc :colnames params)))
> `----
>
> Finally I found a bug with `org-babel-ocaml-parse-output': if the type
> returned by the toplevel was something like "int -> int = <fun>", then
> the matching against "int" would be triggered, and the conversion of
> "<fun>" to an integer would result in "0". To solve this, I made the
> regexp more precise as the value returned by the toplevel is:
> (identifier | -) : type = value
> where the identifier cannot have the ':' character.
>
> Here is the corresponding diff:
>
> ,----
> | @@ -113,7 +116,7 @@
> |  (defun org-babel-ocaml-parse-output (output)
> |    "Parse OUTPUT.
> |  OUTPUT is string output from an ocaml process."
> | -  (let ((regexp "%s = \\(.+\\)$"))
> | +  (let ((regexp "[^:]+ : %s = \\(.+\\)$"))
> |      (cond
> |       ((string-match (format regexp "string") output)
> |        (org-babel-read (match-string 1 output)))
> `----
>
> Hopefully this will be helpful.
>
> Alan

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

* Re: ocaml babel no longer works?
  2013-05-03 15:57           ` Eric Schulte
@ 2013-05-07  7:56             ` Alan Schmitt
  0 siblings, 0 replies; 12+ messages in thread
From: Alan Schmitt @ 2013-05-07  7:56 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode


Eric Schulte writes:

> I think each of these patches in an improvement over the existing
> behavior.  Please do apply them all.

I just applied them.

Best,

Alan

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

end of thread, other threads:[~2013-05-07  7:56 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-08 14:23 ocaml babel no longer works? Alan Schmitt
2013-02-09 12:06 ` Alan Schmitt
2013-02-09 21:09   ` Eric Schulte
2013-02-09 21:17     ` Sebastien Vauban
2013-02-11 21:23     ` Alan Schmitt
2013-02-13 16:24       ` Eric Schulte
2013-02-14  7:40         ` Alan Schmitt
2013-02-14 17:34           ` Eric Schulte
2013-05-02  9:49         ` Alan Schmitt
2013-05-03 15:57           ` Eric Schulte
2013-05-07  7:56             ` Alan Schmitt
2013-05-06  6:20           ` Alan Schmitt

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

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

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