From c8bb547bea279af2bb48c13260f98aa8add07131 Mon Sep 17 00:00:00 2001
From: olpc user <olpc@xo-5d-f7-86.localdomain>
Date: Fri, 10 Jan 2020 14:55:19 -0800
Subject: move intellect-framework-from-internet into folder
---
.../starts/biscuit/1.cpp | 1 +
.../starts/biscuit/2.cpp | 110 +++++
.../starts/biscuit/CORE1.cpp | 505 +++++++++++++++++++++
.../starts/biscuit/CORE2.cpp | 138 ++++++
.../starts/biscuit/Context.hpp | 8 +
.../starts/biscuit/README.md | 29 ++
.../starts/biscuit/biscuit.c | 84 ++++
.../starts/biscuit/dylfunc_call.cpp | 9 +
.../starts/biscuit/dylfunc_compile.cpp | 10 +
.../starts/biscuit/makefile | 8 +
.../starts/biscuit/pgsql_connect.cpp | 9 +
.../starts/biscuit/simple_recv.cpp | 13 +
.../starts/biscuit/simple_send.cpp | 10 +
13 files changed, 934 insertions(+)
create mode 120000 intellect-framework-from-internet/starts/biscuit/1.cpp
create mode 100644 intellect-framework-from-internet/starts/biscuit/2.cpp
create mode 100644 intellect-framework-from-internet/starts/biscuit/CORE1.cpp
create mode 100644 intellect-framework-from-internet/starts/biscuit/CORE2.cpp
create mode 100644 intellect-framework-from-internet/starts/biscuit/Context.hpp
create mode 100644 intellect-framework-from-internet/starts/biscuit/README.md
create mode 100644 intellect-framework-from-internet/starts/biscuit/biscuit.c
create mode 100644 intellect-framework-from-internet/starts/biscuit/dylfunc_call.cpp
create mode 100644 intellect-framework-from-internet/starts/biscuit/dylfunc_compile.cpp
create mode 100644 intellect-framework-from-internet/starts/biscuit/makefile
create mode 100644 intellect-framework-from-internet/starts/biscuit/pgsql_connect.cpp
create mode 100644 intellect-framework-from-internet/starts/biscuit/simple_recv.cpp
create mode 100644 intellect-framework-from-internet/starts/biscuit/simple_send.cpp
(limited to 'intellect-framework-from-internet/starts/biscuit')
diff --git a/intellect-framework-from-internet/starts/biscuit/1.cpp b/intellect-framework-from-internet/starts/biscuit/1.cpp
new file mode 120000
index 0000000..065a594
--- /dev/null
+++ b/intellect-framework-from-internet/starts/biscuit/1.cpp
@@ -0,0 +1 @@
+CORE1.cpp
\ No newline at end of file
diff --git a/intellect-framework-from-internet/starts/biscuit/2.cpp b/intellect-framework-from-internet/starts/biscuit/2.cpp
new file mode 100644
index 0000000..15c9481
--- /dev/null
+++ b/intellect-framework-from-internet/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/intellect-framework-from-internet/starts/biscuit/CORE1.cpp b/intellect-framework-from-internet/starts/biscuit/CORE1.cpp
new file mode 100644
index 0000000..c85c78d
--- /dev/null
+++ b/intellect-framework-from-internet/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/intellect-framework-from-internet/starts/biscuit/CORE2.cpp b/intellect-framework-from-internet/starts/biscuit/CORE2.cpp
new file mode 100644
index 0000000..d3958ac
--- /dev/null
+++ b/intellect-framework-from-internet/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/intellect-framework-from-internet/starts/biscuit/Context.hpp b/intellect-framework-from-internet/starts/biscuit/Context.hpp
new file mode 100644
index 0000000..cb652e8
--- /dev/null
+++ b/intellect-framework-from-internet/starts/biscuit/Context.hpp
@@ -0,0 +1,8 @@
+#include <string>
+
+using namespace std;
+
+class Context {
+public:
+ string text;
+};
diff --git a/intellect-framework-from-internet/starts/biscuit/README.md b/intellect-framework-from-internet/starts/biscuit/README.md
new file mode 100644
index 0000000..4fe45b2
--- /dev/null
+++ b/intellect-framework-from-internet/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/intellect-framework-from-internet/starts/biscuit/biscuit.c b/intellect-framework-from-internet/starts/biscuit/biscuit.c
new file mode 100644
index 0000000..bc5cbef
--- /dev/null
+++ b/intellect-framework-from-internet/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/intellect-framework-from-internet/starts/biscuit/dylfunc_call.cpp b/intellect-framework-from-internet/starts/biscuit/dylfunc_call.cpp
new file mode 100644
index 0000000..bbd2ea7
--- /dev/null
+++ b/intellect-framework-from-internet/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/intellect-framework-from-internet/starts/biscuit/dylfunc_compile.cpp b/intellect-framework-from-internet/starts/biscuit/dylfunc_compile.cpp
new file mode 100644
index 0000000..9023f97
--- /dev/null
+++ b/intellect-framework-from-internet/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/intellect-framework-from-internet/starts/biscuit/makefile b/intellect-framework-from-internet/starts/biscuit/makefile
new file mode 100644
index 0000000..57971ec
--- /dev/null
+++ b/intellect-framework-from-internet/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/intellect-framework-from-internet/starts/biscuit/pgsql_connect.cpp b/intellect-framework-from-internet/starts/biscuit/pgsql_connect.cpp
new file mode 100644
index 0000000..bcf5852
--- /dev/null
+++ b/intellect-framework-from-internet/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/intellect-framework-from-internet/starts/biscuit/simple_recv.cpp b/intellect-framework-from-internet/starts/biscuit/simple_recv.cpp
new file mode 100644
index 0000000..4f82ab3
--- /dev/null
+++ b/intellect-framework-from-internet/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/intellect-framework-from-internet/starts/biscuit/simple_send.cpp b/intellect-framework-from-internet/starts/biscuit/simple_send.cpp
new file mode 100644
index 0000000..62820a0
--- /dev/null
+++ b/intellect-framework-from-internet/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;
+}
--
cgit v1.2.3