[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: |
Simon Beaumont |
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 10:35:27 +0100 |
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!
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.
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.
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>
> [(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