| Time | Item | Who | Notes |
|---|
| 5 min | Interpreter status | | - Great progress being made on normalizer. Still need to handle bindings- we can sort the receives based on the channel. If reading from different channels, can put the channels in order. Should be able to sort the pattern, each has its own free variables.
- Intention is to sort the for's
- Kent submitted a PR for the sorts - needs Kyle to take a look. Used a score tree, rightward branching tree, has the score of the term and the score of the inside of the term to the right. Using the matcher pattern that Kyle also uses in the normalizer.
- Henry - He coming to terms with the design of the Tuplespace. Conceptual barrier of putting out the general purpose storage library versus something that is closely coupled with the Interpreter.
- Tuplespace is getting tightly bound to Rholang, but it could still be useful to release on it's own. Medha states that the priority is to delivery Mercury. A separate library is a nice to have.
- Henry would like type signatures for consume and produce.
- return type is continuation, which is returned based upon a match of the tuple.
- Shared data types and protobufs and code sharing.
- Plan is to implement CORE-174 and send to Kyle for code review.
|
| Node Code Status | Chris Kirkwood-Watts | - Doc review update (JSON API (RPC and Websocket))
- What has been built so far
- Not precisely compatible with what Lykka wants, but that is pretty far away.
- Moved comms main out to Node main - realized that it was hard to build.
|
| 10 min | Last meeting rolled over items | Timm Schäuble, Henry Till, Kyle Butt | - Update after meetings with folks on Storage and Tuplespace
- How does storage interact with multple VM's / Nodes in the future, 1:1 or 1: Many
- Need to dedicate 1 thread / queue (containing context) is the way to go. Timm is not sure that this would work. Synchronization would happen via com events.
- The transition function is completely re-entrant - that is Mike's understanding. If it isn't we need to figure out what it is. - Timm Schäuble Has an action item for this.
- Decision is not to implement multi-threading. Problem is how to sort out merge order for these threads.
- No multi-threaded engine. Can run many VM's - but each VM cannot run multiple threads. We will need to eventually fix this, lacks performance.
- How does the node come together? Primitives or Node Code that wraps it up. Notes from meeting below:
- Node code would start up the comms and storage and pass these to the VM? Seems reasonable? For example, upon startup, the VM was passed the location of storage, and the VM nows know about where it can be accessed.
- Mike thinks that Nodes should manage collections of VM's - deploying contracts, managing VM's, requesting a name to be registered. The individual VM's would then create storage objects if they need them.
- Use a FFI or primitives - VM would be responsible for hooking itself up to storage?
- Every time something goes through the tuplespace (aka a produce) - it logs whatever it gets, and pushes this out to the communications layer.
- Is something absorbing a log? Yes - something consumes the log and feeds it to the network and / or storage.
- replace table_add and table_get with a call that works with LMDB
|
| 10 min | What's Next for Node | Everyone | Target for the next release is March 15th. Interpreter Option - Kyle believes he can cut an SDK - we won't have a process matcher in that time. So some things will be possible in this SDK, others won't.
VM Option: - Can we write a primitive to send a message across the comms layer - and could the VM execute it - As soon as Transition is done, we could do something. Possibly done by end by March.
- Up next VM into the Node - write programs using opcodes that does something interesting and demonstrates the use of the comms and storage layer.
- Implement more Primitives - If we have primitives that can be invoked using ApplyPrim() - we can demonstrate many primitives even without boot.rbl.
|