OpenAI devrait porter le nom de "OpenCrate with Rust" surtout si c'est le projet d'un GrandPère de l'AI qui gage sur IDF slint.
Crate Cargo Rust...
À ma découverte de vouloir, ne par utilisé un MacIntosh, un Apple ou une paire de lunette de Apple pour voir foirer en beauté Rust avec son CARGO de "CRATE", et surtout de n'avoir pas réussi à laisser le "Rust Playground" ouvert plus de 5 minutes sur ma machine en Firefox et voir l'interface planter après avoir testé un projet de "base64", celle d'affiché un menu en mode texte.
IDF tient de l'acronyme ( Intel Developpers Framework ). Et personnellement voir un projet Rust tenir avec des clamps( appelé mitaine dans mon cas ) avec IDF reste un jeu d'équilibre. Facile à briser et relate des thèses et des manipulations qui demandent apparemment d'augmenter l'index mémoire, de la pile si vôtre projet slint plante une fois sur vôtre puce esp32s3.
Côté Arduino
À ma découverte j'ai installé IDF 5.1.5 qui est proche du développement Arduino esp32 (version 3.0.5 et utilise IDF 5.1.33-d... ). Et oui suite à l'adoption de esp32 esp32s3, et esp32 par Arduino toutes les possibilités le projet slint semblait fabuleux et ne comprend même pas l'IA en ce moment que le projet est hyper dépendant de esp32s3... Alors ma cassette esp32 N16R8 fait pitié. Êtes-vous poser la question des différence entre esp32s3 et esp32... Selon xtensa et le projet gcc qui compile le tout, il y a le esp32 est un risv32-i et esp32s3 est risv32-imac supportant à titre d'exemple un codec de "digest" appartenant au processeur et nécessite une revalidation successive lors que des clé de B-Tree son sollicités et extraites. Simplifiant l'accès aux méthodes de classification par clé, les étudiants oublient souvent de refaire le calcul et les index de B-Tree dans des systèmes appelé arborescence neurale classifié. Alors la esp32s3 ne l'oublie pas. Ayant vue ZÉRO appel de l'IA à travers le projet en date des derniers jours, toute le "crémage" de gâteau pour créer une interface graphique au lieu de se basé sur LVGL semble futile à la question, va-t-il resté de la place sur ta cassette M5-Stack "et similaire" en format S3, apparemment esp32s3 avec N8R8 quand il est bel et bien indiqué d'augmenté la taille de la pile pour permettre l'interface graphique de fonctionné, pourrait-elle faire planter la partie IA, ajouté à l'interface. À ma vision de dire tu dois refaire le tout pour séparer l'interface graphique sur une partie, la partie esp32 pure et interconnecté l'IA sur une connection entre un esp32s2, esp32s3 ou même esp32c6 elle serait saine et non-affecté par les problèmes d'interface graphique. Mais je ne connais pas la taille de ton interface graphique, je n'ai ni pu compilé la version de idf pour slint et encore moin réussi à faire marché cargo qui a demandé de compilé i-slint en mode "non_std" qui ne demande pas l'accès au LLVM.
Et quand Rust/Cargo plante.
Çà c'est l'image de cargo avant que sa plante. Et à vrai dire cargo tue la fenêtre de gnome-terminal à la droite et disparait. Ce n'est pas la version de Q.T. avec lequel il y a un bouton "Cargo Build", c'est que la version texte et terminal qui plante.
- Ici en train de compiler i-slint le module dans lequel un fois compilé devrait laissé le idf faire un build et bâtir uniquement l'interface qui sera "flasher" sur la puce esp32s3 et qui à 0 IA dans le code. Pourquoi uniquement sur le esp32s3... Alors même à quatre tentative de compiler i-slint ne fonctionne pas. J'ai essayer d'ajouter le nécessaire pour aussi détecter la puce esp32 et même problèmes
Alors pourquoi parlé de Rust et surtout le générateur de solution qu'ils appellent "Cargo" et contient selon eux des "CRATES" qui sont collé ensemble à travers une liaison similaire au "LLVM". À ma merveille il n'y avait pas d'installation de "LLVM" à la demande du projet "slint" qui demande l'installation de "slint" et demande de ne pas installé les version d'origine du OS dans mon cas la version "Ubuntu 22.04" potentiellement ralentis des ajouts d'animation, ou victimes de l'alourdissement de mon OS par les ajouts d'animation. Compiler un projet de joueur de MP3 demande 90 minutes et plus en mode visuel et se divise par 2 si je recommence en mode texte via l'init-3 de ma box linux. Toujours parlant de ma boîtes Raspberry pi4 avec 4 Giga octets de mémoire. Et ce n'est pas de m'offrir un MAC pour voir réalisé la compilation finale j'ai un autre exemple d'échec avec slint en mode std ( standar ).
Mes efforts sous Linux
Chez VDL2, j'ai eu mon lot de vérification de la récurrence et la possibilité d'avoir fabriqué ma propre version de pilote PPP adapté à une signature en fonction du temps pour aller voir le futur et y extraire slint contiendra OpenAI, je voulais faire une interface avec slint et des fenêtre sous Linus, Fedora Core à l'époque ou Ruby apparaissait. La génération de fenêtre avec un dual Pentium III à 700 Mhz et seulement 30 Gb d'espace au total. Vous savez c'est quoi ce faire prendre 3 Giga Octets pour faire fonctionner le LLVM, et pour l'installation et la gestion de fenêtre sous environnement linux demandait une compilation de i-slint, à planté dans plus ou moins les mêmes intervalles de l'image présenté dans cette nouvelle. Donc je conclus avoir trouvé un mensonge géant sur la fonctionnalité de OpenAI elle serait exclusivement MAC ou "friendly Windows" et je n'ai pas encore de machine Windows pour parler de la suite.Si il y en à une. Je prévois que ce grand-père de l'IA serait à quelques mois de présenté son projets et serait à base de mitaines pour empêcher, son MAC, son RUST ou son CARGO avec i-slint de planté avec idf.py. Et non je ne ferai rien sous MAC pour vous aider.