Audiofanzine a 25 ans !
Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
FR
EN
Notifications
  • Refonte graphique octobre 2025
    Refonte graphique octobre 2025
    Une refonte graphique vient d'être mise en ligne. Nous espérons qu'elle vous plaira. Merci de nous signaler tout bug ou perte de fonctionnalité ici →
  • Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Pour célébrer notre quart de siècle, UVI se joint à nous et vous offre le Digital Synsations Vol.1. Pour en profiter c'est par ici 👉
  • Nouveauté : Bookmark article, news ou tuto
    Nouveauté : Bookmark article, news ou tuto
    Bookmarkez un article, une news ou un tuto et retrouvez-le dans votre section "Mes signets" du menu membre.
  • 6 nouveaux annuaires
    6 nouveaux annuaires
    Luthiers, Réparateurs, Cours de musique, Studios d’enregistrement, de mastering et de répétition... Suggérez l’ajout d’une entreprise, inscrivez la vôtre ou déposez un avis.
  • Alertes disponibilité et baisse de prix
    Alertes disponibilité et baisse de prix
    Ces nouvelles fonctionnalités vous permettent d'être informé·e dès qu'un produit est disponible ou que son prix a baissé.
  • Tentatives d'arnaque dans les petites annonces
    Nous faisons face depuis quelques mois à une recrudescence de tentatives d'arnaques dans les petites annonces. Suivez nos recommandations >
Bidouille & Développement Informatique
News
Articles
Médias
Forums
Tutoriels

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 131 690 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
701
Gremlins > aucune idée :D

Gabou > C'est vrai, il y a beaucoup de manière d'écrire la même chose en C++, et théoriquement Python essaie de limiter à une seule manière de faire qqch, mais sans vraiment y arriver. Peut-être avec Python 3 ? Plusieurs paradigmes différents = plusieurs manières de coder la même chose.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

702

Citation :
Peut-être avec Python 3 ? Plusieurs paradigmes différents = plusieurs manières de coder la même chose.



Different paradigme ne veut pas du tout dire coder la meme chose, ou alors tous les langages sont les memes du moment qu'ils sont turing complete, mais une fois que tu as dit ca... Il y a certains algos qui vont avoir une solution elegante avec un certain paradigme, d'autres avec un autre. Passer un argument par copie ou par reference, c'est un detail d'implementation, ca n'a aucune autre espece d'importance, et ce n'est pas une difference de paradigme pour moi. C'est comme virtual / non virtual, ce type de trucs. C'est un non sens d'avoir ce type de constructions dans un langage un tant soi peu "haut" niveau.

Le coup des strings, et des containeurs en general, c'est significatif du probleme en C++ pour moi: c'est le truc qui est vraiment plus facile dans tout langage en gros plus haut niveau que le C, sauf en C++. Et c'est lie au manque de GC; pour un langage comme le C, c'est normal, c'est le but de controler ce genre de choses. Mais pour un langage "haut" niveau, ne pas avoir ca, c'est vraiment chiant.

Tant que le C++ se cantonne a etre un C avec un peu de syntaxe autour, ok, c'est sympa. Une fois que ca devient du n'imp en utilisant une horreur type template pour faire de la meta programmation et faire des trucs a la boost::bind ou boost::lambda... La, non :surpris:
703

Citation : Le C++ propose plusieurs paradigmes de programmation, et Python aussi, entre la programmation fonctionnel ou objet, c'est tout de même assez différent


A la place de "fonctionnel" tu veux probablement dire "impératif" ? Car ni C++ ni Python ne sont fonctionnel ; sont fonctionnels : lisp, CAML et OCAML...

Citation : On peut faire du joli code en C++ (QT en est un exemple), apres, c'est sur, mais c'est super dur. Le langage est tellement enorme, que tout le monde utilise un "sous C++"... Du coup, c'est courant de voir du C++ completement incomprehensible parce que c'est tres different de ce dont tu as l'habitude.


Je ne pense pas que ce soit très dur de faire du code clair ; ou alors disons que ce n'est pas compliqué mais que c'est long et fastidieux. En plus il est difficile de résister à la tentation de faire des trucs "acrobatiques" (pour "faire objet" notamment), et c'est là que ça devient franchement impossible à maintenir.

