On Thu, Oct 7, 2021 at 3:41 PM Ivan V. <[email protected]> wrote: > > Hi linas, > > Nice to see someone having fun with this thingy :)
Yeah. I don't know why people ignore this mailing list these days. Maybe it's covid. > Thousands of nodes might seem a bit of overkill for this system, especially > considering the fact that this system is a brute s-expression listing > machine, without caring what nodes stand for the same one. I believe the > system wouldn't choke on that, but navigating them would be a Hell of a task. Yep. and that is exactly what the atomspace does! > However, there is one trick that might render all this usable: what if there > was a query system (already a part of AtomSpace) to narrow down only the > nodes we are looking for. Yep! > For example, a command `display some-query` could intercept an output and > pipe such an output to the visualisation module, showing only atoms of our > interest, not the entire Atomspace. Yep! There is no need to "intercept it". It is given to you, directly. The actual syntax would be (display (cog-execute! (MeetLink ... the actual query))) and since display doesn't print a newline, use formated print instead: (format #t "And the answer to the query is ~A\n" (cog-execute! (MeetLink ... the actual query))) > I was also thinking of advancing REPL to editing sessions for Atomspace > scripts. Well, the existing repls allow you to edit to your hearts content. So I guess you mean a new web-page repl? > Such session would first check if Atomspace is empty (eg. no one is currently > using it). well, in typical use, you don't start empty, but either attach to some existing database, or dump a bunch of atoms in. > Then the telnet would populate Atomspace from the editing session, with > intercepting `display` commands, concatenating them ino one s-expression and > piping it out to the visualizer. Lastly, after ending the script, telnet > would wipe out the entire Atomspace to prepare it for the next visualization > cycle. Well, wiping it out would be a bit much... However, there is one weird trick ... In your local atomspace, you can do this: (cog-open (CogStorageNode "cog://example.com:17001")) (fetch-atom (Concept "foo")) ; this will get all the (truth) values ... (store-atom (Concept "bar")) ; this will store all the values (fetch-incoming-set (Concept "foo")) ; get every Link that foo is inside of ... so if example.com is running a cogserver on port 17001, then you can have access to it. and copy atoms between it and your local atomspace. Just don't trash it's contents, the owner might not be happy. --linas > > I believe this would do the trick for reasonably small scripts, just to make > things simpler for newcomers, so they can play with smaller scripts. > > But even if this would work, multi-user access is concerning me as a quirk I > would like to avoid. Guaranteed empty Atomspace between display sessions > would somehow do a job, but it does not scale very well. It would be awesome > if there would be some on-demand allocating of a namespace specific to > individual users connecting to cogserver. > > I agree that implementing editing sessions in this way (with keeping current > Atomspace state empty) sounds somewhat strange. Are there other options for > doing this from telnet? > > All well, > Ivan > > čet, 7. lis 2021. u 21:52 Linas Vepstas <[email protected]> napisao je: >> >> Hi Ivan! >> >> Well that was fun! >> >> There are two REPL loops (four, actually) the guile/scheme repl loop; >> the guile/scheme repl loop provided by the cogserver, which is almost >> the same except it runs over telnet. Then there's the python repl, >> and the cogserver provides a telnet python repl, too. The telnet >> python REPL is almost the same as regular python, but not quite, it >> hand;es whitespace differently. Python is to blame for that: >> whitespace rules for repls are different from whitespace rules on >> files. Whatever. At any rate, these are all inter-operable: atoms >> created in one show up in the other. >> >> An interesting visualization is this one: >> (List (Word "this") (Word "that")) >> (List (Word "this") (Word "thing")) >> (List (Word "this") (Word "cat")) >> (List (Word "that") (Word "cat")) >> ... >> So, if you start at (Word "this") and move up, you'll find a thousand >> List's. Pick one (say, "cat") move down and then back up, you'll find >> a thousand Lists that "cat" is in. Bouncing around in this network >> can be entertaining, provided the pairs are meaningful. >> >> The point here is that the s-expression (Word "that") is globally >> unique: it is one and the same, everywhere. >> >> --linas >> >> On Tue, Oct 5, 2021 at 2:43 AM Ivan V. <[email protected]> wrote: >> > >> > Hi Linas and others :) >> > >> > Diving deeper into OpenCog, I learned some basics of interfacing with >> > Atomspace. I decided to delay the initial idea of visualizing the >> > inference process, and to simply focus my attention to s-expressions which >> > is atomspace based on. See my latest experiment with s-expressions at: >> > >> > http://ocog.atspace.cc/atomizer/ >> > >> > The experiment simply parses provided s-expression string, breaks it down >> > to its elements recursively, and shows it on the screen to navigate by. It >> > isn't a super-king of usability, but it may look fancy to beginners, and >> > attractive enough to show off to someone how the bare Atomspace concept >> > looks like. >> > >> > If bundled with an appropriate opencog input/output system like REPL or >> > something, it may form a usable whole, at least to beginners who learn >> > basics of interacting with Atomspace. >> > >> > Finally, there may be a chance I stitch it to OpenCog. If I opt out for >> > this, I think I'll be using telnet to connect to cogserver. I may want to >> > make read-eval-print-loop accessible from web browsers, updating the >> > visualization of the current Atomspace state on each cycle. There already >> > exist some telnet libraries to do this with php, so I believe this may be >> > a simpler solution than the proposed wrapping atomspace interface for use >> > with js. Maybe not as flexible as Linas' proposition, but simpler. >> > >> > Be well, >> > Ivan >> > >> > >> > pet, 24. ruj 2021. u 06:07 Ivan V. <[email protected]> napisao je: >> >> >> >> Great, I believe it would ease things a lot. Let me notify you when I'm >> >> ready to do some more serious coding. >> >> >> >> Ivan >> >> >> >> pet, 24. ruj 2021. u 04:48 Linas Vepstas <[email protected]> napisao >> >> je: >> >>> >> >>> Hi Ivan, >> >>> >> >>> On Thu, Sep 23, 2021 at 10:51 AM Ivan V. <[email protected]> wrote: >> >>> > >> >>> > Thank you, I'll take some time to think about it if you don't mind. >> >>> >> >>> Heh. Too late! Rather than nagging you or anyone else about this, I >> >>> thought about it a bit, and realized that I could hack up a basic >> >>> solution in a day. So I did. If you grabe the very latest atomspace >> >>> and cogserver code, then you get a simple network API to the >> >>> atomspace, here. The README explains all: >> >>> >> >>> https://github.com/opencog/atomspace/blob/master/opencog/persist/json/README.md >> >>> >> >>> The JSON is delivered as a string, over the network. You still have to >> >>> do something with it. If/when you want to create javascript, node.js, >> >>> emscripten, or whatever kind of interfaces to it, let me know. I just >> >>> now create a new, empty git repo at >> >>> https://github.com/opencog/atomspace-js >> >>> >> >>> Anyone who is interested should just ask, I'll provide write access to >> >>> that repo. >> >>> >> >>> --linas >> >>> >> >>> >> >>> >> >>> > >> >>> > čet, 23. ruj 2021. u 17:34 Linas Vepstas <[email protected]> >> >>> > napisao je: >> >>> >> >> >>> >> On Thu, Sep 23, 2021 at 3:15 AM Ivan V. <[email protected]> wrote: >> >>> >> > >> >>> >> > Just a quick question while we're at it, if I may: what is the best >> >>> >> > way to communicate between web browser and atomspace? >> >>> >> >> >>> >> Currently, none. The "atomspace explorer" used an atomspace server >> >>> >> that was weird, slow, mis-designed, old and incomplete... >> >>> >> >> >>> >> Let me take you on a trip. >> >>> >> >> >>> >> What is really needed are some javascript bindings that talk to the >> >>> >> cogserver. It is very easy, trivial, even, to talk to the cogserver, >> >>> >> and get a reply. The hard part is to convert the results into whatever >> >>> >> javascript you want -- we do not have any existing layer for that. >> >>> >> Creating this layer would be an excellent project. >> >>> >> >> >>> >> Thus, for example: >> >>> >> -- use javascript to open a socket to 17001 >> >>> >> -- send command over that socket; for example, >> >>> >> `(cog-value (Concept "foo") (Predicate "some key"))` >> >>> >> -- read the result, for example >> >>> >> `(FloatValue 1.000000 2.000000 3.00000)` >> >>> >> -- close the socket, or re-use it. >> >>> >> >> >>> >> Great! But how do you convert `(FloatValue 1.000000 2.000000 >> >>> >> 3.00000)` into what you want? (What do you want?) >> >>> >> >> >>> >> Now, before you get on that airplane, and start writing code to use >> >>> >> javascript to talk to the cogserver, consider this: >> >>> >> >> >>> >> If you wrote that code, you would have to cache the results locally, >> >>> >> in javascript. That is, you would have to create a local, in-browser >> >>> >> copy of (Concept "foo") and (Predicate "some key") and remember that >> >>> >> (FloatValue 1 2 3) is attached to it. In other words, you would be >> >>> >> re-inventing the atomspace, locally, running inside the browser. Good >> >>> >> god, why? We already have an atomspace, why reinvent a >> >>> >> browser-specific one? (Because this is what things like the >> >>> >> atomspace-explorer were doing.) >> >>> >> >> >>> >> The correct solution is this: create javascript bindings for the >> >>> >> atomspace. That's it, end of story. Want to talk to some remote >> >>> >> AtomSpace? Just use the CogStorageNode! That's it, you're done. >> >>> >> >> >>> >> I'll stop writing the email here .. because there is nothing more to >> >>> >> say! People who use web browsers need javascript. If we had javascript >> >>> >> binding to the atomspace, you would have it in your browser. >> >>> >> >> >>> >> If you want to create these bindings, I'l create a github repo under >> >>> >> the opencog project, give you full write permission, and you can do >> >>> >> whatever in there. I'm sure many people could use them. >> >>> >> >> >>> >> --linas >> >>> >> >> >>> >> > >> >>> >> > čet, 23. ruj 2021. u 08:24 Linas Vepstas <[email protected]> >> >>> >> > napisao je: >> >>> >> >> >> >>> >> >> On Thu, Sep 23, 2021 at 12:44 AM Ivan V. <[email protected]> >> >>> >> >> wrote: >> >>> >> >> > >> >>> >> >> > As for the visualization tool, I'll have more time in a few >> >>> >> >> > weeks when I settle some of my obligations. >> >>> >> >> >> >>> >> >> You don't have to make promises! There is no intent to guilt-trip >> >>> >> >> you >> >>> >> >> into doing something. >> >>> >> >> >> >>> >> >> > Then, a kind of OpenCog debugger (or IDE) is what I have on my >> >>> >> >> > mind. >> >>> >> >> >> >>> >> >> In the end, whatever you create has to be for yourself, for your >> >>> >> >> own >> >>> >> >> entertainment. If it turns out to be useful for others, that would >> >>> >> >> be >> >>> >> >> wonderful, but, as this long conversation has shown, there's no >> >>> >> >> general vision of what anyone wants. Different people want >> >>> >> >> different >> >>> >> >> things; what's useful for one is useless for another. >> >>> >> >> >> >>> >> >> > It would be something like an atomspace editor communicating to >> >>> >> >> > cogserver, showing inference trees related to edited fragments. >> >>> >> >> > Nothing too fancy, no dozens of options, just a simple atomspace >> >>> >> >> > expressions writing aid, as minimalistic as it can get, with an >> >>> >> >> > editor on the left and related inference trees on the right side. >> >>> >> >> >> >>> >> >> Two part reply. (1) inference trees are very specific to the PLN >> >>> >> >> backward chainer, and have almost nothing to do with the atomspace. >> >>> >> >> (other than that they are kept in the atomspace ... for a while .. >> >>> >> >> until they are deleted. Nil can supply those if that is what you >> >>> >> >> really want.) >> >>> >> >> >> >>> >> >> (2) Don't worry about the cogserver. Don't use the cogserver. Just >> >>> >> >> work with the atomspace directly. Why? (a) you don't need the >> >>> >> >> cogserver to get things done. (b) if you absolutely must have a >> >>> >> >> network connection to some remote AtomSpace, use the CogStorageNode >> >>> >> >> -- it will automatically open a network connection to a remote >> >>> >> >> AtomSpace, and it will automatically trade atoms with it, bringing >> >>> >> >> them over to your local AtomSpace. You just have to specify which >> >>> >> >> atoms. If you are not sure which atoms, you can easily run a query >> >>> >> >> on >> >>> >> >> the remote AtomSpace. >> >>> >> >> >> >>> >> >> Documentation: >> >>> >> >> https://wiki.opencog.org/w/CogStorageNode >> >>> >> >> >> >>> >> >> Demos: >> >>> >> >> https://github.com/opencog/atomspace-cog/tree/master/examples >> >>> >> >> >> >>> >> >> -- linas >> >>> >> >> >> >>> >> >> >> >>> >> >> -- >> >>> >> >> Patrick: Are they laughing at us? >> >>> >> >> Sponge Bob: No, Patrick, they are laughing next to us. >> >>> >> >> >> >>> >> >> -- >> >>> >> >> You received this message because you are subscribed to the Google >> >>> >> >> Groups "opencog" group. >> >>> >> >> To unsubscribe from this group and stop receiving emails from it, >> >>> >> >> send an email to [email protected]. >> >>> >> >> To view this discussion on the web visit >> >>> >> >> https://groups.google.com/d/msgid/opencog/CAHrUA34zZ%2BqFdgycq8PQjp1BvikD0b1Y8HSRSebMMxCfeF5p8Q%40mail.gmail.com. >> >>> >> > >> >>> >> > -- >> >>> >> > You received this message because you are subscribed to the Google >> >>> >> > Groups "opencog" group. >> >>> >> > To unsubscribe from this group and stop receiving emails from it, >> >>> >> > send an email to [email protected]. >> >>> >> > To view this discussion on the web visit >> >>> >> > https://groups.google.com/d/msgid/opencog/CAB5%3Dj6UkUirdXC9h7fmgzHvaZzz46coGYTUAU2TdqigTEXX4xw%40mail.gmail.com. >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> Patrick: Are they laughing at us? >> >>> >> Sponge Bob: No, Patrick, they are laughing next to us. >> >>> >> >> >>> >> -- >> >>> >> You received this message because you are subscribed to the Google >> >>> >> Groups "opencog" group. >> >>> >> To unsubscribe from this group and stop receiving emails from it, >> >>> >> send an email to [email protected]. >> >>> >> To view this discussion on the web visit >> >>> >> https://groups.google.com/d/msgid/opencog/CAHrUA35-K8V6T3V%2BM7nLSze0NdPhcuk9txBNAoMAd1XJ%3DGekEw%40mail.gmail.com. >> >>> > >> >>> > -- >> >>> > You received this message because you are subscribed to the Google >> >>> > Groups "opencog" group. >> >>> > To unsubscribe from this group and stop receiving emails from it, send >> >>> > an email to [email protected]. >> >>> > To view this discussion on the web visit >> >>> > https://groups.google.com/d/msgid/opencog/CAB5%3Dj6Vn5b1NdXa1ptQEtEMXES%3D9H23Ry6J3_X4f%3DAraf%2BEybg%40mail.gmail.com. >> >>> >> >>> >> >>> >> >>> -- >> >>> Patrick: Are they laughing at us? >> >>> Sponge Bob: No, Patrick, they are laughing next to us. >> >>> >> >>> -- >> >>> You received this message because you are subscribed to the Google >> >>> Groups "opencog" group. >> >>> To unsubscribe from this group and stop receiving emails from it, send >> >>> an email to [email protected]. >> >>> To view this discussion on the web visit >> >>> https://groups.google.com/d/msgid/opencog/CAHrUA36dV20DGvtE2hTP94q48-f5BrtBjRi3h%2Bv5U6hYhr3MsQ%40mail.gmail.com. >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "opencog" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to [email protected]. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/opencog/CAB5%3Dj6WS5S0vLzNRTpBP8BSh9N6XhDmd0wxyXgES4fs2iQjHvw%40mail.gmail.com. >> >> >> >> -- >> Patrick: Are they laughing at us? >> Sponge Bob: No, Patrick, they are laughing next to us. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "opencog" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/opencog/CAHrUA35rxQTu%2BNG7-k0h791LruXCLksyUCju-YgzGTC4eaQMOw%40mail.gmail.com. > > -- > You received this message because you are subscribed to the Google Groups > "opencog" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/CAB5%3Dj6V2EFAbtSA-DaLgA9Kod85%3D6yMwVgz1xWoV49QQ0QGAQg%40mail.gmail.com. -- Patrick: Are they laughing at us? Sponge Bob: No, Patrick, they are laughing next to us. -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37UtMHuv-UvU3vUqnCqSuFf0Kvx3%2Be0RHPctdwrJ26aLw%40mail.gmail.com.
