How to get source printing from `include()`

Hi guys,

I have a problem that I’m unable to solve. I’m tried any trick with no results.
I’m writing a lot of Julia snippets (function definitions and unit tests) embedded in a book draft.

Therefore, I write small files loaded into the XeLaTeX sources using the beautiful julia-mono-listings package. Each snippet is loaded to book using the \lstinputlisting{filename} command, and this works perfectly.

The problem: I would like a single copy of Julia codes, of course, and all the snippets are loaded in REPL via the include command. But this one gives no feedback about the loaded sources.
Hence it is not possible to get an adjacent easy view of sources in each chapter … Such view is strongly needed to make well designed changes and debug.

I would like to avoid maintaining two copies of sources … !!
In synthesis, how to get source printing from include command? No clue on the manual.
Thank you for help!

What does this mean exactly? Why/when these codes are loaded in the REPL?

Anyway, probably a good alternative is to put all code into a package, and include all of it in the package module.

By keeping each piece of code in a file you can still reference them from the latex code.

I don’t understand either, my question is what you’re doing with 2 copies, what source printing is (printing the source code during include?) and how it would help. From your post, it sounds like you only have 1 copy and you either \lstinputlisting the text into a LaTeX document or include the code into a REPL session. What does “not possible to get an adjacent easy view” mean, it sounds like looking at the source code while you interact with the REPL, but that can’t be because that’s easy to do.

In short, I write code snippets for inclusion in a book (extensive document – more than 500 pages), but when I modify, evaluate, or debug one of them in REPL, I lack an ensemble view to reason about.
The apparent action is writing them all within the same package or file (one per chapter). But that means having and maintaining double copies of code. Small snippet files and one or more big source files. Hope to be clear

You can include the snippets into the book directly from the package code, if each snipped is in a different file.

Your solution does not change the situation.
Suppose 500 snippet files, all included by file name in the package main (or with hierarchical include). The lack of ensemble view of each subsystem remain if there is no source display feedback.

Conversely, if while evaluating the include() commands for a subsystem or module, it would display the corresponding sources, you may get the desired cue about what you have to design, fix or modify.

Must all these snippets of a chapter be run in order in the same session, as in snippet #8 will not work if you didn’t run snippets #1-#7?

In general, yes

IIUC, you write a book and include a lot of Julia snippets. Each snippet is in a single file. To debug them you want them all together in a single file to make running them in the REPL but you need to know which file to edit in case of errors.

Suppose you have each snippet in a folder and named like “snippet-xx.jl”, you could simply write a small script that concatenates all the snippets and include their respective filename as a comment in between. Then you can debug with that file. If you find an error you’ll know which file to edit, make the edits in the snippet file and rerun your concatenation (possibly automated).

In principle you could also write a reverse function that updates your individual snippet files when you make changes to the merged file. You’d just need to go through the file line-by-line and everytime you encounter a comment of a specific structure change the file you copy the code to.

You understand perfectly my problem and gave a good solution.

Actually, I supposed to need a procedure like this, but was hoping to get a similar tool already working in Julia, in particular as an option to include, so to be able to use only a list of include()s as automation tool.
But anyway, your suggestion looks working, even if requires: (a) opening by hand the snippet in error; (b) possibly some other before it; (c) fix/change where required.
The useful aspect of your solution is that copy-back of corrections to the whole hosting file is not required, and an ensemble view is available.

Thank you all for your help!