From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: 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 Message-ID: <87txl2doqo.fsf@gmail.com> References: <87txl5h91a.fsf@gmail.com> <2F1F01A1-5D4D-4EAC-8B30-A9DE6177137A@datalligator.com> <87txl2fv0k.fsf@gmail.com> <6BC536CA-433B-4498-B648-871A57EA98ED@datalligator.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:32849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Un9I8-00076R-Bb for emacs-orgmode@gnu.org; Thu, 13 Jun 2013 11:18:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Un9I6-0005LR-ES for emacs-orgmode@gnu.org; Thu, 13 Jun 2013 11:18:24 -0400 Received: from mail-pb0-x233.google.com ([2607:f8b0:400e:c01::233]:36653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Un9I6-0005LA-3D for emacs-orgmode@gnu.org; Thu, 13 Jun 2013 11:18:22 -0400 Received: by mail-pb0-f51.google.com with SMTP id um15so10380068pbc.24 for ; Thu, 13 Jun 2013 08:18:21 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Simon Beaumont Cc: emacs-orgmode@gnu.org Simon Beaumont 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 wrote: > >> Simon Beaumont 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