Simon Beaumont <si...@datalligator.com> 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 <schulte.e...@gmail.com> wrote: > >> Simon Beaumont <si...@datalligator.com> 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