Citation : Le coup des strings, et des containeurs en general, c'est significatif du probleme en C++ pour moi: c'est le truc qui est vraiment plus facile dans tout langage en gros plus haut niveau que le C, sauf en C++. Et c'est lie au manque de GC; pour un langage comme le C, c'est normal, c'est le but de controler ce genre de choses. Mais pour un langage "haut" niveau, ne pas avoir ca, c'est vraiment chiant.


En fait tout ça s'explique par des raisons historique et non par des choix bien réfléchis : C avait pour but de remplacer l'assembleur, donc il est à la fois volontairement bas niveau, et involontairement "pauvre / laborieux" parce-que ancien. C++ a essayé de l'enrichir, mais a perdu son homogénéité pour garder une compatibilité ascendante. L'histoire de Perl est encore pire ; tandis que Python devait être déjà assez complet dès sa première version.

Comme toujours la compatibilité ascendante est gage de succès commercial mais aussi d'un gros manque d'élégance / cohérence !

Citation : Pour ce type de trucs, je pense qu'il faut avant tout d'excellents programmeurs. Je sais pas si t'as lu cet article sur une des equipes qui programment pour la navette spatiale... Ils font du code sans bug, en gros.

http://www.fastcompany.com/online/06/writestuff.html


Ya plein de trucs que j'ai trouvés très intéressants dans cet article. Ironiquement ça défend exactement le contraire de la "programmation agile" et de la "méthode bazar" (opposée à cathédrale dans le fameux article de Eric Raymond).

Ca rejoint l'une des thèses du livre (excellent) "Mythical man-month" qui démarre par une citation de restaurant : "la bonne cuisine prend du temps, si on vous fait attendre c'est pour mieux vous satisfaire"...

Par contre il y a aussi beaucoup de points très discutables :
- les démarches de Sun, Microsoft et Netscape ne sont absolument pas comparables.
- la navette spatiale n'est pas un exemple si isolé : les commandes électriques des Airbus, le logiciel des centrales nucléaires sont aussi critiques et fiables (et le nombre de morts potentiels est beaucoup plus important)
- les langages utilisés et les outils peuvent jouer un rôle très important : les méthodes formelles, des outils comme ObjectGeode (programmation en SDL) ou comme Core pour la gestion d'exigences... font une différence énorme.
- l'article compare des choses pas comparables car cette méthode a un coût. Si on regarde le service rendu par rapport au temps passé, on s'aperçoit vite que dans la plupart des domaines il est impossible de se permettre un tel niveau de qualité. En fait en moyenne un développeur de soft "industriel classique" produit 25 lignes quand un développeur de code critique en produit 5 et seulement 1 ligne pour de "l'embarqué vital"...

Mais par contre le côté minutieux plutôt que "Cowboy coding" (voir http://c2.com/cgi/wiki?CowboyCoding , d' ailleurs il y a beaucoup de réflexions pertinentes sur ce site, accessoirement l'inventeur du wiki), pour les spécifications détaillées, pour les tests croisés, pour la stabilité des specs après les débuts de la réalisation... l'article dit beaucoup de choses vraies qu'on lit trop rarement (quand on écrit pas tout bonnement le contraire !)

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

704

Citation :
En fait tout ça s'explique par des raisons historique et non par des choix bien réfléchis : C avait pour but de remplacer l'assembleur, donc il est à la fois volontairement bas niveau, et involontairement "pauvre / laborieux" parce-que ancien. C++ a essayé de l'enrichir, mais a perdu son homogénéité pour garder une compatibilité ascendante. L'histoire de Perl est encore pire ; tandis que Python devait être déjà assez complet dès sa première version.



Je suis bien conscient de l'histoire du C++. Quand tu lis Stroustrup, tu peux voir qu'il y a une justification pour chaque truc.

Citation :
Ya plein de trucs que j'ai trouvés très intéressants dans cet article. Ironiquement ça défend exactement le contraire de la "programmation agile" et de la "méthode bazar" (opposée à cathédrale dans le fameux article de Eric Raymond).



Pas vraiment: tu developpes pas tout comme tu developpes l'exemple donne. Unix est ne tres rapidement, et aujourd'hui encore, c'est le modele de tous les OS.

Il est bien dit d'ailleurs que le cout est eleve, comme tu le dis toi meme. Il n'y a pas une methodes applicable a tout. Typiquement, l'open source a montre que pour faire un OS ou certains types d'applis, ca marche tres bien.
705
Dr Pouet > non, je sais ce qu'estimpératif, j'ai bien dit fonctionnel. Python a emprunté à Haskell certaines choses, on peut programmer de manière fonctionnelle.

La nouvelle norme du C++ va ajouter la possibilité d'avoir un GC et de l'activer si besoin, donc ça ira. Et Python a pas mal évolué depuis le début, je ne crois pas qu'il y ait de GC avec la version 2, mais c'est à revérifier.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

706

Citation :
Python a emprunté à Haskell certaines choses, on peut programmer de manière fonctionnelle.



Pas enormement non plus, et ca va d'ailleurs en diminuant (python 3000 devrait voir l'abandon de map, reduce, voire lambda); ce que python a pris de hasksell, c'est les list comprehension, ce genre de trucs, qui ne sont pas particulierement fonctionnels (c'est juste une jolie syntaxe pour faire des operations sur des containers).

