NEETBOX Cli was proposed for the following considerations:

• Users can create an empty project through neet init, containing premade configuration files and basic folder structure. We hope this functionality will be similar to react cli
• Users can view status of neetbox processes, and monit results marked by @watch
• Users can launch neetbox server and frontend via cli command neet serve
• Users can easily switch the data set being used or manage other file resources through cli. These file resources can be scattered everywhere. When users want to use them, they only need to select them in the cli, and neetbox will create soft links or modify the configuration files.

Since we are here to bring the new cli tools, @AndPuQing would like to introduce click for cli, which would be nice.

Our recent production testings show status api is storing excessive data into db

The two history db files in the screenshot shows that the size of a regular db storing images from client is of the same size as the one which does not store a single image.

The key reason for the problem is that the 'status' table is storing very long and duplicated information, which is storage wasting. Despite that, should it have any value, I think we should at least split status into parts and send them using websocket instead of http, since cpu and gpu usage are instant messages, and configs, which is not, should be stored only once.

• Multi-platform Test
• Websocket Access Test
• ...

Upcoming feature including frontend

Once user run bash command neet init and import neetbox in their python projects, neetbox should be able to trace down hardware and logging, as well as other things including up coming "ploting" features, in a frontend called neetbox frontend. neetbox frontend is an exciting feature in the next release.

Users may set up project to connect to the same neetbox backend (localhost by default) in their workspace config file neetbox.toml, and their logs via neetbox.logging.logger would print into not only console and files, but also frontends. Uses will also see CPU usage and platform information showing in charts on neetbox frontends. Uses can also register custom functions via neetbox.daemon.action (thats also an upcomming feature) and see a button on the frontend, they can trigger the function in their python code by pressing the button on the frontend.

Basically a neetbox client means a project running with import neetbox. users can run projects on multiple machines and let them connect a neetbox server, which gathers information and serves frontend.

But now, we are happy to announce that neetbox client, neetbox server, and neetbox frontend are going to merge into a single package. That is, the new ALL IN ONE neetbox. Once use launch a project with neetbox, neetbox generally check the server address. if it is localhost, neetbox will automatically launch a neetbox backend and frontend locally. If you want to run a neetbox server on cloud servers, you can launch it by bash command neet serve, and edit your projects' neetbox.toml to let them connect your server, the frontend will be launched on your server too.

frontend is on the way, @lideming is in charge and it should not take so long. See new features with frontend in the next release.

As you know, a user-friendly code style will improve the continuity of code development. Methods we need to discuss. There are the design I think,

1. Using black formatter for code format.
2. Using isort to manage imported modules.
3. Using flake8 for checking code style.

Welcome to give more methods to optimize it.

Currently neetbox server supports multiple frontend connects to the same client, and there should be only one client running at time:

However, server should enable multiple client online for the same project id, in case of user may want to run same code with different hyper params simultaneously.

I was trying to use NEETBOX daemon on windows, but it says

[OK]2023-04-14-12:00:25 > NEETBOX/init > Loaded workspace config from D:\GaGs\ntb-test1\neetbox.toml.
2023-04-14-12:00:25 > neetbox.daemon._daemon_client/connect_daemon > Connecting daemon at localhost:20202 ...
2023-04-14-12:00:29 > neetbox.daemon/__attach_daemon > No daemon running at localhost:20202, trying to create daemon...
[ERROR]2023-04-14-12:00:29 > neetbox.daemon/__attach_daemon > Could not fork subprocess because module 'os' has no attribute 'fork'. NEETBOX daemon won't work on Windows.

Would NEETBOX daemon support windows in the future?

This is my configuration file:

name = "vivy"

[logging]

[pipeline]

[integrations]
datasets = []

[daemon]
enable = true
server = "localhost"
port = 20202
updateInterval = 10
uploadInterval = 10
info = [ "log", "status",]

[integrations.environment]
gpus = "auto"

The problem is, as we want a not-dependency-intensive neetbox, we are trying to remove codes with heavy dependencies from core functions. To be specific, in order to avoid installing package 'thop'(which depends on torch) for non-torch users, we have removed import torch from the headings of each python file into the line where the packages are required to overcome the import errors for most of the packages. For example, in neetbox.torch.profile:

from thop import profile as _profile
def profile():
    case 1: ... return
    case 2: ... return
    case that needs thop: ... return

was changed to:

def profile():
    case 1: ... return
    case 2: ... return
    case that needs thop: 
            assert pkg.is_installed('thop')
            from thop import profile as _profile
            ... 
            return

It was simple until we added neetbox.integrations. I'm not a pro for Python things, but I found it much more clear if we move things related to third parties into neetbox.integrations. So what does the neetbox.integrations stand for? In general, neetbox.integrations contains plugins for the original neetbox codes which empowers neetbox with third-party-compbilities.

I first mentioned the idea in #19 , in which I suggest that we should move 'nvidia-smi' and 'conda' command line getters out of neetbox.utils. However, since I'm a little confused about how to effectively add plugins into python class, I'm not sure what to do next to form the general framework for neetbox.integrations. Anyway, I think I need some help. Further discussions and methods are welcomed and appreciated.

Related File(s): https://github.com/visualDust/neetbox/blob/master/neetbox/logging/logger.py

NEETBOX performs strange in cmd:

the output log in cmd is broken. But the logs in files are fine. Is there something wrong?

Many times, I found myself writing duplicated yet not-so-duplicated code for multi-model inferencing. For example:

In whatever project, there is a people-counting model called model1 and another panoptic segmentation model named model2, and I'm uploading the inference result of both model 1 and model2 to a web server. Things are clear so far.

The problem is that for the input camera1, the prediction result of model1 may not be real-time, and the number of people in the screen will change only for every few seconds, so every maybe five seconds, I need model1 to inference; on the contrary, model2 and the original input from camera1 are uploaded synchronously, that is, each frame of the picture from camera1 must have a one-to-one correspondence with each output of model 2. To achieve this, I need to start two threads or the same number of coroutines or something like that, running model1 and model2 separately. Among them, as long as model1 completes the inference, the result will be uploaded; and the picture of camera1 must wait for model2's output of the same picture before they are uploaded together.

So I started neetbox.pipeline, my purpose is, to prepare for the procedure above mentioned, only a few codes are needed:

@pipeline.input("camera1")
class camera1: ...

@pipeline.node("model1", inputs={'camera1':camera1})
class model1: ...

@pipeline.node("model2", inputs={'camera1':camera1})
class model2: ...

@pipeline.endpoint("websocket", inputs={'from_model1':model1,'sync_result_of_model2':[model2,camera1]})
class websocket: 
    if input is from_model1: 
        upload_model1(input)
    if input is sync_result_of_model2: 
        upload_camera1(input[1])
        upload_model2(input[0])

The idea was great, but not easy. Things are becoming harder for more complex forwarding and inference procedures. @PaperCube told me something about Directed Acyclic Graph which makes some sense. See also What is tape-based autograd in Pytorch? to get my point. Does anyone have some suggestions?

According to @lideming , neetbox backend is storing a lot of duplicate data. For example, when the number of CPU cores is large, the field about the CPU in status will repeat a large number of words "frequency" (one for each core). This is just an example, just to illustrate that we do store a lot of unnecessary duplicate data. Therefore, compressing the data before storing it will be a solution

Therefore, we are planning to add compression on columns which store json data using zstd

Further updates will be posted here.