YBoy360 a écrit 833 commentaires

Si vous comprenez comment dessiner le légo, vous comprenez 80 % de la logique. il n'y a rien de tellement plus compliqué.

On est un peu dans la logique du langage turtle que certains on étudié il y a bien longtemps …

En relisant la doc du DSL, j'ai oublié de mettre un passage sur les selecteurs… Je l'ai mis, c'est fondemental pour comprendre comment développer des pièces. Il y a un minimum de sélector (6: top[XYZ], but[XYZ] acceptant ou non un paramètre).

Un exmple de code :

void "Basic Box and Studs"() {
    cd().box(length, length, height).butZ()
    .hollowedSolid(-thickness).topZ().wireFrom() {
        to(stud_spacing, stud_spacing)
        circle(stud_diameter)
        move(2 * stud_spacing, 0)
        circle(stud_diameter)
        move(0, 2 * stud_spacing)
        circle(stud_diameter)
        move(-2 * stud_spacing, 0)
        circle(stud_diameter)
    }.toFace()
            .prism(stud_height)
            .butZ(
              new Vec(
                  length / 2,
                  length / 2,
                  height - 2 * thickness)     <1>
            )
            .wireFrom() {
                circle(stud_diameter + wall_thickness)
                circle(stud_diameter, true)
            }.toFace()
              .prism(
                  height - thickness          <2>
              ).display(image())

}

Ce qui donne :

Ici, (1) butZ (buttom Z) va placer le crayon d'édition au centre de masse de la face la plus loin en direction de l'axe Z, en partant de la position en paramètre. On dessine ensuite le cylindre à partir de 2 cercles concentriques (2).

Merci Thomas ! ça fait longtemps que je suis dessus, en effet.

Ça n'est pas optimal pour le jeux vidéo.

• d'abord ça ne support pas les textures, même pas les faces colorées
• Il est moins limitant d'utiliser un Blender qu'un FreeCAD avec lequel on évite l'édition de mesh directement.

Mais rien n'empêche de le faire. Et tu peux importer importer dans Blender (via Stl) puis Godot.

On peut faire de l'export glTF, voir scripts:

cad-dsl-occt/build/install/cad-dsl/bin/cad-dsl sphere.groovy sphere.glb

On utilise l'export Glb et xpm via OCCT dans notre PLM pour FreeCAD voir preview-stp (compilé sans la XLib, avec EGL).

def a = assembly { place(importStep(args[0])) }

if (args[1])
    a.display(args[1])
if (args[2])
    a.display(args[2])

la méthode display prendra le path du fichier de sortie.

Avec le backend OCCT, on peut sortir du xpm (ou png), STEP, du Glb, du Stl (tout ce que peut sortir OCCT), et du FCStd avec le backend FreeCAD (entre autres).

En utilisant OCCT dans le viewer, on divise par 5 ou 10 le temps de génération des Glb / png par rapport à l'ancienne version qui dépendait de FreeCAD.

On peut également étendre le comportement du compilateur, c'est ce que l'on fait dans taack-ui. Ici pas besoin pour le moment. Mais je ne crois pas que l'on puisse simplement supprimer les types pour le coup.

Ce que j'ai du mal expliquer, c'est que ça :

double side = param('side', 20)

ServerSocket serverSocket = new ServerSocket(22_345)

while (true) {
    try (Socket s = serverSocket.accept()) {
        cd().box(side, side, side / 2).cut {
            position(new Vec(side / 2, side / 2, 0)) {
                cylinder(side / 4, side)
            }
            s << "Measures: ${measure()}"
        }
    }
}

C'est valide, le DSL est inclus dans Groovy. Je pense que c'est ça qui n'est pas commun.

En effet, on va dire qu'il manque des explications …

On peut utiliser double, BigDecimal, mais OCCT requière des doubles.

si tu n'utilises que des double, le type ne sert à rien… autant l'appeler grand_nombre_en_virgule_flottante_compatible_OCCT (ou gnvfco)

Je n'utilise pas que des doubles … Je peux utiliser des sockets, des classes, des objets … Je comprends pas ton point. Tu peux faire n'importe quoi, c'est comme du java, il faut typer sa variable. Mais c'est bien plus lisible, et expressif que du java.