Apres, ca depend de ce que l'on appelle functionnel, c'est comme objet, ca veut plus rien dire. Pour certains, ca veut juste dire qu'une fonction peut etre passee en argument, et a ce niveau la, tous les langages objets, y compris le C++, sont fonctionnels... Ca permet quelques trucs sympas du fonctionnel, mais sans plus le python a ce niveau la.

Pour moi, LE truc fondamental du fonctionnel, c'est de privilegier le "stateless", ce genre de choses. Et la syntaxe qui va avec pour rendre le truc lisible.

Citation :
Et Python a pas mal évolué depuis le début, je ne crois pas qu'il y ait de GC avec la version 2, mais c'est à revérifier.



Si, il y a un GC pour resoudre les cycles, qui ne peuvent pas etre resolus par le systeme de base de gestion memoire en python, a savoir le reference counting. Pypy est une implementation de python en python qui permet optionnelement de faire appel a un GC de maniere globale, par contre. Et evidemment, jython (implementation de python sur JVM) et ironpython (idem sur CLR) utilisent un GC.

En fait, avant, quand je parlais de GC, il fallait bien sur comprendre systeme de gestion de memoire automatique, et non GC en soi.
707

Citation : Pas vraiment: tu developpes pas tout comme tu developpes l'exemple donne.


Certes. Mais les promoteurs des méthodes Agile, XP, Bazar et compagnie oublient la plupart du temps de rappeler que leur méthode ne s'applique pas à tout. Je ne me rappelle pas qu'à un seul instant Eric Raymond décrit des cas où sa méthode bazar ne s'applique pas. Dans l'absolu la méthode cathédrale devrait donner à la fois les softs les mieux conçus et les moins coûteux.

Le problème c'est que dans la plupart des cas on ne sait pas exactement ce que l'on veut faire, donc on commence et on corrige au fur et à mesure ; c'est malheureusement souvent inévitable.

Citation : Unix est ne tres rapidement, et aujourd'hui encore, c'est le modele de tous les OS.


Je ne dirais pas qu'Unix est né très rapidement. Déjà, de par l'expérience de l'équipe qui l'a conçu, les OS précédents ont servi de bases, que ce soit Multics ou d'autres (VMS qu'ils devaient connaître également et qui avait très bonne réputation). D'après https://fr.wikipedia.org/wiki/UNIX et https://en.wikipedia.org/wiki/Unix les débuts datent de 69, mais c'est plus tard qu'il s'est popularisé : en 78 il n'y avait que 600 machines à l'utiliser.

Donc avec l'expérience de gusses comme Ken Thompson, additionnée au temps de maturation du bidule, ça colle effectivement bien avec l'idée qu'il faut prendre son temps pour faire les choses bien.

Citation : Pour moi, LE truc fondamental du fonctionnel, c'est de privilegier le "stateless", ce genre de choses. Et la syntaxe qui va avec pour rendre le truc lisible.


Je suis assez d'accord. Surtout que maintenant la quasi totalité des applications sont conçues de manière multi-thread, alors que peu de gens mesurent les difficultés qui en découlent.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

708
:?!:
FX
709
Oups, pardon, je voulais dire avant la version 2, ce que je viens de revoir d'ailleurs.
map, reduce et filter ne vont pas disparaître, j'avais lu qu'ils seraient dans un module particulier, ce qui serait plus logique étant donné qu'ils travaillent sur des listes principalement et que par exemple pour NumPy, utiliser map ne fonctionne pas trop :)
Mais ça a peut-être évolué depuis, je pense que je vais aller m'abonner à la ML de développement... En fait, c'est surtout que j'ai beosin d'infos sur le futur de Python pour un projet.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

