emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Simon Beaumont <simon@datalligator.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: emacs-orgmode@gnu.org
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 10:35:27 +0100	[thread overview]
Message-ID: <6BC536CA-433B-4498-B648-871A57EA98ED@datalligator.com> (raw)
In-Reply-To: <87txl2fv0k.fsf@gmail.com>

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 <schulte.eric@gmail.com> wrote:

> Simon Beaumont <simon@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> [(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

  reply	other threads:[~2013-06-13  9:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-10 20:07 Bug: Babel Haskell mode [8.0.3 (8.0.3-30-g56b864-elpa @ /Users/ix/.emacs.d/elpa/org-20130610/)] Simon Beaumont
2013-06-10 22:53 ` Eric Schulte
2013-06-11 15:15   ` Simon Beaumont
2013-06-13  5:18     ` Eric Schulte
2013-06-13  9:35       ` Simon Beaumont [this message]
2013-06-13 13:04         ` Eric Schulte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6BC536CA-433B-4498-B648-871A57EA98ED@datalligator.com \
    --to=simon@datalligator.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=schulte.eric@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).