aegir_lf a écrit 36 commentaires

Il a en effet du interrompre brutalement ses vacances au ski en Suisse

Mon Dieu, le pauvre. C'est vrai que là ça sent le sapin, le PDG d'une multinationale qui doit interrompre ses vacances, incroyable, qui l'eut cru ?

Mon pauvre Steve, je vais te foutre le moral à zéro : nous, juste pour s'amuser, on code pendant nos vacances.

C'est HP qui a laissé tomber il me semble.

La réunion et la coordination se fait sur la ML "detaxe" ( detaxe@aful.org ) de l'AFUL. L'initiative a certe été trop faiblement suivie, mais pas sans effets : maintenant toutes les DDCCRF sont au courant du problème, et les gros distributeurs aussi. aegir.

La bonne nouvelle c'est qu'ils annoncent une production de 30 000 ex. par mois, alors que le C700 n'était produit qu'à 20 000 ex. /mois.

Ca veut dire que ça se vend pas mal.

En ce qui concerne les bindings KDE, ils sont normalement toujours à jour.

En effet, les bindings KDE pour les autres langages sont générés automatiquement, donc il devraient toujours être au niveau de la dernière version de l'API KDE.

Un truc vraiment utile dans ce même ordre d'idées, ce serait un outil de modélisation (avec reverse-engineering).

Le support DOS sous Windows XP

WinXP, c'est pas une interface graphique par dessus le DOS ?

J'ai oublié la conclusion : le JOIN c'est mieux :-)

Non, l'opérateur JOIN n'est pas "strictement identique".

Pour le résultat, ce sera effectivement pareil, mais l'optimiseur peut traiter différemment le = et le "[INNER] JOIN".

Par exemple, dans tous les SGBD que je connais, l'optimiseur syntaxique ne considère pas que la relation "=" est transitive. Donc si on fait une requete de type :

A.id = B.id
AND B.id = C.id

l'optimiseur syntaxique n'en déduit pas que

A.id = C.id

Du coup, lorsque l'optimiseur statitistique évaluera les plans d'exécutions possibles, il évaluera le plan en utilisant A ou C comme table directrice, mais jamais B. (quand on sait ce qu'on fait, ça peut être pratique pour blouzer l'optimizeur, mais 99 fois sur 100, c'est une mauvaise idée).

Pourquoi le "=" n'est pas transitif ? Parce que sinon on arrive à des combinatoires trop complexes pour le choix du plan d'exécution. Par exemple si je fais :

WHERE client.id = commandes.client_id
AND client.id = 12345

Il faudrait que l'optimiseur evalue également :

client.id = commandes.client_id
AND commandes.client_id = 12345

et donc qu'il évalue aussi :
WHERE commandes.client_id = client.id
AND client.id = 12345

et
WHERE commandes.client_id = client.id
AND commandes.client_id = 12345

(choix de table directrice)

Pour peu que la jointure soit faite sur 4 tables, et qu'il y ait 2 ou 3 gags de ce genre, le SGBD va passer plus longtemps à évaluer des plans d'exécution qu'à effectuer des requêtes :o)

Par contre, un optimiseur syntaxique (voire statistique), PEUT tout à fait traiter différemment le JOIN. Et si l'optimiseur est codé pour le faire, il choisira le plan d'exécution plus intelligemment qu'avec des "=".

Ou bien il faudrait que ceux qui lisent les commentaires soient plus subtils qu'un parser HTML, et n'aient pas besoin de tag HUMOUR pour être capable de saisir le 2nd degré d'un paragraphe.

Non, c'est pas du javascript, c'est du QSA qui est un langage qui ressemble au javascript.

Le QSA est tout simplement le langage de scripting de QT.