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 925 réponses
  • 117 participants
  • 123 256 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
341

Citation :
Boost n'est pas fourni en package compilé, et je trouve que c'est plutôt à Boost.org qu'il faut se plaindre. Je n'ai aps encore tenté de rajouter Boost.Python, mais avec ce que tu as fait, ça risque d'être rapidement le cas.



Oui, mais la faute est quand meme en partie due a MS et ses outils non standart pour le build. Tous les projets que j'utilise, qui sont en general les references pour leur sujet (Atlas, fftw, sndfile, boost, etc...) ont dans la FAQ un truc special pour microsoft, c'est quand meme dingue !

Bon, sinon, parce que ca va finir en vulgaire ms contre * ( :oops: ), j'annonce que j'arrive enfin a faire tourner un plug in vst, et a tranformer des entrees au travers du plug. Bon, ca vaut ce que ca vaut (ie pas grand chose), mais avec le again en exemple VST, sur mon P4 1.8 Ghz, ca me prend 2 secondes pour traiter une heure de son @ 48 khz avec des blocs de 1024 samples, et j'ai rien optimise (entr autre, le vecteur de sortie est a chaque fois realloue). Ca devrait donc rester utilisable pour tester d'autres plugs. Ca plante avec adelay, mais je pense que c'est parce que j'ai pas verifie comment marche le multi channel, et adelay a une sortie sterreo pour une entree mono, ca doit venir de la.

Je trouve que c'est pas mal, ca a du me prendre 25 heures de codage a tout casser, avec decouverte de VS 8, boost python, revision de C++ et decouverte du fonctionnement hote VST. Bon point pout boost python, en tout cas, et ca confirme mon impression que le C++ reste interessant comme langage intermediaire pour faire le plombage entre le C et d'autres langages plus haut niveau.
342

Citation : Pour répondre à la question ASP, c'est oui, il suffitd e prendre le bon VS, et tout est fourni - et l'indenteur est bien mieux que sous 99% des outils Linux -


le 1% c'est emacs? rien a faire je préfère toujours celui de visual... mais c'est une question de préférence.

Ensuite mon projet est en fait un truc linux à la base, porter sous OSx (je dois l'admetre, sans problème une fois que j'ai remplacer les -lblabla par ce qu'il fallait), et je veux le faire tourner sous windows, mais la... meme avec cygwin tout installé, ben j'ai encore des erreurs sur des link (statique) qui fonctionne ailleur...
la cross compilation à première vu à pas mieux marcher mais il faut que je regarde de plus pret.

j'avais pensé à la solution visual studio, mais ca risque d'etre lourd à gérer si je dois modifier sln et projet juste pour compiler.

Pour ce qui est des autotools, je trouvais ca pratique mais pas vraiment simple... , j'irai faire un tour du coté de scons :)

Merci pour tous les conseils ;)
343

Citation :

le 1% c'est emacs? rien a faire je préfère toujours celui de visual... mais c'est une question de préférence.



A ce niveau la, c'est clairement du niveau de la pref personnelle, parce que perso, j'utilise vim, et ca me va tres bien pour tous mes travaux d'edition. emacs me convient pas a cause de mes pbs de RSI (les ctrl + *, c'est affreux), et bon, le truc de visual, j'ai pas reussi a lui faire coloriser mes trucs, donc bon, j'ai pas capte la puissance du truc ;)

En fait, je suis assez impressionne des perfs de l'hote. C'est vrai que python fait pas grand chose, mais quand meme, le cout du wrapping est negligeable pour des tailles de blocs raisonnable (1024). Pour des petits tailles (genre 64), faudrait que je regarde ce que ca donne avec un truc style psyco.

Citation :
Pour ce qui est des autotools, je trouvais ca pratique mais pas vraiment simple... ,



Non mais deja la lourdeur du truc, c'est phenomenal. Tu change un Makefile.am, et hop que ca reprend 1 minute facile pour regenerer le truc. En lus, c'est pas portable sous autre chose qu'unix, s'il y a une erreur dans ton script, faut avoir le courage de regarder un script de 100000 lignes, etc...
344

Citation : Oui, mais la faute est quand meme en partie due a MS et ses outils non standart pour le build. Tous les projets que j'utilise, qui sont en general les references pour leur sujet (Atlas, fftw, sndfile, boost, etc...) ont dans la FAQ un truc special pour microsoft, c'est quand meme dingue !


Sachant que Boost a son propre outil de compilation, c'est pas la bonne excuse ;) Et il y a un truc pour chaque compilo tout de même.

