ARC transilable async/promise based IO

[HLWeil]

• Added CrossAsync type which acts as an interface for Async in DotNET/Python and Promise in Javascript
• Added base layer of crossAsync IO helper functions
  • Python functions are put directly into the F# source code using Fables emit logic
  • Javascript functions are put into a js source file and called using Fables import logic
    • This is a future to-do, but too much of a time-eater now and the core functionality is stable enough IMO
• Added layer of crossAsync Contract handling functions
• Added top-level crossAsync ARC IO functions
• Added top-level synchronous ARC IO functions, only for dotNET and Python as Javascript is difficult to synchronize

[Freymaurer]

No pypackage reference for femto?

[HLWeil]

We're not using femot at all. Would be a to-do for the future

[Freymaurer]

Femto is for the people installing ARCtrl as it installs nuget and native dependencies.

We did it for the npm dependencies so i thought i make you aware of this

[Freymaurer]

duplicate namespace

[Freymaurer]

So we keep one minimal arc in version control for testing?

Could we not write it first and therefore test correct writing too?

Then we could ommit the ARC from version control

[Freymaurer]

Some brainstorming: Maybe git-submodul the example arc from gitlab? So we can ensure being compatible with the example?

[kMutagene]

Maybe git-submodul the example arc from gitlab?

This is what we do in the integration tests for arc validation packages, see submodule here, action that pulls submodules in CI here and tests if submodules are there here
(obviously, the test fixtures must be translated into pyxpecto, i don't know if it has that functionality)

[HLWeil]

Yep, using the Prototype ARC would be the best solution.

Only using the ARCs written with the library might leave a blind spot for this case.

[Freymaurer]

Is this rick roll?

[Freymaurer]

Actually not! Now i am surprised :D