pasBill pasGates a écrit 16062 commentaires

Ah....

Perso je suis bien content de me retrouver au meme endroit que la derniere fois quand j'ouvres un fichier, c'est peut-etre pas essentiel, mais c'est pratique et agreable, ca ne coute rien si ce n'est quelques Ko sur ton disque de 20Go et ca n'affecte pas le soft final ni tes habitudes de programmation.
L'assistanat c'est au contraire bien pratique, sinon rien ne t'empeche d'ecrire tes lettres avec un crayon plutot qu'un traitement de texte, ca aussi c'est de l'assistanat, en fait selon le point ou tu te places, toute l'informatique c'est de l'assistanat.

Notes qui si tu prenais la peine de voir ce que VC++ contient, tu aurais trouve que tu peux tout a faire creer des makefiles et tout faire en command line, en n'ayant rien d'autre que les fichiers que TU as cree, comme avec XEmacs+gcc++ld+make, en gros t'as le choix entre les 2 approches, mais faut croire que cette partie de VC++ t'as echappe.

Non.

La partie Wizard pour creer des GUI ce n'est qu'une partie de l'IDE.

J'ai l'experience des 2 XEmacs et une IDE(VC++), il n'y a pas photo, l'IDE est bien plus efficace.

Rien que l'exemple du dessus(avoir les noms des methodes, les parametres et leur type, le class browser...) montre l'utilite enorme d'une IDE, ca evite de perdre tu temps a aller regarder dans 4 fichiers differents, ca evite de recompiler 5 fois apres s'etre trompe de parametres, ca evite les bugs ou tu melanges 2 parametres du meme type dans l'appel de fonction car tu les as mis dans le desordre, etc...
Je passes mes journees a programmer depuis un bon moment, et c'est plus que flagrant, une IDE j'aurais un mal certain a m'en passer maintenant tellement c'est pratique.

Faut pas confondre IDE et Wizards, l'un(les wizards) est compris dans l'autre, mais une IDE c'est bien plus que ca.

Non non, il a clairement dit qu'une IDE etait totalement inutile pour programmer, il parlait pas de plateformes, et ca m'a fait sauter au plafond.

Mon propos n'est pas de dire que VC++ est mieux que xyz ou que il manque xyz a Linux, mon propos c'est : Une IDE c'est d'une utilite enorme pour programmer, et je vois ca tous les jours au boulot.

Ah ? T'arrives a changer tous les parametres avec un grep ?
T'arrives a trouver toutes les occurences avec le grep, maintenant pour changer les parametres automatiquement, ben tu m'expliqueras comment tu fais vu que tu donnes des parametres differents selon les endroits(notamment les fonctions avec des parametres par defaut).
Et pour ca, ben moi je vais dans Edit -> Find in Files, j'entre mon expression et hop dans la fenetre du bas j'ai toutes les entrees, je cliques sur chacune et je suis dessus, je peux changer les parametres.

Notes qu'il y a surement des trucs qu'un IDE ne peut pas faire et que d'autres outils peuvent faire, le miracle etant que tu peux tout a fait utiliser les 2 en meme temps histoire d'avoir les avantages des 2.

Une IDE c'est un avantage ENORME, ca fait pas le cafe et le beurre, mais il est TRES clair qu'un dev avec une IDE est plus efficace que sans.

Quand a emacs, ben justement emacs + browser de classe c'est deja un IDE, basique certes mais c'est un IDE.

