The map and iter functions weren't replacing the graph if the input list
length changed. This was just an oversight in coding AFAICT, as the
sneaky case is that if the length stays the same, but the list contents
change, then it's okay to not swap.
This mega patch primarily introduces a new function engine. The main
reasons for this new engine are:
1) Massively improved performance with lock-contended graphs.
Certain large function graphs could have very high lock-contention which
turned out to be much slower than I would have liked. This new algorithm
happens to be basically lock-free, so that's another helpful
improvement.
2) Glitch-free function graphs.
The function graphs could "glitch" (an FRP term) which could be
undesirable in theory. In practice this was never really an issue, and
I've not explicitly guaranteed that the new graphs are provably
glitch-free, but in practice things are a lot more consistent.
3) Simpler graph shape.
The new graphs don't require the private channels. This makes
understanding the graphs a lot easier.
4) Branched graphs only run half.
Previously we would run two pure side of an if statement, and while this
was mostly meant as an early experiment, it stayed in for far too long
and now was the right time to remove this. This also means our graphs
are much smaller and more efficient too.
Note that this changed the function API slightly. Everything has been
ported. It's possible that we introduce a new API in the future, but it
is unexpected to cause removal of the two current APIs.
In addition, we finally split out the "schedule" aspect from
world.schedule(). The "pick me" aspects now happen in a separate
resource, rather than as a yucky side-effect in the function. This also
lets us more precisely choose when we're scheduled, and we can observe
without being chosen too.
As usual many thanks to Sam for helping through some of the algorithmic
graph shape issues!
Clear out lots of cruft and mistakes in this old API. The language GAPI
isn't updated with this commit, and as a result, this won't build, but
the fixes for it are coming shortly. We could have merged the two
commits, but it's easier to show them separately for clarity.
The nil type is being added, but only slightly. It is not meant for real
use in the language. It will not work in all situations, and it isn't
implemented for many methods.
It is being added only for being a "dummy" placeholder value in the
engine when we have an unused value being propagated along an edge.
We want the pattern to be key:0, val:0, key:1, val:1, and so on... This
was previously using 0,1,2,3...
When we use Call directly, we need to fix this. Previously this was dead
code which is why the bug wasn't caught.
This removes the secret channel from the call function. Having it made
it more complicated to write new function engines, and it's not clear
why it was even needed in the first place. It seems that even the
current generation of function engines work just fine without it.
Co-authored-by: Samuel Gélineau <gelisam@gmail.com>
We should consider if it's possible to avoid all of this transforming
entirely, but at least for now, do it all in one place by having an
available helper.
This started because it was possible, not because it was very useful.
The overhead of using the full function API, is lessened by the function
API helpers, and the upcoming improvements in the function API.
It's much easier to have one fewer API's to manage and so on.
It's also a stark reminder of how weak tools like "puppet" are which
only really have data collection systems that don't take arguments.
The provisioner should be able to encrypt things. We should use an empty
passphrase so that the choosing of the actual passphrase can be done at
first boot.
Could be used for any tool, but mgmt is an obvious possibility.
I should check this code more, but it's roughly right and I'm sure it
will get refactored more when I build opt-in provisioning and so on.
We should really be doing the math to find out how far along the string
each token really is, but that's complicated and tedious, especially
with the simplification passes, so let's skip that for now and just show
the whole thing.
This ports things to the new textarea. We need to plumb through things a
lot more, especially the string interpolation math to get the right
offsets everywhere, but that's coming.
Most things don't support this yet, but let's get in some initial
plumbing. It's always difficult to know which function failed, so we
need to start telling the users more precisely.
This should hopefully skip over any USB drives. Of course if we actually
want to provision to a USB drive, then we'll have to add a feature flag
for that.
