| Time | Item | Who | Notes |
|---|
| 10 min | Interpreter status - what features will be ready for 3/15 | | - Open work items, integration of storage layer with Interpreter, namely when do we swap rholangADT.scala for protobuf-generated code.
- Once he gets enough of the normalizing - will have to happen next sprint.
- Needs visibility on what is working on the storage layer
- Henry Till - Implementing the tuplespace in Scala. Working off Kent's python's example.
- Yaraslau and Eitan need to get in sync and in touch with one another. There is a dependency on the matching algorithm.
- Integration testing
- On track for 3/15 or ?
|
| 10 min | Node Status - what features will be ready for 3/15 | Chris Kirkwood-Watts | - Working through https service with Henry.
- Dependent on what the other teams can deliver. Everything else is solved.
- Docker
|
| 10 min | VM - Status and review Plan 'C' | Timm Schäuble | - Talk through plan to implement multi-threading - Need to talk to Greg about multi-threading.
- Talk through plan to stop the translation with the transition function + primitives.
- Outcome - no plan C - we rely on RBL libraries in order to get the VM functioning.
- Timm is going to send Greg a note to figure out multi-threading.
- Timm to go learn about the compiler.
|
| 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.
| |
| 5 min | Depencies Discussion |
| - Lay out any dependencies that you may have on other teams work.
- Storage -Interpreter on matching - Yaraslau & Eitan need to work together.
|
| 10 min | Node.Void Release | EveryoneWhat comes after Node.Hello: Node API for Communications Node.Void→ Node Application Layer & Start of Node API→ Mid March (Chris is out next week) Start and Stop the VMStart and Stop comms libraryRun interpreter? Depends on what can be deliveredTail Logs - we are not going to offer logs - please confirm.Start and stop emitting metrics | - Storage is a library consumed by the interpreter. No access to the storage tier.
- Kyle wants to have a well defined api & some matching code.
- Dependency graph - demonstrate storage is functioning.
- Kyle doesn't feel comfortable that he will be ready by the end of the next sprint with matching.
- Wants to see Joe's interpreter churn through and provide a result.
- No integration testing done with storage & interpreter. - This piece was not properly budgeted.
- Storage API has a slightly different shape for produce & consume- proposal is in the specification.
Target for the next release is March 15th29th. Cut packages on March 12th 26th - Asking for additional sprint for integration testing, Storage.01 timeline is unchanged. 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.
- Goal is to offer the same functionality as the SDK 0.1 release. He doesn't want to release if the interpreter is a step backwards from the SDK 0.1
|