[Babel] [Bug] Cache

[Babel] [Bug] Cache

[Sebastien Vauban]

Hello Eric,

IIRC, some time ago, a bug involving the computation of the hash (when option
cache is enabled) and NoWeb code blocks. I remember that it had been fixed.

However, the following example shows it's not (true anymore):

--8<---------------cut here---------------start------------->8---
#+PROPERTY: cache yes

#+name: common-code
#+begin_src R :eval no
s <- "Hello"
#+end_src

#+begin_src R :noweb yes
<<common-code>>

print(s)
#+end_src

#+results[f472c44e64e310a6d06544dbdfba558a709873a7]:
: Hello
--8<---------------cut here---------------end--------------->8---

Change the "common code" block: edit "Hello", for example, and you'll see that
the evaluation of the other code block is not redone (like if the NoWeb code
was not expanded for computing the hash). It stays printing "Hello".

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [Babel] [Bug] Cache

[Eric Schulte]

Hi Seb,

Could you git bisect this breakage to isolate the offending commit?

Thanks,

"Sebastien Vauban" <sva-news@mygooglest.com> writes:

> Hello Eric,
>
> IIRC, some time ago, a bug involving the computation of the hash (when option
> cache is enabled) and NoWeb code blocks. I remember that it had been fixed.
>
> However, the following example shows it's not (true anymore):
>
> --8<---------------cut here---------------start------------->8---
> #+PROPERTY: cache yes
>
> #+name: common-code
> #+begin_src R :eval no
> s <- "Hello"
> #+end_src
>
> #+begin_src R :noweb yes
> <<common-code>>
>
> print(s)
> #+end_src
>
> #+results[f472c44e64e310a6d06544dbdfba558a709873a7]:
> : Hello
> --8<---------------cut here---------------end--------------->8---
>
> Change the "common code" block: edit "Hello", for example, and you'll see that
> the evaluation of the other code block is not redone (like if the NoWeb code
> was not expanded for computing the hash). It stays printing "Hello".
>
> Best regards,
>   Seb

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [Babel] [Bug] Cache

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> writes:
>>
>> IIRC, some time ago, a bug involving the computation of the hash (when
>> option cache is enabled) and NoWeb code blocks. I remember that it had been
>> fixed.
>>
>> However, the following example shows it's not (true anymore):
>>
>> --8<---------------cut here---------------start------------->8---
>> #+PROPERTY: cache yes
>>
>> #+name: common-code
>> #+begin_src R :eval no
>> s <- "Hello"
>> #+end_src
>>
>> #+begin_src R :noweb yes
>> <<common-code>>
>>
>> print(s)
>> #+end_src
>>
>> #+results[f472c44e64e310a6d06544dbdfba558a709873a7]:
>> : Hello
>> --8<---------------cut here---------------end--------------->8---
>>
>> Change the "common code" block: edit "Hello", for example, and you'll see
>> that the evaluation of the other code block is not redone (like if the NoWeb
>> code was not expanded for computing the hash). It stays printing "Hello".
>
> Could you git bisect this breakage to isolate the offending commit?

I couldn't find any version where my ECM would work. Though, I was sure to have
read comments about that problem -- I never used that situation myself in the
past, so I just assumed it had been fixed in the meanwhile. It seems not.

And here the post of Achim where he explains that problem:

  ╭────
  │ From: Achim Gratz <Stromeko-i47jiTeKxPI@public.gmane.org>
  │ Subject: Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src-block):
  │ 	insert hash for silent results
  │ Date: Sun, 10 Mar 2013 09:52:10 +0100 (38 weeks, 1 day, 6 hours ago)
  │
  │ [...]
  │
  │ But back to my earlier remark about the hash value actually being a
  │ signature of the source block and not the result.  If I use noweb
  │ references, the reference text is cached, not its expansion.
  ╰────

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [Babel] [Bug] Cache

[Eric Schulte]

"Sebastien Vauban" <sva-news@mygooglest.com> writes:

