Reprise du message précédent :

Non, tout simplement : Beta 2 -> B2
060131 -> 2006-01-31 (donc la version a 2 ans déjà )

 
L'auteur mis en premier, c'est parce que je voulais faire une présentation typée "client mail", avec des conversations (sujets).
Après, l'histoire du clic sur toute la ligne, chacun son feeling, mais 99% des gens cliquent sur le sujet lui-même et pas sur la ligne du sujet.
 

 
Gné ?  

il a voulais faire la meme presentation que les mails apparement, mais c vrai que sur un forum, le createur du topic n'est pas interessant, par contre cette mise en page serait bien pour les MP .
 

 
Le php est intérprété, donc les perfs ne sont pas tres bonne, mais on peut isoler le binaire généré (byte code) et le réutilisé, donc le code n'est intérprété qu'une seule fois, les perfs sont logiquement carrément meilleure. J'ai la chance d'avoir l'administrateur d'eaccelerator qui bosse avec moi, ça aide (c'est un tueur en php d'ailleurs)
 

C'est une sorte de mise en cache non ?
Du style, j'externalise les fonctions usuelles dans un fichier que je compile, et tout sera plus rapide ?    
 
Enfin je ne me suis pas encore penché sur le sujet, mais c'est intéressant.

Ok, je percute mieux.

C'est surtout en cas d'erreur en fait, genre là j'avais un peu mal cliqué, et je me suis retrouvé à pas avoir cliqué sur le titre même

Tu n'utilises pas d'outil de gestion de sources/versions pour ton développement?

Le bytecode n'est pas un binaire, c'est un langage intermédiaire, qui est également interprété.

Ce qui est économisé, c'est la conversion entre le code php "haut niveau" et le bytecode (qui est de beaucoup plus bas niveau, et que le runtime PHP consomme), qui coûte très cher en PHP (enfin pas qu'en PHP en fait, mais dans la mesure où PHP n'a ni cache natif à la python ni compilation explicite en bytecode à la java ou erlang, c'est pas donné)

Là, on ne peut plus rien faire pour toi

Non, malheureusement, personne ne m'a encore montré l'intérêt que ça peut avoir.
Et je n'en ai pas ressenti un quelconque besoin, après, si quelqu'un peut me montrer en quelques lignes l'intérêt de ce genre d'outils, je suis prenneur, mais dans l'immédiat, je fonctionne très bien comme ça.

Edit :

 
Oui ça met en cache le byte code, en fait, quand on lance un .php avec le binaire php, il fait une passe pour analyser le code source, genere un pseudo binaire (en mémoire) qui est enfin exécuté par php. Attention ce n'est pas un binaire au sens pur qui n'a plus besoin de sa machine virtuelle. En fait il fait un peut comme java, sauf qu'il compile chaque fois que l'on lance le .php.
 
Donc avec des outils tel que eaccelerator, apc, xcache... ils mettent en cache ce byte code (en mémoire ou sur disque) et réutilise le byte code a chaque demande du .php... ce qui procurre un gros gain en perfs. Le byte code est regénéré si on change une ligne de code dans le .php.
 
Php 6 utilisera son propre logiciel de cache byte code.
 
Compile eaccelerator et test avec AB tu verras ça n'a rien a voir, et surtout a l'utilisation avec un petit serveur. Bon si ton code est trop complexe il peut y avoir quelque segfault   Mais ça ne devrait pas arriver avec un forum. (style utilisation intensive des signaux unix)

Il faut aussi apprendre a optimiser le temps developpeur et pas seulement le temps machine    
 
Ca coute moins cher une machine qu'une developpeur
 
Ensuite, si c'est pour le fun et la passion, c'est interessant d'optimiser de cette façon, mais l'interet du php c'est de simplifier le developement et de gagner du temps    
 

 
Ah bon  

Ben si, suffit d'agrandir la taille de la zone de cliquation

Genre dans mon client mail (haha tu peux rien faire là ) je peux cliquer dans toute la case du titre, pas besoin de cliquer spécifiquement sur les lettres du titre