710

Citation :

Certes. Mais les promoteurs des méthodes Agile, XP, Bazar et compagnie oublient la plupart du temps de rappeler que leur méthode ne s'applique pas à tout. Je ne me rappelle pas qu'à un seul instant Eric Raymond décrit des cas où sa méthode bazar ne s'applique pas. Dans l'absolu la méthode cathédrale devrait donner à la fois les softs les mieux conçus et les moins coûteux.



Je mettrais pas agile et co et ce que dit E. Raymond dans le meme sac, le contexte et le but ne sont pas du tout le meme. De memoire, Raymond donne bien des exemples de trucs ou l'open source ne marche pas tres bien: jeux video par exemple; je pense pas que ce soit super adapate pour des programmes ou l'interface graphique est preponderante, aussi, a moins qu'il y ait de forst interets financiers: typiquement, un soft comme live! ou Reaktor, je crois qu'on n'en verra jamais en open source.

En fait, je ne crois pas du tout que l'open source soit la panacee (j'ai pas enormement d'experience non plus); par contre, il a prouve qu'il etait un puissant moteur pour faire bouger les choses dans une industrie qui beneficie quand meme de sa propre incompetence trop souvent. L'experience montre quand meme que l'open source marche bien avec un leadership tres fort (le noyau linux, Kde, Gnome, Firefox, Debian, Ubuntu). Un truc comme Debian, par exemple, c'est pas vraiment dans l'esprit de faire de la programmation XP: c'est au contraire assez contraignant, et c'est certainement le plus gros projet en lignes de code ayant jamais existe.

Globalement, pour tout ce qui est destine a des programmeurs, je trouve l'open source en general extremement superieur a ce que fournit sa contre partie proprietaire. Gnome, aujourd'hui, est la meilleure interface graphique, largement devant Mac OS X a mon avis pour la simplicite et la coherence.

Citation :
e ne dirais pas qu'Unix est né très rapidement. Déjà, de par l'expérience de l'équipe qui l'a conçu, les OS précédents ont servi de bases, que ce soit Multics ou d'autres (VMS qu'ils devaient connaître également et qui avait très bonne réputation). D'après https://fr.wikipedia.org/wiki/UNIX et https://en.wikipedia.org/wiki/Unix les débuts datent de 69, mais c'est plus tard qu'il s'est popularisé : en 78 il n'y avait que 600 machines à l'utiliser.



J'aurai du etre plus precis: les concepts fondamentaux d'UNIX ont ete crees en peu de temps, et sont restes les references jusqu'a maintenant. Au niveau API, ca reste la reference depuis 30 ans maintenant. Apres, c'est sur que l'Unix de 72 et un Unix d'aujourd'hui, c'est un peu different.

Il y a d'autres exemples de trucs fondamentaux qui ont ete inventes en peu de temps au moins dans le concept (LISP, typiquement). Apres, que ca mette du temps a murir, sur.

Citation :
map, reduce et filter ne vont pas disparaître, j'avais lu qu'ils seraient dans un module particulier, ce qui serait plus logique étant donné qu'ils travaillent sur des listes principalement et que par exemple pour NumPy, utiliser map ne fonctionne pas trop



S'ils sont dans un module particulier, ca veut bien dire que le langage en lui meme ne tend pas a supporter le fonctionnel comme paradigme. En fait, Guido l'explique bien :

https://www.artima.com/weblogs/viewpost.jsp?thread=98196

Citation : En fait, c'est surtout que j'ai beosin d'infos sur le futur de Python pour un projet.



