benoar a écrit 4229 commentaires

  • [^] # Re: vim

    Posté par  . En réponse au journal Votre commande favorite. Évalué à 3.

    Houla, ya beaucoup mieux pour ça (et plus "propre") : depuis vim, un coup de ":make" pour lancer la compil (on peut personnaliser la commande avec ":set makeprg=...", et mettre par exemple "latex \!" à la place; par défaut c'est "make" tout court), puis ":cc" pour voir l'erreur (on arrive sur la première erreur directement après un ":make"), et ":cn" pour passer à la suivante. C'est vraiment très utile. Pour le reste voir ":help quickfix".
  • [^] # Re: Monitorer une carte nVidia...

    Posté par  . En réponse à la dépêche Nouvelles versions des pilotes ATI et NVIDIA pour GNU/Linux. Évalué à 1.

    Cela fait quelques temps déjà (1 an et demi) que le ventilateur de ma GeForce 2 Pro est en rade.

    "Content" de savoir que je ne suis pas le seul à avoir ce problème avec cette carte dont le ventilo est d'une solidité et d'une fiabilité .... désastreuse. Pareil que toi, montage d'un autre ventilo avec 2 bouts de ficelles ...
  • [^] # Re: c'est quand même formidable

    Posté par  . En réponse au journal Linux : la plus vaste blague de l'informatique. Évalué à 1.

    Ensuite : citez donc un debugger qui sait charger un binaire de 100mo, montrer tous les types montrables, faire du hotfixing et faire suivre les breakpoints avec les modifications du code, montrer le code de manière correcte etc. Puisque c'est de sa faute s'il arrive pas à bosser.

    gdb ... pour Mac OS X !! :)

    il gère :
    - les headers précompilés
    - tous les types du système (enfin en Objective-C dumoins)
    - le hotfix
    - suivi des breakpoints avec la modif du code
    - affichage correct du code
    - il plante peu (enfin c'est surtout XCode qui plante ...)
    - et plein d'autres trucs

    bon pour les binaires de 100Mo je sais pas, mais comme dis plus haut, faut être un peu neuneu pour débugger avec toutes les libs en statique.

    Bon ok, tout ca c'est dispo uniquement en utilisant XCode d'Apple, qui est un gros truc proprio qui n'est pas prêt d'être libre. Mais tout ça est géré dans le fond par gcc & gdb !

    Deuxième truc, je sais pas si c'est possible de faire du hotfix en ligne de commande, ni si tout ça est faisable autrement qu'en codant en Objective-C ...

    Vous allez me dire "mais tout ça c'est codé par des ingés de chez Apple, personne aurait pu faire ça dans le libre". Certes, il se sont bien démerdés, et en plus tout ce code est libre comme tout le reste de gcc, mais je pense qu'un jour ou l'autre on l'aurait eu par des contributeurs bénévoles. Un peu moins rapidement, peut-être.

    Alors bon, arrêtez de cracher sur gdb ...
  • [^] # Re: Hummm cela cache aussi la brevetabilite des algo mathematiques

    Posté par  . En réponse à la dépêche Brevets logiciels : analyse de la directive votée par le Conseil de l'UE. Évalué à 7.

    On en arrive à des situations ubuesques comme celle de Microsoft qui arrive à breveter le multibureau avec comme exemple des captures d'écrans de KDE !

    Je voudrais juste faire remarquer (si ce n'a pas déjà été fait) que ces captures sont là pour illustrer les applications déjà existantes; c'est écrit dans le texte du brevet (oui, il faut l'avoir lu avant pour savoir ...).

    Le brevet porte sur le desktop switcher (enfin le truc qui donne un aperçu des bureaux) : La capture de KDE 1 (où on ne voit que le nom du bureau) montre qu'on ne voit pas les fenêtres des desktops, la capture de Gnome montre qu'on voit les fenêtres en petit mais pas leur contenu (juste un carré); eux, ils justifient leur brevet par le fait qu'il affichent le contenu de la fenêtre dans leur desktop switcher.

    Mais cela n'empêche pas qu'Enlightenment l'a fait bien avant eux, mais ça bien sûr, ils n'en parlent pas ...
    Et aussi que ça n'est pas si innovant de n'améliorer un truc que très légèrement (d'ailleurs je crois que c'est un motif de refus du brevet en france si on se base sur un truc déjà existant et en ne l'améliorant que très peu)