diff options
author | olpc user <olpc@xo-5d-f7-86.localdomain> | 2020-01-10 14:55:19 -0800 |
---|---|---|
committer | olpc user <olpc@xo-5d-f7-86.localdomain> | 2020-01-10 14:55:19 -0800 |
commit | c8bb547bea279af2bb48c13260f98aa8add07131 (patch) | |
tree | 7f64265d514dc50427d2e5d8a70e09a46927dfbd /intellect-framework-from-internet/starts/biscuit | |
parent | 5601d1f3324c30651ad3f264ac2d6e7f12ea8b34 (diff) | |
download | standingwithresilience-c8bb547bea279af2bb48c13260f98aa8add07131.tar.gz standingwithresilience-c8bb547bea279af2bb48c13260f98aa8add07131.zip |
move intellect-framework-from-internet into folder
Diffstat (limited to 'intellect-framework-from-internet/starts/biscuit')
13 files changed, 934 insertions, 0 deletions
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; +} |