CrEv a écrit 4577 commentaires

pour ceux qui n'auraient pas compris, je cite une partie du dernier paragraphe de l'édito du numéro 100 (je pensais que ça pouvait être compris...) :

Le premier numéro de l'année 2008 est le 101... troublant, non ? Le premier qui dit "lol", je le mords !

si je me souvient bien avoir lu dans divers posts, linuxfr est justement hébergé dans un datacenter free...

ps : vive GMLF lol
;-)

mon avis :
Je suis abonné à GMLF depuis quelques temps, et je le lis depuis 4-5 ans.
Je suis aussi abonné à misc.
(et accésoirrement il m'est arrivé de lire des Linux Pratique mais plus maintenant)

-> Pour du reseau, de la sécu, ... il vaut souvent mieux se tourner vers misc. C'est d'un niveau souvent très élevé, pas toujours facile à apréhender mais c'est vraiment passionnant.

Pour ce qui est de GLMF je crois qu'on a tous un point de vue différent.
Pour ma part, étant développeur, il m'est arrivé de ne pas lire tous les articles réseau et de trouver qu'il y en a trop.
Mais au final, ce qui me plait le plus c'est justement qu'il y a plein de sujets traité et que ce ne soit pas un magazine de {réseau|programmation|ckonveu}.
C'est ce qui en fait sa richesse et qui m'a permit de décrouvrir bon nombre de choses que je n'aurai pas lu sinon (ben oui, une fois que j'ai le magazine je suis bien obligé d'au moins lire le sommaire ;-))

En clair, même si je survole certains articles (je suis loin d'avoir fini les hors série gcu...) j'estime qu'au moins les 3/4 des articles m'intéressent / me sont utiles.

Pour misc, c'est parfois moins mais je vois ça comme des ressources dans lesquels je pioche selon mes besoins (plus limités car ne bossant pas sur du rézo)

Donc vala, vive GLMF et Misc ;-)

oups, désolé le "MyClass.myFunc.call" était pas du ruby du tout ;-) (du javascript en fait) Désolé pour la confusion.

vi, rajouter un __call__ ... c'est moyen je trouve. Ou plutôt ça doit rester du code "interne"

Concernant les méthodes, attributs, ... Une méthode et un attribut c'est normale que ce ne soit pas pareil
Mais en fait ça dépend comment on fait ;-)
Un attribut est par défaut uniquement privé (et ça c'est le bien)
Mais on peut évidemment le rendre public.
Et on peut également définir les méthodes d'accès aux attributs, mais ces méthodes on l'énorme avantage (selon moi) de se comporter de l'extérieur comme si on accédait directement à l'attribut (pas de get...() set...(value) tout pas beau et lourd)
ex :

$ cat test.rb
class MyClass
        attr_accessor :myAttr
        def myAttr=(value)
                @myAttr = "myAttr is set to #{value}"
        end
        def myAttr
                print @myAttr + "\n"
        end
end

obj = MyClass.new
obj.myAttr = 2
obj.myAttr

$ ruby test.rb
myAttr is set to 2

Sinon, par simple curiosité, comment fait ruby pour un nombre variable d'arguments ? (le *args de python)

def myFunc(*args)
    print args.join(", ")
end

myFunc(1, 2, 3, 4)
1, 2, 3, 4

ok, je comprend mieux.
Mais bon, ça reste une manière étrange de faire, et surtout assez contraingnante je trouve (le fait de _devoir_ le mettre dans les définitions de méthode)
Et pourtant, on peut faire le même effet mais sans se prendre la tête à la définition : MyClass.myFunc.call(x, args)
C'est une autre façon et qui ne nécessite pas de passer self (et en plus c'est plus explicite que python puisqu'on rajoute call ;-) )
Par contre, le coup de map(A.foo, x) est assez intéressant.

Par contre, des derniers exemples illustrent tout à fait ce que je pense de python : c'est pas beau ;-)

def classmethod(meth):
... def call(*args, **kwargs):
... return meth(args[0].__class__, *args[1:], **kwargs)
... return call

entre les __ et les ** ... beurk
Bon ok dans ruby il y a @, mais en parlant de beauté on est clairement dans le subjectif...

C'est comme si on disait que le W3C était inutile : il suffit de regarder les sources de Mozilla. Bon courage ....

non non
c'est plutôt que dans ce cas on regarderait aussi la doc qu'a produit l'équipe de mozilla en codant.

Franchement je comprend pas du tout ce thread.
Tout de suite, NDA = pas de doc...
OK samba reçoit une doc qu'ils n'ont pas le droit de distribuer. Mais qu'est ce qui empêche samba de générer eux même une doc en utilisant _leur_ implémentation des formats qu'ils auront réalisé en utilisant cette doc maudite ?
Maintenant si samba ne veut pas faire de doc (qui elle serait libre, librement distribuable) faut pas en vouloir au NDA mais aux dev de samba.

Nottons de plus, que ceci est autorisé par l'accord, comme je l'ai déjà signalé dans un précédent commentaire....

oui je sais, j'en suis bien conscient (pour le moment j'utilise même un langage où il faut forcément le 'this' pour accéder à un membre) et ça ne me gène pas.
Disons que dans les 2 cas on peut y trouver des avantages
Mais de là à devoir le passer aux méthodes d'une classe... c'est ce point et uniquement celui-ci que je ne comprend pas.
Dans une méthode d'une classe il y a une très très très forte probabilité de devoir utiliser au moins un membre de la calsse et donc de devoir utiliser self dans ce cas. Alors oui, explicite toussa mais là je comprend pas où est l'avantage par rapport à l'implicite... et c'est ce point qui donne une mauvaise impression sur le modèle objet de python (note : je parle bien d'impression, j'y connais pas assez en python pour descendre le modèle objet en lui-même...)

je trouve différent d'avoir ':' et 'end'
le 'end' est remplacé en python par l'indentation. Mais pourquoi le début de la clause / définition non ?

En plus c'est esthétique

Je pense justement le contraire ;-)

Parce que explicit is better than implicit

Voici enfin une vrai différence entre python et ruby. Et je crois que je commence à comprendre pourquoi j'aime ruby et non python ;-)

En fait, ce qui fait la force de ruby je trouve (et on peut le voir encore plus dans un framework comme RoR mais c'est pas le seul cas) est de se baser tant que possible sur des conventions, de l'implicite, ... au contraire de python.
Et c'est probablement aussi ça qui fait que ce langage est souvent aimé des utilisateurs de perl (car là niveau implicite...)

M'enfin, je comprend tout de même la volonté d'être explicite. Par contre, de là à passer self dans chaque méthode d'une classe ... vu comme ça on dirait plutôt un mauvais modèle objet... (désolé, mais fallait bien contre balancer la tentative de troll sur perl...)

dur à dire...
j'ai toujours eu du mal avec python. Je trouve que c'est un langage intéressant mais je n'ai jamais pu m'y faire "graphiquement" (et pourtant je trouve le principe de l'indentation forcée dans python très intéressant)
Mais avoir par exemple :

def myFunc(plop):

Pourquoi avoir un ':' ?
et surtout, pourquoi autant de fonctions préfixés _et_ postfixé par '__'
et pouquoi self partout ?

class Plop:
....def __init__(self):

....def __str__(self):

(désolé pour les '.' mais je savais pas comment faire plus rapidement ;-))

En ruby on aurait plutôt

class Plop
....def initialize
....end

....def to_str
....end
end

Ok, tout ça c'est juste des arguments graphiques. Mais c'est quelque chose qui compte pas mal je trouve dans l'adoption dans langage ou non (après ça dépend aussi des usages qu'on veut en faire...)

En réalité quand j'ai voulu varier de perl, je pensais me tourner vers python. J'ai commencé à regardé et ... bof
J'ai installé ruby et commencé à lire la doc fournie avec et ... cool !
Donc je suis resté sur ruby.
Y'a pas vraiment d'arguments objectifs la dedans...

