>
> 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.

Reply via email to