iterative contract development vs. persistent tuplestore?
I'm working on a takeTurn contract. I eval'd it takeTurn.rho once. Then I fixed a bug. Now what do I do? The solution I came up with was to rename it each time: contract @"takeTurn2", contract @"takeTurn3" and so on. The tuple store dumps grew and grew.
Surely there's a better way.
Do folks stop their node and delete something from /var/lib/rnode? If so, which part? I tried deleting the rspace subdir; no joy.
The short answer here is that the node repl is a terrible environment for iterative development. In order to clear the tuplespace you need to shutdown the node and then delete the entire rspace sub-directory in whatever data_dir you are using before rebooting. Because of the memory mapping that is done in LMDB deleting the files before the node shuts down will not clear the tuplespace. A slightly easier approach is to restart the node with a whole new data_dir each time and then delete them all when you're finished.
The machinery to make the repl a much better iterative development exists, it would just need to be leveraged for this purpose. Essentially the idea would be to use the checkpoint/reset functionality already in rspace and simply expose it to the repl. Perhaps something like :checkpoint to save the current state and then :reset to return to the last checkpoint. Even better would be if you could optionally provide names to your checkpoints and reset back and forth between different tuplespace states. Maybe you could file a feature request for this.
Personally, I have been doing my rholang development in the scala repl lately because I find it to be a little more lightweight than having the full node running. If you are comfortable with sbt and know some Scala then you could take a look at TestSetUtil.