there are currently issues with accessing the templates directly on the filesystem depending on whether or not we're running unit tests or running the program normally™ (and there is an ugly hack in place to determine that), the overall logic atm also assumes access to the templates at hardcoded places..
this all begs for a rework and the best I can come up with right now is to embed the template files directly into the binary at compile time. that way we can always access them, via some function of sorts, perhaps.
tmplSth could then be realised like this (notice the []byte to string conversion):
t,err:=tmpl.Parse(string(tmplSth))
there are currently issues with accessing the templates directly on the filesystem depending on whether or not we're running unit tests or running the program *normally™* (and there is an [ugly hack](https://git.dotya.ml/wanderer/math-optim/src/commit/496ddc191abe4dea9253069010bea30e70e7699e/report/pic.go#L49-L58) in place to determine that), the overall logic atm also assumes access to the templates at hardcoded places..
this all begs for a rework and the best I can come up with right now is to embed the template files directly into the binary at compile time. that way we can always access them, via some function of sorts, perhaps.
sth like this would do:
```go
...
import _ "embed"
//go:embed report/templates/<sth>.tmpl
var tmplSth []byte
...
```
`tmplSth` could then be realised like this (notice the []byte to string conversion):
```go
t, err := tmpl.Parse(string(tmplSth))
```
wanderer
added this to the v0.0.1 milestone 2022-07-16 22:28:33 +02:00
what's left for later is to rework the code-generating part to emitting stuff (report.tex) during runtime instead.
solved in https://git.dotya.ml/wanderer/math-optim/commit/7742642e14b0ba90e81310a43a5d3f73430ac773
what's left for later is to rework the code-generating part to emitting stuff (`report.tex`) during runtime instead.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
there are currently issues with accessing the templates directly on the filesystem depending on whether or not we're running unit tests or running the program normally™ (and there is an ugly hack in place to determine that), the overall logic atm also assumes access to the templates at hardcoded places..
this all begs for a rework and the best I can come up with right now is to embed the template files directly into the binary at compile time. that way we can always access them, via some function of sorts, perhaps.
sth like this would do:
tmplSthcould then be realised like this (notice the []byte to string conversion):partly solved in
446f63b59esolved in
7742642e14what's left for later is to rework the code-generating part to emitting stuff (
report.tex) during runtime instead.