Disons que ruby permet aussi d'être très concis, mais en étant (de base) très lisible.
Le modèle objet de ruby est, je trouve, l'un des meilleurs que j'ai vu pour le moment (c'est pas parfait, mais bcp mieux que certains autres langages)

Maintenant (et c'est absolument pas un argument) j'ai l'impression que beaucoup plus de personnes utilisant perl se tourne vers ruby plutôt que python.

mais ça n'a rien à voir du tout.
Le test acid2 est simplement là pour voir si l'intégration des propriétés css est correcte.
Le fait que ça affiche un smiley n'est pas utile à part à être amusant.
Et en aucun cas c'est sencé être intéressant pour un "intégrateur/graphiste web"

Cette page c'est comme une série de test unitaires permettant de valider ou non certaines propriétés css, et c'est tout !

Et non, ça ne prouve pas l'inutilité du test mais simplement ça prouve que le test a des prérequis, qui sont indiqué et qu'il faut les suivres.
Juste une image :
je fais un crash test avec une voiture. Je change les ceintures pour qu'elles soient elastiques. Le test ne passe plus.
Conclusion :
- le test est inutile
- le test est pourri
- j'ai changé certains paramètres testé et _ceci_ provoque l'erreur

Ce test est intéressant (même si ça ne fait pas tout).
Une "vrai" page n'aurait jamais implémenté autant de particularité et franchement n'aurait aucun intérêt pour tester la validité des propriétés css.

mais qui a parlé d'un code non documenté ???

while at the same time describing how free software projects may release source code and source code comments without violating these confidentiality provisions.

Il est interdit de distribuer la documentation.
Par contre rien n'empêche les développeurs d'écrire _leur_ doc pendant qu'ils codent, de documenter eux même leur code et dans ce cas ça fourni un code source _commenté_ et libre.

non, je pencherais pour une autre explication :
le test contient la ligne suivante en css :

html { font: 12px; ...}

pour configurer la taille par défaut.
Hors dans ce cas il a un minimum font size de 14 qui outre passe la directive de la page.
Et donc forcément la mise en page est cassée.

Le problème vient du fait que dans ce cas le navigateur ne lit pas "correctement" le css car c'est comme s'il l'avait modifié en remplaçant ce 12 par un 14, et comme d'autres données ce servent de cette taille (tout ce qui est en 'em') alors la page n'a plus un rendu correct.

ptetre parce que c'est une beta...

moi ce que j'ai remarqué, c'est une très net amélioration des performances javascript / dom. Sur les applications sur lesquels je bosse, c'est très nettement visible et ça fait plaisir !
Rien que pour cette raison je passerai à firefox 3 (parce que bon, le reste, ... je dis pas que c'est pas bien, mais la pluspart des choses me sont indiférentes)

Sinon, autre petit point discret : le gestionnaire des téléchargement a été revu. Je sais pas trop quel était la différence entre ceux de firefox 1 et 2 mais le 3 marche plutôt bien, alors que tenté de télécharger un fichier de 7Go avec le 1 ... résultat : -2Mo/s et un téléchargement coupé à pile 4Go...
avec le 3 c'est passé ;-)

manquerait plus que hurd sorte avec e17 comme interface par défaut

[http://linuxfr.org/~kakaouete/25859.html]

mais c'est normal que ça arrête l'application comme une grosse brutasse !
l'assert (et je répond ici au commentaire du dessus) ne doit pas être compilée en release.
Une assert ne correspond pas à tous les cas d'erreur mais doit permettre, lors du développement, de tester les pre et post conditions des fonctions.
Si une assert apparaît, alors on est clairement dans un cas où on aurait jamais du être et pour lequel on a pas de sortie propre possible (ex d'une fonction devant retourner tout le temps un pointeur ... sauf que le pointeur, pour une raison indépendante de cette fonction, est nul)
Pour les autres cas il y a les autres gestion d'erreurs.
Il faut, à mon avis, vraiment séparer les types d'erreurs et leurs traitement.

Maintenant, concernant les logs, rien n'empèche (et c'est ce que je fais en général) d'avoir des fonctions prenant des messages en parametre :
a = my_func();
assert_not_null(a, "my_func return a bad pointer plop plop plop");

Enfin, oui, l'assert ne doit plus exister en release, et ce pour plusieurs raisons :
d'une part le code d'assert termine normalement par un exit donc ça crash forcément. D'autre part l'assert étant placée pour tester un cas n'apparaissant normalement pas, l'application crachera de toute manière juste après ou un peu plus loin, ou beaucoup plus loin mais on ne saura jamais pourquoi...

Et oui, niveau perf le gain peut être important. En utilisant les asserts comme pre/post conditions des fonctions (de la majorité) il devient évident que supprimer de quelques à une dizaine de tests par fonction peut avoir des impacts sur la performance globale du programme.

Mais ce que j'ai l'impression en lisant les commentaires des "anti" assert est qu'ils croient qu'il n'y a qu'une façon de traiter les erreurs alors que la méthode "parfaite" n'est qu'un mix de toutes les autres.

ps : non, les fan d'assert n'auraient pas forcément écrit un code plus petit, mais peut être plus grand justement, du fait d'en coller partout où on ne metterait pas un test car on penserait ça inutile alors que...

c'est aussi ce que je pensais en le listant
En outre, avec des asserts bien codées on pourrait avoir la version beaucoup plus parlante et plus light :

jresult some_function( int a, int * b )
{
int ret;
assert_positiv(a);
assert_not_null(b);

ret = some_sub_func( a, *b );
assert(ret, JOK);

....

return JOK;

}

Les asserts sont justement faite pour ces cas. Les asserts sont typiquement là pour tester les cas qui ne devraient pas exister à l'exécution.
Dans cet optique, une assert doit nécessairement provoquer un crash de l'appli, être bloquante car signale un bug, une erreur qu'il faut obligatoirement résoudre.
Rien n'empèche par contre, de loguer dans l'assert, juste avant le "exit".

Pour ma part, je n'utilise pas beaucoup les exceptions (ça dépend aussi des framework) mais je pense qu'un bon traitement des erreurs est multiple :
- des assert pour les entrées / sorties de fonctions. Tout ce qui doit être valide mais sans aucune action avec l'utilisateur (typiquement un pointeur ne devant pas être null). Et ça doit crasher, les asserts doivent crasher pendant le dev et ne seront de toute manière pas compilées (ou seulement le log sera compilé)
- des tests "classiques" avec affichage pour tout problème que l'utilisateur peut contrôler
- des exceptions, des try/catch au milieu permettant de faire remonter les problèmes (très pratique lorsque l'erreur survient dans une routine mais que le traitement de celle-ci ne se fera que dans des couches plus haute)

A priori, il ne gère pas plus les écrans de démarrage de DVD que les autres lecteurs.

Pourton mon kaffeine (avec backend xine je crois) gère très bien les dvds...

Pour ma part, pour tout ce qui est vidéo, je n'utilise que ça.
Il gère les dvds correctement
permet de se déplacer sans prob
passe en vrai plein écran (ce que refuse de faire vlc, il ne fait que se maximiser chez moi (ensuite, ptetre une mauvaise option ou le fait d'être en twinview, je sais pas)

Il possède aussi des fonctionnalités sympa comme le fait de se mettre en pause si je change de bureau, minimise (sympa pour voir un détail pendant un cours instant sans rien perdre)

Réponse des intéressés : c'est pas grave et normal car la version OOo est juste une version online sur laquelle n'est lancé que OOo par défaut.

Donc voilà
(c'est même pas drôle quoi ;-) )

si mais konsole n'est pas installé il me semble (ni xterm)

trop facile :)

Petite méthode testée (mais je suis pas allé plus loin et il y a peut-être plus rapide et plus simple) :
dans OOo, ouvrire l'aperçu web (donc firefox)
dans les pref de firefox changer l'association des fichiers .swf (par exemple) et choisir konqueror
ouvrir un .swf...
et voilà, maintenant qu'on a konqueror, tout devient plus facile ;-)

(en outre, j'ai eu droit à un vlc)

ça va bien quand on est fonctionnaire,[...]. Mais dans la vraie vie, je veux dire, à partir du moment où on travaille pour gagner un salaire à la fin du mois

Tu trouvais qu'il n'y avait pas assez de troll dans le journal et les commentaires ?

à mon avis, dans le cas où il n'est pas possible de retrouver / changer toutes les parties touchées, la solution la plus intélligente serait plutôt de recoder sous la bonne licence les portions génante.
Ca m'étonnerait franchement, pour des personnes se posant justement la question des licences, qu'ils en viennent à changer violement les licences puisqu'ils n'en ont pas le droit.

ra non, l'intérêt des journaux c'est justement pour moi de trouver tout de n'importe quoi comme sujet.
Sans cela, on ne regarderait que les catégories "intéressantes" pour soi et on passerait à côté de choses très pertinentes.

(bon ok, avec un peu moins -mais un peu quand même- de politique et de comique de répétition ça serait pas mal...)