C'est là mon problème. Je ne peux donc pas créer un conteneur qui puisse contenir n'importe quoi, puisque si un utilisateur veut utiliser mon conteneur pour un type qu'il a lui-même créé, ça ne va pas marcher.
Je vais probablement dire une grosse connerie car ca fait longtemps que j'ai pas fait ce genre de truc mais bon tu peux etendre un module donc normalement tu import ton container (qui est dans un module) et tu rajoutes les nouvelles methodes pour ton nouveau type et tu rajoutes un interface.
Regarde aussi les normes 2003 et 2008 car il y a eu pas mal de changement de fait dont, en particulier, la programmation objet. Cela m'etonnerait bien que ce genre de cas ne soit pas gerable d'une facon ou d'une autre maintenant.
Je connais TRES bien le probleme et bon la these c'est aussi un moment ou tu dois devenir independant dans ta recherche et si tu n'es pas capable de comprendre que ce que tu fais n'a absolument aucun interet pour le reste de ta carriere c'est tant pis pour toi.
Aujour'd hui faire du fortran 77 c'est du grand n'importe quoi, cela te bloque et ne t'apporte absolument AUCUNE expertise en dehors de montrer que tu n'as pas la capacite de devenir un chercheur independant avec tes idees a toi en ayant la capacite de les amener au bout.
Oui et ? Le thésard peut et doit leur dire merde. En même temps si il ne comprend pas que faire du fortran 77 c'est débile et qu'il est utilisé par des vieux chercheurs comme techniciens pas cher il mérite sa torture.
Sans rire dis lui de dire stop à cette hérésie, c'est pas vraiment d'avenir et cela ne sera pas très bien vu dans les commissions de recrutement.
Ce que tu veux (si je comprend bien) date de fortran 90. Par contre cela te force à faire le méthode à la main la ou c++, il me semble, permet des trucs plus automatique.
En gros cela se résume à faire un module, un type, les méthodes associées suivant tes type en entrée, définir l'interface nommé ou tu mets juste le nom des méthodes.
3.3.3 Generic procedures
Modules allow arguments of derived type and hence generic procedures with derived types:
MODULE genswap
IMPLICIT NONE
TYPE point
REAL :: x, y
END TYPE point
INTERFACE swap
MODULE PROCEDURE swapreal, swapint, swaplog, swappoint
END INTERFACE
CONTAINS
SUBROUTINE swappoint (a,b)
IMPLICIT NONE
TYPE (point), INTENT(INOUT) :: a, b
TYPE (point) :: temp
temp = a
a = b
b = temp
END SUBROUTINE swappoint
SUBROUTINE swapreal (a, b)
IMPLICIT NONE
REAL, INTENT(INOUT) :: a,b
REAL :: temp
temp=a
a=b
b=temp
END SUBROUTINE swapreal
Nop konqueror regresse a vitesse grand V. Le dernier truc enleve c'est la barre de petits outils qui contenait par exemple un bouton qui permettait de downloader une page web dans une archive ou de ripper un CD directement et plein d'autre options qui ont aujourd'hui disparu et qui ne reviendront pas.
Konqueror est juste moribond, il meurt de mort lente.
Je ne dis pas que l'idee est nul et vu l'evolution du niveau des etudiants de science en programmation il n'y a de tout de maniere pas trop le choix et il va falloir continuer a fournir des front-end simplifie pour faire du calculs numerique. Python est une des options, matlab se positionne pas mal sur le creneau aussi mais aussi des trucs plus specialise comme Ansys (gros monstre hybride) ou abaqus.
Euh les plus gros hpc européens ont la grande majorité de leur utilisation faite par des code écris en fortran… Ce qui est normal pour du calcul numérique.
Les distributions qui s'entête à "ameliorer" le avant packaging ne marchent pas correctement, les distribs qui fournissent kde le plus proche de la version fourni par le projet (arch Linux par exemple) ne rencontre à peu près aucun des bugs présent sur les autres…
Le problème ne vient donc pas de kde mais du packaging !
Non libreoffice est un projet indépendant de gnome. Gnome c'est pratiquement vide en terme d'application vu que libreoffice, the gimp, inks cape etc sont des applications utilisant gtk mais ne sont pas développés par redhat euh je veux dire gnome.
Il est vrai que jamais aucun (groupe) milliardaire comme monsanto n'aurait l'idee diabolique de faire du chantage aux agriculteurs et de les forcer a vendre leur terrain qui serait automatise le lendemain…
Refus de vente cela existe dans la loi francaise, dans la loi anglo-saxon je ne suis pas sur du tout, en fait je pense meme que cela n'existe pas explicitement car les anglo-saxons n'aime pas expliciter la loi. Ils aiment les zones grises et donc sans jurisprudence rien n'ait dit sur l'interpretation qu'un juge fera.
C'est un choix de sa part aussi. Les experts securite ils peuvent gagner beaucoup d'argent mais bon il faut savoir travailler avec les autres souvent ce qui n'est clairement pas la force de l'auteur de GRsec.
D'ailleurs je le trouve bien debile, si le kernel etait parfait de son point de vue, il ne pourrait pas vendre son code donc au lieu d'insulter les devs du kernel il devrait leur dire merci.
Je soupconne que le fait que Albert_ et groumle defendent ce genre de chose explique beaucoup de chose (et je m'inquiete d'etre d'accord avec toi sur le sujet :) ).
Parler de btrfs dans un journal btrfs semble etre non pertinnent pour certaines personnes… je comprend absolument rien a la logique de certaines personnes….
Extended 4 is not designed with SSDs in mind. It is true that it has file system trim support (a critical SSD feature), but outside of that the filesystem was never designed for this use case. Why? It uses a filesystem journal. This means that the filesystem is constantly writing logs down and informing the system of every single change. This can quickly wear out the limited write-space on an SSD running Linux.
Ext4 is a satisfactory choice for solid-state drives with filesystem journaling disabled, and a decent choice for most users, but it should not be the first choice.
Et ext4 sans journal c'est pas forcement le but non?
Ext4 is a satisfactory choice for solid-state drives with filesystem journaling disabled, and a decent choice for most users, but it should not be the first choice.
Je parle du futur mais c'est bien de ne rien prevoir et d'etre reactif et non pro-actif ce n'est pas comme si la recherche sur les systemes de stockage n'etait pas un des domaines les plus actifs.
Il y a des systèmes de fichiers très variés, mais tous ne sont pas destinés à un usage général. Beaucoup sont spécialisés. Tu ne verras pas squashfs comme système de fichier pour tes données par exemple.
Et?
Rient ne dit que btrfs est réellement pertinent pour tout le monde (de même que ext4 en fait) mais probablement pour des usages spécifiques.
Oui en effet rien ne dit mais je ne defend pas specialement btrfs, je dis juste que c'est bien joli tout cela, ext4 est super stable mais bon le futur ne lui appartient surement pas.
Il me semble mais je peux me tromper naturellement, cela m'arrive souvent, que ext4 n'est pas forcement un FS fait pour les SSD, il me semble aussi qu'il a une taille maximale. Enfin il me semble.
D'ailleurs c'est rigolo si les FS actuels sont si bien pourquoi est ce qu'il y autant de boulot (et d'argent) mis pour developper un successeur. Cela doit etre pour le plaisir de jeter l'argent par les fenetres…
Ici on parle de base de données qui deviennent suffisamment grosses pour ralentir Btrfs significativement.
C'est bien pour cela que j'ai parle des BD semantique qui peuvent, assez rapidement, grossir a plusieurs Gigas (ce n'est pas pour rien que j'ai decide de ne plus me servir de ce genre d'outil, c'est pratique mais avec un DD de laptop cela peut facilement devenir un peu … lourd.
Mais on parlait de 100% des utilisateurs de linux donc on ne prend pas en compte les cas particuliers
Il est vrai que j'avais pas pense au telephone mais bon en dehors de 1 cas extremement particulier (joola?), je pense que l'on peut dire que la presence de btrfs sur ce genre de matos est … nul. Donc on retrouve BTRFS ou? Sur le desktop, les serveurs et dans les HPC et tu veux me faire croire que dans ces deux las tu as beaucoup d'utilisateur n'ayant:
ni VM
ni BD un peu consequente
J'ai un "leger" doute. Je suis pret a parier que la grande majorite des utilisateurs linux
desktop ont des VMs et sur les deux autres il y a forcement des BD.
Il y a de plus en plus de logiciels installe par defaut qui vont te creer une BD qui va grandir est arriver a une taille consequente. Je pense a toutes les technos semantique avec baloo/akonadi/tracker.
Ce qui est un peu contraignant et oblige a savoir tes besoins de VM au moment de l'installation. Je ne parle meme pas du fait que un des avantages, en theorie, des FS modernes c'est justement de se passer des partitions cree a l'installation et de travailler avec des volumes. Enfin d'apres ce que j'en ai compris. Alors peut etre que si tu mets tes VM sur un volume particulier le probleme de fragmentation n'existe plus mais bon sous ext4 ce probleme n'existe pas (que je sache). La communaute linux c'est assez moque de FAT et la defragmentations…
[^] # Re: Python pour scripter, C/C++ sous la capot.
Posté par Albert_ . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 3.
Je vais probablement dire une grosse connerie car ca fait longtemps que j'ai pas fait ce genre de truc mais bon tu peux etendre un module donc normalement tu import ton container (qui est dans un module) et tu rajoutes les nouvelles methodes pour ton nouveau type et tu rajoutes un interface.
Regarde aussi les normes 2003 et 2008 car il y a eu pas mal de changement de fait dont, en particulier, la programmation objet. Cela m'etonnerait bien que ce genre de cas ne soit pas gerable d'une facon ou d'une autre maintenant.
[^] # Re: Python pour scripter, C/C++ sous la capot.
Posté par Albert_ . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 5.
Je connais TRES bien le probleme et bon la these c'est aussi un moment ou tu dois devenir independant dans ta recherche et si tu n'es pas capable de comprendre que ce que tu fais n'a absolument aucun interet pour le reste de ta carriere c'est tant pis pour toi.
Aujour'd hui faire du fortran 77 c'est du grand n'importe quoi, cela te bloque et ne t'apporte absolument AUCUNE expertise en dehors de montrer que tu n'as pas la capacite de devenir un chercheur independant avec tes idees a toi en ayant la capacite de les amener au bout.
[^] # Re: Python pour scripter, C/C++ sous la capot.
Posté par Albert_ . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 0.
Oui et ? Le thésard peut et doit leur dire merde. En même temps si il ne comprend pas que faire du fortran 77 c'est débile et qu'il est utilisé par des vieux chercheurs comme techniciens pas cher il mérite sa torture.
Sans rire dis lui de dire stop à cette hérésie, c'est pas vraiment d'avenir et cela ne sera pas très bien vu dans les commissions de recrutement.
[^] # Re: Python pour scripter, C/C++ sous la capot.
Posté par Albert_ . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 5. Dernière modification le 31 août 2017 à 06:26.
Ce que tu veux (si je comprend bien) date de fortran 90. Par contre cela te force à faire le méthode à la main la ou c++, il me semble, permet des trucs plus automatique.
En gros cela se résume à faire un module, un type, les méthodes associées suivant tes type en entrée, définir l'interface nommé ou tu mets juste le nom des méthodes.
3.3.3 Generic procedures
Modules allow arguments of derived type and hence generic procedures with derived types:
MODULE genswap
IMPLICIT NONE
TYPE point
REAL :: x, y
END TYPE point
INTERFACE swap
MODULE PROCEDURE swapreal, swapint, swaplog, swappoint
END INTERFACE
CONTAINS
SUBROUTINE swappoint (a,b)
IMPLICIT NONE
TYPE (point), INTENT(INOUT) :: a, b
TYPE (point) :: temp
temp = a
a = b
b = temp
END SUBROUTINE swappoint
SUBROUTINE swapreal (a, b)
IMPLICIT NONE
REAL, INTENT(INOUT) :: a,b
REAL :: temp
temp=a
a=b
b=temp
END SUBROUTINE swapreal
!similar subroutines for swapint and swaplog
…
END MODULE genswap
[^] # Re: Python pour scripter, C/C++ sous la capot.
Posté par Albert_ . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 2.
Fortran 2003 a la programmation générique et fortran 90/95 en est pas loin avec les modules.
[^] # Re: KDE presque un 10 sur 10 comme DE.
Posté par Albert_ . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 3.
Nop konqueror regresse a vitesse grand V. Le dernier truc enleve c'est la barre de petits outils qui contenait par exemple un bouton qui permettait de downloader une page web dans une archive ou de ripper un CD directement et plein d'autre options qui ont aujourd'hui disparu et qui ne reviendront pas.
Konqueror est juste moribond, il meurt de mort lente.
[^] # Re: Python pour scripter, C/C++ sous la capot.
Posté par Albert_ . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 3.
Je ne dis pas que l'idee est nul et vu l'evolution du niveau des etudiants de science en programmation il n'y a de tout de maniere pas trop le choix et il va falloir continuer a fournir des front-end simplifie pour faire du calculs numerique. Python est une des options, matlab se positionne pas mal sur le creneau aussi mais aussi des trucs plus specialise comme Ansys (gros monstre hybride) ou abaqus.
[^] # Re: Python pour scripter, C/C++ sous la capot.
Posté par Albert_ . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 4.
Euh les plus gros hpc européens ont la grande majorité de leur utilisation faite par des code écris en fortran… Ce qui est normal pour du calcul numérique.
[^] # Re: Le troll n'est pas sorti ?!
Posté par Albert_ . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 2.
Les distributions qui s'entête à "ameliorer" le avant packaging ne marchent pas correctement, les distribs qui fournissent kde le plus proche de la version fourni par le projet (arch Linux par exemple) ne rencontre à peu près aucun des bugs présent sur les autres…
Le problème ne vient donc pas de kde mais du packaging !
[^] # Re: Le troll n'est pas sorti ?!
Posté par Albert_ . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 4.
Non libreoffice est un projet indépendant de gnome. Gnome c'est pratiquement vide en terme d'application vu que libreoffice, the gimp, inks cape etc sont des applications utilisant gtk mais ne sont pas développés par redhat euh je veux dire gnome.
[^] # Re: KDE presque un 10 sur 10 comme DE.
Posté par Albert_ . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 5.
Parce-que c'est plus simple déstabiliser un kart à pédale qu'une Ferrari roulant à 300 km/h.
[^] # Re: Oui faut faire du libre
Posté par Albert_ . En réponse au journal Gentlemen farmers . Évalué à 10.
Il est vrai que jamais aucun (groupe) milliardaire comme monsanto n'aurait l'idee diabolique de faire du chantage aux agriculteurs et de les forcer a vendre leur terrain qui serait automatise le lendemain…
Non je ne vois pas comment cela pourrait arriver!
[^] # Re: Les quatre libertés des logiciels libres
Posté par Albert_ . En réponse au journal Grsecurity attaque Bruce Perens en justice pour diffamation. Évalué à 2.
Refus de vente cela existe dans la loi francaise, dans la loi anglo-saxon je ne suis pas sur du tout, en fait je pense meme que cela n'existe pas explicitement car les anglo-saxons n'aime pas expliciter la loi. Ils aiment les zones grises et donc sans jurisprudence rien n'ait dit sur l'interpretation qu'un juge fera.
[^] # Re: Combien ?
Posté par Albert_ . En réponse au journal Grsecurity attaque Bruce Perens en justice pour diffamation. Évalué à 1.
C'est un choix de sa part aussi. Les experts securite ils peuvent gagner beaucoup d'argent mais bon il faut savoir travailler avec les autres souvent ce qui n'est clairement pas la force de l'auteur de GRsec.
D'ailleurs je le trouve bien debile, si le kernel etait parfait de son point de vue, il ne pourrait pas vendre son code donc au lieu d'insulter les devs du kernel il devrait leur dire merci.
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 0.
Sauf si tu sors le journal non?
Et le journal c'est deconseille avec un SSD…
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 2.
Je soupconne que le fait que Albert_ et groumle defendent ce genre de chose explique beaucoup de chose (et je m'inquiete d'etre d'accord avec toi sur le sujet :) ).
Parler de btrfs dans un journal btrfs semble etre non pertinnent pour certaines personnes… je comprend absolument rien a la logique de certaines personnes….
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 2.
Et ext4 sans journal c'est pas forcement le but non?
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 2. Dernière modification le 06 août 2017 à 00:30.
https://www.maketecheasier.com/best-linux-filesystem-for-ssd/
Je parle du futur mais c'est bien de ne rien prevoir et d'etre reactif et non pro-actif ce n'est pas comme si la recherche sur les systemes de stockage n'etait pas un des domaines les plus actifs.
Et?
Oui en effet rien ne dit mais je ne defend pas specialement btrfs, je dis juste que c'est bien joli tout cela, ext4 est super stable mais bon le futur ne lui appartient surement pas.
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 1. Dernière modification le 04 août 2017 à 10:49.
Il me semble mais je peux me tromper naturellement, cela m'arrive souvent, que ext4 n'est pas forcement un FS fait pour les SSD, il me semble aussi qu'il a une taille maximale. Enfin il me semble.
D'ailleurs c'est rigolo si les FS actuels sont si bien pourquoi est ce qu'il y autant de boulot (et d'argent) mis pour developper un successeur. Cela doit etre pour le plaisir de jeter l'argent par les fenetres…
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 0.
Donc tu penses que dans linux n'a pas besoin de systeme de fichier moderne et adapte a des besoin future? Interessant…
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 0.
Je doute que btrfs soit installe sur un autre tel que joola (et meme la je ne suis pas sur).
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 0.
C'est bien pour cela que j'ai parle des BD semantique qui peuvent, assez rapidement, grossir a plusieurs Gigas (ce n'est pas pour rien que j'ai decide de ne plus me servir de ce genre d'outil, c'est pratique mais avec un DD de laptop cela peut facilement devenir un peu … lourd.
Il est vrai que j'avais pas pense au telephone mais bon en dehors de 1 cas extremement particulier (joola?), je pense que l'on peut dire que la presence de btrfs sur ce genre de matos est … nul. Donc on retrouve BTRFS ou? Sur le desktop, les serveurs et dans les HPC et tu veux me faire croire que dans ces deux las tu as beaucoup d'utilisateur n'ayant:
J'ai un "leger" doute. Je suis pret a parier que la grande majorite des utilisateurs linux
desktop ont des VMs et sur les deux autres il y a forcement des BD.
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 2.
Et la fragmentation des VM et des BD c'est pas lie au systeme?
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 1.
Il y a de plus en plus de logiciels installe par defaut qui vont te creer une BD qui va grandir est arriver a une taille consequente. Je pense a toutes les technos semantique avec baloo/akonadi/tracker.
[^] # Re: Juste une histoire de ressources de développement
Posté par Albert_ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 2.
Ce qui est un peu contraignant et oblige a savoir tes besoins de VM au moment de l'installation. Je ne parle meme pas du fait que un des avantages, en theorie, des FS modernes c'est justement de se passer des partitions cree a l'installation et de travailler avec des volumes. Enfin d'apres ce que j'en ai compris. Alors peut etre que si tu mets tes VM sur un volume particulier le probleme de fragmentation n'existe plus mais bon sous ext4 ce probleme n'existe pas (que je sache). La communaute linux c'est assez moque de FAT et la defragmentations…