Les autotools, j'aime bien, j'arrive à faire des trucs sympas, des vérifs dans tous les sens, ... et la regénération des Makefile lorsqu'on change un Makefile.am, c'est pas dérangeant, c'est rapide chez moi, même si le projet est gros avec des goals ajoutés à la main dedans.

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

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

345

Citation :
Sachant que Boost a son propre outil de compilation, c'est pas la bonne excuse



Je parlais en general, pas specifiquement pour boost (qui est de toute facon hors competition, car utilisant le C++, le langage le plus chiant au monde au niveau standart tant tu as presque un nouveau langage pour chaque compilo).

Citation :
Les autotools, j'aime bien, j'arrive à faire des trucs sympas, des vérifs dans tous les sens, ... et la regénération des Makefile lorsqu'on change un Makefile.am, c'est pas dérangeant, c'est rapide chez moi, même si le projet est gros avec des goals ajoutés à la main dedans.



T'es vraiment bizarre, en fait :diable:

Pour jack, qui est un projet relativement simple (a peine 100 sources, 14 Makefile.am), ca prend 1m30 pour generer un projet (autoreconf + ./configure) usr mon portable a base de P4, quand meme. Donc si tu changes un makefile.am, ca va prendre a peu pres ce temps pour retester. Le fait que de gros projets open source (kde, ardour) cherchent a s'eloigner du truc est un signe a mon avis que ca a fait son temps.

Avoir besoin de 4 langages(perl + m4 + shell + Makefile), au moins 5 outils tous interdependants (aclocal + autoconf + automake + libtool + autoheader), qui genere un script shell de 25000 lignes, c'est quand meme tordu. Sans compter la doc qui est extremement pauvre et eparpillee un peu partout
346

Citation : Avoir besoin de 4 langages(perl + m4 + shell + Makefile), au moins 5 outils tous interdependants (aclocal + autoconf + automake + libtool + autoheader), qui genere un script shell de 25000 lignes, c'est quand meme tordu. Sans compter la doc qui est extremement pauvre et eparpillee un peu partout


oue en fait +1 la dessus.... Scons semble etre vraiment un cran au dessus. (sur les conseils récolté ici je remplace ;) )
347
Ce que je trouve puissant dans scons, c'est de ne pas tenir compte de l'environnement, et surtout d'avoir un vrai langage.

Maintenant, ca a pas mal de defauts:
- pas de prise en compte d'un equivalent de libtool (mais bon, ca marche pas sous windows non plus, libtool)
- la gestion des options est pas tres convivial
- probleme de lenteur ? Perso, j'ai pas eu de problemes avec mes petits projets, et meme un truc comme ardour qui est deja assez lourd est quand meme plus rapide a etre update que autoconf and co. Puis des projets comme blender ou quake l'utilise aussi.
- t'as pas toutes les macro de autoconf. Par exemple, j'ai du ecrire mon propre code pour tester blas et lapack, mon propre code pour faire un tarball des sources, mon propre code pour le versioning de librairies... Mais le fait que tu puisses le faire est cependant un signe du bien fonde de l'outil, car etendre autoconf de cette maniere est quasiment impossible.

Si tu veux maitrisier scons, je te conseille de regarder ardour (qui mixe des librairires sous autoconf), blender et csound.
348
Je vais jeter un coup d'oeil a ces sources la, mais contrairement à autotools ou j'avais du regarder dans d'autre projet comment c'était fait, la ca me semble relativement simple... meme pour tester les trucs genre SDL etc.
349
Y a des choses qui sont pas simples, quand meme. Typiquement, faire un tar ball des sources (l'equivalent du make dist), le unit testing, les specialisations selon plateformes et/ou outil.

Par contre, un truc excellent, je sais pas si t'as vu, c'est qu'il y a une version self contained que tu peux inclure ton projet (parce que scons est pas encore super repandu non plus).

C'est dommage qu'ils aient loupe le coche kde (kde, pour la version 4, etait sur le point d'utiliser scons, mais ils ont prefere cmake a la fin, pour des raisons que je trouve un peu bizarres), ca aurait fait une grossepub, comme le passage a subversion.
350
Scons commence a etre bien répendu quand meme, et vu ses qualitésn ca devrais encore évolué!
Jusque la je dois dire que j'aime bcp!! surtout si on peut inclure une version dans le projet! je compte pas distribué ce sur quoi je travail, mais je veux pouvoir le compiler sur des machines mac, linux et windows, et c'est toujours embant de demander au propriétaire de la machine d'installer un truc...

pour ce qui est des unit test etc, étant donné que j'ai a peu pret aucune formation en génie logiciel, et que donc je vois tout juste ce que ca peut etre, ca me dérange pas trop... Sincèrement la je me mord les doigt d'avoir choisit les autotools avant!!