Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 107 sur 182 PremièrePremière ... 7579799100101102103104105106107108109110111112113114115117157 ... DernièreDernière
Affichage des résultats 3 181 à 3 210 sur 5434
  1. #3181
    Bon, j'ai un problème qui me prends le chou aujourd'hui, j'ai besoin de l'aide des canard parce que j'ai beau fouillé j'y arrive pas.

    J'ai une librairie dynamique qui dépend d'une seconde librairie dynamique.

    Je charge cette seconde librairie dynamique avec dlopen et paf, je récupere un message d'erreur façon "undefined symbol : sem_post" ou "undefined symbol shm_unlink", ce genre de chose.

    Malheureusement ma science du fonctionnement des librairies dynamiques n'est plus ce qu'elle était.

    Normalement, si je ne me trompe pas, quand on charge une librairie avec dlopen on a absolument pas besoin de la charger à la compilation avec des "-lmalib", j'ai bon ?

    Ensuite, la question, c'est comment on peut utiliser une lib dynamique chargé ainsi avec une autre lib dynamique. Avant Ubuntu 20.04 ça marchait parfaitement mon bazare, mais maintenant je ne me souvient même plus comment ça marchait

    Prenons un exemple : j'utilise des fonction de la librairie mathématique dans lib1.so . J'utilise lib1.so dans lib2.so . A ce moment là lib1.so étant une lib dynamique il n'y a pas de lien entre lib2 et lib1 (si je fais ldd on ne trouve pas les noms lié). Quand je compile mon main.c j'ai beau faire ce que je veut, inclure -lm pour lui fournir les fonction mathématique ou quoi, la compilmation passe, mais à l’exécution il ne trouve pas les fonctions qui vont bien.
    Ce qui me parait normal à vrai dire, mais je ne sais plus comment c'est censé fonctionner bien

  2. #3182
    Ouais c'est la confusion entre Dynamic Linking et Dynamic Loading, là tu mélanges.

    On va prendre ce cas:
    App <- Lib1 <- Lib2

    Donc Lib2 est standalone, Lib1 dépend de Lib2 et App dépend de Lib1.

    Dans ce cas tu peux dlopen Lib1 dans App (dynamic loading) mais Lib1 doit (a priori) être linkée avec Lib2 (dynamic linking).

    Dans les deux cas c'est de la résolution de symbole au runtime mais les modalités sont un peu différente, en gros Dynamic Loading c'est le faire "manuellement".

    T'as un exemple complet là

    https://dwheeler.com/program-library...OWTO/x172.html

    (ou ici: https://tldp.org/HOWTO/html_single/C++-dlopen/)

    DL Library Example

    Here's an example from the man page of dlopen(3). This example loads the math library and prints the cosine of 2.0, and it checks for errors at every step (recommended):


    #include <stdlib.h>
    #include <stdio.h>
    #include <dlfcn.h>

    int main(int argc, char **argv) {
    void *handle;
    double (*cosine)(double);
    char *error;

    handle = dlopen ("/lib/libm.so.6", RTLD_LAZY);
    if (!handle) {
    fputs (dlerror(), stderr);
    exit(1);
    }

    cosine = dlsym(handle, "cos");
    if ((error = dlerror()) != NULL) {
    fputs(error, stderr);
    exit(1);
    }

    printf ("%f\n", (*cosine)(2.0));
    dlclose(handle);
    }

    If this program were in a file named "foo.c", you would build the program with the following command:

    gcc -o foo foo.c -ldl
    Donc là on voit bien que la librairie n'est pas linkée à la compilation, mais loadée au runtime "manuellement", et très certainement que la lib dépend d'autres lib, a priori via du dynamic linking.

    ---

    Ensuite chainer du dynamic loading, c'est autre chose, a priori ça marche mais bon faudra bien loader les dépendances dans l'ordre etc.

    Important de noter que le Dynamic Loading en "temps normal" n'est quasiment jamais nécessaire, si tu dynamic link, tu peux hotswap tes librairies, pas durant le runtime mais tu peux juste stopper l'appli, hotswap la lib, et relancer.

    Le seul avantage du Dynamic Loading c'est la possibilité de hotswap durant le runtime, qui très honnêtement est un cas auquel il est très difficile de trouver un intérêt, tu gagnes extrêmement peu à faire ça, voire rien. Et charger des comportements dynamiques au runtime ça s'appelle...: programmer une application!

    Donc je te conseille de toujours rester sur du Dynamic Linking, c'est bien plus solide.

  3. #3183
    Citation Envoyé par Kamikaze Voir le message
    [...]

    Le seul avantage du Dynamic Loading c'est la possibilité de hotswap durant le runtime, qui très honnêtement est un cas auquel il est très difficile de trouver un intérêt, tu gagnes extrêmement peu à faire ça, voire rien. Et charger des comportements dynamiques au runtime ça s'appelle...: programmer une application!

    Donc je te conseille de toujours rester sur du Dynamic Linking, c'est bien plus solide.
    Globalement très d'accord, et j'ajouterai que le Dynamic Loading peut être aussi souvent utilisé dans les mécanismes de plugins (sans pour autant utiliser la possibilité de les recharger plusieurs fois pendant la vie de l'application).
    Dernière modification par Mr Slurp ; 25/09/2020 à 18h53.
    La programmation est une course entre le développeur, qui s’efforce de produire des applications à l’épreuve des imbéciles, et l’univers qui s’efforce de produire de meilleurs imbéciles... L’univers a une bonne longueur d’avance !!!

  4. #3184
    Citation Envoyé par Kamikaze Voir le message
    Ouais c'est la confusion entre Dynamic Linking et Dynamic Loading, là tu mélanges.

    On va prendre ce cas:
    App <- Lib1 <- Lib2

    Donc Lib2 est standalone, Lib1 dépend de Lib2 et App dépend de Lib1.

    Dans ce cas tu peux dlopen Lib1 dans App (dynamic loading) mais Lib1 doit (a priori) être linkée avec Lib2 (dynamic linking).

    Dans les deux cas c'est de la résolution de symbole au runtime mais les modalités sont un peu différente, en gros Dynamic Loading c'est le faire "manuellement".

    T'as un exemple complet là

    https://dwheeler.com/program-library...OWTO/x172.html

    (ou ici: https://tldp.org/HOWTO/html_single/C++-dlopen/)



    Donc là on voit bien que la librairie n'est pas linkée à la compilation, mais loadée au runtime "manuellement", et très certainement que la lib dépend d'autres lib, a priori via du dynamic linking.

    ---

    Ensuite chainer du dynamic loading, c'est autre chose, a priori ça marche mais bon faudra bien loader les dépendances dans l'ordre etc.

    Important de noter que le Dynamic Loading en "temps normal" n'est quasiment jamais nécessaire, si tu dynamic link, tu peux hotswap tes librairies, pas durant le runtime mais tu peux juste stopper l'appli, hotswap la lib, et relancer.

    Le seul avantage du Dynamic Loading c'est la possibilité de hotswap durant le runtime, qui très honnêtement est un cas auquel il est très difficile de trouver un intérêt, tu gagnes extrêmement peu à faire ça, voire rien. Et charger des comportements dynamiques au runtime ça s'appelle...: programmer une application!

    Donc je te conseille de toujours rester sur du Dynamic Linking, c'est bien plus solide.
    Ok merci pour les éclaircissement.
    En fait j'ai fini par trouver ce qui n'allez pas. La "lib2" dans ton exemple dépendaient de pthread et ltr, mais ce n'était pas indiqué à la création de la librairie. Sauf qu'en fait il faut que ça le soit au linkage lorsqu'on créé la librairie lib2 pour que lib 1 puisse gérer la chose et que le App comprenne ce qu'il se passe.

    Maintenant la grande question c'est : pourquoi ce programme fonctionnait parfaitement sous Ubuntu 16 et ne fonctionne plus sous Ubutu 20 (gcc 10) . ... il y a eu un changement autour de pthread et ltr ?

    Bon sinon je crois que l’intérêt ici c'était, dans l'idée d'avoir une appli qui ne charge que le minimum, c'est une appli qui fonctionne en lisant des script qui lancent des sous parties de code C (des "boites") et selon le script on a pas besoin de toutes les boites.
    C'était l'idée à la base, mais en vrai on l'utilise pas trop donc c'est un peu obsolète... (mais je peut pas vraiment changer ça aisément).

    Le but c'était, je pense, de pouvoir avoir un exécutable très petit accompagné juste des .so nécessaire en fonction du script utilisé à cet instant précis. Pour faire de l'embarqué notamment. (oui parce qu'il y a beaucoup de boites, donc ça économise des tonnes de codes).
    Mais avec l'évolution du matériel un exécutable de plusieurs mo ne pose plus vraiment de soucis, même en embarqué.

  5. #3185
    Généralement la pratique c'est de faire du Static Linking pour de l'embarqué. Le truc c'est que le Dynamic Loading n'affecte que la mémoire vive grosso merdo, sur le disque ça prendra la même place, donc l'argument embarqué n'est pas vraiment pertinent, d'autant plus que même avec du Dynamic Linking le truc n'est pas complètement idiot, puis bon ces considérations de "mémoire vive" c'est plus dans le programme lui même, tu gères ta mémoire comme tu veux, sans oublier le paging , y'a plein de systèmes embarqués sans cette distinction mémoire vive vs disque, etc.

    Mais bref on s'éloigne.

    Pour ton problème faudrait que tu redécrives tout à plat, j'arrive pas à suivre tes dépendances exactes. Regarde le code, si y'a une référence à un header, faudra le fournir à la compilation, si c'est du dlopen c'est dynamic loading mais il faudra que le truc loadé fonctionne déjà en standalone, donc qu'il compile et qu'il run en premier lieu.

    Honnêtement si tu poses tout à plat t'es garanti de réussir à faire tourner ton truc, surtout si c'est du C.

    Là je comprends pas si t'essayes de bouger les binaires d'une machine à l'autre, ou autre chose, s'pas clair, c'est la même famille de processeur au moins? Si tu compiles un truc sur du X86 t'sais ça tournera pas sur de l'ARM (bon là ça foire à la résolution de symbole mais s'pour l'exemple)?

    Si tu recompiles tout sur une nouvelle machine c'est garanti que ça fonctionne, si y'a eu une update de pthread qui brise la compatibilité (m'étonnerait mais bon) ça pétera à la compilation et tu verras l'erreur directement.

    En résumé: décris correctement tes dépendances, compile tes trucs dans l'ordre sur la nouvelle machine, du moins dépendant au plus dépendant, si ça casse tu répares.

    Ensuite exécute le bazar et ça devrait être bon, si à l'exécution ça foire je serai surpris.

    En regardant vite fait on dirait qu'il est possible que pthread ait changé d'une version à l'autre. pthread ça veut dire POSIX thread, donc c'est juste une spécification, implémentée différemment selon chaque OS qui est POSIX compliant.

    Donc ouais tu peux pas forcément juste bouger ton binaire, si c'est ce que tu as fait (après je suis pas un expert concernant les garanties de compatibilité qu'ils offrent, perso j'utilise toujours un niveau d'abstraction genre cmake ou autre, et je me soucis pas de ça).

    Ubuntu 16, z'ont ça:
    libc6-dev (2.23-0ubuntu11.2)
    GNU C Library: Development Libraries and Header Files

    Ubuntu 20:
    libc6-dev (2.31-0ubuntu9)
    GNU C Library: Development Libraries and Header Files

    D'après ce thread libc est backward compatible donc je doute qu'on soit sur la bonne voie:

    https://stackoverflow.com/questions/...sions-of-glibc

    ---

    Là ce que j'ai compris c'est

    Lib2 standalone (juste des dépendances système quoi), linkée à Lib1, et l'App dynamic load Lib1 ?

    Donc là il faudrait compiler Lib2, compiler Lib1, compiler l'App puis la lancer.
    Dernière modification par Anonyme20240202 ; 26/09/2020 à 10h11.

  6. #3186
    Citation Envoyé par Kamikaze Voir le message
    Généralement la pratique c'est de faire du Static Linking pour de l'embarqué. Le truc c'est que le Dynamic Loading n'affecte que la mémoire vive grosso merdo, sur le disque ça prendra la même place, donc l'argument embarqué n'est pas vraiment pertinent, d'autant plus que même avec du Dynamic Linking le truc n'est pas complètement idiot, puis bon ces considérations de "mémoire vive" c'est plus dans le programme lui même, tu gères ta mémoire comme tu veux, sans oublier le paging , y'a plein de systèmes embarqués sans cette distinction mémoire vive vs disque, etc.
    Ouais, je sais pas trop l'objectif de l'époque mais c'est comme ça maintenant et j'ai pas vraiment le temps de le retravailler.

    Citation Envoyé par Kamikaze Voir le message
    ...
    Pour le reste le cas précis c'est ça :


    Lib2 :
    C'est la librairie en bout de chaine, elle utilise des fonctions de pthread (sem_post etc.) et ltr (shm_xxx).
    Depuis 1990 que ce programme existe ( ) le programme était compilé très simplement SANS préciser la dépendance à pthread et ltr. En gros c'était un linkage très simple de quelques caractères. (gcc les .o et pif fait le .so)

    Lib1 :
    C'est une librairie qui utilise Lib2 via un linkage dynamique : en gros c'est simplement compilé avec gcc blabla -lLib2 et voila c'est tout et dans la Lib1 on inclut les h de lib2 et on utilise les fonctions de Lib2 et tout marche bien.

    App :
    C'est une app qui charge Lib1 en faisant un dlopen. De 1990 à 2020, sans changement de notre part, ça marchait parfaitement et là paf : unresolved symbol sur sem_post et cie (les symboles venant de la Lib2 via la Lib1)

    Au final j'ai résolu le problème en précisant explicitement à la création de Lib2 qu'il y avait pthread (-pthread) et ltr (-ltr). Et là paf, tout marche.

    Mais pourquoi tout marche maintenant et pas avant, c'est un mystere. Et je confirme que c'est bien QUE sous Ubuntu 20 et gcc 10, puisque j'ai relancé la compilation puis l'execution sur un Ubuntu 16 et ça marchait parfaitement.
    Note que tu peut simplifier grandement le problème si tu veut, sans que ça ne change le problème de fond, puisque j'ai fait un programme test qui charge Lib2 directement en dlopen depuis App et que c'était exactement le même bug. Donc ce n'est pas le chainage le soucis, c'est vraiment le dlopen de Lib2 qui pose problème.

    Sinon pour tes question : on compile toujours le programme en local dans notre cas, même sur embarqué. Comme ça aucun problème.

    Donc ici je parle bien du cas 1 qui marche :
    - compilation sous Ubuntu 16 puis lancement sous Ubuntu 16

    et du cas 2 qui ne marche pas :
    - compilation sous Ubuntu 20 (gcc 10) et lancement sous ubuntu 20.

    Le unresolved symbol était toujours au lancement, aucun problème à la compilation de lib 2, lib1 et app dans les deux cas.
    Alors pourquoi faut-il préciser pthread et ltr de manière exhaustive maintenant, c'est un grand mystère. Et en soit c'est assez chelou. J'avais enregistrer pour ma part que ça ne servait à rien de précise les dépendance à la création d'une librairie mais qu'il fallait plutot les redonner au programme final ...

  7. #3187
    Pas de changements des autres dépendances de ton application ? Peut-être qu'un de ces dépendances préchargeait libpthread et librt pour toi.

  8. #3188
    Ouais a priori pthread et consors étaient linkés silencieusement, possible selon le compilo ou autre (chaines de dépendances, du coup system specific). Il faut toujours linker pthread explicitement de manière générale, ou quelque dépendance que ce soit (faut bien un moyen de résolution)

    J'ai trouvé une histoire similaire ici: https://gcc.gnu.org/legacy-ml/gcc-he.../msg00263.html

  9. #3189
    Citation Envoyé par Cwningen Voir le message
    Pas de changements des autres dépendances de ton application ? Peut-être qu'un de ces dépendances préchargeait libpthread et librt pour toi.
    Nop comme je l'ai précisé, j'ai fait ctrl-c ctrl-v de l'appli sur un Ubuntu 16 et ça a compilé alors que ça ne fonctionnait pas sous Ubuntu 20 + gcc 10

    - - - Mise à jour - - -

    Citation Envoyé par Kamikaze Voir le message
    Ouais a priori pthread et consors étaient linkés silencieusement, possible selon le compilo ou autre (chaines de dépendances, du coup system specific). Il faut toujours linker pthread explicitement de manière générale, ou quelque dépendance que ce soit (faut bien un moyen de résolution)

    J'ai trouvé une histoire similaire ici: https://gcc.gnu.org/legacy-ml/gcc-he.../msg00263.html
    OK, c'est quand même surprenant ce changement "silencieux" sur les versions récentes, j'ai rien trouvé de spécial de mon coté
    Enfin bon, quoi qu'il en soit ça fonctionne ...

  10. #3190
    Putain, la dernière fois sur le topic je découvrais à quel point les mecs qui développent les drivers uboot sont des tanches, et là je découvre la programmation à la pisse de ffmpeg, c'est impressionnant de coder aussi mal, j'ai du mal à croire que le truc tourne tellement c'est laid.

    La documentation est en lice pour le titre du pire torchon jamais sorti, côte à côté avec cette moisissure d'OpenSSL. J'arrive pas à y croire, quand je pense que j'idolatrais à moitié les mecs qui faisaient ce genre de projet.

    Je comprends mieux toutes les news de vulnérabilités sur tel ou tel projet, c'est tellement le bazar, déjà un miracle que ça s'écroule pas, que la vérification de la solidité du truc que ce soit en terme de perf ou de sécurité tu peux oublier

  11. #3191
    Un soucis avec les projets communautaires, c'est que parfois la gestion des collaborateurs est délicate. Il y a des projets où des gens fournissent une fonctionnalité dans un gros bout de code, tout moche, difficile à relire. Mais au moins il y a une contribution, et les bonnes âmes se faisant rares lorsqu'il sagit de se retrousser les manches et coder, les responsables peuvent être tentés d'accepter les contributions, même les pires. Ce n'est pas une très bonne idée, mais c'est parfois ce qui maintient le projet en vie.

    Il y a aussi le problème des contributeurs qui n'assurent pas le suivi, sur le long terme ni sur le court terme, par exemple en ne répondant même pas aux retours sur une merge request (c'est je t'ai envoyé le code, tu l'acceptes ou tu le jettes, en gros). Je ne pourrais pas le leur reprocher, c'est très difficile, ni engageant (personne n'aime déboguer, alors que pousser de nouvelles features, c'est sympa et, surtout, c'est ça qui est visible ; et je ne parle pas du manque de temps libre...) surtout si tu touches à plein de projets, mais voilà, ça laisse le projet dans un mauvais état.
    Bref, sur un projet pro j'aurais du mal à excuser une mauvaise base de code, mais sur de l'opensource, j'ai envie de mettre une main sur l'épaule d'un mainteneur et lui dire avec plein de compassion "t'inquiète, je souffre avec toi". L'opensource, c'est rarement un groupe de barbus qui code ensemble dans un garage en regardant des comics. Pas mal se prennent pour les fils spirituels de Torvald, et ce n'est pas un bon exemple le type (d'après sa réputation, du moins). Il y a évidemment de bonnes communautés, peut être plus sympas/connes selon les technos, ché pas...

    Enfin, peut être que certains projets trop vieux (ça joue) ou mal en point devraient annoncer leur mort publiquement, faire un reset et repartir sur des bases saines.
    Par ex sur GitHub, combien de projets sans commit depuis 5 ans ? Sont-ils encore utilisables ? Parfois oui car la techno n'a pas bougé, parfois plus du tout. GitHub a pourtant une fonctionnalité d' "archivage", qui freeze le projet et le marque comme arrêté, mais trop peu de monde ne prend la peine de s'en servir, et préfère laisser son projet là, comme un zombie.
    Ffmpeg est peut être dans ce cas là : commencé (je n'affirme rien) à une époque ou les bonnes pratiques n'étaient pas ce qu'elles sont aujourd'hui, trop peu de sérieux ou de compétences, c'est devenu du bricolage. Un bon reset lui ferait du bien. Y'a d'ailleurs une lib SSL connue qui a fait ça nan ? LibreSSL ou un truc comme ça je crois, qui s'est fait connaître pour être jeune, plus petite et plus sûre que les grandes libs SSL toutes vieilles et moches. On en reparlera après un audit de sécurité ^^, mais ça fait du bien je trouve.

    Bon, après y'a aussi de vraies quiches hein ^^
    Dernière modification par gros_bidule ; 08/10/2020 à 01h27.

  12. #3192
    Ouais clairement, pour balancer mes propos FFMPEG donne l'impression de bien fonctionner en tout cas, c'est tout a fait utilisable a priori.

    Puis je me plaindrais jamais vraiment des projets open source, souvent c'est des mecs qui prennent sur leur temps sans vraie contrepartie.

    Simplement que c'est vraiment implémenté n'importe comment à tel point que ça donne des doutes quant à certaines fonctionnalités. Mais bon c'est aussi le style C old school j'imagine ou chacun fait ses abstractions à sa sauce. Et en effet on a l'impression sur certaines parties que c'est le travail d'une seule personne qui s'est pas soucié des gens qui allaient passer derrière.

    Faut quand même que j'aille jeter un oeil aux algos core voire si ça fait le travail correctement

  13. #3193
    Rien ne t’empêche de participer. Enfin j’écris ça mais je n’ai pas le niveau.
    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

  14. #3194
    Oui tout à fait, c'est ce que j'entendais notamment par: "je me plaindrais jamais vraiment des projets open source". Le principe c'est que tu peux contribuer.

    Mais en effet y'a moyen que j'y contribue, là en ce moment j'adapte toute cette soupe derrière une API claire (et je convertis ça en C++, mais ça c'est clairement un no-go pour eux, j'imagine qu'ils veulent la compatibilité du C), et je posterai p'têt ça sur Github à part.

  15. #3195
    Bin ffmpeg, c'est un projet qui a quasi 20 ans, ce n'est pas rien.
    Et il est aussi possible qu'une partie du code "moche" soit du à une nécessité d’extrême optimisation du code .

  16. #3196
    Citation Envoyé par olih Voir le message
    Bin ffmpeg, c'est un projet qui a quasi 20 ans, ce n'est pas rien.
    Et il est aussi possible qu'une partie du code "moche" soit du à une nécessité d’extrême optimisation du code .
    Ça joue mais c'est clairement pas la seule raison.

    Faut pas oublier que pas mal de contributions viennent de gens avec un background recherche/vidéo/signal/bas niveau et assez rarement "génie logiciel" (pour ce que ça peut vouloir dire).

    J'ai plusieurs potes qui ont fait des thèses dans la compression vidéo, avec des contributions pour HEVC/AVC et/ou ffmpeg. Et autant les mecs sont pointus dans leur domaine, autant j'aurais vraiment du mal à les considérer comme de "bons" dévelopeurs (et encore, avec les ressources actuelles c'est toujours plus propre que dans le code legacy qui a 20ans).
    C'est la faute à Arteis

  17. #3197
    Bonjour ! Je suis récemment tombé sur l'IDE Microsoft Visual Studio Code sur lequel j'ai pu bosser sur mes projets en python, pour changer de Jupyter Notebook. Franchement, j'aime beaucoup, surtout avec les modules disponibles.

    J'ai vu qu'il existe aussi Microsoft Visual Studio, également gratuit pour les particuliers. Mais, même en cherchant sur le net, j'ai pas trop compris la différence entre les deux (je ne comprends pas non plus tout ce qui est dit dans les fonctionnalités). Un truc qui m'intéresse dedans est le fonctionnement avec la suite Azure, si je me forme à ça. Est-ce que le premier est une sorte de version light du second ?

    Est-ce qu'un expert CPC a une idée ?

  18. #3198
    VS Code est compatible Linux et se veut plus généraliste : +facile de trouver des modules pour tout un paquet de langages via les modules. Visual Studio est plus tourné autour de C# et VB.net (même si des modules existent pour d'autres langages, notamment python/IronPython) et du developpement pour Windows, même si ce dernier point est de moins en moins vrai. Visual Studio est aussi plus "lourd", plus gourmand que VS Code.

    Je travaille principalement sur Linux et utilise plusieurs langages (bash, python, SQL, Lua ) et j'utilise VS Code mais ça dépend des usages donc.

  19. #3199
    Visual Studio n'est pas qu'un éditeur de texte, c'est toute l'ensemble des outils de développement Microsoft en plus de l'IDE : compilateurs, bibliothèques, ...

  20. #3200
    VS : c'est l'IDE historique, qui dit IDE dit un ensemble d'outils et d'intégrations diverses (tests unitaires, analyse performance, mémoire, tests d'infrastructure/de charge, etc)
    VS Code : c'est le petit nouveau, entre l'éditeur de texte avancé (type Sublime text/Atom) et le véritable IDE.

    En fonction de ce que je fais j'utilise l'un ou l'autre.

  21. #3201
    Ah merci ! Bah j'imagine que je suis trop noob en programmation pour avoir besoin de VS du coup, je vais continuer à utiliser VS Code

  22. #3202
    Bonjour les canards !
    Je vous propose un petit exercice qui m'a pris la tête hier, et j'ai bien envie de voir la solution que vous allez trouver: https://www.testdome.com/d/java-interview-questions/4 Question 11 :
    11 Route Planner
    As a part of the route planner, the routeExists method is used as a quick filter if the destination is reachable, before using more computationally intensive procedures for finding the optimal route.

    The roads on the map are rasterized and produce a matrix of boolean values - true if the road is present or false if it is not. The roads in the matrix are connected only if the road is immediately left, right, below or above it.
    Finish the routeExists method so that it returns true if the destination is reachable or false if it is not.
    J'ai réussi avec l'aide des canards, à faire un truc à LaRache et pas opti du tout, et qui choppe un score de 75% (le mieux que j'ai trouvé sur le net sortait 50% de réussite) .
    Sans surprise, le TU Performance test on large map: Wrong answer echoue, et c'est ça qui m’intéresse en fait: qu'elle est la solution optimisée ?

    Bref, ma solution est dispo ici, https://forum.canardpc.com/threads/1...1#post13117142 (et oui je sais, c'est moche )

  23. #3203
    J'ai l'impression qu'il te manque un certain bagage, ce ne sont pas des problèmes de programmation (enfin celui là en particulier, et celui du train je crois mais j'ai survolé), que tu peux résoudre parce que tu connais Java, c'est des problèmes de théorie des graphes, https://fr.wikipedia.org/wiki/Programmation_dynamique, etc. Sans avoir ces connaissances préliminaires tu ne peux pas t'attendre à trouver la solution que les mecs veulent. C'est plus un test pour savoir si tu connais ces sujets plutôt qu'un brain teaser generaliste/de programmation.

    Donc la typiquement: https://en.wikipedia.org/wiki/Reachability


  24. #3204
    Au dela du fait que l'algortithme pourrait sûrement être amélioré, le gros problème de perf qui m'a sauté aux yeux c'est que tu utilises la méthode "contains" sur des listes, elle est du coup en O(n). Si à la place d'utiliser des listes tu utilisais des sets, tu pourrais faire l'équivalent du contain en O(log(n)). Sur des matrices un peu grosses la différence devient vite importante.

  25. #3205
    Citation Envoyé par Garrluk Voir le message
    Au dela du fait que l'algortithme pourrait sûrement être amélioré, le gros problème de perf qui m'a sauté aux yeux c'est que tu utilises la méthode "contains" sur des listes, elle est du coup en O(n). Si à la place d'utiliser des listes tu utilisais des sets, tu pourrais faire l'équivalent du contain en O(log(n)). Sur des matrices un peu grosses la différence devient vite importante.
    Il faut mieux utiliser des tableaux de booléens pour ça, c'est O(1). En plus c'est ce qu'il y a déjà en entrée, donc on reste linéaire pour la complexité en mémoire (voire on peut même réutiliser le tableau d'entrée).

  26. #3206
    Citation Envoyé par Garrluk Voir le message
    Au dela du fait que l'algortithme pourrait sûrement être amélioré, le gros problème de perf qui m'a sauté aux yeux c'est que tu utilises la méthode "contains" sur des listes, elle est du coup en O(n). Si à la place d'utiliser des listes tu utilisais des sets, tu pourrais faire l'équivalent du contain en O(log(n)). Sur des matrices un peu grosses la différence devient vite importante.
    Oui, des listes de String c'est pas le mieux pour gerer les points visités, c'est sûr. C'est juste pour le PoC mais c'est vrai que je commencerais là pour opti.

    Citation Envoyé par Kamikaze Voir le message
    J'ai l'impression qu'il te manque un certain bagage, ce ne sont pas des problèmes de programmation (enfin celui là en particulier, et celui du train je crois mais j'ai survolé), que tu peux résoudre parce que tu connais Java, c'est des problèmes de théorie des graphes
    Mais tout à fait, theories des graphes j'en ai fait y'a 20 ans, j'ai tout oublié depuis. Apres, le but de l'exo est de fournir déjà une methode pas vraiment optimisé qui verifie "simplement" s'il existe un chemin (du coup le TU sur l'optimisation est relou, parce que pour le coup ma fonction couvrent tous les cas :D )

    Aprés, pour la pertinence de l'exo, c'est sûr que ce "test" est bidon. Un des exos c'est "extraire une interface d'une classe". Ok, click droit sur la classe -> refactor -> extract interface, voilou . En tout cas merci pour la vidéo, je mate ça.
    Dernière modification par jilbi ; 22/10/2020 à 14h05.

  27. #3207
    jilbi, si j’ai bien compris, tu peux soit calculer des puissances successives de ta matrice (en transformant False en 0 et True en 1, pas plus que n) et si tu rencontres un nombre non nul à la bonne place, tu réponds True. Mais ça va être long.
    Soit tu peux utiliser un BFS (parcours en largeur) pour déterminer si le sommet est dans la même composante connexe que le premier.
    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

  28. #3208
    Citation Envoyé par ducon Voir le message
    jilbi, si j’ai bien compris, tu peux soit calculer des puissances successives de ta matrice (en transformant False en 0 et True en 1, pas plus que n) et si tu rencontres un nombre non nul à la bonne place, tu réponds True. Mais ça va être long.
    Soit tu peux utiliser un BFS (parcours en largeur) pour déterminer si le sommet est dans la même composante connexe que le premier.
    La multiplication de matrice c'est une complexité en cube du nombre de sommets (qu'on répète plusieurs fois, autant que le diamètre du graphe), c'est encore pire que la liste. Un parcours de graphe (en largeur, en profondeur, n'importe comment) c'est linéaire par rapport au nombre d'arête (carré du nombre de sommet dans le pire cas du graphe complet, mais en pratique souvent proportionnel au nombre de sommets comme ici).

  29. #3209
    Voui, d’où la dernière phrase de ma première ligne.
    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

  30. #3210
    Une vidéo de bibi pour les débutants ou pas


Page 107 sur 182 PremièrePremière ... 7579799100101102103104105106107108109110111112113114115117157 ... 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
  •