Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Common evaluation of multiple code blocks #859

Closed
SimonCoste opened this issue Aug 3, 2021 · 3 comments
Closed

Common evaluation of multiple code blocks #859

SimonCoste opened this issue Aug 3, 2021 · 3 comments

Comments

@SimonCoste
Copy link

Hi, I have a question regarding code evaluation in franklin.

Suppose that I have two distinct code blocks, say

```julia:b1
f(x) = x^2
` ``

and

```julia:b2
g(x) = f(x) + 1
` ``

Franklin's code evaluation will create two script files in __site/assets/path/to/script/code/b1.jl and .../b2.jl, and so in my case, the second block will not compile because it needs access to the function f which is defined in the first script. To circumvent this, I use the following trick:

```julia:b2
include('__site/assets/path/to/script/code/b1.jl') #hide
g(x) = f(x) + 1
` ``

inside the second block, and I hide the include line. I find this not very elegant, and possibly clumsy if I have tens of code blocks with complex dependencies.

Is it possible to evaluate the code in different blocks, but in the same script (for example) ?

@tlienart
Copy link
Owner

tlienart commented Aug 3, 2021

Hello @SimonCoste

All code blocks on the same page are executed as if they were part of one big notebook and so, in particular, share scope. You can see this in the following short example:

julia> using Franklin
julia> s = """
```!
f(x) = x^2
```
some markdown
```!
g(x) = f(x)+1
g(2)
```
""" |> fd2html |> println

<pre><code class="language-julia">f&#40;x&#41; &#61; x^2</code></pre>
<pre><code class="plaintext code-output">f (generic function with 1 method)</code></pre>

<p>some markdown</p>

<pre><code class="language-julia">g&#40;x&#41; &#61; f&#40;x&#41;&#43;1
g&#40;2&#41;</code></pre>
<pre><code class="plaintext code-output">5</code></pre>

I added a few line returns to make it easier to see what's going on. As you can see, the second cell gets evaluated fine and shows its output (5).

Note: the shortcut with an exclamation mark is just for when you don't want to name code cells and say "just evaluate this and show the output immediately after". You don't have to use this, especially if you want to place the result somewhere else than immediately after.

Important corner case

At the moment Franklin's caching is a bit clumsy. So if you're running on the same page and doing stuff, it will generally be fine, but if you return to that page and had defined your b1 cell and then add a new b2 cell afterwards, Franklin will not re-evaluate the first cell and therefore f is not in the current scope.

If this seems silly, I'm working on it right now and it should be fixed soon but it's part of some significant (and non trivial) refactoring.

One way to avoid this is to mark a page as "re-eval everything each time" by adding the page variable reeval = true, with that the problem will never appear. Copy-pastable example:

julia> s = raw"""
       +++
       reeval = true
       +++

       Some markdown

       ```julia:b1
       f(x) = x^2
       ```

       some markdown

       ```julia:b2
       g(x) = f(x) + 1
       @show g(2)
       ```

       And the result: \textoutput{b2}
       """ |> fd2html |> println
→ evaluating code [b2] in (index.md)
<p>Some markdown</p>
<pre><code class="language-julia">f&#40;x&#41; &#61; x^2</code></pre>
<p>some markdown</p>
<pre><code class="language-julia">g&#40;x&#41; &#61; f&#40;x&#41; &#43; 1
@show g&#40;2&#41;</code></pre>
<p>And the result: g&#40;2&#41; &#61; 5</p>

the only reason why you would not want to use that everywhere is that it slows down the processing of a page (since you evaluate all code cells, every time, even when you don't change the code). What I sometimes do is toggle it on and off when I see stuff go stale and some cell failing.

@SimonCoste
Copy link
Author

Bonjour Thibaut,
thanks so much ! I think my problem is exactly the one you mentioned in the "corner case", where I had defined cells and then later added other cells with dependencies.
The reeval=true trick is very nice, I'll use it now and then.
Thank you very much !

@tlienart
Copy link
Owner

tlienart commented Aug 3, 2021

Avec plaisir, et ca m'a fait plaisir de découvrir dataflowr en passant ;-)

@tlienart tlienart closed this as completed Aug 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants