emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Bug: Babel Haskell mode [8.0.3 (8.0.3-30-g56b864-elpa @ /Users/i


From: Eric Schulte
Subject: Re: [O] Bug: Babel Haskell mode [8.0.3 (8.0.3-30-g56b864-elpa @ /Users/ix/.emacs.d/elpa/org-20130610/)]
Date: Thu, 13 Jun 2013 07:04:19 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Simon Beaumont <address@hidden> writes:

> Hi Eric,
>
> Thanks for investigating this.
>
> You got it! The blooming prompt! As you say the comint parser expects
> "Prelude>" and I have customised my prompt in .ghci (also this
> wouldn't work with module loads like :m +Mymodule.Foo as this changes
> the ghci prompt).
>
> BTW if I use a unicode sequence for the prompt (like a greek lambda as
> a few knights of the lambda calculus do) then accept-process-output
> hangs!
>

I would take this up either with the maintainers of comint-mode, or
possibly the inferior-haskell developers.  The function used by Org-mode
(namely `org-babel-comint-with-output') uses standard comint variables
(e.g., `comint-prompt-regexp'), so this is one area where the Babel ship
rises and falls with the quality of the Emacs tide.

>
> Well at least that's me fixed! Would it be possible for comint to
> learn the prompt by sending an empty line and then adapting? -- It
> would need to do this every time it sees a :command and at startup. Of
> course this is ghci specific.
>

I'd raise this with the inferior-haskell devs.

>
> Or is the answer to write an evaluation server for ghc with a well
> defined client API? Then Haskell integration gets a lot easier -- this
> would be like slime (common-lisp) for Haskell. Might be worth an
> enquiry on the Haskell list as there is a Haskell API that might cover
> the requirement.
>

I would imagine that ghci on the haskell side should be fairly easily
adjusted to support such a use case.  Maybe just passing an option when
ghci is started to inhibit any prompt customization would be
sufficient. Another option from the Org/Babel perspective, would be to
add support for non-session evaluation, i.e., compiling the code block
to an executable (perhaps with some default main function), and then
running that executable, as we currently do with C.

Cheers,

>
>
> Simon Beaumont
>
> -------------------
> On 13 Jun 2013, at 06:18, Eric Schulte <address@hidden> wrote:
>
>> Simon Beaumont <address@hidden> writes:
>> 
>>> Well that's really odd: I modded the paths in init.el and did the following:
>>> 
>>> emacs -Q -l init.el foo.org
>>> 
>>> When I eval'ed the code block in foo.org (twice) I still get message:
>>> "Code block returned no value" I've attached the inferior haskell
>>> buffer and all relevant files.
>>> 
>>> (add-to-list 'load-path "~/.emacs.d/elpa/haskell-mode-20130610.152")
>> 
>> I thought maybe it could be a difference between our haskell modes, so I
>> switched to the latest available through my elpa (haskell-mode-13.6),
>> and I still see the correct behavior.
>> 
>>> GHClet fac n = product [1..n]
>>> [(x,fac x) | x <- [0..11]]
>>> "org-babel-haskell-eoe"
>>> i, version 7.6.3: http://www.haskell.org/ghc/  :? for help
>>> Loading package ghc-prim ... linking ... done.
>>> Loading package integer-gmp ... linking ... done.
>>> Loading package base ... linking ... done.
>>>> [(0,1),(1,1),(2,2),(3,6),(4,24),(5,120),(6,720),(7,5040),(8,40320),(9,362880),(10,3628800),(11,39916800)]
>>>> "org-babel-haskell-eoe"
>>>> let fac n = product [1..n]
>>> [(x,fac x) | x <- [0..11]]
>>> "org-babel-haskell-eoe"
>>>> [(0,1),(1,1),(2,2),(3,6),(4,24),(5,120),(6,720),(7,5040),(8,40320),(9,362880),(10,3628800),(11,39916800)]
>>>> "org-babel-haskell-eoe"
>>> 
>> 
>> My *haskell* buffer looks different then yours.  Namely I have
>> "Prelude>" where as you just have ">".  I don't know if this is
>> significant.  Maybe you've customized your ghci prompts in such a way
>> that the comint functions can no longer recognize where output begins?
>> 
>> ,----
>> | GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
>> | Loading package ghc-prim ... let fac n = product [1..n]
>> | [(x,fac x) | x <- [0..11]]
>> | "org-babel-haskell-eoe"
>> | linking ... done.
>> | Loading package integer-gmp ... linking ... done.
>> | Loading package base ... linking ... done.
>> | Prelude> Prelude>
>> | Prelude> 
>> [(0,1),(1,1),(2,2),(3,6),(4,24),(5,120),(6,720),(7,5040),(8,40320),(9,362880),(10,3628800),(11,39916800)]
>> | Prelude> "org-babel-haskell-eoe"
>> | Prelude> let fac n = product [1..n]
>> | [(x,fac x) | x <- [0..11]]
>> | "org-babel-haskell-eoe"
>> | Prelude> 
>> [(0,1),(1,1),(2,2),(3,6),(4,24),(5,120),(6,720),(7,5040),(8,40320),(9,362880),(10,3628800),(11,39916800)]
>> | Prelude> "org-babel-haskell-eoe"
>> | Prelude> 
>> `----
>> 
>> I'm not sure what else this could be.  One option would be to instrument
>> `org-babel-execute:haskell' or `org-babel-comint-with-output' with
>> edebug, and then step through evaluation to see if you can pinpoint
>> where the problem lies.
>> 
>> Hope this helps,
>> 
>> -- 
>> Eric Schulte
>> http://cs.unm.edu/~eschulte
>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]