search

opennars / OpenNARS-4

MIT License
27 stars 8 forks source link

[Feature] GUI #7

Open bowen-xu opened 1 year ago

bowen-xu commented 1 year ago

Is your feature request related to a problem? Please describe.

Develop a GUI for PyNARS.

Describe the solution you'd like

The overall appearance should be similar to that of OpenNARS 3.0.4. Besides, it should visualize the four global evaluations of NARS, as mentioned in https://github.com/bowen-xu/PyNARS/issues/8.

image

The backend (NARS reasoner) and the fontend (GUI) should be totally seperated, in consideration of maintainability. An alternative technique of comminication between the two ends is RPC (remote process call) based on socket.

bowen-xu commented 1 year ago

Two candidate themes I like -

Qt-Material image

PyOneDark image

maxeeem commented 1 year ago

I like the second one, PyOneDark, looks more modern.

bowen-xu commented 1 year ago

I like the second one, PyOneDark, looks more modern.

OK, will try that. Though the first one seems more mature with sufficient documents

bowen-xu commented 1 year ago

The overall archtecture:

image

As a start point, the recent commit (https://github.com/bowen-xu/PyNARS/commit/2c221b8d48cccb5914ac6a92210eba6df61881c2) implement the window.

The following command is to run the gui

python -m pynars.GUI

Here are some alternative RPC packages:

Although I wrote an RPC package befere by myself, I prefer to use a mature package to avoid/reduce potential bugs.

I think the backend (NARS reasoner) can communicate with any type of frontends (GUI, Web, etc). So it would be better if the rpc technique selected is general rather than specific to python.

The runtime efficiency (how many data-packets per second to be sent) is not the major factor I concern, since we can use some techniques (e.g. cache) to decrease the communication frequency.

bowen-xu commented 1 year ago

Although I wrote an RPC package befere by myself, I prefer to use a mature package to avoid/reduce potential bugs.

I decide to use my own package, since I can't find an another RPC package which supports asyncio and websocket simultaneously.

gRPC supports http but not websocket, however, there would be a stable connection between NARS reasoner and GUI, and the datastream comes in real time. Using http in this situation is too wild for me.

zero seems to work, however, it has not supported "for async server (currently the sync server runs async functions in the eventloop, which is blocking)", as mentioned in its homepage.

In the tests shown in zero, it performs the best among zero, aiohttp, aiozmq, fastApi, and sanic. I compared my package aio_rpc with zero and found that aio_rpc is 4.7x faster than zero.

Framework Speed (req/s)
zero (v0.4.1) 2173
aio-rpc 10244

So I will have to write more documents on the repo aio-rpc.

ccrock4t commented 11 months ago

Technical Report

• Load/save the current state of the system from/to a file or database; • Internal clock display and Run, Walk, Stop commands; • Real-time display of the 4 global evaluators and other indicators; • A channel list, with on/off and show/hide commands; • Show/hide/pause/resume the Overall Buffer and Internal Experience Buffer; • Show/hide/pause/resume of the concepts in memory (selectively, as net- work or list); • Show/hide/pause/resume the content of a concept; • Inference log with watch/stop and selective display functions; • Task (belief?) derivation trees; • Adjustable parameters (volume, forgetting rate, decision threshold, ...) • Browse library of experiences and demonstrations; • Message windows with HELP and ABOUT information.

More Info

We still need the above implemented