Reprise du message précédent :
ma langue natale c est pas l anglais non plus mais avant de juger de la qualité d une traduction j essaie de parler mieux que ladite trad d abord
et accessoirement ca marche pas du ton truc
 

ici #main génère une boite en ligne anonyme
#main possede en css {vertical-align:middle;}
et donc la string "test" devrait etre centrée
 
c est la doc qui est pourrie pas la trad

http://news.php.net/php.internals/33694
 
 
k, lol

C'est parce que leur parser est le plus rapide possible
 

Ce qui est grave, c'est que les principaux devs n'ont même conscience de ce qu'ils racontent. Des choses évidentes dans d'autres langages (genre justement la gestion des namespaces) leur paraissent tout simplement "inutile" juste parce qu'on peut faire pareil "en prefixant les noms de classes." Le mec, on dirait qu'il a fait du C toute sa vie, et qu'il n'a même pas essayé de voir ce qui se fait ailleurs...

Ouais mais nan, la reco dit :

ça parait farfelu en effet...
 
en général c pas une super idée d'avoir une fonction clé qui dépend du bon vouloir des gens pour être mise en oeuvre alors qu'il y a moyen de la mettre en oeuvre systématiquement...
 
pis bon, son truc de préfixe ça pue...surtout sur 3 lettres...tu utilises une librarie, le mec a pris les meme 3 lettres, t mort, tu peux nommer aucune de tes classes comme celles de la librairie...

 
dingue, raconte !!

euh tu m excuses mais cette propriété s applique au parent hein  

J'ai jamais dis le contraire, ce que je dis c'est que la propriété vertical-align ne peut pas être héritée automatiquement comme spécifié dans la reco et quoté juste au dessus. En ce, "test" ne peut pas hériter ce cette propriété, et ne sera donc pas aligné.

Le m n'est pas la lettre la plus "large", la lettre la plus large doit etre calculé selon la police. En l'occurence, c'est le plus souvent le W qui pour des raisons d'optique à un oeil qui dépasse en largeur le M, de la meme façon qu'un V est plus haut qu'un E (toujours pour des raisons d'optique). Par contre, j'avoue, je ne me souviens plus de comment s'appelle ce "dépassement" nécessaire, faudrait que je ressorte mes cours, mais ça date de plus de 10 ans maintenant.

P.S.: Désolé pour les accents circonflexes, je viens d'installer ma nouvelle souris et impossible de taper un accent circonflexe depuis, ça me fait ^^e.

Avec l'unicode, c'est style un caractère arabe ou chinois ou je sais pas quoi. Faudrait que quelqu'un test la fonction GetTextMetrics de la lib GDI pour voir (si j'ai le temps je ferais un essai)

Oui enfin, vous vous parlez en programmation, moi je suis un vieu con qui parle en typo française.
Ca se trouve, aux USA, ils considèrent que le V fait la m^^eme hauteur qu'un E, spa mon problème, je me doute bien que dans les caractères Chinois, il doit y en avoir de plus large que le W. J'ai la version Chinoise de MD sous la main, c'est très amusant.

 
bah nan "test" n a pas besoin d heriter vertical-align ...vu que c ets une propriété qui ***DOIT*** s appliquer a son ancetre
te tracasse pas hein  
si tu connais pas le sujet spatafote  
gatsu aussi seche dessus : les specs sont pourries  
 

 
tiens c est marrant mais maintenant que shinuza me l a fait remarquer le chapitre typo du w3c est beaucoup plus pointu sur sa trad que sur l original

Je crois plutôt que t'as rien compris
 
Le principe des Cascading Style Sheets c'est, comme leurs nom l'indique, l'application des propriétés en cascade.
 
Quand je fais :

#foo {color:red}

La propriété color est appliquée à #foo et héritée par le strong qui contient "bar" (d'ailleurs si tu lui rajoute une valeur border-width et border-style, #foo aura un border de couleur rouge, donc la propriété est bien appliquée à #foo et à ses enfants)
 
Si je fais :

#foo {margin-top:10px}

La propriété margin est appliquée à #foo mais pas à <p> car c'est une propriété qui ne s'hérite pas (si c'était le cas, p aurait un margin similaire à celui de #foo)
 
Quand tu regardes la reco tu vois que

• margin et ses dérivés sont

  Inherited: no

• color est

  Inherited: yes

Vertical-align est `Inherited: no`donc il s'applique sur l'élement spécifié dans la règle et à rien d'autre, ni enfant ni parent.
 
Conclusion : Y'a absolument aucune raison pour que le noeud anonyme "test" dans ton code hérite de la propriété vertical-align

 
ok alors j ai rien compris
 
ici qui obtient le vertical align ?
(avec .vAM {vertical-align:middle;} bien sur)
 
 
<div><div class="vAM">test</div></div>
<div><span class="vAM">test</span></div>
<div>test</div>
<div class="vAM"><div>test</div></div>
<div class="vAM"><span>test</span></div>
<div class="vAM">test</div>
 
j espere n avoir oublié aucun cas ...

Dans le cas des 1,2,4,5,6 oui.
 
Le truc c'est que ça ne se voit pas, car la hauteur de la ligne est à `auto`, donc calculée à 0, et c'est le font-size qui détermine la taille de la ligne.
Si tu spécifies une line-height (sur le parent ou sur l'élement en question, vu que c'est une propriété héritée), le contenu d'un element qui porte la classe "vAM" sera bien aligné au milieu.
 

 
Tu peux y mettre ce que tu veux tant que le contenu ne génère pas une autre line-box (à ne pas confondre avec un élement de type inline) qui, le cas écheant aurait également une line-height égale à celle définie sur le parent (donc ça risque de pas être top). Les élements qui génerent une line-box lors de leur insertions sont les élements de type block, et les élements comme <br> <hr>
 
Truc marrant : Quand tu mets vertical-align sur une image avec du texte juste à coté, ce n'est pas le texte que tu alignes mais bien l'image. Le truc c'est que tu aligne l'image au milieu par rapport à la hauteur de la line-box, et c'est l'image qui détermine la hauteur de cette line-box.

Question URl rewriting
 
- Chez free ça marche ?
- ca ce fait uniquement à base de regexp ?

En même temps, son problème est un faux problème. Il dit que les espaces de noms sont inutile mais il prend un cas où on élimine la séparation des espaces de noms en important tout le contenu d'un espace de nom dans l'espace de nom courant.
C'est sur que dans ce cas particulier, il n'y a pas d'intérêt à avoir des espaces de noms.
 
Le problème, c'est que sur la liste interne, ils y en a un ou deux qui se focalisent uniquement sur ce cas particulier en oubliant toutes les autres manières d'utiliser des espaces de noms et ça c'est vraiment débile. (ça doit faire un mois et demis à deux mois que Derick rabache son exemple à la con)
 
Enfin, bon, c'est pas par ce qu'il y en a un qui fait son caca nerveux que ça empêchera pas les espaces de noms d'être implémenté dès php 5.3 (d'ailleurs, c'est déjà le cas) et de même c'est pas par ce que certains font leur caca nerveux par ce qu'une option dangeureuse n'est pas implémenté par défaut (par exemple le fait de pouvoir transformer n'importe quelle variable en super globale) que ça sera rajouté dans le parseur contre l'avis de le majorité.

Heu ... je vois pas le rapport.  

C'est clair. Dans son cas le problème, c'est qu'il se cherche des complications là où il n'y en a pas. Heureusement que la majorité des "principaux devs" arrivent à garder généralement la tête sur les épaules.

 
Je dirais qu'il n'y en avait pas ... joke toussa

Dites, c'est moi, ou le types qui ont ecrit la doc de symfony n'ont jamais teste leurs exemples?

Ou, les exemples fonctionnaient à une epoque, et la doc à jamais été mise à jour

La plupart que j'ai pu testé marchait, t'as quoi qui marche pas ?

Bien sûr que si, c'est pas parce qu'on choisi d'importer le contenu d'un namespace dans le namespace courant (ou de l'aliaser) pour des raisons de simplicité et de clarté que les namespaces ne servent à rien

http://en.wikipedia.org/wiki/Joke

lol

Pas la peine de précher un converti. Personnellement,  je suis bien content qu'ils aient implémenté un système de namespace.
Par contre, lui à l'air de vraiment penser qu'il n'y a (quasiment?) pas d'intérêt aux espaces de noms par rapport aux défauts du système actuel et pour le prouver il donne un exemple où il élimine l'intérêt des espaces de noms en en important dans l'espace courant pour retomber dans les défauts d'un code sans espace de nom. (son 1)
Son 2 est encore plus risible, même si on ne peut pas faire un "use myNamespace::* as *;" on peut faire un "use myNamespace;" qui revient au même. (du moins avec la version de php6 que j'ai récupéré il y a quelques temps c'était possible)
Son 3 a été discuté plusieurs fois sur leur liste interne et le seul truc sur lequel ils n'ont pas réussit à se mettre d'accord, c'est sur la syntaxe pour avoir plusieurs espaces de noms dans un seul fichier. Pour l'intérêt d'avoir plusieurs espaces de noms en lui même il n'y a pas l'air d'avoir de discordance. Le coup de l'abscence des {} et le fait de devoir mettre le mot namespace découlent simplement du fait qu'ils n'ont pas réussit à se mettre d'accord sur une syntaxe qui permet d'avoir plusieurs namespace et qu'ils en sont encore à une syntaxe simplifié. A partir du moment où tu ne peut avoir qu'un seul espace de nom par fichier il n'y a aucun intérêt à rajouter des {} qui entoureront tout le code php ou de mettre le mot namespace au milieu du fichier (ce qui serait une hérésie)
Dans son 4 l'idée d'avoir un endroit où réserver des noms d'espace de noms ou de préfixe est une bonne idée en soit bien qu'inutile si on pense à la méthode choisit par sun pour le java (utiliser le nom de domaine de la companie (ou du site perso) des créateurs d'un logiciel comme espace de nom de base) Par contre son argument comme quoi c'est inutile par ce qu'on peut préfixer des noms de fonctions est franchement débile.
 
Alors vas y dit moi en quoi j'ai tord dans mon analyse de son message.

Pour rappel, c'est un argument que tu utilises régulièrement de manière sérieuse. Une blague n'est marrante que quand elle est comprise.

Pour rappel, faudrait que t'apprennes à lire, j'ai jamais utilisé cet argument (d'autant moins sérieusement) c'est florentg qui l'utilise et on se fighte systématiquement sur le sujet, d'où la blague justement

Même moi j'avais pigé

 
Bah non, la doc est pour la version 1.0 et j'ai pris la version taggee 1.0 pour etre sur (c'est pas mieu sur la 1.0.9)
 

 
Bah deja tout ce qui est generation du model SQL est foireuse. La transformation yml -> propel se trompe la plupart du temps dans l'auto-detection des types et des references. Ensuite, les exemples de redirection sont foireux, ils ne prennent en compte que le cas ou tu mets ton app dans le meme folder que le framework, et d'autres dont je me rappelle plus. Mais bon, ca fait pas tres serieux (comme tous les trucs php, je sais )

ok, autant pour moi.
PS : la bonne page de wikipedia est : http://en.wikipedia.org/wiki/Private_joke

Quelqu'un saurait-il me dire pourquoi cette requête fout mon serveur à genoux, process à 100%, machine à la limite de l'inutilisable ...
 

SELECT u.email
FROM user AS u
LEFT JOIN ad ON ad.email = u.email
GROUP BY u.email

 
Sachant que les requêtes suivantes fonctionnent par exemple :
SELECT u.email FROM user AS u GROUP BY u.email
SELECT ad.email FROM ad
 
J'ai testé une jointure quasi identique sur une autre table, ça marche sans problème
 
J'arrive pas savoir où ça merde, j'ai une table fuckée ? Pourtant j'arrive faire des SELECT dans tous les sens, sur chacune des tables concernées... Il y a un moyen de connaître le "déroulement" d'une requête au fur et à mesure ? Histoire d'essayer de comprendre où ça plante ...
 
Ou toute autre suggestion
 
Le serveur à bien entendu été redémarré plusieurs fois...
 

utilisé un "group by" sans agrégat c'est cherché les emmerdes aussi
Un distinct me parait plus que vivement recommandé.
 
Mais bon j'imagine que ce n'est pas vraiment ta requête car là, dans l'exemple la jointure ne sert strictement à rien.

T'as des exemples + précis ?

SELECT u.email
FROM user AS u
LEFT JOIN ad ON ad.email = u.email
GROUP BY u.email

Fais péter un explain

Le group by sans aggrégat <=> distinct

Non en effet ce n'est pas la requête finale ça, je l'ai épurée mais le résultat est le même.
 
En fait le GROUP BY est là parce qu'il y a un COUNT et un SUM.
 
Le problème est que même avec la requête que j'ai épurée que j'ai mis plus haut j'ai le problème.
 
J'ai laissé tourner la requête de tout à l'heure pour voir si c'était juste lent, ou si le serveur plantait ...
 
Et je viens d'avoir le résultat de mysql :
5873 rows in set (11 min 43.28 sec)
 
Ce que je ne comprends pas, c'est qu'avec la même requête sur les même tables, hier j'avais le résultat en quelques secondes seulement.
 
La requête ne va servir qu'une seule fois, pour récupérer certains user et certaines infos de l'ancien site avant de passer sur le nouveau, donc en soi si la requête est lourde c'est pas très grave... mais là je comprends pas, passer de 2 secondes à 11 minutes quand même ...

Y'a des indexes sur u.email et ad.email ? Ce peut aider non ?

 
Avec la requête complète (donc PAS celle que j'ai mise plus haut), le EXPLAIN me donne ça :
 

 
Ce que je ne comprends pas, c'est pourquoi je n'avais pas de problème quand j'ai testé la requête hier en fait

Il y a peut-être eu des calculs de stats sur les tables et les indexes cette nuit qui font que aujourd'hui, le moteur SQL ne suis plus du tout le même chemin que hier.

C'est un pov serveur MySQL installé en local sur mon PC ... et je doute que quoi que ce soit ait été fait cette nuit

Effectivement

j'ai mis une balise < captain obvious proof

sans la fermer, le post est vide