Linas, Dashboards -- well, when I say dashboard, what I think of are things like > the BIOS boot-up screen -- menus and lists and configurable parameters and > you can navigate it with keyboard or mouse. My wifi router has a dashboard > -- it's a web page, you can configure wifi settings in it. My (android) > cell phone has one: it's the "settings" panel: you can change this or that > setting, turn things on and off. >
So I'm thinking the same thing but for generic data science with opencog. > Take this file, copy it to that directory, start this script, look at > diagnostic output, wait until the dataset is done, and when it's done, > paint a green dot, and if it crashed, paint a red dot. That kind of stuff. > Show me a graph of megabytes used so far, cause I have a datacap of 1 > million atoms per month. JK.😂 What you're asking for here is basically what they pay me the big bucks in Silicon Valley to build on a 9-5 schedule 😂 As previously stated, I really don't mind spinning up some boilerplate, such that a new frontend developer familiar with React and other modern technologies can get up and running with little hesitation. That would literally take me a day or two or effort, tops. But it wouldn't really include any functionality -- it'd just include the foundation to build functionality on top of. If you want a full on production-ready dashboard/control panel experience, with data visualization and data management...that is a different level of responsibility. Even if it isn't built from scratch, plugging your data into a pre-built system is not necessarily more trivial. As someone that doesn't have the full context of opencog/atomese that you have, it would be much easier if you could draw up some wireframes (or go to Upwork.com and hire a graphic designer to build some wireframes for like a measly $100) of the screens you're imagining in your mind. Once I see those screens, it will be much better for me in terms of figuring out the scope of work required here, which I can then clearly communicate back to you. On Tue, Jun 29, 2021 at 12:08 PM Linas Vepstas <[email protected]> wrote: > Reslav, (and Micheal ... below) > > Thanks! That is a very nice summary. I'm not sure quite where that leaves > me, except maybe back at square-one. I'd like to see some kind of cute > graphical atomspace browser that beginners could run, and ... ideally, run > the demos from the examples directory. > > Kind of unrelated to that is that I would like to have a data science > dashboard. So, what Mike says about MOZI -- but I am not working on > bioinformatics, I am working on learning. I have similar needs: I have > datasets that need to be managed and loaded. I have data-mining jobs that > run for hours (or longer). I have to start, stop, checkpoint things, make > backups. Then when I'm done, I need to make charts and plots to see what > happened. > > Currently, I do the above with a strange brew of README files, bash > scripts, config files, gnuplot, and the LyX word processor. I have found > that 99% of potential collaborators do not have the attention span to get > to the end of a README file. You have to be super-duper motivated to read > it, and follow the instructions. So I'm thinking that, vaguely, surely, > there must be some way of converting that into some kind of interactive web > pages that walk you through the steps. > > Again: MOZI has built something like this, but it is custom-tailored to > bioinformatics. And so I can't use any of it. If it was general purpose, > there would be the benefit of shared development: anything done by one > project (e.g. learning) could be used in another project (e.g. > bioinformatics). > > Dashboards -- well, when I say dashboard, what I think of are things like > the BIOS boot-up screen -- menus and lists and configurable parameters and > you can navigate it with keyboard or mouse. My wifi router has a dashboard > -- it's a web page, you can configure wifi settings in it. My (android) > cell phone has one: it's the "settings" panel: you can change this or that > setting, turn things on and off. > > So I'm thinking the same thing but for generic data science with opencog. > Take this file, copy it to that directory, start this script, look at > diagnostic output, wait until the dataset is done, and when it's done, > paint a green dot, and if it crashed, paint a red dot. That kind of stuff. > Show me a graph of megabytes used so far, cause I have a datacap of 1 > million atoms per month. JK.😂 > > Is there some kind of generic data science dashboard out there, that we > could adapt and use for managing opencog systems? > > --linas > > > On Tue, Jun 29, 2021 at 12:08 PM Reslav Hollos <[email protected]> > wrote: > >> TypeScript is a language, a superset of JS that adds syntax for optional >> types (which are extremely helpful). It can be used for React as well and >> for any other JS project. >> >> Angular is a UI framework which is in my opinion over-engineered and is >> built on top of bad practices like mutations (eg. two way data binding). >> Mutations are useful when performance is needed, but if not encapsulated >> tend to be the cause of too many hidden bugs difficult to detect or even >> fix. Newcomers I mentored had problems with Angular since it required too >> much knowledge to contribute even a little. Another example is the >> model-view-presenter structure which I've found to be hard to maintain on >> large projects, it was confusing to too many people and allowed for >> mistakes to happen very easily. Having such complexity at the very >> beginning takes focus away from the application. >> >> React is a UI library which I believe got it right from the start, it >> revolves around separation of concerns, app state propagates hierarchically >> downwards (unidirectional data flow) and changes are done with callbacks >> instead of directly mutating (these are called controlled components). >> Mutations can still be used, but are not used by default. React uses >> virtual DOM and an algorithm called 'reconciliation' that determines when >> and what to update in the DOM, since state changes generate new objects, to >> me it's simpler than Angular's Change Detection. All of which is debatable >> but in React things have mostly worked out of the box for me, while in >> Angular there were many times an extra step, a solution to a problem that >> should not have existed in the first place and felt like a workaround. >> React has JSX syntax that combines HTML and JS and recent updates added >> 'hooks' syntax which even more simplifies the state management. >> >> In short I think that React based projects have bigger chances for >> community contributions because of ease of use. >> >> About NPM, it can sometimes be tricky but I think it's manageable, it >> shares some problems/solutions from many different package managers, like >> mismatch of node version between dev environments, incorrect handling of >> package-lock.json (a file that hardcodes all dependencies of dependencies >> versions) or some library incompatibilities with another library which >> solution is usually in github issues comments. I use NPM in all JS projects. >> >> This is based on the experience I accumulated over the last 6 years. >> >> Reslav >> >> On Tue, Jun 29, 2021, 16:19 Linas Vepstas <[email protected]> wrote: >> >>> >>> >>> On Tue, Jun 29, 2021 at 8:57 AM Reslav Hollos <[email protected]> >>> wrote: >>> >>>> I'm also interested in AtomSpace UI and have had very pleasant dev >>>> experience with React (as well as TypeScript which I would recommend). >>>> >>> >>> Well, the current code is in "Angular" -- and is TypeScript. How >>> different is that? Are Angular and React two different versions of the >>> same thing, or are they completely different? I can code in javascript just >>> fine, but things like npm and etc. leave me stumped -- when there's a >>> problem, I don't know how to debug it. >>> >>> --linas >>> >>> -- >>> 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/CAHrUA34hy9RZBg897pPX-hwhkcf_%2BbHmE%2B4QRSsE60p%3DnjKb9Q%40mail.gmail.com >>> <https://groups.google.com/d/msgid/opencog/CAHrUA34hy9RZBg897pPX-hwhkcf_%2BbHmE%2B4QRSsE60p%3DnjKb9Q%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/CANHDs8%3DrtH%3DUwMb5zwetbX9UPk3XiFnTnw2hy--aNmDqXkr3%3DA%40mail.gmail.com >> <https://groups.google.com/d/msgid/opencog/CANHDs8%3DrtH%3DUwMb5zwetbX9UPk3XiFnTnw2hy--aNmDqXkr3%3DA%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/CAHrUA34UVtF9vnOua5YOEVQuwZo_Z3PJkNZGVVYaC3H4yNUycg%40mail.gmail.com > <https://groups.google.com/d/msgid/opencog/CAHrUA34UVtF9vnOua5YOEVQuwZo_Z3PJkNZGVVYaC3H4yNUycg%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/CAPPXERrZ5tpm5HD-nQxs09ykEUERzQ0hAcytrahzU_vE-UBhdg%40mail.gmail.com.
