Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 126 sur 182 PremièrePremière ... 2676116118119120121122123124125126127128129130131132133134136176 ... DernièreDernière
Affichage des résultats 3 751 à 3 780 sur 5437
  1. #3751
    Ce sont des cours à suivre en vidéo (il y'en a aussi en texte). Si je veux, je peux suivre d'autres cours avec un niveau plus avancé.
    Si je veux suivre tout le "path" Angular (de begginer à advanced), par exemple, c'est 64 heures de cours.

    Pour ce que tu suis (HTML, JS et CSS), t'as un path de 35 heures de cours

  2. #3752
    Citation Envoyé par vectra Voir le message
    Pour info, j'ai juste copié à la main ma keymap Clion vers Rider et tout a marché de suite. Je regrette qu'il n'y ait pas de fonction pour synchroniser les IDEs Jetbrains entre eux, c'est peut-être parce que j'utilise CLion avec une licence et Rider en mode évaluation sans compte.
    Je réagis un peu tard, mais pour la prochaine fois si tu veux copier une keymap custom d'un produit jetbrains vers un autre produit jetbrains, tu peux au choix :
    - exporter ta keymap, puis l'importer dans ton autre ide (File > Manage IDE settings > export/imports settings > tu coches juste "keymap")
    - sinon à la main : dans le dossier de ton profil utilisateur, tu as un dossier keymap, avec un fichier xml par profil de keymap. Soit le copier coller fonctionne, soit tu l'édites (et tu fais le merge). Ca restera plus rapide que se farcir la copie de chaque raccourci à la main via l'interface.

  3. #3753
    Citation Envoyé par deathdigger Voir le message
    Ce sont des cours à suivre en vidéo (il y'en a aussi en texte). Si je veux, je peux suivre d'autres cours avec un niveau plus avancé.
    Si je veux suivre tout le "path" Angular (de begginer à advanced), par exemple, c'est 64 heures de cours.

    Pour ce que tu suis (HTML, JS et CSS), t'as un path de 35 heures de cours
    Ah cool ça, je prends aussi. Ça me fera toujours une bonne occasion de réviser quand j'aurai terminé mon programme actuel.

  4. #3754
    Il ne me reste plus que le projet final pour la certification professionnelle HarvardX, mais j'ai fait une pause et je bloque à m'y remettre

  5. #3755
    Code With Me, l'outil de dévellopement collaboratif de Jetbrains est disponible avec les versions 2021 des IDE.
    Je l'utilise de temps en temps pour du pair-programming avec des collègues en télétravail et c'est rudement bien foutu.
    C'est la faute à Arteis

  6. #3756
    Dites, quelles est la raison qui vous vient à l'esprit pour expliquer qu'une boucle d'ouverture/fermetures (ou création/suppression) de fichiers finisse par foirer quand elle va suffisamment vite ?

    Je corrige certains codes d’élèves qui ont cette structure :

    Code:
           fichier1 = fopen("FICHIER1", "w");
           fichier2 = fopen("FICHIER2", "w");
           fprintf(FICHIER2, "%d\n", TRUC);
           fprintf(FICHIER2, "%d\n", TRUC2);
           fclose(FICHIER2);
           fclose(FICHIER1);
           remove("FICHIER1");
    Ça s’exécute dans une boucle très rapide. Et de temps en temps, segfault parce que le fopen foire ou le fclose ou le remove.
    Alors oui c'est évidemment une bonne pratique de toujours vérifier si les choses se déroule bien sur ces fonctions, mais je me suis rendu compte à la réflexion que je ne saisit pas bien ce qui peut faire foirer ce genre de chose sur le système, d'un point de vue bas niveau ... . La vitesse du DD ? L'OS ? Autre chose ?
    Dernière modification par Nilsou ; 14/04/2021 à 16h02.

  7. #3757
    Quand tu supprimes un fichier, tu lui mets un flag "à supprimer", donc si tu le recréé derrière, il n'est peut-être pas encore supprimé.
    (Enfin j'avais eu le problème pour des dossiers, je suppose que c'est similaire pour des fichiers).

  8. #3758
    Hooo, intéressant ...

    Donc c'est dépendant de la nature de l'OS et de ses boucles interne ainsi que du DD j'imagine ?

    Donc au final si on veut utiliser un fichier comme l’indicateur d'un verrou pour un accès concurrents de deux programmes (l'un en écriture l'autre en lecture par exemple) à un autre fichier (voir code ci-dessous, FICHIER1 est le verrou et FICHIER2 le fichier de donnée) impossible que ça fonctionne à haute vitesse ... ?

    Du coups ça serait quoi la bonne pratique dans ce cas là ? Mémoire partagée ?

  9. #3759
    Un sémaphore nommé peut-être (sem_open) ?

  10. #3760
    Citation Envoyé par Nilsou Voir le message
    Hooo, intéressant ...

    Donc c'est dépendant de la nature de l'OS et de ses boucles interne ainsi que du DD j'imagine ?

    Donc au final si on veut utiliser un fichier comme l’indicateur d'un verrou pour un accès concurrents de deux programmes (l'un en écriture l'autre en lecture par exemple) à un autre fichier (voir code ci-dessous, FICHIER1 est le verrou et FICHIER2 le fichier de donnée) impossible que ça fonctionne à haute vitesse ... ?

    Du coups ça serait quoi la bonne pratique dans ce cas là ? Mémoire partagée ?
    Tu veux lire ton fichier pendant qu'il est écrit ? Ou juste le lire pendant que l'autre n'écrit pas ?

    Si c'est le deuxième cas, un sémaphore ou un mutex nommé.

  11. #3761
    Mais une sémaphore, j'ai plutôt l'habitude d'utiliser ça en interne dans un programme, pour les threads etc... ça fonctionne entre deux programme qui ne se connaissent ni d’Ève ni d’Adam ?
    Question sans doute con, mais ça fait un bout de temps que je n'ai pas manipulé tout ça. J'imagine que si il y a un nom on peut se la retrouver entre programme, un truc comme ça...

    edit :

    ha oui :
    A named semaphore is identified by a name of the form
    /somename; that is, a null-terminated string of up to
    NAME_MAX-4 (i.e., 251) characters consisting of an initial
    slash, followed by one or more characters, none of which
    are slashes. Two processes can operate on the same named
    semaphore by passing the same name to sem_open(3).

    Bon maintenant, la question c'est à quel point c'est une norme qui fonctionne sur tout les systèmes ... je crois me souvenir que Windows n'est pas tout à fait Posix si ?

  12. #3762
    C'est ça, le nom permet de le retrouve entre programmes.
    Ex : https://www.boost.org/doc/libs/1_42_...med_mutex.html

    Edit : sinon, en fonction de ce que tu veux faire, un pipe.

  13. #3763
    Ok merci, maintenant est-ce que ça fonctionne bien en multi-plateforme ? Windows il aime ce genre de truc ?

  14. #3764
    Si tu utilises .Net, oui.

    (Ca dépend de ta bibliothèque j'imagine)

  15. #3765
    Si on parle bien de C++, je rappelle à l'occasion qu'on est en 2021 et que C++20 est déjà largement supporté.
    Dans C++17, on a a priori tout le contenu de boost::filesystem qui est passé dans std.
    Mais je suppose que c'est juste un cours de C.

    Et C++17 supporte une palanquée de fonctionnalités sur les threads, mutex, sémaphores et autres. De ce côté, alignement large sur QT5.

    - - - Mise à jour - - -

    Citation Envoyé par gros_bidule Voir le message
    Je réagis un peu tard, mais pour la prochaine fois si tu veux copier une keymap custom d'un produit jetbrains vers un autre produit jetbrains, tu peux au choix :
    - exporter ta keymap, puis l'importer dans ton autre ide (File > Manage IDE settings > export/imports settings > tu coches juste "keymap")
    - sinon à la main : dans le dossier de ton profil utilisateur, tu as un dossier keymap, avec un fichier xml par profil de keymap. Soit le copier coller fonctionne, soit tu l'édites (et tu fais le merge). Ca restera plus rapide que se farcir la copie de chaque raccourci à la main via l'interface.
    Désolé pour le lag.
    J'ai juste eu à recopier la keymap et en fait je l'avais déjà fait au moment de poster, mais merci du coup de main
    En fait, je m'étonnais que la keymap ne puisse pas être passée de CLion vers Rider autrement qu'en bidouillant à la main. Je sais faire depuis que je masterise CLion vu que je suis maniaque des keymaps custom, mais c'est relou.

    PS: comme j'ai un vrai boulot maintenant, j'en ai profité pour me payer le pack complet Jetbrains, au moins pour une année. Ca me fera une licence perpétuelle de Rider; on verra si ça vaut le coup de renouveller.
    J'ai pris le pack 3 mois avant la fin de la licence annuelle de CLion, et ça ne m'a coûté "que" 115 euros vu qu'ils ont pris en compte mon ancienneté chez CLion et qu'ils l'ont appliquée au full-pack.

    Visiblement, un projet Rider passe directement sous Visual Studio, bon à prendre. Ca marche aussi avec CLion, mais pour cela il faut que le CMake du projet soit bien carré comme il faut; j'ai eu du ramp-up à faire avant d'obtenir un projet directement importable sur Visual, mais puisque CMake est notre nouveau standard (même Qt s'y met -mal), autant investir.

  16. #3766
    Citation Envoyé par vectra Voir le message
    Et C++17 supporte une palanquée de fonctionnalités sur les threads, mutex, sémaphores et autres. De ce côté, alignement large sur QT5.
    Il n'y a pas de mutex/sémaphore nommés ou inter-processus dans la bibliothèque standard.

  17. #3767
    Mea culpa pour le "nommé", mais par contre je vois bien des mutex et j'ai joué avec (ceux de Qt sont un peu plus faciles).
    Si tu tiens absolument à nommer un mutex, tu peux pas les enquiller dans une map à clé string? :con:

    PS: ils ont visiblement intégré les sémaphores dans la révision 20: bon à savoir!
    https://en.cppreference.com/w/cpp/th...ting_semaphore

  18. #3768
    Au pire tu installes le plugin Izual Studio

  19. #3769
    Citation Envoyé par vectra Voir le message
    Mea culpa pour le "nommé", mais par contre je vois bien des mutex et j'ai joué avec (ceux de Qt sont un peu plus faciles).
    Si tu tiens absolument à nommer un mutex, tu peux pas les enquiller dans une map à clé string? :con:

    PS: ils ont visiblement intégré les sémaphores dans la révision 20: bon à savoir!
    https://en.cppreference.com/w/cpp/th...ting_semaphore
    Nommé, c'est au niveau du noyau, pour que plusieurs processus puissent récupérer le même objet. POSIX gère ça pour les sémaphores (sem_open), et la mémoire partagée (shm_open), mais pas pour les mutex (mais Windows si). Mais Robix66 a déjà cité boost pour avoir une bibliothèque qui en propose de façon portable.

  20. #3770
    Oui OK, c'est beaucoup plus clair là.

    En plus je suis doublement teubé parce que j'ai bossé sur des QLocalsocket lors de mon ancien job, qui sont implémentés par des named pipes sous Windows (pour récupérer le même tuyau à partir de process différents, et pas seulement de threads). Effectivement c'est très pratique et efficace avec l'interface proposée par Qt.
    Rien sur std pour implémenter ça a priori, mais y'a encore et toujours une lib boost pour faire le job...

    - - - Mise à jour - - -

    Citation Envoyé par Orhin Voir le message
    Code With Me, l'outil de dévellopement collaboratif de Jetbrains est disponible avec les versions 2021 des IDE.
    Je l'utilise de temps en temps pour du pair-programming avec des collègues en télétravail et c'est rudement bien foutu.
    Manque de bol, je suis le seul à avoir une licence Jetbrains semble-t-il.

  21. #3771
    Aujourd'hui au taff j'ai pu constater qu'en Python y'a pas que les membres qui sont dynamiques. Les méthodes aussi.
    J'aurais dû m'y attendre, et c'est écrit un peu partout sur le net, mais quand même, ça fait mal.
    Bordel de merde, je maudis les concepteurs de ce mécanisme sur 99 générations.

  22. #3772
    Citation Envoyé par vectra Voir le message
    Manque de bol, je suis le seul à avoir une licence Jetbrains semble-t-il.
    Mais c'est ça qui est bien justement avec Code With Me, seule la personne qui invite a besoin d'avoir une licence.
    C'est la faute à Arteis

  23. #3773
    Citation Envoyé par Taro Voir le message
    Aujourd'hui au taff j'ai pu constater qu'en Python y'a pas que les membres qui sont dynamiques. Les méthodes aussi.
    J'aurais dû m'y attendre, et c'est écrit un peu partout sur le net, mais quand même, ça fait mal.
    Bordel de merde, je maudis les concepteurs de ce mécanisme sur 99 générations.
    Les méthodes ne sont que des fonctions assignés à des membres, non ? Il me semble que c'est pareil dans tous les langages à objets dynamiques : javascript, lua, ...

  24. #3774
    Citation Envoyé par Orhin Voir le message
    Mais c'est ça qui est bien justement avec Code With Me, seule la personne qui invite a besoin d'avoir une licence.
    Sinon codetogether c'est simple, multi IDE, et gratuit

  25. #3775
    Gratuit ?
    https://www.codetogether.com/pricing/

    Le truc bien avec CodeWithMe c'est que tu peux très simplement installer un serveur local, donc tu n'as pas à passer par des serveurs externes (ce qui est problématique dans certaines entreprises).
    - La version 3 est arrivée !

  26. #3776
    Citation Envoyé par Nilsou Voir le message
    Hooo, intéressant ...

    Donc c'est dépendant de la nature de l'OS et de ses boucles interne ainsi que du DD j'imagine ?

    Donc au final si on veut utiliser un fichier comme l’indicateur d'un verrou pour un accès concurrents de deux programmes (l'un en écriture l'autre en lecture par exemple) à un autre fichier (voir code ci-dessous, FICHIER1 est le verrou et FICHIER2 le fichier de donnée) impossible que ça fonctionne à haute vitesse ... ?

    Du coups ça serait quoi la bonne pratique dans ce cas là ? Mémoire partagée ?
    Tu as un vrai cas d'usage, ou c'est purement rhétorique ?

    Parceque dans le principe, utiliser des fichiers (un truc lent, imprévisible, potentiellement bufferisé et avec un comportement à la fois lié à l'OS et l'implémentation de ton compilateur) pour synchroniser des processus (un truc rapide) c'est fondamentalement idiot.

    Mais bon admettons. Dans ce cas, ça reste toujours idiot d'utiliser un fichier verrou car il n'apporte strictement rien de plus, il n'est pas plus synchronisé que le second fichier. C'est même potentiellement pire car tu as plusieurs appels système qui peuvent s'intercaler.

    Typiquement : rien n'empêche ce déroulé de se produire
    Code:
    (F1 n'existe pas)
    Producteur   |    Consommateur
                 |    test = Ouvrir(F1)   
                 |    test == faux => ouvrir(f2)
    ouvrir(f2)   |
    créer(f1)    |
    ecrire(f2)   |   lire(f2)
    ...
    Bref, F1 ne sert à rien, il faut un élément externe pour contrôler l'accès...
    Le sémaphore nommé ça peut le faire, sinon en environnement posix tu as aussi fcntl qui permet de mettre en place directement des locks sur les fichiers.
    https://pubs.opengroup.org/onlinepub...ons/fcntl.html


    Mais bon dans le fond on en revient à ma question de base : pourquoi transmettre des données à travers un fichier ?
    Tu dis "communiquer entre deux processus totalement indépendants" conceptuellement.... c'est impossible.

    Si ton processus consommateur par exemple est un binaire "boîte noire" dont tu ne sais rien, il faut bien que l'auteur ait défini d'une manière ou d'une autre un protocole de communication ie une spécification de où et comment il s'attend à ce qu'on lui fournisse les données qu'il va lire. Et dans ce cas il n'y a pas de question en fait, tu ne peux qu'implémenter ce qu'il attend (ce qui peut être un sémaphore nommé et un fichier... mais je n'aurais pas très envie d'utiliser un processus qui utilise ça ).

    Si maintenant vu ce que tu décris tu es plutôt dans un exercice où les étudiants écrivent le code de tout... le plus simple et logique (et performant) serait de leur faire écrire un seul programme qui fork deux processus, avec un pipe pour communiquer entre les deux processus.

    Si le but c'est de faire écrire le producteur et le consommateur par des étudiants différents, on en revient au point plus haut où il faut qu'ils définissent un protocole de communication... Là encore le pipe reste très facile à mettre en place (mais implique de lancer les processus en même temps ./producteur | ./consommateur ).

    Si le but est d'avoir des processus qui pissent être lancés et tourner totalement indépendamment là ça devient un peu plus complexe... mais le problème reste le même : il faut définir par quel canal ils ont communiquer. Mémoire partagée, sockets... là encore il y a du choix, mais tout ça reste strictement OS-dependant.

    Si tu veux un code portable, il faut passer par du middleware portable qui va abstraire tout ce qui est au niveau système.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  27. #3777
    Qt/QLocalsocket fait pile ça, testé entre programmes de langages aussi.
    Sinon, la solution courante serait de passer par des sockets, non?
    Ca fait partie des autres leçons de programmation système que j'ai un peu oubliées avec le temps.

  28. #3778
    Citation Envoyé par Lazyjoe Voir le message
    ...
    Ouais, mais tu vois vite que ça devient compliqué pour des étudiants à faible niveau.

    Alors qu'un code qui vérifie la réussite des fopen, des remove, des fprintf et autres fclose, ça fait très bien le taf sans aucune erreur, ça fonctionne partout et sur tout système. C'est lent, mais fonctionnel. Pour passer une valeur toutes les 5 secondes, ça fait parfaitement le taf par exemple. (en tout cas on a une plateforme de test qui stress test leurs code dans tout les sens, et avec des sécurités sur les fopen et autres, ça passe dans tout les cas)

    L'exemple que tu donne n'est pas très correct puisque le producteur test aussi l'existence de F1. Je ne suis pas certains que fopen fait sur un fichier qui n'existe pas puisse te renvoyer OK si le fichier est encore en attente de création, ça me parait improbable non ? Après tout, si c'était le cas, une écriture du même processus juste après la création d'un fichier poserait problème de temps en temps !

    Le système de fichier de verrou pour les accès concurrent, c'est quand même un truc qui est assez courant il me semble... (même si en général c'est pas pour les ouvrir toutes les secondes ni pour écrire dans un autre fichier ...)
    Dernière modification par Nilsou ; 15/04/2021 à 15h02.

  29. #3779
    Citation Envoyé par Nilsou Voir le message
    L'exemple que tu donne n'est pas très correct puisque le producteur test aussi l'existence de F1. Je ne suis pas certains que fopen fait sur un fichier qui n'existe pas puisse te renvoyer OK si le fichier est encore en attente de création, ça me parait improbable non ? Après tout, si c'était le cas, une écriture du même processus juste après la création d'un fichier poserait problème de temps en temps !
    Ok effectivement mon exemple était un peu mal fichu.
    Prenons plus basique : si les deux processus effectuent le test d'existence de F1 "en même temps"

    Code:
    Producteur                    |     Consommateur
    test = fopen(F1,'r')          | test = fopen(F1,'r')
    test == vrai => fopen(F1,'w') | test == vrai => fopen(F1,'w')
    ecrire(F2)                    |    lire(F2)                        => résultats incohérents
    fclose(F1)                    |  fclose(F1)
    remove(F1)                    |   remove(F1)                => système pas content car un des deux va vouloir effacer un fichier qui n'existe déjà plus
    Et ça je suis à peu près certain que ça marche sous unix, rien n'empêche d'ouvrir plusieurs fois un fichier en écriture, on peut même vouloir le faire volontairement (plutôt en mode "append" pour que les données restent cohérentes ligne par ligne même si l'ordre est pas garanti). Par contre sous Windows il va criser il me semble.

    Bref sur des processus volontairement ralenti pour un exercice, il y a de bonnes chances que ça marche la plupart du temps, mais il y a aussi 100% de chances que ça crashe si tu laisse les processus tourner suffisamment longtemps.
    Surtout qu'avec des fichiers, tu as une latence assez importante dûe aux appels systèmes... donc le "en même temps" ça peut être large avec des milliers (millions ?) de cycle CPU d'intervalle.

    Pour moi ça reste quand même un des aspects fondamentaux en programmation concurrente : si tu veux accéder à une ressource partagée quelle qu'elle soit, tu dois obligatoirement avoir un mécanisme permettant de t'assurer de son lock, et t'assurer d'avoir bien obtenu le lock avant de t'en servir.

    Et l'exemple avec les fichiers est un parfait démonstrateur de pourquoi ça ne fonctionnera pas de manière garantie si tu n'as pas de lock, donc pédagogiquement c'est intéressant aussi.
    Dernière modification par Lazyjoe ; 15/04/2021 à 16h29.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  30. #3780
    Citation Envoyé par Nilsou Voir le message
    Ouais, mais tu vois vite que ça devient compliqué pour des étudiants à faible niveau.
    C'est la synchronisation inter-processus/thread qui est compliqué aussi. Le plus simple c'est de ne rien partager et se contenter de se passer des messages par socket/pipe quand c'est possible.

    Citation Envoyé par Nilsou Voir le message
    Le système de fichier de verrou pour les accès concurrent, c'est quand même un truc qui est assez courant il me semble... (même si en général c'est pas pour les ouvrir toutes les secondes ni pour écrire dans un autre fichier ...)
    Je n'ai jamais utilisé ce genre de synchronisation, j'y connais pas grand chose, mais est-ce que ça n'utilise pas les appels à fcntl cités par Lazyjoe ?

    Edit: j'ai été voir l'implémentation de dnf (gestionnaire de paquets de redhat), il utilise flock, ce n'est pas un simple open.
    Dernière modification par Cwningen ; 15/04/2021 à 17h17.

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