> Hi Eric,
>
> Eric Schulte wrote:
>> "Sebastien Vauban" <sva-news@mygooglest.com> writes:
>>>
>>> IIRC, some time ago, a bug involving the computation of the hash (when
>>> option cache is enabled) and NoWeb code blocks. I remember that it had been
>>> fixed.
>>>
>>> However, the following example shows it's not (true anymore):
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> #+PROPERTY: cache yes
>>>
>>> #+name: common-code
>>> #+begin_src R :eval no
>>> s <- "Hello"
>>> #+end_src
>>>
>>> #+begin_src R :noweb yes
>>> <<common-code>>
>>>
>>> print(s)
>>> #+end_src
>>>
>>> #+results[f472c44e64e310a6d06544dbdfba558a709873a7]:
>>> : Hello
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> Change the "common code" block: edit "Hello", for example, and you'll see
>>> that the evaluation of the other code block is not redone (like if the NoWeb
>>> code was not expanded for computing the hash). It stays printing "Hello".
>>
>> Could you git bisect this breakage to isolate the offending commit?
>
> I couldn't find any version where my ECM would work. Though, I was sure to have
> read comments about that problem -- I never used that situation myself in the
> past, so I just assumed it had been fixed in the meanwhile. It seems not.
>
> And here the post of Achim where he explains that problem:
>
>   ╭────
>   │ From: Achim Gratz <Stromeko@nexgo.de>
>   │ Subject: Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src-block):
>   │ 	insert hash for silent results
>   │ Date: Sun, 10 Mar 2013 09:52:10 +0100 (38 weeks, 1 day, 6 hours ago)
>   │
>   │ [...]
>   │
>   │ But back to my earlier remark about the hash value actually being a
>   │ signature of the source block and not the result.  If I use noweb
>   │ references, the reference text is cached, not its expansion.
>   ╰────
>

In that thread we agreed that the expansion of no-web references
*should* be included in code blocks for hashing, but no-one has had the
time to implement this.

I believe this is still the case.

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [Babel] [Bug] Cache

[Achim Gratz]

Eric Schulte writes:
> In that thread we agreed that the expansion of no-web references
> *should* be included in code blocks for hashing, but no-one has had the
> time to implement this.

I think we may have discussed this before, but if you make the hashes
dependent on the possibly recursive noweb expansions this would require
that all expansions be re-computed all the time or you would need to
discern which of the expansions are "pure" (i.e. depend only on their
arguments, functional-style), which have session semantics and which of
the ones that have session semantics should possibly not be
re-evaluated.  I'm not sure that opening this can of worms is worth the
trouble.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [Babel] [Bug] Cache

[Sebastien Vauban]

Achim Gratz wrote:
> Eric Schulte writes:
>> In that thread we agreed that the expansion of no-web references
>> *should* be included in code blocks for hashing, but no-one has had the
>> time to implement this.
>
> I think we may have discussed this before, but if you make the hashes
> dependent on the possibly recursive noweb expansions this would require
> that all expansions be re-computed all the time

I did not think at recursive Noweb expansions. But, yes, that problem could
come up as well.

> or you would need to discern which of the expansions are "pure" (i.e. depend
> only on their arguments, functional-style), which have session semantics and
> which of the ones that have session semantics should possibly not be
> re-evaluated. I'm not sure that opening this can of worms is worth the
> trouble.

Maybe a solution to avoid recomputing too much things (in number, and in taken
time to do that) would be to only compute the hash for "static" expansions --
the ones without parameters, where it's simply a copy/paste of text in multiple
spots.

If even that is not done/doable, then some error should be triggered when one
uses both the "cache" and the "noweb" header arguments. Because, in the current
situation, we think that the graphs (or, in a general way, the results) are
up-to-date while it's wrong -- you've changed some piece of code somewhere, and
the cached results are still used.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [Babel] [Bug] Cache

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

Achim Gratz <Stromeko@nexgo.de> writes:

> Eric Schulte writes:
>> In that thread we agreed that the expansion of no-web references
>> *should* be included in code blocks for hashing, but no-one has had the
>> time to implement this.
>
> I think we may have discussed this before, but if you make the hashes
> dependent on the possibly recursive noweb expansions

What is a recursive noweb expansion?  I think of the following, which
will cause errors in any situation.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: recursive.org --]
[-- Type: text/x-org, Size: 107 bytes --]

#+name: a
#+begin_src sh
  echo "hi <<b>>"
#+end_src

#+name: b
#+begin_src sh
  echo "hi <<a>>"
#+end_src

[-- Attachment #3: Type: text/plain, Size: 753 bytes --]


> this would require that all expansions be re-computed all the time or
> you would need to discern which of the expansions are "pure"
> (i.e. depend only on their arguments, functional-style), which have
> session semantics and which of the ones that have session semantics
> should possibly not be re-evaluated.  I'm not sure that opening this
> can of worms is worth the trouble.
>

I still (and I think this was my issue last time) don't see how noweb
expansions are more complicated than :var arguments.  That said I agree
that this is an edge case, and I certainly don't have time to make this
change (which you right could be complex) at the moment.

Best,

>
>
> Regards,
> Achim.

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D