Joshy Orndorff JoshOrndorff

A project plan for Joshy's first 90 days with the RChain marketing team.

Deliverables

Rholang tutorial
- Intermediate skill-level audience
- Example motivated
- Includes exercises and questions
- Possible integration with rchain.cloud
Rnode installation and use videos
One overview of what RNode can do

RNode Log Message Guide

RNode version 0.6.4

The RNode software is quickly developing a reputation for being verbose. All that output is helpful for developers debugging and also for validators and node operators monitoring the health of their node. But it isn't valuable if you don't know how to read it.

Here I'll summarize the main interactions your node has, and translate the most common and useful log messages.

Starting up

At startup your node generates any necessary files that don't already exist, gets familiar with your network configuration, and reports some useful information about itself.

Rholang vs the Dining Philosophers

Rholang is frequently touted as a fully concurrent programming language. It will be blazing fast because it only executes things sequentially when absolutely necessary. It allows us to avoid resource starvations and thread deadlock. And it isn't even clunky or hard to use because all of this is uilt right into that concurrent computational model.

That's definitely the sexiest programming language I've ever heard of, but what does all of that actually mean? Let's investigate one of rholang's real-world benefits, inherent concurrency, in the context of a classic computer science problem known as "The Dining Philosophers".

The Problem Setting

Imagine two philosophers sitting across from each other on the east and west sies of a table. They each have a bowl of pasta, but there is only one set of silverware. The knife is on north, and the fork on the south. Everyone knows it takes both pieces of silverware to eat pasta, so no philosopher can eat until they have both uten

San Francisco Blockchain Week Review

Joshy Orndorff's reflections on RChain's presence at San Francisco Blockchain Week. Thoughts were written 13 October 2018 while the conference was still fresh on my mind.

What we did well

Gave a keynote speech
Ran a workshop
Had a booth
Represented technical (Joshy, Ned), community (Patrick), and investment (Reflective team) personnel

	module PI-SYNTAX
	imports DOMAINS

	// Processes
	syntax Proc ::= Norm // Normal processes are still processes
	\| Proc "\|" Proc // Parallel
	\| "!" Proc // Replication
	\| "(" "v" Id ")" Proc // New name
	\| "(" Proc ")" // Allow parens for grouping

	pragma solidity ^0.4.24;

	// WARNING: This code is intended for brainstorming purposes. No effort has been
	// made to use safe math, write tests, or pen test. I haven't really even
	// thought about function access.



	contract RHoursProject {

	new seq in {

	// Take a cons list of contracts, run them sequentially
	contract seq(@[head, tail], @ack) = {
	new return in {
	@head!(*return)
	\|
	for (_ <- return){
	seq!(tail, ack)
	}

	// When listening for data (or continuation) at a name, the returned
	// blockResults contain only blocks in which data was actually sent on
	// the specified name. HOWEVER, each block in the blockResults contains
	// a postBlockData which contains ALL previous sends on the name, not
	// only the sends in that block. This code demonstrates that behavior
	// by sending on the public name @"testChan" in blocks 1, 3, and 5, but
	// not in blocks 2, 4, and 6.
	//
	// Run this shit on a fresh node if you care about your sanity.
	//

	new stdout(`rho:io:stdout`) in {
	@"tenthCaller"!("Joshy", *stdout)
	}