From 7d2e7e186fcee41c46683a0b76e9531f94f91692 Mon Sep 17 00:00:00 2001 From: user Date: Wed, 23 Oct 2019 17:34:39 -0400 Subject: move content to starts folder for consolidation --- 1.cpp | 1 - 2.cpp | 110 -------- CORE1.cpp | 505 ------------------------------------- CORE2.cpp | 138 ---------- Context.hpp | 8 - README.md | 29 --- biscuit.c | 84 ------ dylfunc_call.cpp | 9 - dylfunc_compile.cpp | 10 - makefile | 8 - pgsql_connect.cpp | 9 - simple_recv.cpp | 13 - simple_send.cpp | 10 - 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 + 26 files changed, 934 insertions(+), 934 deletions(-) delete mode 120000 1.cpp delete mode 100644 2.cpp delete mode 100644 CORE1.cpp delete mode 100644 CORE2.cpp delete mode 100644 Context.hpp delete mode 100644 README.md delete mode 100644 biscuit.c delete mode 100644 dylfunc_call.cpp delete mode 100644 dylfunc_compile.cpp delete mode 100644 makefile delete mode 100644 pgsql_connect.cpp delete mode 100644 simple_recv.cpp delete mode 100644 simple_send.cpp create mode 120000 starts/biscuit/1.cpp create mode 100644 starts/biscuit/2.cpp create mode 100644 starts/biscuit/CORE1.cpp create mode 100644 starts/biscuit/CORE2.cpp create mode 100644 starts/biscuit/Context.hpp create mode 100644 starts/biscuit/README.md create mode 100644 starts/biscuit/biscuit.c create mode 100644 starts/biscuit/dylfunc_call.cpp create mode 100644 starts/biscuit/dylfunc_compile.cpp create mode 100644 starts/biscuit/makefile create mode 100644 starts/biscuit/pgsql_connect.cpp create mode 100644 starts/biscuit/simple_recv.cpp create mode 100644 starts/biscuit/simple_send.cpp diff --git a/1.cpp b/1.cpp deleted file mode 120000 index 065a594..0000000 --- a/1.cpp +++ /dev/null @@ -1 +0,0 @@ -CORE1.cpp \ No newline at end of file diff --git a/2.cpp b/2.cpp deleted file mode 100644 index 15c9481..0000000 --- a/2.cpp +++ /dev/null @@ -1,110 +0,0 @@ -#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 -#include -#include -#include - -#include - -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 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/CORE1.cpp b/CORE1.cpp deleted file mode 100644 index c85c78d..0000000 --- a/CORE1.cpp +++ /dev/null @@ -1,505 +0,0 @@ -// 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 -#include -#include -#include -#include - -#include - -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 -//#include -//#include -//#include -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 -// 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 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: -// -// 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 -// - -// 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/CORE2.cpp b/CORE2.cpp deleted file mode 100644 index d3958ac..0000000 --- a/CORE2.cpp +++ /dev/null @@ -1,138 +0,0 @@ -// 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 - // 2: please explain "not" - // 2: made - // - // 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/Context.hpp b/Context.hpp deleted file mode 100644 index cb652e8..0000000 --- a/Context.hpp +++ /dev/null @@ -1,8 +0,0 @@ -#include - -using namespace std; - -class Context { -public: - string text; -}; diff --git a/README.md b/README.md deleted file mode 100644 index 4fe45b2..0000000 --- a/README.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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/biscuit.c b/biscuit.c deleted file mode 100644 index bc5cbef..0000000 --- a/biscuit.c +++ /dev/null @@ -1,84 +0,0 @@ -// 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/dylfunc_call.cpp b/dylfunc_call.cpp deleted file mode 100644 index bbd2ea7..0000000 --- a/dylfunc_call.cpp +++ /dev/null @@ -1,9 +0,0 @@ -// 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/dylfunc_compile.cpp b/dylfunc_compile.cpp deleted file mode 100644 index 9023f97..0000000 --- a/dylfunc_compile.cpp +++ /dev/null @@ -1,10 +0,0 @@ - -// this process builds a dynamic library wrapping other code - -extern "C" void dylfunc_compile() -{ - // write a dylfunc for passed context content - // compile it with g++ -shared -fPIC source.cpp -o source.so -} - - diff --git a/makefile b/makefile deleted file mode 100644 index 57971ec..0000000 --- a/makefile +++ /dev/null @@ -1,8 +0,0 @@ -default: 1.run - -%.run: %.out - git add *.cpp - ./$^ - -%.out: %.cpp - g++ -ggdb -std=c++11 -o $@ $< diff --git a/pgsql_connect.cpp b/pgsql_connect.cpp deleted file mode 100644 index bcf5852..0000000 --- a/pgsql_connect.cpp +++ /dev/null @@ -1,9 +0,0 @@ -// this process / function connects to a postgresql atomspace backend, creating it if needed - -#include - -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/simple_recv.cpp b/simple_recv.cpp deleted file mode 100644 index 4f82ab3..0000000 --- a/simple_recv.cpp +++ /dev/null @@ -1,13 +0,0 @@ -// receives information as a text line on stdin -// works on StringValue 'text' - -#include -#include - -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/simple_send.cpp b/simple_send.cpp deleted file mode 100644 index 62820a0..0000000 --- a/simple_send.cpp +++ /dev/null @@ -1,10 +0,0 @@ -// sends information as a text line on stdout -// works on StringValue 'text' - -#include -#include -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; -} 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 +#include +#include +#include + +#include + +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 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 +#include +#include +#include +#include + +#include + +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 +//#include +//#include +//#include +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 +// 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 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: +// +// 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 +// + +// 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 + // 2: please explain "not" + // 2: made + // + // 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 + +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() +{ + // 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 + +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 +#include + +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 +#include +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