From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Schulte <schulte.eric@gmail.com>
Subject: Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert
 hash for silent results
Date: Fri, 08 Mar 2013 15:09:45 -0700
Message-ID: <877glhsfus.fsf@gmail.com>
References: <1362542863-25992-1-git-send-email-aaronecay@gmail.com>
	<87obetsgma.fsf@Rainer.invalid>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([208.118.235.92]:47255)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <schulte.eric@gmail.com>) id 1UE5UT-0005X6-Vc
	for emacs-orgmode@gnu.org; Fri, 08 Mar 2013 17:10:18 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <schulte.eric@gmail.com>) id 1UE5UO-00081r-HN
	for emacs-orgmode@gnu.org; Fri, 08 Mar 2013 17:10:13 -0500
Received: from mail-pb0-f44.google.com ([209.85.160.44]:58651)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <schulte.eric@gmail.com>) id 1UE5UO-00081S-BN
	for emacs-orgmode@gnu.org; Fri, 08 Mar 2013 17:10:08 -0500
Received: by mail-pb0-f44.google.com with SMTP id wz12so1657758pbc.3
	for <emacs-orgmode@gnu.org>; Fri, 08 Mar 2013 14:10:07 -0800 (PST)
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=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: Achim Gratz <Stromeko@nexgo.de>
Cc: emacs-orgmode@gnu.org

Achim Gratz <Stromeko@nexgo.de> writes:

> Aaron Ecay writes:
>> In order for the cache feature to work, the hash of a finished
>> computation must be inserted.  But, this is not currently done for src
>> blocks which have the option :results none.  Thus, we should insert a
>> dummy empty result for these blocks, which will hold the hash.
>
> Getting a results block when specifying ":results none" feels a bit
> strange.

I would agree.  I don't believe *any* changes should take place in the
buffer when a code block is executed with ":results none".

> Since it is not the results that are hashed, but the effective
> parameters of the invocation, wouldn't it make more sense to store the
> parameter hash with the source block or call rather than the result?
> That would free up the current place to hash the actual result to
> check if the results have been tampered with.
>

I prefer leaving the hash with the results, as it is the results which
are "hashed".  Also, same input does not always guarantee same output,
e.g.,

#+begin_src sh
  date
#+end_src

>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte