tuan kuranes a écrit 451 commentaires

Pas de progres ces 10-20 dernieres années du coté theorique.

En pratique on peut plus facilement les appliquer. Par exemple, les reseaux de neurones demandant beaucoup de puissance de calculs, on commence a s'en servir (la théorie date des années 80).
Pour des problemes comme celui-la il faudrait des avancées théoriques significatives...

Tu as raison, je reformule ma pensee :
Plus un language est de haut niveau, moins les "programmeurs" l'utilisant ont a manier de concept informatique abstrait. (fonction, variables, memoires, objets, heritages, etc...)

Pour VB et PHP je donnais des pistes de leurs succes aupres de "apprenti codeurs" capable de coder des logiciels complexes qui marchent. On est d'accord, c'est un nid a problemes... mais ils arrivent a leur fins et c'est la le point que je voulais souligner :
Ce qu'ils arrivent a faire la, il ne pourraient le faire avec des languages plus bas niveau.


Il faut bien differencier les 2 pistes dans mon post:

->codage simple : sans apprentissage de concepts informatiques)

->resoudre le probleme de couts, bug des logiciels complexes : la il faut renforcer l'apprentissage de concepts (comme les designe patterns) permettant a l'informaticien d'exprimer ses intuitions plus facilement.

" avec les avancées qu'on a fait en IA ces dernières années"

Lesquelles ?
Les IA est tres loin de pouvoir faire le "programmeur virtuel"

Ton probleme est un peu le probleme du compilateur des langages formels... cf http://fr.wikipedia.org/wiki/Langage_formel(...)

pour résoudre le problemes des bugs et des couts associes :

Management => Extreme programming. (programmation par paires, test unitaires, client-dev synchro le + possible, etc...)

Modules => Utilisation de librairies, modules le plus possible (revient a decouper en petit probleme les grands). L'Open Source donne ici de grands résultats.
Un bon exemple est de developpement de jeux video (million de dollars de budgets) lire ce papier :
A FLEXIBLE AND EXPANDABLE ARCHITECTURE FOR COMPUTER GAMES Jeff Plummer => http://www.jeffplummer.com/Writings/Thesis/Thesis_with_Appendix.pdf(...)

Apprentissage => Tous les developpeurs devraient connaittre par coeurs les motifs de conception basique. (design patterns du gof)

Pour l'écriture de logiciel moins complexe, mon opinion personnelle:

Plus un language est de haut niveau, moins les "programmeurs" l'utilisant ont a manier de concept abstrait.

On va vers la multiplicité des languages et leurs adaptation a la tache (qui explique le succes de php pour le web, le succes de VB pour excel et access).

Quand on recupere des sources VB et PHP, on le voit bien : Pas de fonction, que des variables globales, pas de gestion memoires, etc... et souvent les codeurs sont pas tres vieux.
Mais ca marche.

Pour les taches complexes non standard (pas du web, access, excel), il faut assembler des modules en langage de bas niveau pour gagner en expressivité du langage (et ne surtout pas tout recoder soi-meme.)
C'est tout le succés de Java de proposer des librairies standard tres etoffées, l'assemblage est alors tres simple, et le gain en expressivité est tres vite réalisé.

"On peut considérer que les designers font du développement, avec des sources qui peuvent être conséquentes"

je ne dis pas que c'est pas complexe aussi, mais en microelectronique, on est :

- En systeme fermé
- Avec des entrees sorties tout a fait caractérisees, bornées.

Bref, le rêve pour un developpeur.

Ce n'est malheureusement pas comparable a l'envirronemment de développement logiciel.

Avec le logiciel, on est confronté à :

- Multiplicité des configurations de l'os, rendant impossibles les tests par le developpeurs sur toutes lse plates-formes (os, noyaux, patches, etc...)

