On Sat, Jul 3, 2021 at 1:33 PM Lansana Camara <[email protected]> wrote:
> Linas, > > Dude I totally get it. Again, you have me confused for someone I’m not. > I'm sorry. Thank you. Let us continue, then. > > Let’s take a step back. Correct me if I’m wrong, but this whole thread is > about you wanting to rebuild a UI that was left in a poor state and is > difficult to maintain, right? > Yes, something like that. Except it was never a UI -- it was a neat demo that drew some pretty pictures. They weren't terribly useful in themselves, it was more of a "proof of concept". There was an implicit promise that this would be a platform which could be extended to perform more sophisticated tasks that "real life users" would need -- to do something "actually useful". I recently thought to myself "oh hey, that screenshot looks nice, lets run it", and promptly realized that there's a substantial amount of maintenance needed just to get it operating again. At this point, starting all over again becomes a viable option. > So, how do we make sure we don’t find ourselves in that place again? > By understanding how we got to this place, the first time. At the end of every project, a good project manager performs a "post-mortem" -- an analysis of everything that went right, and everything that went wrong. What should be done the same next time, what should be done differently. So, just like engineering, but with ill-defined social structures and procedures, instead of software. ( I saw one post-mortem that lasted two weeks -- all-day meetings, involving everybody on the team showing up for at least one day. Maybe we can be quicker here?) Now I could talk about "what we want in the future", but that is surprisingly ill-defined, so let's take the trip down memory lane. There have been eight "visualization" attempts with opencog: * One used "dotty" and converted a select portion of the AtomSpace into a graph. I think Joel created this, and Ben got him to make three graphs that were presented at a conference. What's wrong with dotty? Well, back then, the pictures it drew were not very pretty. Nor was it some do-everything visualization tool: it was some quick hacks. It needed to do one task and it did it, but there was no clear path forwards. * Hopping around in time: just a year ago, I hacked some GML (graphics markup language) to export some very special AtomSpace graphs, and then used Cytoscape to draw them. This is almost exactly like the dotty situation, just with a completely different set of technology, There is no obvious path forwards to a "do it all, do everything" atomspace visualizer. * Tulip. Same story as above, but with Tulip. * GTK Viewer. This was a learning experience for someone who was writing their first major GTK app. Learning experiences are great, for the people doing the learning. Less so for everyone else. Problem? The requirements were never clear. The requirements were "draw Atoms in the AtomSpace" and it did that. But so what? Who is going to use this? What will they use it for? What is it good for? If you build a tool that no one needs, then it's not a tool, its artwork. * AtomSpace Viewer -- written in javascript and HTML5. Screenshot looks fairly impressive. I never saw it run. Was it useful for anything? Was it ever used to do anything useful? I don't know, I don't think so. However, based on the screenshot, it looks like it was "almost useful" .. for .. something!? * Glimpse. No clue what that was. I think it was HTML5 and javasccript. No surviving screenshots. * GephiMindAgent -- streamed Atoms to Gephi. Written in either C++ or python, not sure. The source code appears to have been lost. (I was unable to find it) * The present-day (as of 2017) AtomSpace Explorer -- javascript and Angular. Draws pretty pictures, but does not do anything interesting or useful. Conclusion: -- three tools were quick hacks that were used to do something actually useful and needed. But, as quick hacks, they had no future. -- five tools that draw pretty pictures, but did not do anything useful. Some or maybe even all of these might have been "platforms" that could be extended, enhanced to add new, useful features, so that they *could* be used for something useful. However, they all bit-rotted, before that happened. How do we avoid this problem in the future? Well, -- The tool needs to do something actually useful, today. Pretty pictures are not enough. -- It has to be maintainable and extensible. That means cleanly organized code, reasonable documentation, a build process that is reproducible. Should not depend on obscure, hard-to-find, unstable components. -- I think the above two are enough to guarantee a user base that is interested enough in the code to keep it moving forward. As long as there is a user base, bit rot can be mostly avoided. This email is too long already so let me cut it off here. The next task is really to solve the first bullet: what should the new system do, and how will that be interesting enough to keep it maintained? Also: can it be laid out so that the new system can be cobbled together by an extremely small number of programmers with a tiny amount of free time? These last two questions are non-trivial, and may be "unsolvable", if there are no willing users. -- Linas > > That’s the problem I’m trying to solve. A tried and true technology that > has strong community support is typically a good approach to solve that > kind of problem. That’s all. > > If you have other recommendations, fine. If they’re better tools to solve > the problem at hand, fine. > > On Sat, Jul 3, 2021 at 11:19 AM Linas Vepstas <[email protected]> > wrote: > >> Lansana, >> >> Let me be clear about this. There is nothing wrong with javascript, or >> with React, and I never once said that there was anything wrong with those >> technologies, or that this was NOT the correct solution. If you, or anyone >> else, can cobble together a solution based on that technology, I would >> welcome it. >> >> I am trying to open your eyes to other possibilities, to other ways of >> seeing the world. You are not the first programmer to walk this Earth, you >> are not the first person to have been faced with these kinds of problems. >> I do not enjoy reading insulting, demeaning emails, no matter who writes >> them. >> >> From what I can tell, you appear to be deeply immersed in "bro culture". >> This is a toxic behavior pattern, where young guys (usually white guys) >> think that they have all the answers to everything, and are quite willing >> to insult and demean anyone who is not a part of their "in group". Don't be >> that guy. Don't insult everyone who doesn't agree with your viewpoints. >> >> -- linas >> >> On Sat, Jul 3, 2021 at 1:58 AM Lansana Camara <[email protected]> wrote: >> >>> We hear you. You have a very strong opinion. But before you say, once >>>> again, how hard C and C++ is, and how easy javascript is, you should try >>>> Glade. https://glade.gnome.org/ And not just try it, but get good with >>>> it. Build an app with it. >>> >>> >>> I'll tell you what - you try React/TypeScript, and I'll try Glade. The >>> challenge is to build a cross-platform app that runs on desktop + web. >>> After experimenting, we can both come back with our analysis and >>> compare/contrast things like community support, the time it took us from >>> start to finish, difficulties encountered, etc. Deal? >>> >>> You've mistaken me for a biased, opinionated developer. Wrong. I use the >>> right tool for the job. >>> >>> On Fri, Jul 2, 2021 at 6:48 PM Linas Vepstas <[email protected]> >>> wrote: >>> >>>> >>>> Hi Lansana, >>>> >>>> >>>> On Thu, Jul 1, 2021 at 11:58 PM Lansana Camara <[email protected]> >>>> wrote: >>>> >>>>> >>>>> Keep in mind that even Grafana's UI is built in JavaScript ;) building >>>>> a modern frontend like what you're seeking using a language like C/C++ >>>>> would be an anti-pattern. It's simply harder to do it that way. >>>>> >>>> >>>> We hear you. You have a very strong opinion. But before you say, once >>>> again, how hard C and C++ is, and how easy javascript is, you should try >>>> Glade. https://glade.gnome.org/ And not just try it, but get good with >>>> it. Build an app with it. >>>> >>>> Now, if we had some kind of app builder for javascript, then, yes, you >>>> might have a point. But as long as you use words like "anti-pattern", that >>>> is just bomb-throwing. It basically illustrates that .. I dunno .. you are >>>> young and inexperienced, and haven't been around the block, yet. There's >>>> much, much more to this big wide world than what your friends are talking >>>> about. >>>> >>>> When you drink the Kool-Aide, ask yourself, "what did they put in this >>>> stuff?" >>>> >>>> --linas >>>> >>>> >>>>> On Thu, Jul 1, 2021 at 9:53 AM Abdulrahman Semrie <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Linas, >>>>>> >>>>>> (Sorry for not responding earlier. As Mike have explained, I'm on >>>>>> vacation and don't check my e-mail regularly. I should be able to answer >>>>>> more questions when I'm back next week) >>>>>> >>>>>> More or less, the three requirements that you mentioned above have >>>>>> either been partially implemented (1) or were planned to be implemented >>>>>> (2 >>>>>> & 3) in the previous Mozi platform iteration, albeit using the (now old?) >>>>>> Python API of the AtomSpace. The code for both the backend and frontend >>>>>> is >>>>>> available on gitlab in a private Mozi repository. I should probably >>>>>> export >>>>>> it to github and make it public. >>>>>> >>>>>> Going through the list of requirements: >>>>>> >>>>>> 1) We had an interface to create an AtomSpace from a scheme file but >>>>>> back then we had issues keeping the imported data into separate >>>>>> AtomSpaces >>>>>> and accessing them independently. If you remember. this is before you >>>>>> implemented the copy-on-write functionality. However, with the AtomSpace >>>>>> gRPC server <https://github.com/Habush/atomspace-rpc> that I wrote >>>>>> few months back, this is possible and I have been using multiple >>>>>> atomspaces >>>>>> to run annotation tasks but haven't developed a generic UI around it. >>>>>> >>>>>> 2) I was actually planning to extend the gRPC server by integrating >>>>>> it with Grafana <https://grafana.com/> for monitoring purposes. >>>>>> Unfortunately, I didn't find the time to implement it. AFAIK, Grafana >>>>>> handles much of the UI stuff and only needs some API for it to be used >>>>>> as a >>>>>> dashboard/monitoring tool. I think this is easier than writing a new UI >>>>>> code. >>>>>> >>>>>> 3) For the visualization, in addition to the visualizer in >>>>>> https://github.com/opencog/external-tools/, we developed our own >>>>>> custom Cytospace visualizer that visualized atoms representing >>>>>> biochemical >>>>>> entities using custom layouts. This is the visualizer used in the >>>>>> annotation service you linked above. The main issue we had with the >>>>>> Cytoscape visualizer was calculating the layout algorithms on the >>>>>> front-end >>>>>> when the size of the graph got bigger. I suppose anyone who wants to use >>>>>> a >>>>>> data explorer with the atomspace will eventually run into such a >>>>>> performance issue as the atomspace gets bigger. To resolve this, I >>>>>> created >>>>>> a small library <https://github.com/Habush/annotation-graph> that >>>>>> runs the layout algorithm on the backend and send the coordinates of the >>>>>> nodes and edges to the front-end. This code is not generic but some part >>>>>> of >>>>>> it can be reused or it can be refactored to make it generic. >>>>>> >>>>>> > Maybe a kind-of-like jupyter for the atomspace. >>>>>> >>>>>> This kind of functionality was also implemented on the old Mozi >>>>>> platform using cogserver but it needs updating. >>>>>> >>>>>> In conclusion, a skeleton of what you have listed above exists, but >>>>>> needs refactoring to make it generic/reusable and also merge it into one >>>>>> tool/product. >>>>>> >>>>>> On Saturday, June 26, 2021 at 10:04:34 PM UTC+3 linas wrote: >>>>>> >>>>>>> Hi Xabush, >>>>>>> >>>>>>> So I have a tough question for you: the MOZI webserver ... >>>>>>> >>>>>>> I'm trying to solve a meta-problem: I want to increase developer >>>>>>> engagement in opencog/atomspace. For that, it would be nice to have a >>>>>>> web >>>>>>> UI. Three of them actually, or four. >>>>>>> >>>>>>> 1) A web UI that allows users to create new atomspaces, and put (by >>>>>>> hand) some atoms into it, and visualize simple graphs. So, people can >>>>>>> point >>>>>>> their browser at it, and mess around. >>>>>>> >>>>>>> 2) A job control panel web UI. So, for the language learning >>>>>>> project, I have a collection of bash scripts that start and stop the >>>>>>> atomspace, and ingest text files, and take hours or days to run. I >>>>>>> thought >>>>>>> of MOZI because it has some similar requirements. >>>>>>> >>>>>>> 3) A data explorer. Given an atomspace, with say, millions of atoms >>>>>>> (from language learning, or from biochem), I want to explore what's >>>>>>> inside >>>>>>> of it: print all atoms in some cluster, ranked by frequency, or plot >>>>>>> some >>>>>>> histogram of mutual information vs frequency or whatever. Maybe a >>>>>>> kind-of-like jupyter for the atomspace. Again, I think of the MOZI work >>>>>>> in >>>>>>> this direction. You were trying to get a simple web UI for biochemists >>>>>>> to >>>>>>> use. I want the same deal, but for linguists. Under the covers, it's all >>>>>>> the same stuff: just atoms in the atomspace. >>>>>>> >>>>>>> How can this be accomplished? You've built some kind of custom >>>>>>> solution for 2 & 3 for MOZI, but I don't understand how to backtrack >>>>>>> out of >>>>>>> that, and custom-tailor it so that it works for language learning >>>>>>> instead >>>>>>> of ChEBI or PubChem. Any ideas? >>>>>>> >>>>>>> I mean, you and Hedra have put a lot of effort into these things... >>>>>>> >>>>>>> I see things like this: >>>>>>> https://github.com/MOZI-AI/annotation-service >>>>>>> >>>>>>> and this: >>>>>>> https://github.com/MOZI-AI/annotation-service-ui >>>>>>> >>>>>>> And I'd like to have it work for the kinds of graphs and systems in >>>>>>> the language-learning codebase, instead of biochemistry. What would it >>>>>>> take to have that work? Do I really have to start from scratch? Is >>>>>>> there a >>>>>>> way to recycle any of the work that you've done, and use it for other >>>>>>> applications? >>>>>>> >>>>>>> I don't want to go off and state the obvious, but maybe I should go >>>>>>> off and state the obvious: if this web UI stuff was generic, then other >>>>>>> users could use it, which means that other users could show up and help >>>>>>> fix >>>>>>> bugs and add features. It would grow the project overall ... it would >>>>>>> help >>>>>>> anyone interested in the atomspace and in singularitynet and all that >>>>>>> jazz >>>>>>> ... >>>>>>> >>>>>>> BTW, back in the days of Hanson Robotics, we had the same problem >>>>>>> ... I think we throw a lot of money at some Brazillian to create a WebUI >>>>>>> for the Owyl behavior tree subsystem, but .. of course, that code failed >>>>>>> with the AtomSpace, so it was like .. wasted money, wasted effort. .. we >>>>>>> still don't have a generic AtomSpace WebUI ... >>>>>>> >>>>>>> -- 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/d16f492c-26f2-4f21-807e-e02cfd8f7c6cn%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/opencog/d16f492c-26f2-4f21-807e-e02cfd8f7c6cn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> 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/CAPPXERrWx4%2B59Kf163pAnmyaOD%2B5bbQ0pSJ89vFbE50CPrSLNw%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/opencog/CAPPXERrWx4%2B59Kf163pAnmyaOD%2B5bbQ0pSJ89vFbE50CPrSLNw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> 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/CAHrUA35AAE89d4K6bxZeofcyDKbrsXkQCCcvBCGtRj-nv6OLhg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/opencog/CAHrUA35AAE89d4K6bxZeofcyDKbrsXkQCCcvBCGtRj-nv6OLhg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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/CAPPXERpw8PyF5%3DA9TN4c2FeNcbTqRPnokVA4S%3DOQEukh65qVCg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/opencog/CAPPXERpw8PyF5%3DA9TN4c2FeNcbTqRPnokVA4S%3DOQEukh65qVCg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> 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/CAHrUA35xZpJ%3Db6a3ZObT2AD1GjLdUVsFa6Q0DSMHBaow4GUSCw%40mail.gmail.com >> <https://groups.google.com/d/msgid/opencog/CAHrUA35xZpJ%3Db6a3ZObT2AD1GjLdUVsFa6Q0DSMHBaow4GUSCw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAPPXERony-grxxDKwf_c4TCqKwdUEcGc75FgADefSY1QQG-6HA%40mail.gmail.com > <https://groups.google.com/d/msgid/opencog/CAPPXERony-grxxDKwf_c4TCqKwdUEcGc75FgADefSY1QQG-6HA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAHrUA34dcgm78siGnQQicEyqfciQfk65mAXXRS2uLnm48giijw%40mail.gmail.com.
