From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Org babel with multiple linked segments of source code Date: Tue, 29 Mar 2011 08:09:15 -0600 Message-ID: <87bp0urowj.fsf@gmail.com> References: <87lj06a677.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=39540 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4Zkd-0007FT-Je for emacs-orgmode@gnu.org; Tue, 29 Mar 2011 10:20:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4Zkc-0006hj-9A for emacs-orgmode@gnu.org; Tue, 29 Mar 2011 10:18:31 -0400 Received: from mail-iy0-f169.google.com ([209.85.210.169]:37141) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4Zkc-0006hU-4L for emacs-orgmode@gnu.org; Tue, 29 Mar 2011 10:18:30 -0400 Received: by iyf13 with SMTP id 13so309250iyf.0 for ; Tue, 29 Mar 2011 07:18:29 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicholas Patrick Cc: emacs-orgmode@gnu.org Nicholas Patrick writes: > I may try playing around with the sequential sections...since that's how I'm > currently writing the majority of this file. Most of the pieces of code are > simply defining functions that call other functions or macros and wouldn't > be executed alone. However, I'm defining other blocks as tests for the > functional sections. So I might do the following: > Maybe you could try either putting all of your functional definitions into a single large code block, or you could write all of your functions in their own named code blocks #+source: foo1 #+begin_src emacs-lisp (deufn foo1 () :foo1) #+end_src #+source: foo2 #+begin_src emacs-lisp (deufn foo1 () :foo2) #+end_src and then use a single "functional-definitions" code block to collect all of these functional definitions #+source: functional-definitions #+begin_src emacs-lisp <> <> #+end_src this single code block could then be easily included in other code blocks. #+begin_src emacs-lisp <> (def xyz (f1 (f2 foo))) ; produces bar #+end_src #+results: : bar I know this isn't exactly what you were after, but it does work under the current system. I'd be interested to hear if other LP systems have something analogous to a "concatenate" function... Best -- Eric > > #+source: functional-definitions > #+begin_src emacs-lisp > (defn f1 > #+end_src > > #+source: functional-definitions > #+begin_src emacs-lisp > (defn f2 > #+end_src > > #+begin_src emacs-lisp > <> > (def xyz (f1 (f2 foo))) ; produces bar > #+end_src > > #+results: > | bar | > > I'm still pretty new to using babel, so I haven't figured out much other > than the basic tangling capability. Maybe my example could be accomplished > with something like a ':concatenate yes' option on the > functional-definitions blocks. > > On Tue, Mar 22, 2011 at 9:57 PM, Eric Schulte wrote: > >> Hi, >> >> The setup you suggest below is not currently supported. I fear >> implementing such a system could have some odd semantic extensions into >> other parts of Org-mode code blocks, for example, would it then make >> sense for the results of a code block to be collected over all code >> blocks with that name? For example, >> >> #+source: test2 >> #+begin_src emacs-lisp >> 1 >> #+end_src >> >> #+source: test2 >> #+begin_src emacs-lisp >> 2 >> #+end_src >> >> #+begin_src emacs-lisp :var data=test2 >> data >> #+end_src >> >> #+results: >> | 1 | 2 | >> >> Maybe, but this is certainly not possible under the current setup. >> >> Anyways, back to your use case, maybe it would be equally convenient to >> simply have a number of sequential code blocks in the Org-mode file all >> tangle out, as they will be placed in the tangled file in the order they >> appear in the Org-mode file, so your example below could be changed >> to... >> >> ** tangling example >> :PROPERTIES: >> :tangle: test1.clj >> :exports: none >> :END: >> >> #+begin_src clojure >> blah >> #+end_src >> >> #+begin_src clojure >> foo >> #+end_src >> >> #+begin_src clojure >> bar >> #+end_src >> >> #+begin_src clojure >> blah >> #+end_src >> >> While not the same as what you suggested this may be sufficient. >> >> Best -- Eric >> >> Nicholas Patrick writes: >> >> > I'm trying to figure out how to minimize the overhead with using babel to >> > write some segments of code. I find myself writing short segments of a >> set >> > of functionality, then writing a collector source block which is referred >> to >> > later on in the code... e.g. >> > >> > ********************* >> > #+srcname: test1 >> > #+begin_src clojure :tangle test1.clj :exports none :noweb yes >> > blah >> > <> >> > blah >> > #+end_src >> > >> > #+srcname: test2 >> > #+begin_src clojure >> > foo >> > #+end_src >> > >> > #+srcname: test2 >> > #+begin_src clojure >> > bar >> > #+end_src >> > ********************* >> > I'd like to see >> > blah >> > foo >> > bar >> > blah >> > >> > but I see >> > blah >> > foo >> > blah >> > >> > What I'd like to see is a single srcname for the code that just >> concatenates >> > the two different sections when it is referred by <>. >> > That way I don't have to come up with different names and collectors and >> so >> > on and so forth. Maybe I'm just not doing "literate programming" right, >> but >> > when I'm hacking stuff together, I'd like to minimize the housekeeping. >> > e.g. >> > >> > Is there a way to do this? >> >>