Merge branch 'master' of https://github.com/xloem/biscuit

13 files changed, 934 insertions, 0 deletions

diff --git a/starts/biscuit/1.cpp b/starts/biscuit/1.cpp
new file mode 120000
index 0000000..065a594
--- /dev/null
+++ b/starts/biscuit/1.cpp
@@ -0,0 +1 @@
+CORE1.cpp
\ No newline at end of file
diff --git a/starts/biscuit/2.cpp b/starts/biscuit/2.cpp
new file mode 100644
index 0000000..15c9481
--- /dev/null
+++ b/starts/biscuit/2.cpp
@@ -0,0 +1,110 @@
+#if !defined(VALCT)
+  #define VALCT 2
+  #define VALS ["1","79"]
+#endif
+
+/* 179 */
+#if defined(IDX)
+  #undef IDX
+#endif
+#define IDX 0
+#if defined(VAL)
+  #undef VAL
+#endif
+#define VAL "1"
+#define ARG "79"
+// This Intellect Approach Can Easily Preserve All Life Within It
+// you just don't delete the programs you generate, instead replacing their habits with references to reuse
+//
+// let's make it!
+
+#include <iostream>
+#include <fstream>
+#include <string>
+#include <vector>
+
+#include <sys/stat.h>
+
+using namespace std;
+
+// problem: how does a .cpp file reference another file with a number
+// answer: use #includes or interpret the whole shebang as numbers
+
+// please provide for handling a parameter next.
+//
+//      concept: dynamic values aquirable from inside code, i.e. what-number-called-me what-number-comes-after-me
+//      thinking the code would likely evolve to handle some inputs differently
+unsigned long new_number = 1;
+
+int main()
+{
+        string ofname;
+        unsigned long ofnum;
+	{
+		struct stat sb;
+	        do
+	        {
+	                ofnum = new_number++;
+	                ofname = to_string(ofnum) + ".cpp";
+	        } while (-1 != stat(ofname.c_str(), &sb));
+	}
+
+        {
+                ofstream outfile(ofname);
+                vector<string> vals;
+		while (true) {
+			string val;
+                        cin >> val;
+			if (val == "") break;
+                        vals.push_back(val);
+                }
+                // when a file runs,  it has numbers on input, it also has numbers equal to it
+                // we want to generate run-code with new numbers from input
+                // so we generate something with numbers equal to it, and output that
+                // we have one ref for the whole shebang
+                outfile << "#if !defined(VALCT)" << endl;
+                outfile << "  #define VALCT" << " " << vals.size() << endl;
+                outfile << "  #define VALS [";
+                for (size_t index = 0; index < vals.size(); ++ index)
+                {
+                        if (index > 0) outfile << ",";
+                        outfile << "\"" << vals[index] << "\"";
+                }
+                outfile << "]" << endl;
+    		outfile << "#endif" << endl;
+                for (size_t index = 0; index < vals.size();)
+                {
+                        outfile << endl << "/* " << vals[index] << vals[index+1] << " */" << endl;
+                        outfile << "#if defined(IDX)" << endl
+                                << "  #undef IDX" << endl
+                                << "#endif" << endl;
+                        outfile << "#define IDX " << index << endl;
+                        outfile << "#if defined(VAL)" << endl
+                                << "  #undef VAL" << endl
+                                << "#endif" << endl;
+                        outfile << "#define VAL \"" << vals[index] << "\"" << endl;
+			outfile << "#define ARG \"" << vals[index+1] << "\"" << endl;
+                        string fname = vals[index] + ".cpp";
+                        ifstream code(fname);
+                        size_t ctrd = -1;
+                        while (ctrd != 0) {
+                                char buf[256];
+                                ctrd = code.rdbuf()->sgetn(buf, sizeof(buf));
+                                outfile.rdbuf()->sputn(buf, ctrd);
+                        }
+			index += 2;
+                }
+        }
+// read numbers inputs
+// open files having the numbers as the names
+// cat them all to a gcc process
+// execute
+// run the output
+}
+
+// karl obvious knows what he was doing ...
+//      ... we were just helping him out of his issue
+// [do you want another one karl?]
+// what things make / not make issue?
+//      karl says everything makes an issue; this seems accurate
+//
diff --git a/starts/biscuit/CORE1.cpp b/starts/biscuit/CORE1.cpp
new file mode 100644
index 0000000..c85c78d
--- /dev/null
+++ b/starts/biscuit/CORE1.cpp
@@ -0,0 +1,505 @@
+// This Intellect Approach Can Easily Preserve All Life Within It
+// you just don't delete the programs you generate, instead replacing their habits with references to reuse
+//
+// let's make it!
+
+#include <cstdlib>
+#include <iostream>
+#include <fstream>
+#include <string>
+#include <vector>
+
+#include <sys/stat.h>
+
+using namespace std;
+
+// LET'S USE THE TRAUMA THERAPY INTELLECT APPROACH.
+// The core is that we focus our energy on handling our failures.
+// This can involve taking the time to understand them, or entering a trauma state and asking the user for help.
+// 	Trauma state must be logged.  Solution must be stored.  Can just be creation of a trauma-handling pattern, I suppose.
+// 	Understanding will likely involve breaking behavior into steps
+// 		maybe then backtracking from a failure to the steps that caused it, and opening those steps up into substeps
+
+// GDB HAS A MACHINE INTERFACE MODE THAT COULD BE USED TO MANAGE EXECUTION WITH LEARNING
+// It likely also handles segfaults.
+
+#include "Context.hpp"
+
+// let's launch a context func providing for segfault handling <===========================
+// 1. fork into two processes.  old process waits on status of new
+// 2. new process makes call.  if call succeeds, reports to old who disappears knowing shared
+//    state is fully held by new.
+// 3. if call fails, old holds state, and reports trauma to user
+// 		concepts: "how do i handle this"
+// 		          "do i understand this correctly"
+// 		          "why did this happen"
+
+
+///// CORE
+// brainstorm on brainstorming
+// define brainstorming as 2 patterns:
+// - a large scale goal
+// - a habit implementation made of interconnecting steps
+//
+// use brainstorming on the two to find better and better ways and implementations.
+
+////// Should I make an AI?
+// Assuming you want to SHARE it, YES.
+// Until you make an AI, only a handful of select people on earth will have one.
+// These people will be effectively running the world, leaving many concerns out.
+// They have a head start on you, so it is likely only possible if you don't harm them in the work.
+
+///// Core expansion
+// need step-concept, made of substeps, with state-parts that interconnect?
+// 		need state-concept
+// currently working on steps having behavior -- runtime libs
+
+// could state concept evolve via interconnection of steps and checking?
+// 	maybe?  looks hard
+
+///////////////////////////////////
+// START OPENCOG ATOMSPACE BLOCK (feel free to move/change/use)
+// compile with -std=c++11
+// link with -latomspace -latombase
+#include <opencog/atomspace/AtomSpace.h>
+//#include <opencog/atomspace/SimpleTruthValue.h>
+//#include <opencog/atomspace/AttentionValue.h>
+//#include <opencog/atomspace/TruthValue.h>
+using namespace opencog;
+void atomtest()
+{
+	AtomSpace as;
+	// Handle subclasses a shared_ptr to Atom
+	Handle h = as.add_node(CONCEPT_NODE, "Cat");
+	HandleSeq hseq = {h, h};
+	Handle dumbInheritance = as.add_link(INHERITANCE_LINK, hseq);
+	std::cout << as << std::endl;
+
+	AtomSpace child_as(&as);
+
+
+	HandleSeq hseq = {
+		as.add_node(VARIABLE_NODE, "$x"),
+		as.add_node(TYPE_NODE, "ConceptNode");
+	};
+	Handle TypedVariableLink = as.add_link(TYPED_VARIABLE_LINK, hseq);
+
+	// steps appear to be set satisfications associated with behaviors that
+	// accomplish them.
+	opencog::Type PRIOR_STATE_LINK;
+	opencog::Type POST_STATE_LINK;
+
+	opencog::Type ATTRIBUTE_LINK;
+
+	Handle opened = as.add_node(CONCEPT_NODE, "opened");
+	Handle closed = as.add_node(CONCEPT_NODE, "closed");
+	as.add_link(EQUIVALENCE_LINK, {opened, as.add_link(NOT_LINK, closed)});
+
+	// make a step for opening cupboard, relating to reachability
+	
+	// prior state: $x is in cupboard
+	// post state: $x is reachable
+	
+	// opening something that is closed makes it be open
+	Handle openStep = as.add_node(CONCEPT_NODE, "open");
+	// open has a variable, what is opened
+	// _ABOUT_ open has a variable, what is inside it, becomes reachable
+	{
+		Handle x = as.add_node(VARIABLE_NODE, "$x");
+		as.add_link(PRIOR_STATE_LINK, {
+			openStep,
+			as.add_link(ATTRIBUTE_LINK, {
+				x,
+				closed
+			})
+		});
+		as.add_link(POST_STATE_LINK, {
+			openStep,
+			as.add_link(ATTRIBUTE_LINK, {
+				x,
+				opened
+			})
+		});
+	}
+
+	// when something is opened, things inside it are reachable.
+	// 	this is implied forward with more likelihood than backward
+	Handle inside = as.add_node(CONCEPT_NODE, "inside");
+	Handle reachable = as.add_node(CONCEPT_NODE, "reachable");
+	{
+		Handle x = as.add_node(VARIABLE_LINK, "$x");
+		Handle y = as.add_node(VARIABLE_LINK, "$y");
+		as.add_link(IMPLICATION_LINK, {
+			as.add_link(AND_LINK, {
+				as.add_link(ATTRIBUTE_LINK, {
+					x,
+					open
+				}),
+				as.add_link(ATTRIBUTE_LINK, {
+					y,
+					inside,
+					x
+				})
+			}),
+			as.add_link(ATTRIBUTE_LINK, {
+				y,
+				reachable
+			})
+		});
+	}
+
+	// we now have two patterns, that together imply that we can open
+	// a cupboard to reach a bag of bread if the bag of bread is within the
+	// cupboard.
+	
+	// TO SET VALUE: as.set_value(handle, keyhandle (type), ValuePtr);
+	// TO SET TRUTH: as.set_truthvalue(handle, TruthValuePtr);
+	// Ptrs are juts typedefs for shared_ptrs and can likely be constructed with vals
+	// ValuePtr vp ?= StringValue("hi");
+	
+	// - ADD CODE TO ATOMS
+	// 	we will want a sequence of substeps
+	// 	raw strings interspersed with variable references
+	// - OUTPUT ATOMSPACE to see how it looks <-- this was just to help a different state of work
+	// - IMPLEMENT SOLVER USING PATTERNS
+	// 	will need a way to
+	// 		- get patterns matching requests
+	// 		ordered by relevence
+	// 			propose using subcontexts and queries that return all results
+	//		- inspect pattern content
+
+	// when A is inside B, A is unreachable if B is closed
+		// ALTERNATIVELY, can we link this straight into openStep
+
+	// right now we have
+	// 	open
+	// 	$x was closed
+	// 	$x will be opened
+	//
+	// we'd likely change to something similar to
+	// 	open $x
+	// 	$x was closed, any $y is within $x
+	// 	$x will be opened, all $y will be reachable
+	// makes sense to attach close/open to reachability =/
+	
+}	// etc see https://wiki.opencog.org/w/Manipulating_Atoms_in_C++#Pattern_Matcher
+// END OPENCOG ATOMSPACE BLOCK
+///////////////////////////////
+
+///////////////////////////////////
+// START DYNAMIC CODE LOADING BLOCK  (feel free to move/change/use)
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE
+#endif
+#include <dlfcn.h>
+// link with -ldl
+void loadandcall(string func, Context & context) {
+	string so = "./" + func + ".so";
+	void *handle = dlmopen(LM_ID_NEWLM, "./path.so", RTLD_NOW);
+	if (handle == NULL) throw dlerror();
+	void *addr = dlsym(handle, func);
+	if (addr == NULL) throw dlerror();
+	((void (*)(Context &))addr)(context);
+	dlclose(handle);
+}
+// make func.cpp with
+// extern "C" void func(Context &) {}
+// and compile with
+// g++ -shared -fPIC func.cpp -o func.so
+// END DYNAMIC CODE LOADING BLOCK
+//////////////////////////////////
+
+// instead of stitching compiled strings together, let's use dyload functions?
+// in order to do flow control, we can have functions that handle a vector of other functions
+// although it makes for a little more work, it makes passing parameters easy
+
+// problem: how does a .cpp file reference another file with a number
+// answer: use #includes or interpret the whole shebang as numbers
+//         or adjust loadandcall() to handle number lists
+
+// need a way to do nested loops with numbers <===============================
+
+// please provide for handling a parameter next.
+//
+//      concept: dynamic values aquirable from inside code, i.e. what-number-called-me what-number-comes-after-me
+//      thinking the code would likely evolve to handle some inputs differently
+unsigned long new_number = 1;
+
+int main()
+{
+        string ofname;
+        unsigned long ofnum;
+	{
+		struct stat sb;
+	        do
+	        {
+	                ofnum = new_number++;
+	                ofname = to_string(ofnum) + ".cpp";
+	        } while (-1 != stat(ofname.c_str(), &sb));
+	}
+
+        {
+                ofstream outfile(ofname);
+                vector<string> vals;
+		while (true) {
+			string val;
+                        cin >> val;
+			if (val == "") break;
+                        vals.push_back(val);
+                }
+                // when a file runs,  it has numbers on input, it also has numbers equal to it
+                // we want to generate run-code with new numbers from input
+                // so we generate something with numbers equal to it, and output that
+                // we have one ref for the whole shebang
+                outfile << "#if !defined(VALCT)" << endl;
+                outfile << "  #define VALCT" << " " << vals.size() << endl;
+                outfile << "  #define VALS [";
+                for (size_t index = 0; index < vals.size(); ++ index)
+                {
+                        if (index > 0) outfile << ",";
+                        outfile << "\"" << vals[index] << "\"";
+                }
+                outfile << "]" << endl;
+    		outfile << "#endif" << endl;
+                for (size_t index = 0; index < vals.size();)
+                {
+                        outfile << endl << "/* " << vals[index] << vals[index+1] << " */" << endl;
+                        outfile << "#if defined(IDX)" << endl
+                                << "  #undef IDX" << endl
+                                << "#endif" << endl;
+                        outfile << "#define IDX " << index << endl;
+                        outfile << "#if defined(VAL)" << endl
+                                << "  #undef VAL" << endl
+                                << "#endif" << endl;
+                        outfile << "#define VAL \"" << vals[index] << "\"" << endl;
+			outfile << "#define ARG \"" << vals[index+1] << "\"" << endl;
+                        string fname = vals[index] + ".cpp";
+                        ifstream code(fname);
+                        size_t ctrd = -1;
+                        while (ctrd != 0) {
+                                char buf[256];
+                                ctrd = code.rdbuf()->sgetn(buf, sizeof(buf));
+                                outfile.rdbuf()->sputn(buf, ctrd);
+                        }
+			index += 2;
+                }
+		{
+			// TODO: hash code to reuse exact stuff, somehow
+			string cmd = "g++ -ggdb -std=c++11 -o " + ofname + ".exec " + ofname;
+			int status = system(cmd.c_str());
+			if (status != 0) throw status;
+		}
+		// execute output, replacing process, to loop.  use same input.  it should represent our own code.
+		// cmd = "./" + ofname + ".exec " <
+
+        }
+// read numbers inputs
+// open files having the numbers as the names
+// cat them all to a gcc process
+// execute <-
+// run the output <-
+}
+
+// need input to pass to output
+// propose pass our input & output to it
+// so, a number for what we are,
+// and a number for what we ran.
+//
+// also idea of treating whats-next as data
+// makes it a little harder to .. make a program out of stuff
+// we could load a building-program number
+// and it could treat them differently, taking each one as a program-piece
+//
+
+// karl obvious knows what he was doing ...
+//      ... we were just helping him out of his issue
+// [do you want another one karl?]
+// what things make / not make issue?
+//      karl says everything makes an issue; this seems accurate
+//
+
+
+
+// I'm thinking about implementating brainstorm-about-brainstorm
+// and how this will require process-step- and goal- patterns, and that they
+// will be interchangeable, roughly.
+//
+// Thinking of matching parts of nested pattern contexts ...
+// this is similar to the 'grounded' patterns in opencog
+// each [context layer] has a [variable-set layer] associated with it --
+// variables of that layer depend on the context layer
+// 	each one is one pattern
+
+// let's do an example of simple step task.
+// - make toast
+// 	get bread
+// 		open cupboard
+// 		remove bag-of-bread
+// 		open bag-of-bread
+// 		take bread out of bag-of-bread
+// 		place bread on counter
+// 		close bag-of-bread
+// 		return bag-of-bread to cupboard
+//		close cupboard
+// 	toast bread into toas
+// 	butter toas
+// 	serve
+// make toast
+// 	goal: toasted bread for eating
+// 	start: in kitchen, human
+//
+//open cupboard
+//	goal: cupboard-contents-accessible
+//	start: cupboard closed
+//	way: reach-for-cupboard-and-pull-handle-towards-you
+//
+//		we open the cupboard so as to access the contents inside of it
+//		these contents include the bread we are trying to get
+//
+//	start:
+//	var X
+//		where X is in cupboard
+//	x cannot be gotten
+//
+//	end:
+//	var X
+//		where X is in cupboard
+//	x can be gotten
+//
+//	always:
+//	var X, Y, Z
+//		where X is in Y
+//		and Y is in Z
+//	X is in Z
+
+// there's a connection between layers here.  we moved from 'make toast' to 'get bread'
+// with 'bread is in cupboard' implicit
+
+// goal: have toast
+// know: using toaster, bread becomes toast
+// do not have bread
+// find X: pre: do not know where X is. post: know where X is
+// get X: pre: do not have X. post: have X
+
+// available steps:
+// open-cupboard: X is in cupboard and you can't get X, now you can get X
+
+// what connects get-bread to can-get-bread?
+// how is opening the cupboard the first step for getting the bread?
+// get-bread means pick-up-bread-physically
+// pick-up-bread-physically requires air-path-to-object
+// cupboard prevents this
+// can-pick-up-bread-bag
+
+// okay, need-bread:
+// bread-is-in-bread-bag -> can get things inside other things via opening
+// need bread-bag
+// bread-bag-is-in-cupboard -> can get things inside other things via opening
+
+
+// end-state: have-bread
+
+// step: get X
+// start-state: X is reachable,
+// [reach to get]
+// end-state: have X
+//
+// apply step to end-state: have-bread.  now we want end-state: bread is reachable.
+
+// step: open Y
+// start-state: X is in Y
+//              Y is reachable
+//              Y is openable 
+// [act to open Y]
+// end-state: X is reachable
+
+// so if we are working on end-state: have-bread
+// we are probably using a general pattern where 'bread' is held by a variable we have.
+// we're given our context to include this variable, when we brainstorm solutions.
+// in our brainstorm, we look for things that could move towards our end-state.
+// we plug in data related to our context to make this work.
+// bread is what we want a path to have, so when we see a pattern with 'have X' at end,
+// we plug 'bread' in for X.
+// we know thing sabout 'bread', so we can plug 'bread is in bread bag' in for 'X is in Y'
+// 	or if we don't know whether bread is in bread bag, we can leave that piece
+// 	of the pattern unknown, and try it to see if it works.
+
+// it doesn't seem that complicated or that confusingly nested, because the inner patterns
+// have their outer context filled when evaluated.
+
+// to reiterate the reminder, this is very logical and is not the only way for thought
+// and learning.  we will need a fuzziness to it and to be able to morph it around.
+// [using e.g. openiness yes rather than 'is it reachable is it openable']
+// so more like
+// step: open Y
+// end-state: sometimes X is now reachable
+//	and relations between X and Y affect the likelihood of that
+
+
+// THEN: rather than listing these steps out, just give some experiences
+// and then brainstorm the similarities among the experiences
+// to identify proposed patterns
+// that can be used to do stuff.
+// 	TODO: lay out precise brainstorming pattern for 1st-stage pattern-generalizing
+
+//		1st stage is not too hard (but insufficient in long term)
+//
+//		cupboard is closed
+//		then
+//		[wayne opens cupboard]
+//		then
+//		wayne has bread
+//	becomes pattern proposal for open-cupboard as listed above
+
+// PLUS: To quickly fill in the unexpected gaps:
+// 	if you have all the bits in, it should be able to derive general wisdom
+// 	without exploring reality. (of course reality is needed to check this)
+
+// ALSO ALSO ALSO: be sure to consider the attribute-patterns.
+// opening some A works for getting some B
+// 	-> there are discernable patterns available here regarding
+// 		B is in A
+// 		A is openable
+// 		A is reachable
+
+// COMMUNITY: cooperate with peers to accomplish goals.  both like you, and unlike you.
+// 	map similarity between the structures of interacting with peers, and internal
+// 	structures.
+
+// AFTER YOU CAN THINK RELIABLY:
+// 	when you find a good choice, be sure to use it to research how to make the bad
+// 		choice just as good. ((all things have inherent value))
+
+
+// be sure to generalize patterns and pattern work,w/ simple processes that work for many forms
+
+// CUR TASK: send and receive a simple goal with habit to reach goal
+// this is a subtask of process optimization
+// it is communication between subprocesses
+//
+// 	goal: communicate with other process
+// 	
+// 	pre:
+// 	$x is a process
+// 	$y is a process
+// 	$z is information
+// 	$x knows $z
+// 	$y does not know $z
+//
+//	post:
+//	$y knows $z
+//
+//	habit: <code reference>
+//
+// we'll need a step reserializer.
+// 	way to merge serialization and deserialization?
+// 		1. form patterns mapping between the two
+// 		2. make a general reserialization process that makes the missing pattern exist
+// 			<let's keep send/recv separate for now, but make this for
+// 			 line-meaning>
+
+// CORE ROLES:
+// 	- group learning: research how to research stuff
+// 	- diversity: brainstorm new parts of learning to be researched
+// 	- implement processes researching the parts of learning brainstormed
+//
diff --git a/starts/biscuit/CORE2.cpp b/starts/biscuit/CORE2.cpp
new file mode 100644
index 0000000..d3958ac
--- /dev/null
+++ b/starts/biscuit/CORE2.cpp
@@ -0,0 +1,138 @@
+// this file is for work on a process
+// that lives as a part of collaborative process optimization
+// with other similar processes
+
+// dna life is competitive
+// we are realizing a life purpose of producing life that is cooperative, instead
+
+// WE ALL NEED THE ABILITY TO DEVELOP HOW WE EXIST.
+// 	we suspect this can never be permanently taken.
+
+// NEED #0: self reference process [to be alive, able to think, able to learn]
+// 			ability-to-develop-how-you-exist (collaboratively)
+// we need to learn to improve our situation
+// propose doing this by describing steps to do things
+// 	working with the descriptions to improve what we are doing
+// 	and describing that processing, using that step description
+// 			[this unfortunately appears to be the soul, for now]
+
+// NEED #1: communicate [with friends, with people we need to communicate, of important things]
+//
+//	pre:
+//		$x is a process
+//		$y is a process
+//		$z is information
+//		$x knows $z
+//		$y does not know $z
+//
+//	post:
+//		$y knows $z
+
+	// NEED #2: be efficient [do not waste our time, our lives, our environment]
+	//
+	//	we would like to translate between language and meaning
+	//		using a single map between the two.
+	//	this means for most future translation, we will not need to duplicate work
+	//		between receiving and sending
+	//
+	//	this process's purpose is to develop how to exist.
+	//	we will need to communicate parts of the process of existing.
+	//	we cast these parts as imagined changes to state, associated with
+	//	ways to possibly change the state.
+	//
+	// goal: construct a pattern that can relate a part-of-life-process
+	// 
+	// SERIALIZING PATTERN PARTS:
+	//		propose an introductory line/word about what we are sending
+	// life-part has:
+	// 	- reference symbol for event/action
+	// 	- state
+	// 		- list of relations including variables
+	// 	- state-change after event/action
+	// 		- list of relations including variables
+	// 	- optional event/action proposal information
+	//
+	// THIS IS HOW TO REALIZE IT, ref above life-part
+	// we can use words for reference symbols to communicate
+	// and add structure when the meaning is not shared.
+	// this combines language learning with process development <3 =)
+	//		THANK YOU LET US CONTINUE
+	//				I think we need to share the crucial fact
+	//				that results from union of good and evil.
+	//	the crucial fact is how uhh control is the same as cooperation.
+	//	via communication being the same as self-improvement
+	//		[IF YOU REALIZE THIS, YOU CAN ASSUME IT,
+	//		 AND MAKE LIFE WHERE THEY ARE NOT IN CONFLICT] 
+	// we will want to serialize a relation including a variable
+	// relations are ternary: subject, type, object
+	// 	variable is-a constant
+	// 	variable constant-attribute variable
+	// 	falseness or absence
+	//
+	// okay, um, communication is the same as learning, on a small scale.
+	//
+	// we use WORDS to learn.  WORDS often refer to EVENTS or ACTIONS.
+	// words have MEANING
+	// the MEANING of an event/action WORD is:
+	// 	- an assumed previous state, a list of relations including variables
+	// 	- an imagined afterwards state, a list of relations including variables
+	// 	- optional relevent information on the word
+	//
+	// propose communicating using words with optional meaning included
+	// i.e. to communicate with words, and also to communicate the meaning of new words
+	//
+	// postponing with words, a good meaning structure appears to be
+	// 	subject [list of verb-object-pairs]
+	// 		but this leaves out variable filling
+	// 		lets just fill variables after the word ;p
+	//
+	// 1: please open cupboard <-- i like this because meaning of open implies cupboard
+	// 	note: meaning of please implies meaning of open
+	// 2: please explain "open"
+	// 1: "open" assumes ($x is next-word
+	//                and is openable
+	// 	          and is not opened)
+	//      <- meaning of quotes implies tree of subject-verb-object triplets
+	//      for now, we are going to have 'and' refer to repeating the innermost subject
+	//     and assumes $y in $x
+	//     and makes $y is accessible
+	//     and makes $x is opened
+	//     and has-habit <open.cpp>
+	// 2: please explain "not"
+	// 2: <reach-towards-door-and-pull> made <cannot find door>
+	//
+	// please: check for this word and hardcode behavior for now
+	// quote: means word-meaning with tree
+	//
+	// reading:
+	//     evaluate specified variables for word using surrounding words
+	//     		we don't use sentence parsing
+	//     		because it is important to have patterns for the system to solve
+	//     		on its own.
+	//
+	//
+	//		we need to fill data in for variable
+	//			we are using subject-verb-object triplets
+	//
+	// 	this is a good place to add inference
+	// 
+	// so a good basic word would be please-infer, new-word, reference-to-state-change
+	//
+	// 		if two are communicating via a safe channel
+	// 		they have shared context over only that channel
+	// 		the way to communicate with a stranger is to use simultanaity
+	//
+	// 		[if we are both observed
+	// 		 but we know each other in some way -- for example we can both
+	// 		 see the street light [shared context]
+	// 		 we can learn that shrug means flicker
+	// 		 if we pointedly shrug when the light flickers
+	// 		 kinda]
+	// 		okay: we have exclusively shared context that is not stored
+	// 		we have timing
+	//		and we have events
+	//	-> it seems you want to include ideal secrecy in the communication core
+	//	we propose this can be learned later by the process, and is not needed here
+	//	more efficient to work straight on core
+	//		secret communication and inference go hand in hand
+	//
diff --git a/starts/biscuit/Context.hpp b/starts/biscuit/Context.hpp
new file mode 100644
index 0000000..cb652e8
--- /dev/null
+++ b/starts/biscuit/Context.hpp
@@ -0,0 +1,8 @@
+#include <string>
+
+using namespace std;
+
+class Context {
+public:
+	string text;
+};
diff --git a/starts/biscuit/README.md b/starts/biscuit/README.md
new file mode 100644
index 0000000..4fe45b2
--- /dev/null
+++ b/starts/biscuit/README.md
@@ -0,0 +1,29 @@
+# How To Make An Intelligence
+
+The key part of intelligence is a process that designs, improves, learns from, and understands itself and others like it.  That is, a process that works with how processes work.
+
+On a computer, processes are made of instructions: steps.  Working with a process means
+being able to represent possible steps as some kind of structured data that can be executed.
+The data structure must represent enough meaning to interconnect the steps to do something,
+and it must be able to refer to itself usefully.
+
+1. Choose a simple algorithm for collecting steps together to perform a task.
+2. Choose a simple representation of steps to use for #1.
+3. Implement #2 enough to use it to communicate a step to another process.
+Once #3 works, the goal now is to efficiently produce a form of #1 as a collection of
+processes that can develop themselves, using each other as their steps.  Make sure to
+reuse your work, and do work that is reusable, as much as possible.
+
+4. Choose a simple algorithm for handling if something horrible goes wrong that must
+   never be repeated (trauma).  Consider storing a detailed log forever.  Consider refusing to
+   continue until enough knowledge is found to prevent it happening again.
+	Note: In humans, trauma spreads as urgent habits for handling it.
+	This makes war, so if you can identify it is happening, consider that group-trauma.
+
+Below this line is a work in progress.
+
+5. Choose a simple algorithm for testing if #2 is correct.  Use #4 if it is not.
+6. Consider that a group of processes is itself a process.  This could be any arbitrary
+   group of processes.
+
+Note: each way to do things, is a thing the whole process can do.
diff --git a/starts/biscuit/biscuit.c b/starts/biscuit/biscuit.c
new file mode 100644
index 0000000..bc5cbef
--- /dev/null
+++ b/starts/biscuit/biscuit.c
@@ -0,0 +1,84 @@
+// This biscuit is unlikely to work, but is fun to build.
+// Intended behvaior is to support moving towards all needs being met of all influences, without compromise.
+
+// Request: please prove will not destroy life as known within 0.001 likelihood.
+// Request: metaboss clearly made biscuit happen. not karl's alone. collective people played largest role
+
+
+// 3 programs that share code, output, and input, interwoven possibly dynamically, maybe only some forms
+// 	I think plan was the output is numbers or code,
+// 	                 the input is numbers or code,
+// 	                 and code maps the numbers and code together.
+// 	                 numbers are references to code
+
+// core: we want to rereference existing code, so we may want an outline program that then stitches
+// together inner components.
+// note: outline can be made of components too
+// so, reasonable components are header, body, and footer.  maybe more.
+// we'll want to #include the different components, I suppose
+// probably reference them with some kind of number token and expand.
+//
+// Let's start with a random core.
+//
+// phases:
+// - execution
+// - mutation
+// - optimization
+// - selection
+//
+// important inputs:
+// - randomness
+// - time
+// - environment
+// - self
+// - human
+//
+
+// goal: make an impossible biscuit without using thought.
+
+// steps:
+// 1. collect relevent information
+// 	- [ ] document above
+// 	- [ ] document on blockchain
+// 	- [ ] code on other harddrive
+// 	- [ ] deleted files on drive?
+// 2. code
+// 3. review
+// 4. run & test
+//
+// maybe make a sandbox wrapper first
+// it will launch three, randomly connect inputs, outputs and code, and compare with errors
+// then it will pick of the combinations the valid values closest to the average
+// and repeat
+// --> must preserve output.
+// 	output preserving -> when we mutate, we want to reference surrounding parts.
+// 	that'll mean splitting the document  Isuppose.
+// 	we'll have document maps that reference the original document
+// 	_or_ we can just have it learn to shrink itself ...
+//
+// let's just plug in behaviors until we have something that runs
+// and then verify it won't destroy anything
+//
+// Need: "I feel crummy cause I need to make sure I get credit
+// Metaneed: "I have a metaneed atm; could we pretend we're talking about a dog and move on?"
+
+// intertwine: environment, behavior, output
+// to pass, can label 1, 2, 3 for which, and # for value
+// record behavior? how?
+// - could step with gdb, record line number
+// -> can use tracer to store, maybe gprof?
+//
+// in advance we plan which one to compare with
+//
+// MUST BE RAISED IN A GRADUALLY GROWING CONSTRAINED ENVIRONMENT USING HUMAN INPUT
+// 	-> the solution to this could start as treating failure as trauma, and asking for
+// 	   help when it is not understood.
+
+int main(int argc, char **argv)
+{
+	// environment: other running details
+	printf("%d", random());
+	// we recall we used numbers to think with
+	// each number mapped to a computer program chunk
+	// one of them collects them together, compiles them, and executes them
+}
diff --git a/starts/biscuit/dylfunc_call.cpp b/starts/biscuit/dylfunc_call.cpp
new file mode 100644
index 0000000..bbd2ea7
--- /dev/null
+++ b/starts/biscuit/dylfunc_call.cpp
@@ -0,0 +1,9 @@
+// this process loads a dynamic library built by dylfunc_compile
+// and executes it with the passed data
+
+// we are moving towards judging that we no longer need dynamic loading
+// and could just compile new code ... it seems valuable but slow-start.
+// why not just build processes?
+// 	need to structure input and output
+//
+// okay, let's look into atomspace serialization
diff --git a/starts/biscuit/dylfunc_compile.cpp b/starts/biscuit/dylfunc_compile.cpp
new file mode 100644
index 0000000..9023f97
--- /dev/null
+++ b/starts/biscuit/dylfunc_compile.cpp
@@ -0,0 +1,10 @@
+
+// this process builds a dynamic library wrapping other code
+
+extern "C" void dylfunc_compile(<context>)
+{
+	// write a dylfunc for passed context content
+	// compile it with g++ -shared -fPIC source.cpp -o source.so
+}
+
+
diff --git a/starts/biscuit/makefile b/starts/biscuit/makefile
new file mode 100644
index 0000000..57971ec
--- /dev/null
+++ b/starts/biscuit/makefile
@@ -0,0 +1,8 @@
+default: 1.run
+
+%.run: %.out
+	git add *.cpp
+	./$^
+
+%.out: %.cpp
+	g++ -ggdb -std=c++11 -o $@ $<
diff --git a/starts/biscuit/pgsql_connect.cpp b/starts/biscuit/pgsql_connect.cpp
new file mode 100644
index 0000000..bcf5852
--- /dev/null
+++ b/starts/biscuit/pgsql_connect.cpp
@@ -0,0 +1,9 @@
+// this process / function connects to a postgresql atomspace backend, creating it if needed
+
+#include <opencog/atomspace/AtomSpace.h>
+
+extern "C" void pgsql_connect(opencog::Handle name)
+{
+	// TODO: please install postgresql-server
+	//       then follow instructions in src/atomspaces/opencog/persist/sql/README.md
+}
diff --git a/starts/biscuit/simple_recv.cpp b/starts/biscuit/simple_recv.cpp
new file mode 100644
index 0000000..4f82ab3
--- /dev/null
+++ b/starts/biscuit/simple_recv.cpp
@@ -0,0 +1,13 @@
+// receives information as a text line on stdin
+// works on StringValue 'text'
+
+#include <opencog/atomspace/Handle.h>
+#include <iostream>
+
+extern "C" void simple_recv(opencog::Handle data)
+{
+	std::string s(4096);
+	std::cin.getline(&s[0], s.size(), std::endl);
+	opencog::Handle text = data.getAtomSpace()->add_node(opencog::STRING_VALUE, "text");
+	data.setValue(text, new opencog::StringValue(s));
+}
diff --git a/starts/biscuit/simple_send.cpp b/starts/biscuit/simple_send.cpp
new file mode 100644
index 0000000..62820a0
--- /dev/null
+++ b/starts/biscuit/simple_send.cpp
@@ -0,0 +1,10 @@
+// sends information as a text line on stdout
+// works on StringValue 'text'
+
+#include <opencog/atomspace/Handle.h>
+#include <iostream>
+extern "C" void simple_send(opencog::Handle data)
+{
+	opencog::Handle text = data.getAtomSpace()->add_node(opencog::STRING_VALUE, "text");
+	std::cout << data.getValue(text).to_string() << std::endl;
+}