tu écris des closures typées (j'insiste)

ça a l'air d'avoir du sens pour toi, pas pour moi et tu n'en démontres pas l'intérêt dans ton journal.

Pas que pour moi…

Les closures typées sont passées en paramètre de méthodes (en générale, le dernier paramètre). Elles permettent de donner la classe du delegate, grâce à l'annotation @DelegatesTo (je raconte ça pour que les intéressé regarde sur un moteur de recherche).

Ce que cela apporte :

void "Test cut 3 boxes"() {
    cd().box(1, 1, 1).cut {
        position(new Vec(1, 1, 1) * 0.6) {
            box(1, 1, 1)
        }
        position(new Vec(1, 1, 1) * -0.6) {
            box(1, 1, 1)
        }
    }.display()
}

box().cut ne prendra que les solides et ne résoudra que des méthode s'appliquant aux solides. Donc on évite à la compilation et durant la rédaction de code, des erreurs. Et l'IA ou la complétion de code sera bien plus rapide. C'est tout. Pas la peine d'avoir fait une thèse pour ça. En plus, comme c'est typé l'exécution est bien plus rapide.

En effet, voila ce que je nomme DSL (c'est aussi valide). Il y a 3 couches dans ce que l'on a fait :

• Le binding Java <-> OCCT ;
• Le pattern Builder (c'est un design pattern bien connu) qui m'a permit d'implémenter le début de ce que l'on peut appelé un DSL en évaluant les limitations de ce pattern ;
• Le DSL (qui est complet, contrairement au Builder).

Le DSL n'est qu'un arbre typé dans du Groovy. Tu peux reprendre les instructions du langage Groovy (if, switch …) et tu écris des closures typées (j'insiste). On peut utiliser double, BigDecimal, mais OCCT requière des doubles.

Groovy permet d'exprimer des grandeurs physiques et d'y associer des opérations. MAIS :

Les doubles sont en générale homogène à une longueur ou à des degrés dans notre cad. Pas de Kg, pas de durée, pas d'autres mesures physiques, donc l'overhead de remplacer des doubles par des quantité physique ne me paraît pas valoir la chandelle.

J'aurais, en effet dû expliqué l’acronyme DSL (Domain Specific Language), c'est un langage dédié à une tâche.

cd comme Cad DSL. Je tiens compte de tes remarques et vais corrigé les pages.

Concernant l'IA, un exemple est sur la page du plugin Intellij : cad dsl 4 intellij

De mémoire le prompt c'est "fais-moi un avion rc a turbine, en utilisant CAD-DSL" … Et je peux te dire que l'IA, va très très loin bien plus loin que ça :

=> Si tu donnes la référence de ta turbine, des servomoteurs, de ton imprimante 3D, de ton PLA-LW, l'avion sera équilibré et prêt à être imprimé, les paramètre de l'imprimante proposés.

Le tout en 5 minutes … en passant le CLAUDE.md à Claude Opus 5.5. Sincèrement, c'est la chose la plus impressionnante que j'ai pu voir en tech. Je n'osais même pas en parler ici, ni posté ce que j'ai obtenu.

Second exemple :

=> Le code des lampes OBSTA a été obtenu à partir d'un STEP de 8Mo, le code généré fait 17 Ko, 50% de commentaires, il est lisible et ultra-factorisé. Les features (symétrie, contraintes, réutilisation des contours) n'apparaissent pas dans le STEP, mais ça apparaît dans le code… On peut ensuite l'ouvrir dans FreeCAD et traduire le nom des pièce en chinois.

Pour info, il manquait un artefact sur maven, il est maintenant publié.

Donc si vous créez un projet, comme dans example.

Vous pouvez supprimer mavenLocal() du fichier Gradle.

Et normalement vous avez tout …

On est vendredi, tu ouvres une discussion sans doute intéressante, bref, bonne journée à toi, je vais aussi en profiter de la météo.

Le projet à plusieurs années, j'ai commencé à utiliser Claude jeudi dernier, et oui, faire un binding seul est chiant à mourir, et je pèse mes mots.

Ça ne justifie rien, ni la pollution, ni le temps gagné. On est d'accord. Mais s'arrêter aussi tôt dans le jugement est un peu péremptoire également.

Sur ce point je suis d'accord avec toi. Ce n'est pas difficile à intégrer, c'est juste que par moment il faut redémarrer, et malheureusement, c'est difficile de savoir quand.

Cela dit, je reste gêné par la licence AGPL d'un produit ayant vocation à être intégrer dans un autre. Qu'une application indépendante soit AGPL, très bien, il faudrait un LAGPL pour les composants de ce type.

Dans le cas de Collabora, le code tourne vraiment séparément de ton application, donc l'impacte au niveau des licences est moindre (mais du coup, c'est moins intégré…).

Il fallait comprendre que FreeCAD NX-Style, dispose aussi d'un PLM.

Pour le coup, je n'ai pas bien compris le lien avec Freecad-Strata qui est un PLM / PDM.

Il y a un truc, le plus gros contributeur de EasyPDM et Strata, c'est Claude. Toutes les solutions sont basées sur Git, donc c'est un peu différent de notre proposition.

Je n'ai pas compris la gestion des merges… c'est plutôt un écrasement … Il ne devrait pas appeler ça merge.

Je suis impatient de pouvoir tester la modélisation d'hélices et d'ailes.

En passant, j'ai beaucoup fait de mise à jour du module plm (que tu as commenté), j'ai la chance d'avoir eu de nombreux retours pour le coup, j'essaierai d'en faire un journal.

Je vais me renseigner sur le History Workbench.

Certaines fonctionnalités paraissent vraiment intéressantes, comme les comparaisons entre versions de modèles, que je ne pensais pas faisable.

On a un petit avantage avec notre approche, c'est de pouvoir identifier rapidement qui utilise un fichier, et aussi pouvoir intégrer l'historique à un workflow applicatif.

Pour la sauvegarde, effectivement, ce sera un élément gênant, mais ça n'a aucune incidence lors de la synchronisation. Les fichiers étant dé-dupliqués sur le serveur, il ne se passera strictement rien (juste un peu de bande passante consommée).

Malheureusement, la méthode isDirty n'est pas très bien gérée par FreeCAD dans le cas de documents liés. Donc il n'y a pas de solutions simple, à ma connaissance.

Dans le même genre, il y a la duplication de l'historique des documents modifiés, qui ne fonctionne pas parfaitement à cause de cela.

Concernant les forks d'historique, il y a un exemple dans la vidéo. Ça consiste juste à avoir plusieurs historiques d'assemblages proches. L'historique est linéaire. Dans l'approche choisie, 2 personnes partagent l'historique, c'est le dernier qui sauvegarde qui impose la dernière version. Les 2 personnes devront donc se mettre d'accord, ou avoir un historique distinct.

C'est du marketing non ? Une sorte mise en scène … les explications restent vraiment partielles.

Est-ce qu'au final ils ont réussi leur objectif ces agents pollueur ?

On achète encore pas mal de voiture du peuple en France … Et LinuxFR c'est du RubyOnRails !

Ce qui est paradoxal avec Omarchy, c'est qu'il ne mise que sur DHH, il y a aussi un coté mytho assez étoufifiant je trouve.

ça se voit trop : pas de 🚨 🎓 👨‍🏫 🎯 📌 kikoolol. Je ne serais pas fier..

Démissionner c'est combattre ? Courage fuyons !

C'est en partie dû à MS, qui a favorisé NVidia avec les versions successives de DirectX, au marché qui fait ses choix, pas toujours lié à la raison, s'il y en est une, peut être aussi une mauvaise gestion, comme c'est courant dans les grosse boîtes.

Bref, avoir une bonne techno ne suffit pas. Cela dit, Apple et Snapdragon utilise PowerVR. Donc ce n'est pas vraiment un échec.

Ta dépêche est passionnante ! Je n'ai que très peu de connaissance en micro-électronique. Même aujourd'hui, faire un adaptateur graphique n'est pas commun, alors en 1973-1976 … Je bookmark, félicitation.

Pourquoi ST s'est tourné vers Imagination Technologies ? Je ne peux que spéculer : NVidia était dépendant selon moi, à ST, pour la partie contrôleur mémoire. NVidia a dû monter en compétence sur ce sujet et trouver d'autres fondeurs plus compétitifs. C'est donc une raison industrielle (je spécule).

Une petite parenthèse, toujours selon mon vécu, la fin des gros Unix (IBM, SUN, SGI) était pour une grande partie dû au fait que le meilleur fondeur de l'époque était Intel, aussi bien en terme de prix qu'en terme de performances, et qu'il ne partageait pas ses FAB. Or, le choix de la FAB, la logistique, les réapro sont des éléments fondamentaux pour des produits industriels "grand public" (les Station Sun étaient des produits quasi grand public en 2000, comme le serait aujourd'hui un PC haut de gamme).

On oublie souvent que Tim Cook par exemple, était responsable de la logistique chez Apple, et pas de la R&D. Il a sans doute œuvré pour le passage vers Intel, puis vers ARM.

Il me semble que les Kyro 1 et 2 furent aussi conçues et fondues par ST, c'était également révolutionnaire. ça utilisait la techno de Powervr, elles pouvaient appliquer 8 textures en une passe, tout en consommant moins de bande passante que les GeForce 256 SDR pour 2 textures.

J'ai aussi travaillé pour un fabricant de gpu, responsable de XVR 4000… Je faisais des optimisation GPU et CPU, fin 90 début 2000.

A peu près tous les ERP (Entreprise Resource Planning), pour entreprise de plus de 100 personnes sont codé en Java. Pour le particulier je ne connais pas grand chose à part Minecraft et les jeux du sieurs écrivant cette nouvelle, et des app Android…

La grande force de Java c'est l'efficacité lorsque la charge augmente, en plus de la portabilité et du fait d'avoir accès à une plateforme, plus qu'un simple compilateur/langage.

Ça n'a pas beaucoup d'intérêt pour un particulier (le premier point): on va vouloir exécuter rapidement du code et que ça ne prenne pas trop de mémoire, la grande force du C et C++ (sans templates) est qu'il peuvent partager des bibliothèques en plus d'avoir un modèle de mémoire plus compacte.

Mais Rust, Java et les autres seront moins efficace, il n'y a pas de mécanisme simple de relocation de bibliothèque. Prenez un Kde, plus vous utiliser simultanément d'application KDE, moins il y aura de mémoire privé allouée à chaque app.

Bref, Java est très utilisé ou il couvre un besoin et est efficace. Le problème de la densité de mémoire pourrait être adressé par le projet Valhalla.