Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 139 sur 182 PremièrePremière ... 3989129131132133134135136137138139140141142143144145146147149 ... DernièreDernière
Affichage des résultats 4 141 à 4 170 sur 5438
  1. #4141
    Après franchement, si c'est un projet avec du Vulkain et cie, sans milliers de fichiers etc. Un simple make fait le job pour ce genre de projet.

    Et sinon je rejoint l'avis de Kamikaze : si tu pars sur du Clion, ne modifie que le Cmakelist à la main sans te prendre le chou avec le reste.

  2. #4142
    Citation Envoyé par Nilsou Voir le message
    Je dirais : même réponse, à partir du moment ou tu a deux systèmes distincts pour 32bit vs 64bit, et que tu code pour l'un de ces systèmes, tu peux te permettre de ne pas faire de code compatible avec l'autre.
    Citation Envoyé par Kamikaze Voir le message
    Ouais je pensais à des trucs idiots. Perso quand je pense à void pointer je pense à stocker une adresse, dont la taille dépend de ton système, du coup si tu transmets ça via réseau ou autre si t'as des proc connectés et convertit etc. Je sais pas. Mais bref j'imagine que le post de Cwningen résume bien "censé être un type opaque et on ne doit pas te préoccuper de ce qu'il contient"
    Non, ce n'est pas un problème de taille, le -1 est bien de la même taille que le pointeur. Et on ne transmet pas un handle sur le réseaux, donc pas de problème de ce coté là non plus. Mon problème c'est que INVALID_HANDLE_VALUE avec ses allures de constante n'est pas une expression constante (dans le sens du C++). Alors qu'en utilisant intptr_t (ou LONG_PTR pour parler en Windows), il n'y aurait aucun problème. Mais à l'époque ou windows.h a été écrit ça paraissait sûrement être une bonne idée d'utiliser void * et -1 (il n'y avait pas de types chiants qui voulaient faire du C++).

  3. #4143
    Re ! Merci pour vos réponses

    Après enquête, il y a probablement plein de choses "en trop" dans le CMakeLists.txt généré (notamment, les groupes de sources de Visual Studio, avec les accents dedans, genre "Fichiers d'entête", etc).
    Rien de grave, mais du superflu que j'essaierai de cleaner pour arriver à mon CMakeLists.txt minimal fonctionnel.


    Et ça tombe bien, il sera suivi par Git donc je vais pouvoir y aller étape par étape.

    Et sinon, il ne manquait qu'une seule chose pour que ça fonctionne : les sous-dossiers du dossier des sources du projet de lib statique.
    Section d'include dans le fichier tel qu'il a été généré par le tool Python :
    Code:
    ################################################################################
    # Include directories
    ################################################################################
    target_include_directories(${PROJECT_NAME} PUBLIC
        "${CMAKE_CURRENT_SOURCE_DIR}/../../LapinCore/src"
    )
    Que j'ai donc modifié comme suit :
    Code:
    ################################################################################
    # Include directories
    ################################################################################
    target_include_directories(${PROJECT_NAME} PUBLIC
        "${CMAKE_CURRENT_SOURCE_DIR}/../../LapinCore/src"
        "${CMAKE_CURRENT_SOURCE_DIR}/../../LapinCore/src/io"
        "${CMAKE_CURRENT_SOURCE_DIR}/../../LapinCore/src/maths"
        "${CMAKE_CURRENT_SOURCE_DIR}/../../LapinCore/src/rendering"
        "${CMAKE_CURRENT_SOURCE_DIR}/../../LapinCore/src/utils"
    )
    Et boom, un p'tit clic sur "Run" :
    Code:
    F:\Developpement\Repositories\LapinRenderer\bin\x86_64\Debug\MS-Windows\LapinTests.exe
    Exercizing 3 suites :
      Exercizing suite 'LrPoint'... PASSED
      Exercizing suite 'LrVector'... PASSED
      Exercizing suite 'LrMatrix'... PASSED
    
    All suites : PASSED
    
    Appuyez sur une touche pour continuer...
    Et voilààà...
    Donc au final : solution du tool retenue, y'avait juste à rajouter quelques entrées de sous-dossiers de sources dans les include. EZ.


    Je vais pouvoir utiliser CLion sur le mois qui va s'écouler, pendant la période d'essai, et voir ce que ça donne. Sous Linux comme sous Windows.
    Visual Studio "non Code" me convient très bien, mais Netbeans j'avoue qu'il est un peu austère (même si infiniment mieux qu'Eclipse, en ce qui me concerne).

    Ah et sinon, c'est pas un projet Vulkan/OpenGL/whatever, c'est un projet de ray tracer.

  4. #4144
    Ah ok je vois c'est le truc classique de certaines API qui te passe un void* et tu convertis selon le contexte, genre le callback dans lequel t'es tu sais quel type tu veux. J'étais à l'ouest. J'ai jamais utilisé windows.h

    Mais au final ça reste de l'arithmétique sur des adresses d'une certaine taille non, et INVALID machin c'est juste une adresse spéciale?

    Je suis également pas sûr de piger pourquoi C++ interdit ça puisqu'il me semble que:

    #define INVALID_HANDLE_VALUE ((HANDLE)(LONG_PTR)-1)
    est forcément connu à la compilation donc dans la logique de ce que veut être constexpr.

    Y'a une explication ici, mais ça me passe au dessus de la tête: https://en.cppreference.com/w/cpp/la...#Type_aliasing

    reinterpret_cast (or equivalent explicit cast) between pointer or reference types shall not be used to reinterpret object representation in most cases because of the type aliasing rule.
    This rule enables type-based alias analysis, in which a compiler assumes that the value read through a glvalue of one type is not modified by a write to a glvalue of a different type (subject to the exceptions noted above).

    Note that many C++ compilers relax this rule, as a non-standard language extension, to allow wrong-type access through the inactive member of a union (such access is not undefined in C).
    Donc bref, ne pourrais tu pas faire tout ton dirty business via un truc propre comme tu disais que t'aurais voulu que ce soit, et tu cast les HANDLE.

    Code:
    #include <iostream>
    #include <windows.h>
    
    constexpr std::uintptr_t invalid_handle = 0xFFFFFFFFFFFFFFFF; // on se démerde pour avoir ça correct
    
    template<class T>
    void dirty_business(T input) {
        std::cout << "haha! " << (void*)input << std::endl;
    }
    
    int main() {
        auto object = 0;
        HANDLE test_handle = &object;
        std::cout << test_handle << std::endl;
    
        if((HANDLE) invalid_handle == INVALID_HANDLE_VALUE) {
            std::cout << "mais oui" << std::endl;
        }
    
        dirty_business((std::uintptr_t)(test_handle));
    
        return 0;
    }
    On est bien d'accord que c'est une idée de merde hein, mais bon en continuant comme ça, ça fonctionnerait non?

    - - - Mise à jour - - -

    Citation Envoyé par Taro Voir le message
    Re ! Merci pour vos réponses
    Bravo, ça tourne!!!

    J'espère que t'aimeras CLion, j'aime beaucoup (c'est pas encore parfait mais bon, j'ai pas trouvé mieux).

    Si t'as des questions repasse ici

  5. #4145
    Une question ( j'y connais rien au langage informatique ) on peut changer l'ia dans un vieux jeux sur dos ou amiga des années 90, debugger le jeu, rajouté des élements graphiques ?

  6. #4146
    Pour être précis, je voulais faire une classe pour avoir un type un peu plus propre pour gérer ce genre de ressource, puis ensuite utiliser le nouveau type avec quelque chose dans le style de unique_ptr.

    Code:
    template <typename T, T NullValue>
    class nullable_resource
    {
        // ...
    };
    
    using windows_handle = nullable_resource<HANDLE, INVALID_HANDLE_VALUE>;
    using unique_handle = unique_resource<unique_handle, CloseHandle>;
    
    using posix_fd = nullable_resource<int, -1>;
    using unique_fd = unique_resource<unique_fd, close>;

  7. #4147
    Citation Envoyé par calixie Voir le message
    Une question ( j'y connais rien au langage informatique ) on peut changer l'ia dans un vieux jeux sur dos ou amiga des années 90, debugger le jeu, rajouté des élements graphiques ?
    Si on avait le code source, ça serait plus facile (mais pas forcément légal).
    une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
    Canard zizique : q 4, c, d, c, g, n , t-s, l, d, s, r, t, d, s, c, jv, c, g, b, p, b, m, c, 8 b, a, a-g, b, BOF, BOJV, c, c, c, c, e, e 80, e b, é, e, f, f, f, h r, i, J, j, m-u, m, m s, n, o, p, p-r, p, r, r r, r, r p, s, s d, t, t
    Canard lecture

  8. #4148
    Citation Envoyé par Cwningen Voir le message
    Non, ce n'est pas un problème de taille, le -1 est bien de la même taille que le pointeur. Et on ne transmet pas un handle sur le réseaux, donc pas de problème de ce coté là non plus. Mon problème c'est que INVALID_HANDLE_VALUE avec ses allures de constante n'est pas une expression constante (dans le sens du C++). Alors qu'en utilisant intptr_t (ou LONG_PTR pour parler en Windows), il n'y aurait aucun problème. Mais à l'époque ou windows.h a été écrit ça paraissait sûrement être une bonne idée d'utiliser void * et -1 (il n'y avait pas de types chiants qui voulaient faire du C++).
    Hum, en quoi ce n'est pas une expression constante ? À la compilation on sait parfaitement comment transformer -1 en void* ...
    En plus ton post initial laisse entendre qu'il y a un intptr_t quelques part :

    Citation Envoyé par Cwningen Voir le message
    INVALID_HANDLE_VALUE (un define pour, en gros, (void *)(intptr_t)-1)
    En plus reinterpret_cast c'est bien fait à la compilation, donc je vois pas trop le soucis, surtout qu'il est bien précisé dans la doc de reinterpret_cast :
    3) A value of any integral or enumeration type can be converted to a pointer type. A pointer converted to an integer of sufficient size and back to the same pointer type is guaranteed to have its original value, otherwise the resulting pointer cannot be dereferenced safely (the round-trip conversion in the opposite direction is not guaranteed; the same pointer may have multiple integer representations) The null pointer constant NULL or integer zero is not guaranteed to yield the null pointer value of the target type; static_cast or implicit conversion should be used for this purpose.
    En plus, comment tu peux être certains que c'est bien un reinterpret_cast qui est fait si la syntaxe c'est (void*)-1 ?? Le compilateur appelle les cast dans cet ordre sur les cast de type C :

    1) When the C-style cast expression is encountered, the compiler attempts to interpret it as the following cast expressions, in this order:
    a) const_cast<new_type>(expression);
    b) static_cast<new_type>(expression), with extensions: pointer or reference to a derived class is additionally allowed to be cast to pointer or reference to unambiguous base class (and vice versa) even if the base class is inaccessible (that is, this cast ignores the private inheritance specifier). Same applies to casting pointer to member to pointer to member of unambiguous non-virtual base;
    c) static_cast (with extensions) followed by const_cast;
    d) reinterpret_cast<new_type>(expression);
    e) reinterpret_cast followed by const_cast.

    edit : en fouillant un peu, c'est bel et bien un reinterpret_cast qui est fait et c'est bel et bien un problème connu des constexpr de ne pas manger de reinterpret_cast au motif que « si c'est mal utilisé on peut aboutir à des comportement indéfini » . Donc voila, toutes les conversions d'adresses en autres choses et vice-versa ne semblent pas pouvoir être des constexpr.

    Il y a ce genre de méthode pour passer outre : https://arne-mertz.de/2017/06/steppi...y-from-define/
    Mais mon dieu que c'est laid ...

    On trouve pas mal de demande de devs pour que C++ allège cette contrainte en détectant les cas ou le reinterpret_cast est foireux. Parce que bon, là, faut avouer que c'est un brin ridicule quand même que (void*)-1 ne puisse pas être vu comme constante à la compilation alors que n'importe quel débutant peut écrire la chose en binaire sur papier ...
    Dernière modification par Nilsou ; 11/06/2021 à 22h00.

  9. #4149
    Citation Envoyé par Kamikaze Voir le message
    Bravo, ça tourne!!!

    J'espère que t'aimeras CLion, j'aime beaucoup (c'est pas encore parfait mais bon, j'ai pas trouvé mieux).

    Si t'as des questions repasse ici
    Merci

    Et deux modifs de plus ! J'ai fetch+rebase (oui, je le rappelle, pull c'est le mal ) sous Linux et j'ai essayé de faire un Run depuis CLion.
    Deux trucs à changer, tout d'abord la définition de préprocesseur _WINDOWS à virer dans le cas d'un build sous Linux (non bloquant, mais l'appli de test s'en sert pour faire un system("pause") à la fin si on est sous Windows, et j'veux pas que ça le fasse sous Linux), et ensuite des dépendances vers des libs Microsoft à virer également (bloquant, link en échec si je les garde). Même pas sûr que ces dernières soient vraiment nécessaires, en tout cas pour la plupart j'ai un grooos doute. Je tenterai un clean, mais sous Windows du coup, pour tester le link après modifs.

    Du coup, j'ai vu un peu plus haut dans le CMakeLists.txt, des if(MSVC) avec des trucs derrière, donc j'ai repris cette syntaxe pour distinguer les deux OS pour mes définitions de préprocesseur et de dépendances.

    Maintenant que je peux compiler, linker, et faire tourner l'exécutable sous Windows comme sous Linux via CLion (avec Vc++ ou G++ derrière), je peux attaquer le clean du projet pour virer les trucs qui ont l'air inutiles.
    J'ai vu différentes section de "stub" (genre pour Nuget, jamais utilisé perso) et puis y'a pas mal de trucs qui ont été repris de la solution Visual Studio qui ont l'air inutiles, comme je le disais plus haut.

    J'ai l'impression que CLion n'est pas vraiment prévu pour bosser avec des sources en dehors du dossier du projet.
    Tel qu'est mon CMakeLists, les fichiers sources de "LapinTests" sont listés mais pas ceux de "LapinCore". Et si je les drag'n'drop pour les éditer, c'est possible, après avertissement que je suis hors-projet. Y'a sûrement des choses à faire dans mon projet pour les lister correctement, ça fera partie du boulot à faire après cleaning.

    Je vais arriver à voir un truc équivalent au vsproject et au nbproject, j'vous l'dit !

  10. #4150
    CLion utilise le CMake pour déterminer si un truc fait partie du projet. Donc si tu ouvres un fichier source qui n'est pas dans le CMake, ou qui est dans le CMake, mais pas vraiment résolvable (mauvais chemin), il sera indiqué comme faisant pas partie du projet. Aussi si tu linkes une library déjà compilé et que tu n'en liste pas les sources, bah ça fait pas partie du projet. C'est logique tu verras, y'a aucune embrouille, faut juste s'habituer un peu au début, mais y'a rien de "caché" c'est très explicite.

    Le mieux serait que tu suives cet example:

    https://github.com/ttroy50/cmake-exa...ojects/A-basic

    Clone le github, ensuite avec CLion tu ouvres le dossier A-basic.

    Prends le temps de piger en regardant les cmake un par un et tu seras le roi du pétrole.

    Dans ton cas subbinary devrait correspondre à LapinTest et une library jouera le role de Core.

  11. #4151
    Oui ça semble logique

    C'est pas bien différent d'un projet vscode ou netbeans, si ce n'est que tu définis tout dans un .txt et si t'es pas familier avec la syntaxe ça paraît insurmontable au début.
    Là où pour un projet configuré via des menus dans un IDE la syntaxe importe peu, t'as juste à faire le tour des options pour spécifier celles qui t'intéressent.

    Mais je dois pouvoir lister mes sources et les inclure, pour qu'il ne couine pas quand je les édite, et surtout qu'il me les affiche dans la vue du projet.
    Idéalement avec les sous-dossiers (io, maths, rendering, etc).


    Je vais m'y faire c'est juste le début qui est un peu perturbant.

  12. #4152
    Citation Envoyé par calixie Voir le message
    Une question ( j'y connais rien au langage informatique ) on peut changer l'ia dans un vieux jeux sur dos ou amiga des années 90, debugger le jeu, rajouté des élements graphiques ?
    Le code source de la grosse majorité des jeux Amiga qui pèsent, c'est de l'assembleur.
    68000 parfois, mais aussi spécifiques aux chips sonores et surtout graphiques.
    Dans de rares cas, des jeux en C ou en Blitz Basic.

    Donc, la réponse est 'non'.

    Rares exceptions, si tu trouves des fichiers .mod ou .iff sur la disquette du jeu, tu serais en position de modifier les musiques ou les éléments graphiques. Mais en général ce sont les jeux perraves qui sont comme ça; les jeux optimisés sont à la fois compressés, packagés et protégés contre la copie. D'autant que les chipsets réels ou émulés sont toujours aussi limités, donc ne pas espérer faire de miracles.

    - - - Mise à jour - - -

    Citation Envoyé par Taro Voir le message
    Oui ça semble logique

    C'est pas bien différent d'un projet vscode ou netbeans, si ce n'est que tu définis tout dans un .txt et si t'es pas familier avec la syntaxe ça paraît insurmontable au début.
    Là où pour un projet configuré via des menus dans un IDE la syntaxe importe peu, t'as juste à faire le tour des options pour spécifier celles qui t'intéressent.

    Mais je dois pouvoir lister mes sources et les inclure, pour qu'il ne couine pas quand je les édite, et surtout qu'il me les affiche dans la vue du projet.
    Idéalement avec les sous-dossiers (io, maths, rendering, etc).


    Je vais m'y faire c'est juste le début qui est un peu perturbant.
    Ton projet, c'est simplement un dépôt git avec un CMakelist à la racine.
    Tu peux avoir des sources qui ne sont pas traitées par le CMake, elles apparaitront quand-même dans l'arborescence que tu définis comme tu veux.
    Idéalement, un CMakelist par répertoire et un add_subdirectory(monrep) qui est fait à partir du CMake du dessus et c'est marre.

    Un tel projet sera maintenant reconnu et avalé par Visual, c'est tout.
    Même QT s'est mis à CMake.

    Très franchement, je ne supporte pas l'idée d'avoir un fichier projet qui soit géré en interne par un IDE. Le CMake que tu fais pour CLion, il passe en ligne de commande sous Unix sans aucun souci.
    Je viens de faire de même sous Windows, dans le but de passer le truc en CICD: c'est un peu plus délicat et tricky mais ça passe également.
    Un projet ne doit pas être lié à un IDE, il doit exister par lui-même. Que l'IDE aide à le définir, OK.

  13. #4153
    Citation Envoyé par vectra Voir le message
    Très franchement, je ne supporte pas l'idée d'avoir un fichier projet qui soit géré en interne par un IDE. Le CMake que tu fais pour CLion, il passe en ligne de commande sous Unix sans aucun souci.
    Je viens de faire de même sous Windows, dans le but de passer le truc en CICD: c'est un peu plus délicat et tricky mais ça passe également.
    Un projet ne doit pas être lié à un IDE, il doit exister par lui-même. Que l'IDE aide à le définir, OK.
    Oui.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  14. #4154
    Perso je suis pour les conventions qui définissent la structure du projet en fonction de l'organisation de ses fichiers. Rust fait ça pas mal mais malheureusement cargo est quand même passé par là. Les systèmes de builds sont tous plus pourris les uns que les autres et franchement ça serait pas mal de s'en soustraire, et ça aiderait aussi grandement l'intégration.

    Raz le cul des trucs "modernes" comme Meson qui régressent complètement en fonctionnalités et ne supportent par exemple que Ninja pour l’exécution du build. Tous les projets open-source précédemment sous autotools migrent vers cette merde. Oui autotools c'est pourri, mais au moins ça s'intègre correctement.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  15. #4155
    Faut tout passer sous Gradle
    En vrai, Gradle gère plutôt bien le C/C++, très bien le web frontend avec JS/TS et trucs utilisant gulp/webpack/angular/vue etc, y'a pas que les langages basés sur la JVM. Il existe même des plugins pour Rust, mais je ne sais pas encore ce qu'ils valent.
    Et si c'est l'install Gradle (et donc d'une JVM ou JDK) qui vous fait peur, ça se fait en deux lignes de commande avec brew ou sdkman. Y'a même des paquets au moins pour debian et arch. Sous Windows + IntelliJ y'a rien à installer : il contient déjà un Gradle, et il (IJ ou Gradle si récent) permet de télécharger tout seul un JDK.
    En tous les cas ça vaut le coup de zieuter ça. Les sources du site de la conf MiXiT sont un bon exemple d'intégration backend Java + fontend JS, tout (dont Gulp) géré par Gradle : https://github.com/mixitconf/mixit

  16. #4156
    Non mais en vrai c'est tout autant de la merde. C'est le genre de truc qui ne marche bien que si tout le monde utilise le même système de build. Quand tu intègres des projets hétérogènes c'est vachement plus sympa si les trucs fonctionnent ensemble sans avoir à réécrire les règles pour les recompiler.

    Et ensuite, si tu as un dénominateur commun pas trop mal foutu, disons Make par exemple, tu peux gérer proprement l'ordonnancement et le parallélisme de la compilation et gagner énormément de temps. Mais quand au milieux tu as des projets trop malins™ qui préfèrent se limiter à des outils modernes™, genre Ninja, et qui ne sont même pas foutus de s'ordonnancer entre eux, bah tu te retrouves à devoir sérialiser la compilation des différents composants, quitte à flinguer un gros potentiel d'optimisation, pour ne pas exploser ta machine de build quand tous les ninjas vont se dire que c'est une super idée de démarrer chacun #CPU process pour compiler du C++.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  17. #4157
    De retour pour des news

    J'ai fait encore du cleaning additionnel dans les configs pour mon projet version CMake.
    Je comprenais pas pourquoi la bibliothèque statique sortait bien dans ma hiérarchie bin/x86_64/<conf>/<os>/, et pas l'exécutable qui lui sortait dans un dossier bin/ à partir du dossier clpoject/ du projet. Tout en ayant un link qui se passait bien.


    Bref, j'ai identifié que ça venait de la masse de trucs un peu obscurs qu'il y avait dans le dossier CMake/ créé par le tool python.
    J'ai viré les références à ces fichiers-là, ça m'a sorti quelques erreurs mais au final ces lignes n'étaient pas indispensables donc je les ai virées dans la foulée.

    Magie, j'arrive à choisir mon dossier de sortie pour les binaires . Bon j'ai découvert après m'être arraché quelques cheveux qu'il s'agit de ARCHIVE_OUTPUT_DIRECTORY et non LIBRARY_OUTPUT_DIRECTORY quand on sort une bibliothèque statique.

    Bref ça y est c'est bon, j'ai viré la grosse majorité de la config, il reste à priori uniquement le strict nécessaire, ça compile, ça linke et ça tourne via CLion/VC++ sous Windows, je file pousser mes modifs pour tester dans la foulée que je peux faire la même chose sous Linux (compiler, linker, tourner, sans modifs additionnelles en théorie !).

  18. #4158
    C'est validé : ça fonctionne impecc avec CLion/G++ sur ma petite OpenSUSE. Nickel !
    Il me reste donc à continuer de coder sur le projet et, tout naturellement, je vais me familiariser avec ce nouvel IDE.

    Vous savez s'ils font des promos de temps en temps sur leurs licences ? 89€, ça reste acceptable, mais si y'a moyen de toper ça pour moins, je ne cracherai pas dessus.

  19. #4159
    Dans un an ça sera moins cher
    Ou tu déclares une adresse à Jersey

  20. #4160
    Tu t’inscris pour visionner des meetups type Java User Group, Php User Group, bref des Machin User Group. Il ya souvent des licences JetBrains à gagner. Et vu qu'il n'y a généralement que peu de spectateurs (j'aurais cru l'inverse avec le côté online depuis la pandémie ^^ mais les JUG n'ont jamais été aussi désertés, triste), tu as plus de chances d'être le grand gagnant de la loterie.
    En plus tu apprends des choses.

  21. #4161
    Yo les canards y'en a parmi vous qui touche du Mongo? Vous utilisez quel client?

    Ma boite me paye Studio 3T mais je trouve pas l'outil plus fantasse que ça. La seule fonctionnalité cool c'est la comparaison de base de données, qu'on peut sûrement programmer soi même mais bon, pour un truc quick & dirty c'est ok.

    Je me cherche quelque chose de mieux, avec de meilleures visualisations des données, une interface plus modulaire, etc.

  22. #4162
    Hello, on utilise pas mal Mongodb ici, et on a la version gratuite de Studio3T, robo3T.
    Autant te dire que tu as déjà de la chance d'avoir la version payante

    Pour la visualisation des données, peut-être que le client officiel te donnera plus d'infos selon ce que tu souhaites faire (mais c'est pas la panacée): https://www.mongodb.com/products/compass

    Mais sinon c'est un peu le vide niveau GUI, je n'ai jamais trouvé un client vraiment satisfaisant honnêtement...

  23. #4163
    Ok je vois. Je trouve les interfaces vraiment vieillottes ouais. Une couche graphique un peu pauvre qui ne fait que masquer quelques appels en ligne de commande.

    J'ai l'impression que y'a tellement peu de concurrences que ces produits dominent et font de l'argent facile sur les allergiques de la ligne de commande

  24. #4164
    Yeah, mongo c'est un peu comme kafka, les bons clients - même payants - se font hélas rare.
    D'ailleurs pour Kafka on m'a conseillé Offset Explorer 2. Pas transcendant, un peu relou mais fait le taff (et gère bien les params de connexion, c'est très complet à ce niveau), mais je peine à trouver plus agréable ou aussi léger (y'a des GUI type serveur web avec un dockerfile... ouch, ou des trucs de plusieurs Go, merci bien). Vous auriez une bonne adresse pour manger du kafka ?

    [edit] Pour MongoDB, JetBrains a intégré le support Mongo dans son client de bases de données. Donc plugin IntelliJ Ultimate (déjà intégré), sinon DataGrip. Je ne sais pas ce qu'il vaut, pas touché à mongo depuis.

  25. #4165
    Bon, les gens, questions Spring Boot, et plus particulièrement Spring Rest. Description (simplifiée) du problème :

    J'ai une méthode de mon API pour créer des profil utilisateurs au sein d'un client. l'Id (business, pas technique) du profil est fourni par le client. Chaque création se fait au sein d'une transaction, oeuf corse

    Bien entendu, chaque profil utilisateur doit avoir un id différent. J'ai donc une contrainte DB, ainsi une petite vérification au début de ma méthode qui renvoie benoitement une 409 en cas de conflit. Sauf que.

    un utilisateur de mon api fait de la merde (normal, vous me direz, c'est a ça qu'ils servent) et m'envoie coup sur coup deux fois la même requête de création. Les deux transactions démarrent quasiment immédiatement.

    Ce qui fait que ça merde à la clôture de la seconde transaction, avec une erreur de contrainte au niveau de la business key, et ça me balance une exception bien merdique en erreur 500, au lieu de ma 409 toute propre.

    D'ou ma question :

    Connaitriez-vous un moyen simple de "locker" une transaction ou un appel Spring Rest en fonction des paramètres de la fonction appelante (ici, le business id).

    Je pourrais faire un lock niveau BdD sur l'objet client, mais ça m'emmerde un peu, parce que ça serait pas très propre et que parce ça bloquerait toutes les modifications du client.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  26. #4166
    Tu peux gérer les créations de profils dans une file ?
    Le endpoint de créa de profil attend que sa demande sorte de la file pour donner une réponse.
    Voir si Spring propose des trucs déjà intégrés pour gérer ça. Voir aussi si ton API est hébergée sur un seul serveur, ou plusieurs. Si un seul, et si ça ne changera jamais (mauvais pari, mais bon...), tu mets un synchronized ou équivalent (de mémoire ton endpoint rest c'est un singleton donc un synchronized devrait aller) là où il faut et vala, les saves seront séquentiels.

  27. #4167
    Ah intéressant bidule, je vais tester l'option jetbrains!

  28. #4168
    Citation Envoyé par gros_bidule Voir le message
    Tu peux gérer les créations de profils dans une file ?
    Le endpoint de créa de profil attend que sa demande sorte de la file pour donner une réponse.
    Voir si Spring propose des trucs déjà intégrés pour gérer ça. Voir aussi si ton API est hébergée sur un seul serveur, ou plusieurs. Si un seul, et si ça ne changera jamais (mauvais pari, mais bon...), tu mets un synchronized ou équivalent (de mémoire ton endpoint rest c'est un singleton donc un synchronized devrait aller) là où il faut et vala, les saves seront séquentiels.
    Le problème de la file, c'est que ça reste complètement séquentiel. En gros, si deux utilisateurs veulent créer deux profile qui ne rentre pas en conflit, leurs demandes s'effectueront de manière séquentielle. Pas glop, et à ce niveau, autant lock le client au niveau DB, ça sera plus simple.

    Synchronized, j'y ai pensé, le souci, c'est qu'il porte sur une instance, pas une valeur. Donc pas possible de synchroniser sur la valeur du paramètres, comme je le souhaitais. Après, y'a la librairie XSync qui gère ça, c'est p'têt une solution

    j'ai p'têt moyen de me démerder avec une collection "Thread safe", soit en passant par les coroutines Kotlin, soit via un singleton dédié, mais bon, a ce niveau, beaucoup de boulot pour un ROI faible, autant locker le client et corriger le souci quand ça deviendra un problème.

    L'idée, c'était surtout de voir si des gens avaient déjà rencontré ce souci dans une app Spring, et si y'avait une solution "toute faite".
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  29. #4169
    Citation Envoyé par Teocali Voir le message
    Le problème de la file, c'est que ça reste complètement séquentiel. En gros, si deux utilisateurs veulent créer deux profile qui ne rentre pas en conflit, leurs demandes s'effectueront de manière séquentielle. Pas glop, et à ce niveau, autant lock le client au niveau DB, ça sera plus simple.

    Synchronized, j'y ai pensé, le souci, c'est qu'il porte sur une instance, pas une valeur. Donc pas possible de synchroniser sur la valeur du paramètres, comme je le souhaitais. Après, y'a la librairie XSync qui gère ça, c'est p'têt une solution

    j'ai p'têt moyen de me démerder avec une collection "Thread safe", soit en passant par les coroutines Kotlin, soit via un singleton dédié, mais bon, a ce niveau, beaucoup de boulot pour un ROI faible, autant locker le client et corriger le souci quand ça deviendra un problème.

    L'idée, c'était surtout de voir si des gens avaient déjà rencontré ce souci dans une app Spring, et si y'avait une solution "toute faite".
    Pour moi c'est un cas aux limites, pas la peine de te prendre la tête avec ça, sauf si ça gêne vraiment le métier. Si c'est la 500 qui te gêne il y a sûrement moyen de distinguer l'exception produite par la DB et de recover avec un 409 non ? Si le double send vient d'un front, ce serait plus simple de gérer ça niveau front.

  30. #4170
    Coucou les gens,


    J'aurais besoin d'un coup de main sur Gitlab!
    J'utilise le Trigger pour, en gros, cloner et compiler un sous-projet 'api_common' qui est une dépendance de mon projet actuel.

    Je fais ça deux fois, car j'ai deux projets 'project_1' et 'project_2' qui ont besoin de l'api.

    Chaque fois que je push dans master sur projet_1 ou projet_2, le gitlab-ci s'active, va cloner localement l'api_common, la builder, puis builder le projet. Ca marche nickel.

    Sauf que, ce que je voudrais maintenant, c'est forcer une update des pipelines de projet 1&2 chaque fois que je fais un push dans 'api_common'.

    On a essayé de gérer les 'project subscriptions' du projet 1 & 2 pour y ajouter l'apo_common, mais ça n'a pas été possible (les dépôts ne sont pas publics).
    Je voulais savoir si quelqu'un avait une idée pour mon cas, ou de manière générale pouvait m'éclairer sur les bonnes pratiques qui sont d'usage dans ce cas là. J'ai vu passer les webhooks aussi, mais pas sûr que ce soit ce qu'il me faut

Page 139 sur 182 PremièrePremière ... 3989129131132133134135136137138139140141142143144145146147149 ... DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •