From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 4P58K7uiWGCyeAAA0tVLHw (envelope-from ) for ; Mon, 22 Mar 2021 13:59:23 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id OMljJ7uiWGDBDwAA1q6Kng (envelope-from ) for ; Mon, 22 Mar 2021 13:59:23 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 97D07DBC1 for ; Mon, 22 Mar 2021 14:59:22 +0100 (CET) Received: from localhost ([::1]:48202 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOL5V-0000Ym-6g for larch@yhetil.org; Mon, 22 Mar 2021 09:59:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57042) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOKoZ-0007eA-KT for emacs-orgmode@gnu.org; Mon, 22 Mar 2021 09:41:51 -0400 Received: from mx1.riseup.net ([198.252.153.129]:38604) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOKoT-0001Mo-FM for emacs-orgmode@gnu.org; Mon, 22 Mar 2021 09:41:47 -0400 Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4F3wdg617KzDw28; Mon, 22 Mar 2021 06:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1616420503; bh=ylQaK8b/t6amnOUsOE6mV6JECsK66R7Yl1ucXi8YYQk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=C4B/eNWT5f+40LwuoWgmEkPu9GWkFCEt2BPowO9ehBh8yl90ebUJJqADC/Q3NhrT9 sJ5kjFqCJPdRfu3HevykZcVSM8/K4vpk+UOqJrDfTy78f++plapGbi0N42iat0EWxd MxTckDnWE2f0oSIYMFbZlDkjdF1pZgwGSq8uV0wc= X-Riseup-User-ID: DBC6C9451A42CB95A73FC5EAA740A80F792E88B85F9A893F0A34A0F736FDF21B Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4F3wdf6PYbz1yBB; Mon, 22 Mar 2021 06:41:42 -0700 (PDT) From: c4t0 To: "Thomas S. Dye" Subject: Re: source blocks DAG evaluation References: <87k0q0ymk1.fsf@riseup.net> <8735wnsy97.fsf@tsdye.online> Date: Mon, 22 Mar 2021 10:41:40 -0300 In-Reply-To: <8735wnsy97.fsf@tsdye.online> (Thomas S. Dye's message of "Sun, 21 Mar 2021 16:44:36 -1000") Message-ID: <87czvrz4ob.fsf@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=198.252.153.129; envelope-from=c4t0@riseup.net; helo=mx1.riseup.net X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1616421563; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=0A+XzC55UPPMzh6OPrFhGFNfJljG7p3wyk7AZsKSvB4=; b=U5PbtOUon2g2FGZpwKq87VbakcbTvQ9Spo46nWk3i4WEGRsQt+HDayd6Sk9EE1ft/1ccca TNrfNYTr8vRGkHKTl336QJMogqh6lk0nOjWt090LXQBFFRVaHAyu1vuBgc9LBthwCbQWTy OFIjNlkB+fUBanNVpr0PWN7t+KBMuIXySxiNJDAo6wTbkI17U83Dlin/nI4rzpqIiV7OFY bu0VsKs6IbLOyHtiMW0tY8P/wIOv7FKoKoTNpLq3TJLqAKKotdHY2q6vNZtP7g0T2dINdW QBUN1xUJezjpvj5htU9A8unPIbAdILbLDTguNkrKWVcTut9DJv54jLPlRXboOg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1616421563; a=rsa-sha256; cv=none; b=iIkhf4dJJApo8ju51TKDvrjdG4Q6AmDGUwx/N1mfR4Rc805JJNGchrYLsF5R/NX8MjqvTe kKU80lagTJ0kds32Uof2n4ZgACWKWEXanymUPn+qq98Tyxfana5p01k6uZV5OcgmnuMzAJ +qQgVdtEQQgHcZ20E7epf3RiI31klPEzzB3JX/r5gzmU3u8LuGIrbyoIaEGH03Ci9tj4nB W3j7ZMa15YTfNGlc9cqZJE/I9TwqSjTWe4qLf8aFAajaAbponAalCYbE6nHBIJCoIIZeRh 5fKuXU+vSw+sGJZ6LBSOQ7BGd11NG5HUF1DDCgTM1QZRm6FotUQrqtBZMTO34A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=riseup.net header.s=squak header.b="C4B/eNWT"; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -3.12 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=riseup.net header.s=squak header.b="C4B/eNWT"; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 97D07DBC1 X-Spam-Score: -3.12 X-Migadu-Scanner: scn0.migadu.com X-TUID: qeZCFwX/YfBU Hello Thomas! That is fairly nice, thanks! I can use it for the moment. I see a minor problem, if you export it, the last block will show all the code and that may be redundant or undesired. But that can be solved fiddling with exporting options or code I guess. btw, using :noweb no-expor= t, just leaves the <> sintax, so it's not what I want.=20 In this sense it also doesn't do any cycle resolving, when a there is one it just fails with "org-at-heading-p: Variable binding depth exceeds max-specpdl-size" That may be ok, you shouldn't have cycles. But there is a more realist problem, you *can* have, diamonds dependencies. Say libA -> libB -> libD -> main \> libC / If you <> from main, you will get two copies of libA source code. That may be a problem in some languages and it's definitely bad at export time. The good about noweb expansion is that you can ignore the problem with the sessions all together and it will work with things that doesn't have sessions at all (now I remember a home work in assembler that I did in org-mode with noweb expansion ...) So, maybe if I try to improve anything, to address this issue, maybe is the code for noweb expansion? Maybe some options to conditional output the template expansion or just remove the <<*>> calls. I don't know if the semantics of what I want go along a template expansion ... I have the feeling that we might need something particular for this, like a (require ...) for org-mode source blocks. thanks! COD. "Thomas S. Dye" writes: > Aloha c4to, > > I would be tempted to use noweb expansion here. > > #+name: libB > #+begin_src scheme :results none :noweb yes > > <> > (define greetings (string-append hi ", " "to all the people!")) > #+end_src > > #+begin_src scheme :session example :results output :noweb yes > <> > (display greetings) > #+end_src > > Does this do what you want? > > All the best, > Tom > > c4t0 writes: > >> Hi, >> >> Is it possible to have a dependency hierarchy of source blocks? >> >> i.e.: in C, if you use libA from a compilation unit and that=20 >> library needs libB, you don't need to include it in main.c >> >> -> main.c >> #include "libB.h" >> -> libB.c >> #include "libA.h" >> >> you don't need to: >> -> main.c >> #include "libB.h" >> #include "libA.h" >> >> because library headers are closed under inclusion. >> >> I haven't succeeded in doing the same in org-mode. Even after=20 >> populating org-babel-library-of-babel. >> >> Using #+call just doesn't work. Using :var is better, evaluates=20 >> all, but there appears to lack session support, it doesn't check=20 >> for cycles and it feels a little hacky >> >> With #+call I need to do it like this: >> >> #+name: libA >> #+begin_src scheme :results none >> (define hi "hello") >> #+end_src >> >> #+name: libB >> #+begin_src scheme :results none >> (define greetings (string-append hi ", " "to all the people!")) >> #+end_src >> >> here is my "main" I need to C-c C-c in each #+call line and=20 >> write the :session that the code block uses in each one, and do=20 >> it in the correct order. If I C-c C-c in libB first it won't=20 >> eval because 'hi' is not defined. >> >> #+call: libB[:session example] >> #+call: libA[:session example] >> #+begin_src scheme :session example :results output >> (display greetings) >> #+end_src >> >> source blocks can be #+call(ed) but aren't closed under #+call=20 >> (a source block can be called but then the callee won't) >> >> instead I would like to : >> >> #+name: libA >> #+begin_src scheme :results none >> (define hi "hello") >> #+end_src >> >> #+call: libA >> #+name: libB >> #+begin_src scheme :results none >> (define greetings (string-append hi ", " "to all the people!")) >> #+end_src >> >> #+call: libB >> #+begin_src scheme :session example :results output >> (display greetings) >> #+end_src >> >> - there shouldn't be needed to C-c C-c in the #+call line,=20 >> evaluating the source block alone should suffice. >> - there shouldn't be a need to write the :session >> - it should use the session of the user evaled block, unless=20 >> specified otherwise >> >> In the other hand, using :var with a dummy variable: >> >> #+name: libA >> #+begin_src scheme :results none >> (define hi "hello") >> #+end_src >> >> #+name: libB >> #+begin_src scheme :results none :var _=3DlibA >> (define greetings (string-append hi ", " "to all the people!")) >> #+end_src >> >> #+HEADER: :var _=3DlibB >> #+begin_src scheme :session example :results output >> (display greetings) >> #+end_src >> >> It evals libA then libB and finally the (display greetings)=20 >> code. >> But it fails, because the :session example is ignored. Even if I=20 >> add a :session example to every source block (which would be=20 >> really bad, sessi=C3=B3n must be decided by the consumer) it doesn't=20 >> work. I think that is because :var expects a value, so it just=20 >> opens a new session to evaluate code every time. >> >> Besides if there are any dependency cycles, it just fails with:=20 >> Lisp nesting exceeds =E2=80=98max-lisp-eval-depth=E2=80=99 >> >> So if I'm right and there is not an implemented way to do this,=20 >> how can we do it? Adding session support for :var? constructing=20 >> a DAG of #+calls and then evaluating in order? maybe using a new=20 >> header? >> >> COD. > > > -- > Thomas S. Dye > https://tsdye.online/tsdye