A custom developed artificial neural network, which can grow over time and doesn't require normalization of input-values, within an as-a-Service structure.
Home Page: https://docs.hanami-ai.com
License: Apache License 2.0
Use OpenID Connect-/OAuth-Flow for the authentication process.
Add strerror(errno) in error-cases of bind, connect and so on in the networking-library to get additional error-output for easier debugging.
Location: https://github.com/kitsudaiki/Hanami-AI/tree/develop/src/libraries/libKitsunemimiNetwork
Even the m_websocket is initialized with new, a delete on the variable crash the program. In all examples for the websocket of the boost-library, they initialize it on the stack instead of the heap. For cleaning they make some dirty internal stuff, which failes when initializing it with new and try to delete at the end.
There have to be found a solution, how to keep the websocket open and cleanup without memory-leak.
Because there are only a few websockets expected in the life of a client, this seem not too critical at the moment.
Add CODEOWNERS-file
In the Dashboard there is already a logout-function. This only removes all cookies inclusive the auth-token. To make this process complete, the token should be blocked by the backend after the logout, as long as the token is not expired.
Rename libKitsunemimiHanamiMessaging to libKitsunemimiHanamiNetwork
The measurements of temperature, speed and power-consumption by Azuki should be persisted in order to no get lost when restarting the programm.
Rename BlossomLeaf to BlossomIO to be more expicit.
Each generic database-table should have the name-column mandatory beside the uuid and so on.
At the moment there is only one button to download only the pdf-version of the REST-API documentation. A modal should be added with options to change the output-format.
The data-items are at the moment a structure of classes, where each object within the tree is created by a new-call. At least thanks to the memory-leak-tests this is no place for memory-leaks, but it is slow to create and parse in libKitsunemimiJson. It have to be reworked to a structure, where everything of the tree is already on one single byte-buffer located. That way the massive amount of new and delete is not necessary and serialization and deserialization within the project is not necessary and makes the code much faster.
Set rules for develop and v* branches and v*-tags
At the moment the expired-time for a JWT-token is hard-coded to 3600 seconds (https://github.com/kitsudaiki/MisakiGuard/blob/develop/src/api/v1/auth/create_token.cpp#L163). This has to be change to be configurable by the config-file.
For error-messages within modals, there is already a basic error-output. For errors, which appear in actions like requesting lists or measurements when the connections is broken, there is no error-output, only an empty content with error in the console-output at the moment. So to increase the usability, there has to be error-popups for these asynchronous cases.
At the moment the generic library have additional library specific namespaces. For example libKitsunemimiJson has
namespace Kitsunemimi
{
namespace Json
{
...
}
}
this should be changed to only
namespace Kitsunemimi
{
...
}
Because in internal objects are uniquely named enough and it only blows up the syntax in the upper layers.
The libraries, which contain a parser-generator, can not be build with multiple threads in parallel, because it results in compiling errors. The only solution, which was found so far and is used in the build-scripts of the single repositories, is to limit the number of threads in the build-process only for this repositories to 1. For this new central pro-file in this repository, this solution doesn't work so well. For now only a global limit to 1 worked. This slows down all repositories, which doesn't need this workaround, which makes the build-process unnecessary slow.
A solution has to be found to fix this performance issue.
Actual this repository here serves only as central anchor for this project. All sub-components and libraries are only attached as git-submodules. The basic idea at the beginning by keeping all as separate repositories was the re-usability of the libraries in other projects. At this time I still had my automation tool, which had also used these libraries.
But there are problems:
Primary problem is the huge amount of maintenance workload for the huge amount of repositories, which will become even more in the future.
So I decided to close all the sub-repositories and merge the source-code of all into this repository here. This should make the workflow more effective. Even if this structure has its own disadvantages.
The generating of the REST-API documentation should also support OpenAPI-format as output.
Add a implementation of all client-functions in Rust.
Use actix-web for the implementation of the http- and websocket-client.
The current output of the system-information coming from Hanami is only a plain printed json. This has to be packed in a better graphical structure.
Add time-stamps as mandatory field to the tables in the database, which have the UTC-timestamp when the entry was created.
The library libKitsunemimiSakuraLang should be removed from the project. It contains a script-language, which I created this lib for my automation-tool SakuraTree. The primary feature was easily defining parallel tasks for a faster deploy-process.
I wanted to use the library again for the internal API of the Hanami-AI, but it changed over time and now only some minor parts are still used for the validation of input- and output-variables of internal APIs. The rest is not needed anymore and it doesn't seems, like this will change.
So even that means, that a huge amount of work becomes deprecated and lost, I decided to delete the library from the project, because I don't like dead and unmaintained code. The only parts, which are used, should be moved to libKitsunemimiHanamiNetwork, which use these parts at the moment.
Removing the library also means, that the jinja2-parser libKitsunemimiJinja2 becomes deprecated too, because it is not used anywhere else.
Actions in the single rows of tables are single buttons at the moment. This use much space and doesn't scale very well. So a dropdown-menu should be used, where all buttons are collected.
use Github-Actions as CI-pipeline
There were already multiple tries in the past to bring the core of Kyouko on a GPU. Main problem was the allocation of new memory and race-conditions. Past tests were already successful to run a network with the MNIST-test-case on a GPU, but the performance was very bad.
So other ways have to be found. Maybe GPU's could be used in a supporting way.
For the processing on GPU OpenCL has to be used for now, to be hardware independent.
Entries in tables should be clickable to show additional information of the resource in a modal.
Change origin from private gitlab to github
The measurements for the power consumption and the thermal production of the cpu are requested over the REST-API at the moment. To increase performance, the values should be pushed over the websockets. With this it would also be possible for live-updates of the data. For this there also is a redraw of the d3-output necessary.
There was an upstream-change, which breaks the github workflow badge in the readme-files:
Has to be fixed to this (example for libKitsunemimiCommon):
Because for more flexibility and consistent, only protobuffers should be used and not a mix. This should also make the code easier to maintain.
Because it was developed on a system with Intel-cpu, some metrics on can not be correctly read from systems with AMD-cpu.
Files to fix: https://github.com/kitsudaiki/Hanami-AI/tree/develop/src/libraries/libKitsunemimiCpu/src
Similar the the generation of the REST-API-docu the documentation of the database-schemas should be automatic too. This doesn't has to be done over a REST-API-endpoint
With openssl version 3, which is installed with ubuntu 22.04, there are compiler-warnings like this:
../../../libKitsunemimiCrypto/src/signing.cpp:35:33: warning: 'HMAC_CTX* HMAC_CTX_new()' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
35 | HMAC_CTX* ctx = HMAC_CTX_new();
| ~~~~~~~~~~~~^~
In file included from ../../../libKitsunemimiCrypto/include/libKitsunemimiCrypto/signing.h:14,
from ../../../libKitsunemimiCrypto/src/signing.cpp:9:
/usr/include/openssl/hmac.h:33:33: note: declared here
33 | OSSL_DEPRECATEDIN_3_0 HMAC_CTX *HMAC_CTX_new(void);
| ^~~~~~~~~~~~
The binary still build, but this has to be fixed.
Rename Sagiri to Shiori
At the moment all resources like data-sets are private, so only the user who owns it, the project-admin and global admin can see this. In order to change this, there are setter necessary for each resource to be able to change the visibility.
creae multiple users with different projects and permissions and look, what they can see from other useres depending of the selected visibilty more of the resources
The actual network-stack doesn't consider big-endian and little-endian architecture, which will result in crashed for example when the sdk-lib runs on another computer with different architecture or later when components will run on different nodes, which has potentially different architecture.
Changes:
To avoid brute-force-attacks against a user-account, there should be a counter for failed login-tries. After 3 failed login-tries there should be a forced wait time, which can be configured via config-file. Only after this timespan there should be login-try possible again. This should prevent brute-force attacks against a user-account.
At the moment only the unix-domain socket server are used for internal communication and not the tcp-server. But these only listen 0.0.0.0 they are a bit bad at the moment anyway. For future setups, this should be updated to be able to bind them to specific interfaces.
The actual workflow with repositories is not optimal, especially in regards to make central automatic tests over all repositories with API-tests in the near future. As preparation, this repository should not only be a link for generic issues and other organizational stuff, but should become the central point of this project.
When a task in the backend failed, there is no response for the user. The task should result in an error-state with a message of what went wrong.
The current output of the thread-mapping coming from Azuki is only a plain printed json. This has to be packed in a better graphical structure.
The temporary files, for example when uploading data-sets, are a very primitive implementation. The following work-packages are necessary to improve the files.
This Hanami-AI meta-repository should contain all repositories in context of this project as submodule, to have a direct like and the combined packages to check out all necessary repositories at once.
Docker images should be signed for security reasons.
Signing of docker-images: https://docs.docker.com/engine/security/trust/
The REST-API-docu should also contain every possible error-status for each endpoint.
Review and update/fix api-endpoints, like description, reqex and so on
Similar the the generation of the REST-API-docu the documentation of the config-files should be automatic too. This doesn't has to be done over a REST-API-endpoint
The actual build-scripts of the repository only rolling out the list of defined tags/branches of the listed repositories. This has two problems:
Desired behavior:
With this for developing new features, which affects multiple branches, there is no change in the build-script necessary anymore
The last two main-components, which were planned, still has to be implemented and connected to the infrastructure.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.