On Sun Feb 21, 2021 at 18:54 CET, Bakul Shah wrote: > On Feb 21, 2021, at 9:14 AM, Sebastien Binet <s...@sbinet.org> wrote: > > > > On Sun Feb 21, 2021 at 17:46 CET, Patrick wrote: > >> Hi Sebastien, > >> > >> that was a manual translation of the web file. > >> My plan was to do more than that, ... TeX is such a beast. > > > > yeah... "how hard would it be to translate ~20k lines of C/C++ code (or > > 6k lines of obfuscated Pascal code) into a set of nicely structured Go > > packages" ? :) > > > Aren't you supposed to read Knuth's TeX: The Program book instead of > the 6k lines of Pascal?!
of course, reading the thorough documentation is always a good thing. but why spend the time to re-write something that works from scratch instead of trying to to automatically, mecanically, translate it to some target? the way I see it, anyone who wants to have a TeX engine in language XYZ, has 3 broad choices: a) write from scratch, reading the TeX book documentation; this will produce a new engine that will have its own set of bugs, and can be called a "real" TeX engine only when it passes the "trip" test, b) write the tooling to translate the WEB "specification" into language XYZ (either directly from WEB, which, in the case of tex.web is a Pascal dialect, or from the already targeted languages: Pascal, C or C++) c) wrap the output of one of the already targeted languages in the desired language XYZ. I went with c) first as it seemed the best strategy to have something working, with the "full" pipeline enabled, allowing to have the usual "edit && go test ./..." refactor cycle at the ready. > > Also, I don't understand why anyone would want to do that. > > > > > my initial strategy to have something working in a mixture of Go and > > C/C++ (I am in the middle of getting rid of the C++ part), is OK to get > > some PDFs out of the gate, but I think I need to invest in the tooling > > to do the automatic web->Go translation. (either web->Pascal->Go or > > web->C->Go.) > > Doesn't web2c directly translate the web sources to C? yes. but it does so with a lot of global state, preventing the output to be (easily) used as a library. I figured the adiabatical migration from a C++ output to a C one and then to a pure-Go one would be easier (migrating each C++ class field to a C struct field, each C++ method to a C-struct+func one, etc...) - a process that could be done piece-wise, while still maintaining the "go test ./..." green light at each commit (instead of a big bang migration.) those were my assumptions and work hypotheses. I of course can't claim they will hold true for the complete process :) -s -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/oQ2sXkGAoNgPJMzbPBzoxzBokN6FcDhflIDb22DAnig%40cp4-web-034.plabs.ch.