A priori, python 3000 (la prochaine version qui s'autorise des changements incompatibles) ne changera pas fondamentalement les choses. Tu t'attends a quoi comme changements ?
711
Je ne sais pas encore à quel points ils vont disparaître, et effectivement, cela fait des années que Guido veut virer lambda, mais lambda sera encore présent dans Python 3000 d'après le PEP 3099. Pour le reste...

En fait, je n'attends aucun changeent, je les scrute pour pouvoir préparer un ouvrage sur le Python actuel et le futur - orienté scientifique, d'ailleurs -

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

712

Citation :
Je ne sais pas encore à quel points ils vont disparaître, et effectivement, cela fait des années que Guido veut virer lambda, mais lambda sera encore présent dans Python 3000 d'après le PEP 3099. Pour le reste...



J'avais lu quelque part, mais sans verifier, que lambda sera deprecated pour python 3000. Pour python oriente scientifique, il y a de quoi faire je pense, parce que le seul bouquin a ma connaissance est assez mauvais. Par contre, le sujet est vaste, et pour qu'il soit utile, il faut qu'il brasse pas mal de sujets. Je suis pas sur que la ML de python-dev soit la plus interessante pour python et scientifique: les ML scipy-dev/numpy-dev et tout ce qu'il y a autour (matplotlib/chaco/ipython, voire pytables), puis des trucs comme pypy sont plus interessants a mon avis a regarder.

En tout cas, il y a moyen de faire un truc vachement interessant. Si jamais ca se concretise, mets moi au courant :)
713
C'est vrai que lambda n'est pas indispensable, jamais encore utilisé, donc bon ;)

En fait, je regarde python-dev pour les évolutions, par ex savoir si le buffer de NumPy va être standard ou pas, je suis déjà abonné à matplotlib-*, scipy-* et numpy-user, ça va, mais je vais sans doute regarder plus loin avec pytables, ça va dépendre du temps que j'ai.
Ce qui est bien, déjà, c'est que NumPy soit stabilisé, une version 1.0, tous les livres parlent de Numeric ou de Numarray, c'est dommage.
En revanche, le mien sera en français, et comme c'est pour des scientifiques, il y aura une moitié environ dédiée au langage en lui-même. Et je te tiendrai au courant, naturellement, je mettrai un mot ici ;)

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

714

Citation :
Ce qui est bien, déjà, c'est que NumPy soit stabilisé, une version 1.0, tous les livres parlent de Numeric ou de Numarray, c'est dommage.



numpy est fondamentalement API compatible avec numarray d'apres ce que j'ai compris (jamais utilise numarray, perso), y compris niveau C.

Je pense que le gros truc qui manque a numpy pour voir plus d'utilisateurs, maintenant, ce sont des installers binaires sous linux (ca va venir j'espere avec la release 1.0, et perso, je bosse en ce moment meme sur un "proof of concept" de systeme de build cross distribution en utilisant le nouveau systeme de Suse), mac et windows, une meilleure doc.

Apres, le truc concernant une interface commune pour des buffers, j'ai un peu laisse tomber, je comprends pas grand chose aux reticences sur python-dev, certains arguments me depassent un peu techniquement aussi, et finalement, et je m'en fous pas mal :) Je prefere me plonger dans pypy, c'est plus interessant aussi bien techniquement que sur les possibilites.
715
Arf :)
Effectivement, NumPy est normalement pas mal compatible avec numarray, mais bon, il y a tout de même des spécificités - comme des modules dépréciés dans NumPy car normalement présents dans SciPy -
J'ai constaté que c'était surtout scipy où il manquait des paquets. NumPy, je l'ai sur Fedora Core, donc je suis content :)

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

716
Fedora :surpris: J'ai du subir ca au debut en venant au labo, j'ai reussi a convaincre mon boss d'avoir une debian ou une ubuntu. Entre les bugs du compilo fortran et les blas/lapack completement bugges jusqu'a recemment... J'ai vraiment beaucoup de mal avec cette distro; je trouve la qualite generale des paquets assez mediocre.

numpy 1.0.*, il y a pas beaucoup de distro qui le supportent aujourd'hui (debian testing, et la prochaine ubuntu devraient aider). Installer numpy en soi est trivial, le probleme ce sont les dependances pour les librairies numeriques (Atlas surtout, Umfpack aussi, mais c'est moins fondamental). Je me suis fait un petit port pour numpy avec compilation de toutes les dependances, et maintenant, j'espere pouvoir fournir dans les jours qui viennent des rpm et deb pour chaque nouvelle version de numpy (avec mon fast clip :) ).

Si numpy est installe, installer scipy est tres facile, par contre, je suis etonne que certaines distributions ne fournissent que numpy...
717
Comme toi au début, surtout qu'on reste bloqué à certaines vieilles versions si on ne met pas à jour le système - j'ai une FC5 et j'ai matplotlib 0.82... - et comme notre adminustrateur connaît bien FC, on reste avec FC.
Pour les dépendances, je ne sais pas, je suis sûr que j'aurai pu installer des bibliothèques plus performantes, mais comme je ne travaille pas encore exclusivement avec Python, je m'en fous.

