On Saturday, 3 July 2021 at 03:48:53 UTC+2 linas 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. > Ah, I remember toying with Glade… a decade ago. I don’t think GNOME developers use it anymore - GNOME Shell itself uses JavaScript nowadays for example. A better proposition for C++ would be QtCreator because it and Qt framework at least are supposed to be cross platform - there is a UI designer in QtCreator of course. All in all the problem with these is that they make you stuck with a specific tool (Glade / QtCreator) and framework (GTK+ / Qt) and none of those are particularly popular anymore (besides GTK+’s niche in Linux world). > > Now, if we had some kind of app builder for javascript, then, yes, you > might have a point. > A quick search shows that there are some options for JS too, like https://openchakra.app, https://reactstudio.com or https://builderx.io. > 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/a71bc91a-2316-4c2e-8876-8c9cf5077c82n%40googlegroups.com.
