Classic tangle/weave support a la org/babel-mode #119

Hello, I'd like to write something like my-app.html.pm and produce main.c and util.c for example, as well as my-app.html - I'm sure this is possible but to my surprise have not been able to find any mention of this on the web (I'm not happy with having to write main.poly.pm and utils.poly.pm, etc).

If anyone's done this I'd be delighted to see the implementation or if anyone can offer me a head start.

Something like ◊code[#:tangle "main.c"]{int main () {return 0;}} - extracting these is the easy part but I'm not sure what is the correct place to add the racket code to extract them and write the output files - template.html? Or perhaps add a root tag function to pollen.rkt? I guess either would work but I'm sure there's a 'right' way to achieve this.

In any case the above approach raises the concern that the pollen server will be oblivious to these side-effect files - but it would be nice if they appeared as per usual in the web listing (and what file generated them).

Thank you for this awesome project!

Hello, I'd like to write something like `my-app.html.pm` and produce `main.c` and `util.c` for example, as well as `my-app.html` - I'm sure this is possible but to my surprise have not been able to find any mention of this on the web (I'm not happy with having to write `main.poly.pm` and `utils.poly.pm`, etc). If anyone's done this I'd be delighted to see the implementation or if anyone can offer me a head start. Something like `◊code[#:tangle "main.c"]{int main () {return 0;}}` - extracting these is the easy part but I'm not sure what is the correct place to add the racket code to extract them and write the output files - `template.html`? Or perhaps add a `root` tag function to `pollen.rkt`? I guess either would work but I'm sure there's a 'right' way to achieve this. In any case the above approach raises the concern that the pollen server will be oblivious to these side-effect files - but it would be nice if they appeared as per usual in the web listing (and what file generated them). Thank you for this awesome project!

I’m not clear why you’re ruling out separate source files. I would make main.c.pp, utils.c.pp etc. and have them extract the appropriate code tags from my-app.html.pm (or wherever). Then it works well with the project server, and raco pollen render, and make, etc.

I’m not clear why you’re ruling out separate source files. I would make `main.c.pp`, `utils.c.pp` etc. and have them extract the appropriate `code` tags from `my-app.html.pm` (or wherever). Then it works well with the project server, and `raco pollen render`, and `make`, etc.

I see it as a step backwards or sideways - you wouldn't write object file templates by hand for every source file you may have; this is similar.

It's also less flexible and forces you to maintain two ends of the same process. Additionally I intend to inject the same, or slightly modified, code and comments into multiple output files - which means I would have to change the html.pm file and then also each c.pp that may be affected - it's the beginnings of a maintenance nightmare.

I foresee many more issues, but ultimately that's just not the way I want to do things, or how my brain works, and feels like a big handicap in my pursuit of literate programming nirvana.

But your suggestion, which I was blind to, is at least better than using poly files - an idea I hated because it forces my documentation to take on an unnatural form dictated by the code organisation.

Perhaps I can generate those .c.pp files from .html.pm - I think I've seen someone here asking about generating/splitting multiple .pm files from one? Seems reasonable/doable.

If that's possible then I guess it would solve everything and works the way the server expects. I could then use the pdf example to trigger compilation of those artifact .c.pp files whenever the .html.pm is compiled - or am I dreaming?

I see it as a step backwards or sideways - you wouldn't write object file templates by hand for every source file you may have; this is similar. It's also less flexible and forces you to maintain two ends of the same process. Additionally I intend to inject the same, or slightly modified, code and comments into multiple output files - which means I would have to change the html.pm file and then also each c.pp that may be affected - it's the beginnings of a maintenance nightmare. I foresee many more issues, but ultimately that's just not the way I want to do things, or how my brain works, and feels like a big handicap in my pursuit of literate programming nirvana. But your suggestion, which I was blind to, is at least better than using poly files - an idea I hated because it forces my documentation to take on an unnatural form dictated by the code organisation. Perhaps I can generate those .c.pp files from .html.pm - I think I've seen someone here asking about generating/splitting multiple .pm files from one? Seems reasonable/doable. If that's possible then I guess it would solve everything and works the way the server expects. I could then use the pdf example to trigger compilation of those artifact .c.pp files whenever the .html.pm is compiled - or am I dreaming?

Labels Milestones

Classic tangle/weave support a la org/babel-mode #119