Aaron Ecay aarone...@gmail.com writes:
Hi Eric,
2013ko martxoak 23an, Eric Schulte-ek idatzi zuen:
Unless you actually try :var and find it lacking in some way, I'd prefer
to stick with simply using :var to identify dependencies between code
blocks. We've seen in other places how
Hi Eric,
2013ko martxoak 23an, Eric Schulte-ek idatzi zuen:
Unless you actually try :var and find it lacking in some way, I'd prefer
to stick with simply using :var to identify dependencies between code
blocks. We've seen in other places how providing multiple alias for
header arguments
Aaron Ecay aarone...@gmail.com writes:
Hi Eric,
I’m jointly replying to 2 of your emails.
2013ko martxoak 13an, Eric Schulte-ek idatzi zuen:
This is what is already taking place. The :var header arguments are
automatically expanded into dependencies between code blocks, and the
results
Hi Eric,
I’m jointly replying to 2 of your emails.
2013ko martxoak 13an, Eric Schulte-ek idatzi zuen:
This is what is already taking place. The :var header arguments are
automatically expanded into dependencies between code blocks, and the
results of previous code blocks are included in the
Achim Gratz strom...@nexgo.de writes:
Eric Schulte writes:
From re-looking at Achim's previous noweb example, it seems that we
currently do *not* include the values of noweb expansions in code block
hash calculations, I think this is a bug which should be fixed.
It could very well have been
Aaron Ecay writes:
I think this points in the direction of having the notion of
dependencies among source blocks.
[...]
I know nothing about knitr, but the problem at hand is both well studied
and has numerous solutions[*]. That is, once we've decided on what the
execution model is.
[*] Not
Aaron Ecay aarone...@gmail.com writes:
Hi Eric,
2013ko martxoak 9an, Eric Schulte-ek idatzi zuen:
Could something like the following work? Removing :results none and
adding something small as the returned result which may easily be parsed
and placed in the buffer w/o problem.
Aaron Ecay aarone...@gmail.com writes:
Hi Achim,
2013ko martxoak 10an, Achim Gratz-ek idatzi zuen:
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
Eric Schulte writes:
From re-looking at Achim's previous noweb example, it seems that we
currently do *not* include the values of noweb expansions in code block
hash calculations, I think this is a bug which should be fixed.
It could very well have been a conscious decision, given that this
Hi Eric,
2013ko martxoak 9an, Eric Schulte-ek idatzi zuen:
Could something like the following work? Removing :results none and
adding something small as the returned result which may easily be parsed
and placed in the buffer w/o problem.
#+begin_src R :cache yes
# code to
Hi Achim,
2013ko martxoak 10an, Achim Gratz-ek idatzi zuen:
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. See the
example below where after the
Eric Schulte writes:
A hash marks a *result* with an indication of what was used to generate
it (code block parameters). The point of a hash is to allow the
result to be returned without having to re-execute. For this reason, I
think that the hash should live with the result.
Here Babel is
Achim, Eric,
Achim Gratz wrote:
Eric Schulte writes:
A hash marks a *result* with an indication of what was used to generate
it (code block parameters). The point of a hash is to allow the
result to be returned without having to re-execute. For this reason, I
think that the hash should
Sebastien Vauban writes:
A more general question: shouldn't cache be unusable (generate an
error) when there is a session? In the presence of a session, I've
the impression that caching results is always wrong. Who knows its
contents before executing the code, in the next Emacs session?
That
aarone...@gmail.com writes:
2013ko martxoak 8an, Eric Schulte-ek idatzi zuen:
I would agree. I don't believe *any* changes should take place in the
buffer when a code block is executed with :results none.
A common use case for me is to use a babel block to load a large dataset
into R. I
Achim Gratz strom...@nexgo.de writes:
Eric Schulte writes:
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
That's not what I'm seeing, but I may be missing
2013ko martxoak 9an, Eric Schulte-ek idatzi zuen:
Maybe a better solution would be to add a feature to avoid echoing
very large results to the minibuffer. It should be very
straightforward to add a user customizable variable (e.g.,
`org-babel-max-echo-length' or somesuch) which limits the
2013ko martxoak 9an, Eric Schulte-ek idatzi zuen:
A hash marks a *result* with an indication of what was used to generate
it (code block parameters). The point of a hash is to allow the
result to be returned without having to re-execute. For this reason, I
think that the hash should live
Eric Schulte writes:
Ah, my fault for not completely reading and understanding your previous
post. I'm currently working on a set of patches with Achim which should
(I believe) resolve this issue.
It doesn't yet, but I#ll add another patch to rename this binding.
IIRC, the naming was so that
As I understand this particular case, the OP is using a hash not to mark
a result as up to date, but rather to mark a side effect (loading data
into R) as having taken place. I think this is a misuse of a cache.
It depends on whether one looks at a cache as “a place to store results”
or
On Tue, Mar 5, 2013 at 11:07 PM, Aaron Ecay aarone...@gmail.com wrote:
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
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
Achim Gratz strom...@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
Aaron Ecay aarone...@gmail.com writes:
On Tue, Mar 5, 2013 at 11:07 PM, Aaron Ecay aarone...@gmail.com wrote:
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.
2013ko martxoak 8an, Eric Schulte-ek idatzi zuen:
I would agree. I don't believe *any* changes should take place in the
buffer when a code block is executed with :results none.
A common use case for me is to use a babel block to load a large dataset
into R. I want this to be cached, in the
Eric Schulte writes:
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
That's not what I'm seeing, but I may be missing something again. The
hash is for the
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.
---
lisp/ob-core.el | 5 -
27 matches
Mail list logo