En tout cas, si tu fournis les paquets ubuntu et debian, c'est top :) je n'ai pas encore testé sur ma Ubuntu chez moi :)
En ce qui concerne scipy, la discussion sur la fourniture des paquets a été avordé sur la ML, ça va peut-être s'améliorer, il faut trouver des gens...

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

718

Citation : Je mettrais pas agile et co et ce que dit E. Raymond dans le meme sac, le contexte et le but ne sont pas du tout le meme.


En fait je parlais d'un point qui est quand même commun à tout ça : la démarche de développement fortement itérative.

Dans beaucoup de cas la démarche itérative est plus ou moins inévitable car le besoin est précisé au cours de la réalisation. Néanmoins, quand le coût d'une itération est trop élevé (en argent, en délai, voire en risque de dysfonctionnement), ça ne marche plus. Dès qu'un système est composé de nombreuses parties fortement dépendantes les unes des autres et avec une évolution importante, pour pouvoir arriver au but il faut une vision globale et s'y tenir sans la remettre sans cesse en question, surtout si chacun le fait dans son coin.


Citation : J'aurai du etre plus precis: les concepts fondamentaux d'UNIX ont ete crees en peu de temps, et sont restes les references jusqu'a maintenant.


C'est vrai, mais des bons concepts ne sont pas suffisants pour faire un soft fiable comme il en est question dans l'article sur la navette.


Citation : Au niveau API, ca reste la reference depuis 30 ans maintenant.


C'est aussi parce-que le poids de l'historique et le besoin de compatibilité ascendante sont très élevés. Il y a quand même beaucoup de trucs qui ont mal vieilli mais qu'il est difficile de changer ; par exemple toutes les fonctions de la libc qui positionnent des variables globales au process (genre errno ou les signaux) posent problème en programmation multi-thread.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

719
Pour le multi thread, faut voir que ca va assez a l'encontre du principe Unix, en fait. La plupart des programmeurs UNIX n'aiment pas beaucoup les threads.


Citation :
Dès qu'un système est composé de nombreuses parties fortement dépendantes les unes des autres et avec une évolution importante, pour pouvoir arriver au but il faut une vision globale et s'y tenir sans la remettre sans cesse en question, surtout si chacun le fait dans son coin.



Un systeme avec beaucoup de dependances, la encore, c'est un systeme qu'execrent la culture Unix en general. Apres, je veux bien croire qu'il y ait des programmes ou tu n'aies pas le choix, mais c'est je pense justement un des bons cotes de l'open source, c'est que ca ne tend pas a privilegier ce genre de design, car ca s'y prete pas. Le mauvais cote, c'est peut etre que certains types de softs en patissent, parce que necessitant ce type de design.

Mais quand tu vois le noyau linux, Gnome qui en moins de 10 ans a une interface et une coherence que mac n'a plus, ou debian qui propose quand meme plus de 10000 programmes/librairies, compilables sur une dizaine d'architectures, et installable presque 100 %, y a quand meme de quoi etre impressionne, non ?

En ce moment, par exemple, je suis en train de me plonger dans le packaging debian, et quand tu vois qu'en 2-3 commandes, tu peux installer un OS dans une jail root avec telechargement automatique de tous les programmes, tester l'installation de ton paquet... Ca represente des millions et des millions de lignes de code, toutes dependantes, et ca marche nickel. Mais la encore, Debian a des policy tres strictes, je sais pas si on peut vraiment encore parler de bazaar.

Citation :
Comme toi au début, surtout qu'on reste bloqué à certaines vieilles versions si on ne met pas à jour le système - j'ai une FC5 et j'ai matplotlib 0.82... - et comme notre adminustrateur connaît bien FC, on reste avec FC.



Pareil ici, mais quand je suis arrive a l'universite, j'avais 6 jours pour ecrire un article, et aucun de mes programmes ne marchait apres 2 jours d'intense labeur, donc j'ai force la main. Puis bon, comme je connais quand meme tres bien debian et ubuntu maintenant, je viens rarement emmerde l'admin.

