Paul Guyot

> My question still holds: "... why would we need an option for this? If cache is working [from your PR onward] and makes building faster and more consistent, shouldn't...

> i.e. why would https://github.com/erlef/setup-beam/pull/156/files#diff-1243c5424efaaa19bd8e813c5e6f6da46316e63761421b3e5f5c8ced9a36e6b6R36 be required as an option. Do you foresee a case where not using the cache, as you propose, would be better? This uses some space...

> I think we all agree that the action could/should cache the elements it depends on, but stuff like PLTs, consumer-specific dependencies, etc. should not be included (which is what...

> Also, it seems one of the tests is failing. Yes, this is flappy, this is the rationale for this PR to establish caching or set a mirror to ensure...

> > because the entry was also cached in parallel from repo.hex.pm > > If a job fails the cache is not created. I assume here you're saying that those...

> > Yes, this is flappy > > I understand this might happen in consumers of the action, but the action tests should never fail; the knowledge of "having to...

Also `term_is_number` (can't comment on the line)

We should do what you suggest (implementing the way ourselves with stdio_usb_connected()) and advertise the feature as it's very useful for development. @fadushin also shared this link that may be...

armel build is currently broken. See https://github.com/atomvm/AtomVM/pull/644 for a renewed approach to this using docker images instead of debian bootstrap.

> This approach is one of the 2 I was thinking about. The other was offloading x regs > to a linked list, which is very slow, but it might...