Ça ne fait peut-être pas avancer les choses, mais c'est le cas. Un IDE pour la programmation, c'est comme un traitement de texte WYSIWYG (c'est même pire) : ça ne sert à rien, juste à attirer l'oeil du neuneu devant.

Mon dieu ce qu'on peut lire comme conneries des fois ici...

Petit exemple de l'utilite d'une IDE:
Tu tapes sous VC++ :

MyClass NewInstance(3,4,6);

NewInstance.
---> Et la oh miracle, il te montre toutes les methodes et les donnees membres de la classe, plus besoin de se casser les burnes a retourner dans l'autre fichier voir ce que c'est, et une fois que t'as tape le nom de la methode, oh miracle encore, il te montre quels parametres sont necessaires et leur type, quand tu vois les noms des parametres ca t'evite de les mettres dans le mauvais ordre(genre le nom du directory a la place du filename et autres, ce qui est un bug, ca ne se voit pas a la compilation), etc...

Ca c'est HYPER utile, ca evite de perdre du temps a chercher le nom de la methode, a se souvenir du type de parametre, a compiler 3 fois parce que tu t'es gourre en tapant, etc...

On peut aussi parler de cette magnifique fonction qui permet de voir tous les endroits d'ou une fonction est appellee, chose ENORMEMENT utile quand tu modifies quelque chose.

Et ce n'est qu'un exemple parmis bien d'autres.

Voila, toi tu t'amuses avec ton petit editeur de texte, moi avec une IDE de mon choix, on code le meme soft et je te paries que je le termine bien avant toi, et probablement avec moins de bugs.

Non faut arreter de delirer quand meme, les IDE c'est un gain de temps ENORME.

Si c'est gens avaient eu l'idee de regarder une fois les menus de VC++ ils auraient remarque dans le menu Insert, l'entree New Class qui est en 1ere position dans le menu, et qui oh miracle cree un fichier par classe, s'occupe de mettre ton destructeur en virtual et mettre des #ifndef BLABLA #define BLABLA autour du contenu de ton .hpp

En gros t'utilises ca et tu crees une nouvelle classe tres facilement, ca encourage les neuneus a l'utiliser, et ca cree 1 fichier par classe.

Tu voles la propriete intellectuelle du concepteur en piratant son soft, donc oui il y a vol. Il y a des crimes pires que d'autres, le kidnapping est surement pire que le piratage, ca n'empeche que le piratage est illegal et represente un vol. Dans "propriete intellectuelle" il y a le mot "propriete" au cas ou tu n'aurais pas remarque, si tu t'appropries ce qui m'appartient sans mon accord tu me voles.

Quand a l'interet commun ben c'est justement le cas, l'interet commun c'est de ne pas laisser les gens s'approprier tes biens sans ton consentement, et en piratant tu violes cela.

Tu utilises un soft que j'ai ecrit sans mon consentement, tu me voles, point. Donc oui yeupou, tu es un voleur.

Maintenant il y a 2 types de voleurs:
- ceux qui volent par necessite, ils ont un reel besoin genre se nourrir, avoir un toit,..., qu'ils ne peuvent pas payer. Ils ne volent donc pas par choix mais par necessite, c'est excusable.
- ceux qui volent par facilite et gout du luxe, ils pourraient tout a fait se passer de ce qu'ils volent mais volent quand meme soit parce qu'ils n'ont pas les moyens de se payer ce luxe, soit parce qu'ils ne veulent pas depenser leur argent la dessus, ceux la je ne vois pas pourquoi on leur ferait le moindre cadeau.

Et mon petit doigt me dit que tu n'avais pas un besoin vital de jouer a des jeux pirates et que tu aurais tres bien pu t'en passer, j'en deduis que tu entres dans la 2eme categorie.

Donc si je comprends bien, tu consideres que ces lois sur le piratage sont completement idiotes, inutiles et donc qu'il ne faut pas les respecter ?

J'esperes que personne ne pense comme ca, sinon notre monde est vraiment mal barre.

Tiens moi j'estimes que kidnapper les riches ca ne lese personne, apres tout 1 million de rancon sur le milliard qu'ils ont c'est rien du tout, au total c'est comme si ils avaient rien perdu.

Ah c'est beau les gens qui refont les lois a leurs gouts.

Perdu,

Je n'ai jamais update mon systeme par autre chose que WindowsUpdate, et il n'est pas vulnerable a l'attaque. Tout simplement parce que le fix etait dans un autre patch pour IE.

Mes stats je les tiens d'une news sur Debian qui etait passe il y a quelques semaines de cela ou eux-memes donnaient cette stat.

Tiens c'est drole ca, la mefiance.

J'ecris un soft qui recoit et fait des connectiosn reseau que je mets en GPL, je fais bien attention a poser dedans un buffer overflow bien cache. Resultat, je peux faire le con avec n'importe quelle machine qui a ce soft.

Trouver un buffer overflow bien cache en faisant une code review c'est hyper dur, tu prends ca, le nombre de gens qui vont effectivement lire le code du soft(faible), et tu en deduis que je serais tranquille pendant un bon moment, et le jour ou il est decouvert, ben je dis "Ah mais croyez mo, c'est un bug ! C'est un buffer overflow, ca peut arriver a tout le monde !"
Preuve en est que sendmail et wu_ftpd se retrouvent encore avec des alertes pour buffer overflow alors que c'est parmis les softs les plus connus, les plus utilises, les plus anciens, donc les plus audites.

Et le plus drole: vu que je sais exactement quel est le probleme(vu que c'est moi qui l'ai mis), je peux le corriger en 1 heure, et apres je recois les acclamations de la foule qui me considere des lors comme un gars qui prend la securite au serieux.

Alors bon la confiance dans les LL, tu repasseras, que le code soit accessible ou pas, mettre des backdoors est tres simple.

Debian met 35 jours en moyenne pour corriger un trou de securite, Microsoft qui se fait tout le temps critiquer pour etre lent a sortir les patchs, refuser de les sortir, etc... met moins de temps que ca.
Donc si MS est effectivement comme bcp de "fans" de Linux/du libre le disent, lent pour corriger les defauts, ca veut dire que les autres sont bien plus rapides que MS, j'en deduis que Debian, qui est pourtant regarde comme etant tres serieux et tout, est tres lent vu qu'il est plus lent que MS qui est deja lent.

Ou alors c'est peut-etre que MS est tres loin d'etre le plus lent et que Debian est juste un petit peu lent.

Si je vais sur http://developer.gnome.org/doc/API/glib/glib-threads.html#G-MUTEX-L(...)

Je lis:
" GMutex is not guaranteed to be recursive, i.e. a thread might block, if it already has locked the GMutex. It will deadlock then, of course."

Un thread ne peut pas locker 2 fois de suite le meme mutex. Donc ton P2 ne fonctionne pas, le 1er g_mutex_lock(mutex2) et le dernier se suivent des la 2eme boucle --> deadlock car P2 ne peut pas unlocker mutex2 vu qu'il est bloque sur le deuxieme g_mutex_lock(mutex2).

Euh.... c'est qui Pouaite ?

Sinon, ce genre de choses est plus frequent que tu ne pourrais le penser.

C'est beau, mais ca marche pas....

Si ton process 1 fait son boulot periodique et acquiert le mutex(le lock a la fin dans la fonction my_func) avant que le 2eme process ait ete schedule, le 2eme process ne pourra par faire son boulot car il sera encore bloque sur son g_mutex_lock(mutex).

D'autre part, il y a le probleme suivant(on regarde en boucle):

P1...................P2
lock(mutex)
attend
unlock(mutex)
bosse...............lock(mutex)
......................bosse
......................unlock(mutex)
lock(mutex)

lock(mutex)
attend
unlock(mutex)........--> P2 ne peut pas locker le mutex, car P1 a fait 2 locks de suite, il faut donc 2 unlock
bosse
lock(mutex)

C'est pas le probleme, Windows n'a jamais essaye d'etre un Unix, c'est un OS completement different. Porter les softs d'un Unix a l'autre ne pose en general pas de problemes, hors dans ce cas la, le comportement est different entre Linux et les autres Unix sans aucune raison valable, et le pire c'est que ca se voit pas a la compilation, faut le savoir sinon t'es dans la merde. Et il est impossible de rendre son soft portable sans faire des cochonneries. En gos ca rend le portage des applis multithread tres complexe, sans compter le fait qu'il est impossible de le faire sur les kernels <2.4.

Oui mais si tu utilises clone, ton soft devient Linux only, impossible de porter ca sur xxxBSD, Solaris, IRIX ou autres, c'est pas tres utilisable a moins de commencer a jouer avec des #define.

Petit probleme:

Comment tu fais pour synchroniser 2 processus separes avec ca ?

Tu as 2 processus:
1 fait un boulot xyz, et pose un timer pour se reveiller dans 20 secondes chaque fois avant de prendre un autre job.

l'autre processus a besoin de se reveiller en meme temps que le processus 1 car il a des trucs a faire avec le boulot du process 1.

Pas possible avec ta methode, il n'y a aucun moyen de signaler au 2eme processus qu'il faut se reveiller, tout simplement car ton timer est local a un thread. Pour faire un truc du genre il faut un truc qui soit accessible globalement sur le systeme comme les mutex et semaphores. Ca serait en theorie possible en rajoutant du bordel pour balancer des signaux a l'autre process, mais la ton soft devient dependant du 2eme process, il doit le connaitre. Avec un timer global, le 1er process n'a meme pas besoin de savoir que le 2eme existe, le 2eme prend un handle sur le meme timer et fait son job.

L'exemple ici present non il sert a rien, je l'ai cree de toute piece, mais ca pourrait tout a fait servir, tout depend de ce que tu fais.

Des threads qui doivent se reveiller a des intervalles precis c'est hyper frequent, pouvoir specifier plus d'un intervalle par thread c'est utile aussi.
Ensuite avoir plusieurs threads qui font de meme avec des timers differents, c'est simplement plusieurs requetes qui ont ete faites, rien d'extraordinaire.
Tu peux tout a fait imaginer plusieures sources de donnees, certaines produisent de nouvelles donnees toutes les 30 secondes, d'autres toutes les 2 minutes 10, etc...
Un thread peut avoir besoin des donnees de la source 1 et la source 4, un autre des sources 2,3 et 5, etc... Voila, ca te donne le probleme ci-dessus.

Ben t'appelles quoi "bas niveau" ?

Mon soft n'avait rien de bas niveau, c'etait 100% user-mode. Et j'ai ete oblige de le refaire justement a cause de ce probleme de PID qui fait que ce n'est pas le process lui meme qui recoit le SIGCHLD et le refile a un thread, mais le thread createur, qui pourrait tout a fait avoir disparu. Et ca c'est : 1) contraire a la norme 2) TRES embetant, la preuve en est que j'ai du completement modifie mon soft a cause de ca, et je suis surement pas le seul dans ce cas, sans compter que le resultat est moins performant que le soft original.

Oui mais tu ne sais pas que c'est instable jusqu'au moment ou il te claque dans les doigts, c'est bien ca le probleme.

T'en sais rien, peut-etre que ces drivers qui sont dans le kernels depuis des annees ont des bugs qui font des kernel panics, mais personne n'a encore eu la malchance de tomber dessus.
Tu n'es jamais sur a 100% qu'un soft est bug free, ca vaut aussi pour les drivers.

C'est pas un micro-noyau au sens puriste du terme, les drivers sont en mode kernel.

L'exemple que j'ai pris(PID differents) a pour consequence que:
- Certaines choses sont rendues bien plus compliquees par rapport a d'autres systemes
- Ca oblige a refaire l'architecture des softs a cause d'un systeme qui fait differemment de tous les autres Unix

En gros ca fait bien chier et quand on sait que PID veut dire PROCESS ID, on se demande comment les threads d'un meme process ont un PID different.

Quand a la doc de glibc, ben sur http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_toc.html(...) il n'y a rien du tout, tu l'a prise ou ou ta doc ?

Pour ce qui est du timing, c'est donc bien ce que je disais, il faut faire un truc assez moche(mettre le code pour l'attente hors du thread, pas un bon design car tu delocalise le code) qui prend plus de ressources(1 thread en plus qui gere la chose) et il faut gerer quand tu ajoutes des threads, enleve,... histoire que le thread de gestion se melange pas les pinceaux et oublie pas de threads.

Sinon pour mon probleme a moi, ben OUI laisser sur un waitpid() c'est un TRES GROS probleme.
Apres 500 connections tu te retrouves avec 500 threads attendant sur un waitpid(), dans le genre performance killer c'est dans le top 10, le scheduler il claque avec ca(sans compter les 2Mo de stack bouffes par chaque thread). Quand tu fais du load balancing t'essayes d'habitude d'avoir les meilleures perfs possibles, le waitpid() c'est hors de question.

Ca depend si tu consideres qu'un driver est une partie du kernel ou pas.

Un des drivers fait le con, et degueulasse des structures du kernel mais pas trop, ca crashe pas immediatement.

Le kernel fait son petit bout de chemin, et apres un petit moment se met a traiter ces donnees corrompues, il voit que c'est le merdier --> kernel panic.

Super, et moi aussi j'en ai vu des kernel panic, je pourrais donc faire le meme genre de deduction que toi, mais j'ai l'honnetete de me dire que ca vient peut-etre d'autre chose que de l'OS plutot que critiquer l'OS immediatement.

Mais a part ca, je vois pas trop ce que ca a voir avec le sujet, on parlait de multithreading/multitache et multiprocessing.