Le probleme pour numpy, c'est Atlas, en gros. C'etait vraiment chiant a installer, car deja ca met 3 plombes a compiler, le systeme de build est propre au soft; comme il ne donne qu'une partie de LAPACK, il faut completer toi meme la librairie avec LAPACK de NETLIB, et ca ne produit pas de libraries dynamiques. Heureusement, la version de dev, depuis peu, permet tout ca de maniere plus au moins automatique.

Sinon, matplotlib, c'est facile a compiler toi meme, je pense. Pour numpy/scipy, j'avais annonce garnumpy, le systeme pour compiler numpy et cie automatiquement dans un repertoire local (eg ca fout rien en l'air, tu peux tout effacer, tu n'as pas besoin des droits root); je l'ai teste sur Fedora Core (5 ou 6, je sais plus), ca marchait.

Citation :
En ce qui concerne scipy, la discussion sur la fourniture des paquets a été avordé sur la ML, ça va peut-être s'améliorer, il faut trouver des gens...



Oui, je sais (je fais partie des gens qui en parlent de temps en temps). Si tu suis la ML numpy-dev, tu devrais voir arriver bientot une premiere version (non optimisee) de numpy :)
720
Je suis tjs aussi paumé dans vos discussions :mdr: :bravo: mais si vous pouviez me donner des articles de réf sur le net pour la prog parrallele, multithread, ainsi que pour la prog embarqué, ca serait gentil :)

cptn.io

721
Pour la programmation parallèle, il y a des webinars chez Intel en ce moment :) https://w.on24.com/r.htm?e=36883&s=1&k=D76A2FD29D7444AEC06765011A2D4953&partnerref=Intel_MCCommunity

J'ai installé rapidement matplotlib chez moi, effectivement, pour le reste, j'attend les paquets - et donc je n'utilise pas encore scipy au boulot -
Je ne savais pas que c'était si compliqué d'installer NumPy !

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

722
Pour la prog embarquee, j'y connais rien, je peux pas t'aider. Pour le concurrent programming, des articles interessants sont sur ce blog:

http://www.thinkingparallel.com/

Apres, ca depend de ce que tu veux faire. Le multi-threading pour avoir une sorte de parallelisme, style GUI et thread worker en backgroud, c'est relativement facile. Si tu veux plus, ca devient vite tres complique; vaut mieux s'initier avec des langages qui ont un support pour le multi-threading, je pense (java, python), quite a passer au C/C++ apres.
723

Citation :
n'utilise pas encore scipy au boulot -



Tu peux l'installer tres facilement si tu as deja numpy, quand meme: en gros, perso, je mets tous mes softs dans $HOME/local, et pour scipy, je fais



python setup.py install --prefix=$HOME/local


Apres, il faut que python puisse trouver scipy, donc il faut que tu rajoutes le path ou se trouve scipy:



PYTHONPATH=$HOME/local/lib/python2.4/site-packages python


Je te conseille ipython comme shell, ca rend le truc beaucoup plus sympa: perso, je me fais un alias, style alias lipython='PYTHONPATH=$PYTHONPATH ipython'. Ca permet d'eviter de foutre la merde en general pour python/ipython tel qu'utilise par d'autres programmes (j'exporte jamais globalement PYTHONPATH).
724
Comme pour matplotlib ;)
Je connais IPython, mais je ne l'ai pas encore trop utilisé. Il est installé sur la bécane, mais j'utilise peu l'interactivité de la l'interpréteur, les 3/4 du temps, c'est directement des gros modules que j'exécute ou que je code, et là, IPython n'est pas trop adapté.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

725
Hello

Merki pour les liens ! Concernant l'info embarqué c'est surtout concernant les noyaux tps réel sur arm, et le cross compiling et les précautions à prendre que je cherche des infos ...
Ce que j'aimerais faire concernant la prog parallele, c'est passé un programme optimisé pour un seul coeur à en exploiter plusieurs, et également réaliser un plug in permettant de faire des calculs répartis sur des petits clusters concernant du tps réel pour de la vidéo et de l'audio.
Je connais pas encore le Python mais ca fait un bail que je veux m y mettre, pkoi pas ! Je connais un tt chti peu le java mais bon je prefere partir sur le Python et l'apprendre à fond, java me semble en perte de vitesse à part pour les applis web ...

Bref j ai cours :) See U

cptn.io