From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: [babel] ob-C.el annoyances Date: Fri, 15 Apr 2011 10:24:58 -0600 Message-ID: <87zknr8osr.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:43461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAlqj-0001lW-7f for emacs-orgmode@gnu.org; Fri, 15 Apr 2011 12:26:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QAlqg-0007Ao-KN for emacs-orgmode@gnu.org; Fri, 15 Apr 2011 12:26:25 -0400 Received: from mail-pv0-f169.google.com ([74.125.83.169]:34812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAlqg-0006qu-Fq for emacs-orgmode@gnu.org; Fri, 15 Apr 2011 12:26:22 -0400 Received: by mail-pv0-f169.google.com with SMTP id 4so1547670pvg.0 for ; Fri, 15 Apr 2011 09:26:22 -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: Julien Fantin Cc: emacs-orgmode@gnu.org Julien Fantin writes: > Hi list, hi Eric, > > I've been using ob-C to go through the K&R book, and I've noticed a few > annoyances along the way. > > * Use of the captial C identifier > > Support functions are defined as ob-C-*. In consequence, I need to > #+begin_src C to get a block to execute, because #+begin_src c fails > with "No org-babel-execute function for c!". The problem is that I can't > edit the block since there is no C-mode. Defining an alias fixed the > issue, but it doesn't work OOTB, and doesn't feel like a good solution > at all. > I've changed the default value of `org-src-lang-modes' so with the latest version of Org-mode the "begin_src C" code blocks will use the appropriate mode without the need to define an alias. Thanks for pointing out this inconsistency. > > Is there a reasoning behind this, or where you, as I suspect, trying to > define some support functions that would work for both C and C++ ? > For a while we had a mix of both "C" and "c" in our function names, and recently we normalized on "C". It seems we left a few loose ends in this process. > > > * Feeding text into blocks > > This is not directly related to ob-C.el, but I was looking for a way to > feed some text to a block's STDIN while it was executed by babel. I > wanted to specifiy this text either inline from the block's header > arguments or from a dedicated text block. > There is currently the option of passing command line arguments to C code blocks, e.g., #+begin_src C :cmdline 1 2 3 4 5 :includes int main(int argc, char **argv){ printf("argv[1] %s\n", argv[1]); return 0; } #+end_src #+results: : argv[1] 1 However there is no support for piping to/from the STDIN/STDOUT/STDERR of code blocks. The issue of pipes has come up before (for example with a robust piping interface, we could stream data between code blocks in much the same way as piped commands on the command line). Such a change would require significant work, may require support for asynchronous code block execution. While such large projects may make (for example) a good google SOC project, I don't believe they will be implemented in the near future. > > It'd ideally look like this : > > ** Inline > > #+begin_src c :feed foo bar > int main(void) { > while ((c = getchar()) != EOF) { > putchar(c); > } > return 0; > } > #+end_src > > #+results: > : foo bar > > ** From a text block > > #+source: my-stdin > #+begin_src text > foo bar > #+end_src > > #+begin_src c :feed my-stdin > int main(void) { > while ((c = getchar()) != EOF) { > putchar(c); > } > return 0; > } > #+end_src > > #+results: > : foo bar > > TL;DR if this is already possible somehow please skip the following and let > me know :) > > I couldn't figure out how to pipe the text from within babel though. So > I resorted to tangling the text blocks, and redefined > org-babel-C-execute to use that new header argument :feed. It gets > prepended to the cmdline in the org-babel-eval function call ; if foo is > an existing file it gets cat'ed through a pipe to the rest of the > cmdline in org-babel-eval, otherwise it is simply echo'ed. This is not > as good as what I described above, but after getting to use it, I really > think a generalization of this use-case is desirable. > > Please let me know whar you think. > I agree fully, however I would want to implement piping in such a manner that it can easily be extended to any language, rather than in a C specific manner. It sounds like you have a nice solution currently. Perhaps rather than overwriting the execute function, you could wrap this up into a new function, and share the code on Worg so others could incorporate it into their workflow. Best -- Eric > > Regards, > Julien. > > > -- Eric Schulte http://cs.unm.edu/~eschulte/