- Multiplicité du materiel rendant impossibles les tests par le developpeurs sur toutes lse plates-formes (intel, ppc, ram, ddram, cartes video differentes, souris, pad, vitesse de bus, taille de l'ecran, etc...)

- Multiplicité des entrées-sorties rendant impossibles les tests de toutes les combinaisons possible (les cas de tests de courverture complete sont tres rare, voire inexistants en cas réels.)

- Contexte (autres logiciels en marche qui modifient le comportement de l'ordinateur)

Tout ca rend tres difficile le développement... et le débogage encore plus : le plus grand probleme étant souvent d'arriver a reproduire un bug, tellement le nombre de conditions a remplir est grand.

"Si les bugs sont rares, c'est parce que faire une erreur ca coûte très cher"
c'est le cas en developpement de gros logiciels... combien coute une Ariane explosée ou une journée de panne SNCF a ton avis ?

Utilisateur depuis longtemps, c'est tres, tres bien et complet.
Et le suivi est a la hauteur de l'appli, les failles de securite sont vite corriges, et ils font des audits de securite de l'appli regulierement.

Seul regret, le "Photo Printing Services", tres pratique pour mes proches desirant se faire envoyer les photos imprimees ne marchent qu'avec des services americain. (Mais ca marche bien)

Les entreprises francaise proposant ce services ferait bien de se rajouter dans la liste.
C'est quand meme tres pratique.

Ogre gere tout ce qu'est cense gerer les prochains unreal au niveau 3d.

TOUT.
Voire plus.

La difference se fait donc au niveau du contenu (modeles, textures shaders, etc...) et marketing (les screens truquees sont pratique courante dans la profession).

l'avantage de q3 c'est le cote moteur complet. (avec par exemple un code reseau nickel).

Son desavantage principal : pas de supports des vertex et pixels shaders.

C++, Windows, Mac OSX,d Linux, (GCC, MSVC).
utilises OpenGL.
Mais est prevu pour etre portable sur d'autre API. (separation nickel.)

http://www.tulrich.com/geekstuff/gameswf.html(...)

Tous les blogs statiques genre http://www.movabletype.org/(...) en beneficieront. (enfin ceux sur apache, IISS a eu des problemes avec les specs http1.1)

Quelques dynamiques aussi (surtout ceux qui ont beaucoup de clients...) souvent sous forme de patch plugin (lastmodified2 pour bloxsom)

Sur mon serveur de mail, ca m'arrange et j'utilise pas toujours le meme ordinateur (j'aime IMAP pour ca)

ssh + export X c'etait pour ton UI... vi forever;) m'enfin c'est un peu lourd quand meme...

Merci, Que de bonnes nouvelles, je vais me tenter une migration des les taches finies.

C'est que mon serveur mail est sur mon serveur, faire un ssh/export X pour ajouter un feed est un peu lourd... au pire je me bricolerais un php pour editer le YAML par HTTPS...

J'utilise http://www.aaronsw.com/2002/rss2email/(...) mais c'est pas imap et je dois donc ajouter des regles de tri dans mon mailproc pour les avoir dans mes folder comme il faut (et ca surcharge postfix)

- Peut-on rajouter des feeds depuis le mailer, en posant des mails dans un folder special parse en cron par le feeder, comme pour les entrainment de Dspam ?

- Un Timer par feed ?
(certains (pour surveiller mes sites (wiki, forums) des spammers sont a 5 mn), d'autres a 1 fois par h et d'autres 1 / jour)

- Bonne utilisation le time et le etag pour ne pas surcharger le serveur ?
cf http://fishbowl.pastiche.org/2002/10/21/http_conditional_get_for_rs(...)

C'est OpenSwan maintenant qui remplace freeswan.
(et compatible avec les noyaux 2.6)

Ils ont une bonne doc d'install tres detaillee sur leur site
(meme pour les clients windows 2k et XP).

Ca s'installe sans aucun probleme..

Merci pour ton boulot !

On a suivi avec interet ton travail d'optimisation...

Peux tu nous livrer quelques conclusions sur les
pistes/ astuces / trucs a faire / trucs a ne pas faire ?

y'a pas vraiment le choix : nforce4 64 bits
(RAID0, RAID1, RAID 0+1 hardware et driver nforce linux64, et reseau gb integre.)

Pour info, photoshop commence par decompresser tout le fichier en memoire (donc en RAM + swap perso photoshop)

Donc je n'investirais pas demesurement dans le serveur mais plutot dans les stations.

Pour photoshop, du DD rapide (genre sata raid0) sur les stations d'edition et des tampons enormes (2-5go) sur des partitions proche du debut de ces disques.

Le serveur ne servant que de sauvegarde ou d'ouverture de fichier.

ET

Au besoin, fais un cours sur le ratio pixels/ppp/dpi imprimante pour qu'ils choisissent les bonnes tailles d'edition et non pas le max possible a chaque fois, meme pour un flyer imprime en 600 dpi...

"C'est vraiment pénible car on ne peut plus faire une animation en fonction du temps sans que ça saccade"

En 3d, on utilise toujours un temps moyen sur les n dernieres frames, jamais un temps absolu pour l'animation. (et encore plus pour la physque, l'IA, etc)

ET

un max de temps qui permet d'empecher l'execution (si on sort de ton appli et que l'on rentre 2mn plus tard). Si l'ecart de temps est trop important, on annule l'execution de cette frame et on reprend a la nieme prochaine..

Reference : "The Clock: Keeping Your Finger on the Pulse of the Game," Game Programming Gems 4, Charles River Media, 2004.

Des specialistes de ton sujet qui pourront surement te repondre : http://www.remakes.org/(...)

un paquet de "hello world" (tetris, pong, breakout, minigolf, etc...)

http://www.ogre3d.org/phpBB2/viewtopic.php?p=48929(...)

"juste" le rendu.

Pour le reste, beaucoup de morceaux de code ont ete donne dans les forums :
-Son : openAL, Fmod.
-Collisions/physique : Opcode, Ode, Newton, Tokamak
-Reseau Enet
-Video : Ogg vorbis, theora, ffmpeg

En bref, Ogre est un vrai moteur 3d alors que G3d est une surcouche d'opengl avec des fonctionnalites non-3d et 3d integres sur la base du "utiles dans pluseurs projets 3d donc mis dans la lib" (le reseau par exemple)

Sinon les differences :

- License BSD contre LGPL pour Ogre.

- Ogre supporte directX7 et directX9 et OpenGL (sous win les drivers ATI sont assez mauvais en OpenGL par exemple) et est prevu pour d'autres protage (un portage playstation et Xbox ont existe a un moment.).G3d ne supporte qu'OpenGL.

- Ogre contient bcp plus de fonctionnalites utlise couramment dans les jeux et la 3d (animation, particules, mutl-textures, multi passes) scripts pour les materiaux et les particules (Vraiment utile.), etc...

- G3d n'a pas de systeme de plugins, pas de separation moteur-gestion de scenes, du coup il faut mettre les mains dedans. ( Ogre c'est sous forme de plugins une gestion de scene BSP, terrain, Octree.. g3d c'est "AABSPTree" code en dur.

"même pas opensource"
http://developer.nvidia.com/object/cg_compiler_code.html(...)

Ogre ne "depends" pas de cg, il permet de l'utiliser au travers d'un plugin, c'est tres different...

Tu peux choisir d'utiliser toute les autres formes de langages de shaders disponibles de nos jours.

( et Cg est dispo pout Mac, linux et windows, en 32 et 64 bits.)

Une peu de lecture qui fait du bien sur le sujet :
http://www.idealx.org/doc/xp-synthese.fr.html(...)

Le support linux est complet : autant de fonctionnalites que sous windows. (plusieurs des devs sont sous Linux, et tous ont Linux installes sur un de leur PC.)

Et meme plus, avec le support AMD64 sous linux. (sous debian:attention il y a un probleme avec la libpng, si le post sur la liste debian n'a pas corrige le probleme cf http://www.ogre3d.org/phpBB2/viewtopic.php?t=6624&start=50(...))

Apres ta carte video et ton driver supporte plus ou moins la 3d...
(Ogre ne fait pas d'emulation logicielle de la 3d)

"l'ajout du support des hardware pixel buffers et du rendu HDR (High Dynamic Range)"

Plus clairement il s'agit du support de textures "float" utilisables pour donner des rendu de hautes qualites (HDR).

La precision de ces textures vont aussi aider a l'utilisation des GPU comme processeur mathematiques specialises : les implementations d'IA sur GPU de Reseaux de Neurones sont de l'ordre de 10^6 noeuds et de 10^8 poids pour une conectivite moyenne de 100. (bon, le cerveaux humain, c'est 10^11 neurones et 10^15 synapses... en plus d'autres choes...)

Ogre est un moteur 3d de tres grande qualite, avec une conception vraiment bien pensee, une communaute tres active, une documentation tres complete, et en plus libre.

Ce que ne dit pas la nouvelle, c'est que ce moteur a toutes les fonctionnalites de moteurs Pro, gestion des lumieres a la DoomIII, Gestion du bump-mapping a la Unreal Engine 3, Animation de squelettes par shaders, etc...

Voire plus, grace au support de la communaute :
Differents scenemanagers adaptes selon le jeu (interieur,exteieur, villes, grand terrain, etc...) Rapports de bugs, Wiki, Forums, Contributions, patches, outils de plus en plus nombreux, et teste sur de nombreuses plate-formes (configuration machine et logicielles)

A noter , il existe une version en .Net appelee Axiom qui compile sous Mono.

Pour propragmmer proprement en javascript il faut utiliser la methode objet. (classes, heritages, etc...)

http://www.sitepoint.com/article/oriented-programming-1(...)