Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 123 843 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
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