Consider making a version of gomacro more portable

[morangorin]

Problem:

1. gomacro does not compile on a raspberry pi (the compiler runs out of memory) which is problematic when using gomacro with native libraries (because cross-compiling with cgo is not straightforward). (on a positive note, gomacro does run on a raspberry using cross-compiling, which is great... but plugins do not seem to be supported)
2. gomacro cannot be used with google app engine because it uses the unsafe package

Question: would it be possible to have a smaller and simpler version of gomacro ? (perhaps at the cost of performance and/or features ?)

[cosmos72]

Two very relevant questions, that I already pondered in the past. Thanks for asking them :) They are quite different, so let me answer to 1. here, while I answer to 2. in #43:

The main problem with compiling gomacro natively on low-memory systems, as Raspberry Pi, is the gomacro/imports/syscall and the gomacro/fast packages. The first links all symbols from the syscall package, and current Go compilers need a huge amount of RAM (~1GB) to compile it. The second is the interpreter itself, and compiling it eats ~1GB too. I routinely compile gomacro on Odroid C2, an ARM64 board with 2GB RAM running Linux, and it works flawlessly both in 32bit and 64bit flavors. If you can, I think adding 1GB+ swap to the Raspberry Pi and being (very) patient should be enough to compile gomacro natively.

An alternative is trying to reduce the amount of RAM required to compile it: quite straightforward for the gomacro/imports/syscall package - just split the huge init() function into a lot of small functions - but much harder for the gomacro/fast package.

Another alternative is to use the older, much slower and much smaller gomacro/classic interpreter instead of gomacro/fast: it currently misses a command-line REPL, but it's basically a matter of duplicating gomacro/cmd and replacing the calls to fast interpreter with calls to the classic one. If you are willing to work on this, I will happily accept it as a contribution.

[morangorin]

Thank you for the quick answer. I am using my own REPL and I did not realize that I could switch from the fast interpreter to the classic one. Except for speed, is there any feature that the classic interpreter is missing?

[cosmos72]

Yes, I just documented the limitations in gomacro/classic/README.md. They are, in summary:

• untyped constants and arithmetic on them, as 1<<100, are evaluated as typed constants.
• types are not accurate when mixing untyped constants with typed values, i.e. uint8(10) + 1 gives uint64(11) instead of uint8(11).
• interpreted interfaces are not functional (they can only be declared).
• interpreted types cannot implement compiled interfaces.
• struct tags are ignored.
• support for embedded fields in structs is very limited - they mostly work as non-embedded fields.

Plus it also has the limitations of the fast interpreter listed in gomacro/doc/features-and-limitations.md