• Le premier et principal, c'est de conserver tout l'historique du projet (et d'être facilement backupé, dans la mesure où le repository est habituellement stocké sur une machine serveur il suffit de backuper le serveur et même si ta maison brûle, tant que les backups sont à l'abri t'es tranquille)
• Le second, c'est de faciliter la recheche de bugs (par exemple quand tu découvres un bug et que tu ne sais pas d'où il vient exactement, tu peux revenir en arrière pour voir si c'était déjà buggé)
• D'ailleurs, le 2bis c'est que ça sert de machine à voyager dans le temps: tu peux récupérer n'importe quelle version de ton projet (genre si tu as enlevé un truc que tu veux remettre, ou si tu veux voir quelque chose que tu avais fait précédement, ou même comment tu l'avais fait)
• Un 3e intérêt majeur, c'est que ça permet de synchroniser facilement plusieurs machines, et donc que ça facilite aussi bien le développement depuis plusieurs machines (genre j'ai une machine de bureau dans mon appart et un portable, et je peux dev sur n'importe lequel des deux et facilement les synchroniser) que les contributions (tu peux bosser avec d'autres, ou d'autres peuvent bosser avec toi et contribuer à ton projet)
• Si t'es pas du genre à tenir un log permanent de tes modifs, ça te permet de te souvenir des modifs faites et d'extraire un changelog (aussi bien pour toi que pour d'autres)
• Enfin, ça permet de facilement publier le code (avoir un repo lisible par tous pour la publi du trunk), et de maintenir des "branches" différentes de manière à peu près correcte (genre tu lances ta v5, mais tu continues à maintenir et patcher la v4 au moins pendant un temps)

Sur mes projets persos, j'utilise un SCM surtout pour la synchro entre des ordinateurs multiples et pour l'historique de version, le dernier me permettant de faire des essais et de partir un peu dans tout les sens (je sais que si je fais une connerie je peux facilement revenir en arrière sans me demander où j'ai mis mon backup et si j'ai pas oublié de le faire. C'est un peu comme un CTRL-Z infini)

Mais qu'est-ce que tu racontes?

a la base oui
 

Apres si on utilise un algo en bois c'est sur que l'on peut utiliser des mise en cache, ça restera un algo en bois

Eacc propose pas d'outil pour convertir un fichier php en bytecode directement ?

 
Non malheureusement Et je ne pense pas que ça soit fait un jour. (je les comprends vu que php 6 intégrera APC le concurant)

Une sorte de compilateur?

C'est vrai que ça serait pas mal d'avoir du php "pré-compilé" directement dans les fichiers source.

 
Merci pour tes explications.
J'essaierai pour la première fois de ma vie, d'avoir un truc à moi sur sourceforge.net
Je verrai bien, avec une éventuelle future v6

Zend Encoder ne fait que crypter les sources et quelques optis directement, le fichier doit être réinterprété ensuite par PHP/Zend il me semble (EDIT : après vérif sur leur site, il semble que cela permette de bypasser le parseur php ).

PHP aurait dû faire proposer ça depuis longtemps (gratuitement contrairement à Zend), ça leur coûte rien de vérifier via une entête de fichier ou je ne sais quoi qu'un .php est déjà précompilé/interprété, de sauter alors la partie parseur php et de l'exécuter directement, 5 lignes de code en plus dans leur bazar c'est pas la mort. Ca en ferait des gains de ressources, de taille de fichier sûrement aussi, au lieu de perdre du temps à réinterpréter à chaque fois des fichiers invariants ou de bricoler avec des caches de bytecode externes...

Masklinn> il y a quoi comme outils de gestions de version pour php? c'est interessant.

C'est pas lié à un langage
 
Perso tous mes projets sont sous CVS depuis 3 ans.

 
C'est ce que fait eaccelerator ou xcache, et en open source, donc ça va quand meme, mais il a fallut un truc exterieur domage. Cet handicap sera réglé avec php6 et APC intégré.

 
Au boulot on utilise Buildix, ça marche au poil pour gerer les projets (svn pour les sources)

Ok tout s'explique, je pensais que t'étais dérangé, en fait t'es sadique. Php + CVS, t'as tout ce qui faut pour bosser chez Yahoo!

manque la gestion des couleurs
manque la recupération des mdp
manque la possibilité de rajouter des smiley (ou faire comme la v4, ce que j'ai fait avec la v5 que j'ai )

C'est vrai que y a 3 ans Mercurial, Git, SVN c'était super stable est répandu
J'ai pas pris le temps de migrer vers SVN
Et j'en ai pas besoin.

Au taff, SVN.
Lors de mon ancienne mission j'ai initié la migration PVCS -> CVS y a 2 ans

Mais laissez crever CVS enfin  

Non mais j'installe plus des dépots CVS, j'en ai juste un qui tourne

Mais qu'est ce que tu fais là toi

De toutes façon, tout le monde sait que c'est SourceSafe qu'il faut utiliser comme contrôleur de version

MS ferait bien mieux de laisser tomber cette technologie vieillissante (pas d'évolution fondamentale en 10 ans, quand même) et de commercialiser Source Depot (leur solution interne conçue pour gérer les développements depuis Windows 2000)

Bah, tu fais bien comme tu veux, mais pas avoir de commit atomique avec le changeset qui va bien, c'est super relou je trouve
(sinon tu connais cvs2svn ? )

Je contribue à élever Grenoble au rang de ville l33t pour faire des forums

bah y'a plein de gestionnaires de versions open source et gratos, MS irait pas s'amuser à en commercialiser un je pense...

C'est indépendant du langage, sauf dans certains cas particulier (certains outils, comme Envy, sont spécifiques à un langage -- ici Smalltalk). La majorité travaillent simplement sur des fichiers, texte ou binaires, quels qu'ils soient.

À titre personnel, en 2008, sans avoir de backlog à convertir, je conseillerais de partir sur du Mercurial ou du Git.

En l'occurence, il y a 3 ans SVN était déjà stable depuis un moment

Ils filent TFS maintenant, paraît que c'est moins pire que SourceSafe

http://en.wikipedia.org/wiki/Visual_SourceSafe
http://en.wikipedia.org/wiki/Team_Foundation_Server

Et accessoirement, il y a plein de gestionnaires de sources commerciaux: http://en.wikipedia.org/wiki/Perforce http://en.wikipedia.org/wiki/Clearcase http://en.wikipedia.org/wiki/Bitkeeper http://en.wikipedia.org/wiki/AccuRev%28vcs%29 http://en.wikipedia.org/wiki/Vault [...] _system%29 etc...

SourceSafe est vendu (ou était?) en standalone, et fourni avec Visual Studio. A partir de 2005, je crois que ça a évolué mais on était resté à VSS6 à cause du projet principal, en VB6.
 

Ah zut, j'en avais entendu parler à un moment et je n'ai pas suivi, j'avais complètement oublié

VSS était vendu jusqu'à l'époque de VB 6. Quand je parlais de commercialiser un gestionnaire de source, je pensais plutôt à celui utilisé en interne, mentionné quelques posts plus haut

 
VSS (6.0, décliné en a,b,c et d) etait utilisé jusqu'à VS 2003.
 
Aujourd'hui, avec VS 2005, on a un superbe VSS 2005, qui se trouve n'être qu'un VSS 6.0e... mais avec une meilleur intégration à VS 2005 (et des menus en dégradé de couleur ). Il n'est finalement utilisé que pour les petites structures, les grosse equipes s'orienterons plus vers des VS 2005 Team System intégrant un systeme bien plus performant.
 
 
(PS: et je conchie ClearCase...)

Oui, l'interface est plus jolie mais je ne l'ai vue que par dessus l'épaule d'un utilisateur, je ne sais pas s'il y a eu des changements. Et que ça avait l'air incompatible avec les versions précédentes, au passage.

 
Aucun changement.... VSS 2005 est une évolution mineure de VSS6
 
Aucun problème pour utiliser VSS 2005 sur une repository VSS 6.0