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

How to use the Julia jupyter kernel to generate plots in output #53

Closed
00krishna opened this issue May 30, 2022 · 4 comments
Closed

How to use the Julia jupyter kernel to generate plots in output #53

00krishna opened this issue May 30, 2022 · 4 comments
Labels
bug Something isn't working

Comments

@00krishna
Copy link

00krishna commented May 30, 2022

I was trying to understand how to generate plots in a codebraid file with julia codeblocks. Julia has its own jupyter kernel, usually called IJulia.

Would something like this work, or does codebraid not yet support Julia jupyter kernels? Also, usually Julia jupyter kernels are attached to a Julia virtual environment. I think codebraid designed to pick the Julia environment that is in the same directory as the pandoc markdown file--as per the changelog and the addition of the --project=@. flag. So would this set then allow me to call the local IJulia jupyter kernel from the local Julia environment--as opposed to the global environment, etc.

I tried the following code:


```{.julia .cb-nb jupyter_kernel=julia session=random example=true}
using Plots
x = 1:10; y = rand(10); # These are the plotting data
plot(x, y)

While there are no errors, the file does not show the actual plot. I also attached the original file and the pdf.
julia_output.pdf
julia-braid-test.md

@gpoore
Copy link
Owner

gpoore commented May 30, 2022

There are a couple of issues. IJulia defaults to SVG output, which Codebraid currently ignores for display purposes. I can probably add support for that to the next release, which will be within the next few days. For now, you can use default(fmt = :png) or something similar to switch to a supported output format.

The other issue is that Starting kernel event loops. can appear at the start of the document whenever code runs, if you are writing your document to stdout or using Codebraid Preview. If you just rebuild the document (so the cache is used), this goes away. It looks like IJulia writes messages to stdout during startup. I don't know if there's a way to disable that. Otherwise I suppose Codebraid might be able to modify stdout during startup to capture the message.

@00krishna
Copy link
Author

Excellent. Okay, I set the default to :png and that seems to have worked. So that is really nice. Thanks for the tip on that.

I sometimes see that kernel event loops message when running codebraid. I just checked my test document and it did not seem to be a problem, but I will stay on the lookout for it. So the solution, as you say, is just to build the file twice--so that the cache is used. I will keep that in mind. I am hoping to use codebraid to take the pandoc markdown and process it for running in a Hugo blog. So I suppose I just have to instruct my build routine to always run all codebraid build twice--to make sure those extra comments are not in the final output.

gpoore added a commit that referenced this issue Jul 8, 2022
…ich output formats that are automatically displayed (#53)
@gpoore gpoore added the bug Something isn't working label Jul 8, 2022
@gpoore
Copy link
Owner

gpoore commented Jul 8, 2022

The dev version on GitHub now fixes a bug in creating SVG files and adds SVG to the formats that are automatically displayed. So SVG will work automatically by default now. It's working very nicely in Codebraid Preview. A new release with these features will be on PyPI in the next day or so.

For the case of creating PDF files, you may still want PNG, depending on how you are telling Pandoc to create the PDF and whether that method supports SVG images.

@gpoore
Copy link
Owner

gpoore commented Jul 8, 2022

The kernel event loops message issue should now be solved as well, so no extra steps or building twice should be needed in the future for Jupyter kernels that write messages to stdout or stderr.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants