Thanks @dpsanders, I am working on an extension example for my research, hopefully it will work out well
@ChrisRackauckas has made a very good connection in the comments, feel free to add another comment if you have an extension in mind, always good to learn new interesting stuff! Appreciate your feedback.
I just meant to show how to use exponential random variables in continuous time. At least the version I saw didn’t have a code example for that.
Got it, I thought it would pollute the grand finale, I prefer to leave the mystery
1 Like
Thanks @ChrisRackauckas, submitted the feed to juliabloggers.com just now.
@juliohm I would use the methods suggested by @Tamas_Papp above to work with Jekyll. It does mean you need come up with a separate Makefile for jmd
s so it’s not ideal.
Also it doesn’t look too hard to write your own Converter for Jekyll Plugins | Jekyll • Simple, blog-aware, static sites. You could e.g. write out the content to a temp file, run weave and read the converted contents back to Jekyll.
Given that the weaving is the most costly step, and woven files tend to be static after that, I prefer to keep it manual.
@mpastell, my main concern with writing a converter is that it will rely on Weave.jl and won’t build on GitHub pages, correct?
Correct. You’d need to run Jekyll locally and commit the build.
No, it is not. It just has stuffed a lot of dust under the rug
Also, not that.
Output (and everything else) is generated in any post tagged jupyer-notebook.
My solution is actually pretty convoluted and gross,
is kind of a variation on what @ChrisRackauckas does,
to generate blog posts from Jupyter Notebooks.
I uses the script that is in https://github.com/oxinabox/oxinabox.github.io/tree/master/scripts/jupyter to generate the posts.
It uses a custom nbconverter config, including a custom template (in nbconvert fashion using Jinja2).
I can no longer recall the difference between defining your own nbconverted config+template,
and defining your own converter for notebook-> jekyll
This then generates the Jekyll posts, which include the liquid templating for Highlighting.
I hoped that I could get Kramdown to do the highlighting which would have made:
```julia
#code here
blocks work.
But I could not, so I had to use the [Jekyll/Liquid way](https://jekyllrb.com/docs/templates/#code-snippet-highlighting), with the
{% highlight julia %}
#code here
{% endhighlight %}
Which I think is worse.
The truely painful stuff was not in getting highlighting to work, it was in getting the Images in the output working.
I learnt a new level of hatred for nbconvert and jekyll that day.
1 Like
@oxinabox so Jekyll and Julia will never play well? What should we do about this issue?
What’s the problem with running Weave locally and pushing generated markdown to gh pages? I could add a Jekyll formatter to use {% highlight julia %}
for code and correct figure paths for output.
I don’t use Jekyll myself so I’d appreciate if you opened an issue of whats missing.
juliohm
@oxinabox so Jekyll and Julia will never play well? What should we do about this issue?
Problem is, I am concluding, jekyll is just not a great platform.
And nor is Jupyter.
They are both merely better than other things for various reasons.
You can make them both work,
but nothing is loverly about doing.
Merely, possible.
mpastell
What’s the problem with running Weave locally and pushing generated markdown to gh pages?
I see nothing wrong with this plan.
1 Like
@mpastell could you please elaborate on how this is done with a simple example?
I set a simple example repo that should get you started, see: https://github.com/mpastell/weave-ghpages-sample . Let me know if something is not clear.
4 Likes
Thank you @mpastell, that is awesome, I will look into the repo for future posts, just released a new one where I copy the Julia output manually again:
Update: Weave.jl now works with Hugo (thanks @mpastell!) This blog post has links to the source of my blog if someone wants to implement this setup.
3 Likes
I’m a bit late to this party, but I’m currently using http://prismjs.com/ which can be used in a bunch of different platforms.