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 327 327

Le pub des programmeurs

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

726

Citation :
Comme pour matplotlib



Oui, sauf que scipy n'a aucune dependance supplementaire par rapport a numpy. Pour compiler, ca reste le probleme fondamental, et si numpy est present, le probleme est regle.

Citation :
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é.



Oui mais si tu veux corriger un bug dans un script, c'est nettement plus pratique que l'interpreteur python de base. Typiquement, matplotlib met un certain temps a se charger quand meme, et ca me fait chier d'attendre 10 s a chaque fois pour corriger une pauvre erreur de syntaxe; la, la commende %run d'ipython permet de recharger a la volee, de voir tes variables, etc... Bref, ca utilise les qualites d'introspection de python, et c'est un peu l'interet de la chose.
727

Citation : La plupart des programmeurs UNIX n'aiment pas beaucoup les threads.


Je pense même que beaucoup de programmeurs expérimentés s'en méfient fortement ! Il y avait un célèbre article de John Ousterhout (créateur de tcl/tk) sur ce sujet. En fait la plupart du temps pour que la conception soit bonne il faut un méthode + un maximum de minutie (et aucun développeur inexpérimenté dans l'équipe). autant dire que c'est assez rare.

Citation : 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


Effectivement le problème c'est quand tu n'as pas le choix, par exemple un système comme celui de la SNCF ou tu as des serveurs centraux, des clients lourds au quatres coins du pays, un lien avec les services minitel + internet, des liens avec des services externes (sous-traitance, partenaires commerciaux...). Quand tu changes une fonctionnalité importante, ça entraîne des modifs dans tous les coins, et rien que le déploiement de la nouvelle version est un problème complexe en soi.

Citation : 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 ?


Bien sûr ! En fait, je n'ai peut-être pas été clair, mais je ne critique pas du tout l'open-source. Je critique uniquement les "évangélistes" qui de temps à autres inventent une méthode (qui peut avoir des qualités indéniables) et semblent prétendre qu'elle s'applique avec succès à tous les besoins. C'est cette argumentation "il existe une méthode qui est la meilleure quele que soit le type de projet" que je critique. Et l'exemple de la navette, comme celui de la SNCF, sont des cas où une démarche fortement itérative est inadaptée.

Citation : 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.


Nan mais dans l'article de Eric Raymond, le bazar désigne la méthode de développement, et pas du tout le résultat obtenu. Et puis c'est pas péjoratif, c'est juste un peu provocateur !

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

728

Citation : Je suis tjs aussi paumé dans vos discussions 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


Houla, c'est vaste tout ça ! En plus l'embarqué, il y en a 36.000 sortes !

Un point de départ : https://fr.wikipedia.org/wiki/Programmation_informatique

Si l'anglais ne te rebute pas, la version anglaise de la wikipedia est souvent plus riche ; et souvent les deux sont complémentaires.

Sur la programmation parallèle : https://fr.wikipedia.org/wiki/Programmation_concurrente , tu peux aussi faire tes propres essais en créant plusieurs threads en java (ou n'importe quel langage) !

Tu peux aussi te promener ici : http://c2.com/cgi/wiki?ProgrammingParadigm

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

729

Citation :
Je pense même que beaucoup de programmeurs expérimentés s'en méfient fortement ! Il y avait un célèbre article de John Ousterhout (créateur de tcl/tk) sur ce sujet. En fait la plupart du temps pour que la conception soit bonne il faut un méthode + un maximum de minutie (et aucun développeur inexpérimenté dans l'équipe). autant dire que c'est assez rare



Les thread vont un peu a l'encontre de la culture unix en general, car entre autre les UNIX ont des processus legers (vs NT ou VMS, par exemple: la creation de processus est au moins un ordre de grandeur plus longue que sous linux sur la meme machine; pour linux au moins, cette duree a diminue dans le temps), etc...

Je pense que pour les thread et le concurrent en general, on est tout simplement en manque d'outils: on en est encore a gerer ca a la main, un peu comme le C le faisait pour la memoire vive. C'est que recemment que l'on commence a voire des outils apparaitre dans l'industrie (erlang, etc...); il y a aussi google qui finalement est techniquement fondamentalement base sur la programmation concurrent (mapreduce). Ca prend du temps a faire correctement, tout simplement.

Citation :

Nan mais dans l'article de Eric Raymond, le bazar désigne la méthode de développement, et pas du tout le résultat obtenu. Et puis c'est pas péjoratif, c'est juste un peu provocateur !



Non mais je sais bien, je l'ai lu le bouquin, hein :)
730
> Miles, si t'es aventureux, j'ai annonce une version alpha de rpm pour numpy and scipy sur fedora core (5 et 6) et openSUSE (10.2) sur numpy-dev :)