Le pub des programmeurs
- 1 927 réponses
- 117 participants
- 131 720 vues
- 130 followers

Anonyme



Anonyme

You must also link to the FFTW library. On Unix, this means adding -lfftw3 -lm at the end of the link command.
MIRACLE ! Ca marche !


Merci à toi et idulsen bon, je vais regarder tous ces trucs la de près maintenant

[ Dernière édition du message le 02/02/2017 à 19:33:29 ]

Anonyme


Al1r

MIRACLE ! Ca marche !



J-Luc

Nous ici on fait tout avec .NET, c'est vraiment facile à aborder et c'est très adapté à l'extrême prototyping : le truc qu'on fait pour essayer et qui devient le utilitaire préféré de tout un service en prod. Clients lourds, site web, on fait tout avec, ça code hyper vite et plutôt bien, genre les gens reprennent facilement derrière. M'enfin, ce n'est que mon avis. Toutefois, on utilise Visual Studio depuis plus de 10 ans, si ça merdait on le saurait.
Ce que je ne comprends pas c'est l'engouement pour JS (et JSON du coup), tout ce que j'ai vu écrit en Javascript était en mode plat de nouilles, non structuré, totalement imbitable. Genre régression, genre je montre que je sais faire un programme illisible. Déjà, les indices de boucles i, j ou k, chez moi (et mes stagiaires) c'est interdit.
En plus Mono fait tourner les assembly Visual Studio sans recompilation sur Raspberry Pi sous Ubuntu 16 et ça c'est hyper bien, on en met plein en prod. Ecriture et debug sur PC sous Windows et zou, copier coller sur le Pi.
Il y a deux moyens d’oublier les tracas de la vie : la musique et les chats.
Albert Schweitzer
[ Dernière édition du message le 06/02/2017 à 12:38:17 ]

Al1r

A propos de Jamin
mais je ne crois pas qu'on puisse avoir plusieurs sorties
Tu peux démarrer plusieurs instances de Jamin, chaque instance te donne 2 input et 2 output dans les connexions de Jack. Tu peux alors configurer chaque instance comme tu le veux et donc faire ton routage comme tu l'entend si tu as plusieurs cartes son.
Deux problèmes cependant:
- le premier, le nombre d'instance de Jamin risque de demander beaucoup de ressources (CPU, memoire)
- la latence de chaque carte pourrait mettre le souk dans la cohérence du signal final


Chris Kazvon


J'ai pas eu la foi de tester en rentrant du taff hier

Enfin faut dire aussi que le temps de recevoir l'adaptateur hdmi/vga faut que je squatte la télé quand je trifouille le pi, c'est pas très waf compliant

Je reçois une pette uca202 en fin de semaine, je pourrai faire des tests plus complets.
Mais si c'est juste pour deux subs et deux têtes, au pire une deuxième uca202 et hop

Chris Kazvon
-------------------------------------------------
Introduction à Hornresp et Tutoriels - Tutoriels Vidéo pour Room EQ Wizard

props

Nous ici on fait tout avec .NET, c'est vraiment facile à aborder et c'est très adapté à l'extrême prototyping : le truc qu'on fait pour essayer et qui devient le utilitaire préféré de tout un service en prod. Clients lourds, site web, on fait tout avec, ça code hyper vite et plutôt bien, genre les gens reprennent facilement derrière. M'enfin, ce n'est que mon avis. Toutefois, on utilise Visual Studio depuis plus de 10 ans, si ça merdait on le saurait.
Ce que je ne comprends pas c'est l'engouement pour JS (et JSON du coup), tout ce que j'ai vu écrit en Javascript était en mode plat de nouilles, non structuré, totalement imbitable. Genre régression, genre je montre que je sais faire un programme illisible. Déjà, les indices de boucles i, j ou k, chez moi (et mes stagiaires) c'est interdit.
En plus Mono fait tourner les assembly Visual Studio sans recompilation sur Raspberry Pi sous Ubuntu 16 et ça c'est hyper bien, on en met plein en prod. Ecriture et debug sur PC sous Windows et zou, copier coller sur le Pi.
+1 pour le .NET.
Pour tout ce qui est javascript, l'écosystème a énormément évolué depuis quelques années, notamment avec l'essor de Node Js et de l'ES6 (la spec du langage javascript). La syntaxe ressemble à présent à celles de n'importe quel langage objet moderne. Il y a pléthore de librairies et frameworks pour développer "propre" : jQuery (tend à être de moins en moins pertinent avec l'unification des browsers, mais bon ça reste une référence), Lodash (pour ne plus jamais coder de boucles avec des indices

La condition essentielle est de respecter les bonnes pratiques (principes SOLID et TDD !), ce qui est de toute façon valable pour n'importe quel langage / plateforme.

Chris Kazvon


Pour pas squatter la téloche du salon, je suis finalement passé par une connexion ssh avec vncviewer

Ça a l'air chouette comme soft, plus qu'à tester !
Edit: j'avais mis "update" en trop dans la commande
Chris Kazvon
-------------------------------------------------
Introduction à Hornresp et Tutoriels - Tutoriels Vidéo pour Room EQ Wizard
[ Dernière édition du message le 09/02/2017 à 10:29:25 ]

Truelle est un manchot

Pour tout ce qui est javascript, l'écosystème a énormément évolué depuis quelques années, notamment avec l'essor de Node Js et de l'ES6 (la spec du langage javascript). La syntaxe ressemble à présent à celles de n'importe quel langage objet moderne. Il y a pléthore de librairies et frameworks pour développer "propre" : jQuery (tend à être de moins en moins pertinent avec l'unification des browsers, mais bon ça reste une référence), Lodash (pour ne plus jamais coder de boucles avec des indices), puis les grosses machines : Angular, React etc... On trouve également beaucoup d'outils orientés devops / testing : gulp, protractor, karma, browserify, webpack etc... On peut utiliser Typescript pour se rapprocher encore davantage d'une syntaxe tyle C#, mais bon l'ES6 est déjà bien robuste de ce côté-là.
La condition essentielle est de respecter les bonnes pratiques (principes SOLID et TDD !), ce qui est de toute façon valable pour n'importe quel langage / plateforme.
Regardez du côté de elm, c'est pas dégueu comme truc (basé sur Haskell, ça te compile ton bordel en JS).
Sinon bientôt tout ça sera de l'histoire ancienne avec Wasm.


J-Luc

Hum... ok, je viens de lire au moins 30 noms bizarres en 3 minutes...
C'est pas gagné, quand on choisit un IDE et un langage c'est pour 10-15 ans : valider les outils, stabiliser nos sources, et surtout former tous les intervenants : usines, s/traitants,... Alors je reste en .NET pour l'instant :-)
Il y a deux moyens d’oublier les tracas de la vie : la musique et les chats.
Albert Schweitzer

props

Hum... ok, je viens de lire au moins 30 noms bizarres en 3 minutes...
C'est pas gagné, quand on choisit un IDE et un langage c'est pour 10-15 ans : valider les outils, stabiliser nos sources, et surtout former tous les intervenants : usines, s/traitants,... Alors je reste en .NET pour l'instant
Oui désolé j'ai volontairement balancé des noms en vrac, Google faisant le reste.
Le .NET va prendre un bon coup de jeune avec la version .NET Core en tout cas.
C'est tout le débat stabilité long terme vs. réactivité face au changement...
J'ai bien connu les deux, de façon même très caricaturale. J'ai un peu bossé en environnement indus, les mecs utilisaient encore des machines, outils et langages d'il y a 20 ansQuand je suis arrivé et que j'ai commencé à leur parler de frameworks, d'open source, de test driven, je me suis fait bien rembarrer. Bon j'étais pas expert en conduite du changement des têtes de mules non plus
![]()
Quand j'ai intégré ma boite actuelle, qui était une startup, et l'esprit de la boite était absolument tout l'inverse, nouveau langage ? on l'utilise ! Nouveau framework ? on le met en place ! Quel bordel quand je suis arrivé... Du coup on s'est retrouvés à utiliser des technos juste pour le fun (grosse erreur !), dont on aurait sans doute pu très bien se passer, avec des conséquences qui ont pu être fâcheuses, livraisons retardées à cause de la courbe d'apprentissage liée à l'utilisation d'une nouvelle techno non mesurée et incluse dans le planning, gros risque pour la stabilité du produit à cause de l'utilisation de technos pas assez mûres, etc...
L'idéal est de trouver le juste milieu entre ces deux extrêmes...

EraTom

Oui enfin ce n'est pas si simple.
Perso je suis plutôt fan de la souplesse du C# et de ce qui avec , etc.
Dans l'industrie il y a d'autres contraintes comme... La sécurité : pour compiler le code des commandes de vol d'un avion il faut utiliser un compilateur certifié.

Jimbass

Citation de EraTom :Perso je suis plutôt fan de la souplesse du C# et de ce qui avec , etc.
Moi aussi je m'accorde en Db.
Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts

Anonyme

La condition essentielle est de respecter les bonnes pratiques (principes SOLID et TDD !), ce qui est de toute façon valable pour n'importe quel langage / plateforme.
sujet intéressant ! Plus important que le langage choisi , l'important est aussi de savoir jongler entre les différents paradigmes de programmation et notamment la programmation fonctionnelle qui est la base de bon nombre de bonnes pratiques pour avoir du code robuste, réutilisable et dont l'execution peut être parallélisable. Quand je vois par example le taux d'utilisation d'un langage comme scala en France par rapport aux pays anglo-saxons.... ca fait peur...
[ Dernière édition du message le 09/02/2017 à 17:21:35 ]

Al1r

Le temps.
Utiliser des nouvelles techniques est un fait, les questions suivantes se posent directement
- combien de temps va-t-on utiliser cette application? Six mois, un an, plus?
- Y a-t-il un héritage informatique? si oui, quelle compatibilité avec le nouveau langage?
- la maintenance des applications dans le temps? Réécrire du neuf? Intégrer l'existant et comment?
- Charge de travail de la maintenance? Vitesse de déploiement...
- ...
[ Dernière édition du message le 09/02/2017 à 23:24:13 ]

Dr Pouet

Quelques soient les langages et les méthodes de programmations, il y a un facteur que l'ont ne peux négliger...
Le temps.
Utiliser des nouvelles techniques est un fait, les questions suivantes se posent directement
- combien de temps va-t-on utiliser cette application? Six mois, un an, plus?
- Y a-t-il un héritage informatique? si oui, quelle compatibilité avec le nouveau langage?
- la maintenance des applications dans le temps? Réécrire du neuf? Intégrer l'existant et comment?
- Charge de travail de la maintenance? Vitesse de déploiement...
- ...
Ah oui, je vois bien ce que tu veux dire vu que je m'occupe de maintenir pas mal de vieux trucs ! (Je ne parle pas du Révérend)
Oui enfin ce n'est pas si simple.
Perso je suis plutôt fan de la souplesse du C# et de ce qui avec , etc.
Dans l'industrie il y a d'autres contraintes comme... La sécurité : pour compiler le code des commandes de vol d'un avion il faut utiliser un compilateur certifié.
Le Z100

[ Dernière édition du message le 09/02/2017 à 22:13:10 ]

Jimbass

Dans l'industrie il y a d'autres contraintes comme... La sécurité : pour compiler le code des commandes de vol d'un avion il faut utiliser un compilateur certifié.
Dans ce cas particulier, on parle de sûreté. C'est conceptuellement assez différent de la sécurité ... (avec en plus une subtile différence avec safety et security)
Et donc tout le code doit être certifié (on doit prouver une couverture de test exhaustive ou presque selon le niveau de criticité, prouver qu'il n'y a pas de code mort, démontrer que l'ordonnancement est correct, etc.)
https://fr.wikipedia.org/wiki/DO-178
Pour ca on utilise des langages comme ADA ou du bon vieux C, avec lesquels on peut maîtriser toute la chaîne de production du code.
Juste pour donner un ordre de grandeur : si on imprimait toute la doc nécessaire à la certification d'un avion, la masse de papier serait à peu près équivalente à la masse ... de l'avion lui-même. (Oui, c'est un gars d'Airbus qui me l'a dit.)
De manière plus générale, dans les systèmes embarqués et/ou temps réel il n'est pas opportun d'utiliser certaines "bonnes pratiques" de l'informatique générale. Les couches d'abstraction en grand nombre, les frameworks pléthoriques, la récursion, les trucs dynamiques (JIT compiling, garbage collection, etc.) sont super mauvais pour la compacité du code, sa performance, et surtout la répétabilité de cette performance.
D'ailleurs on ne s'intéresse qu'au pire cas, quand tout est en train de déconner. Par exemple on mesure/analyse le temps d'exécution au pire cas d'une tâche (WCET, Worst Case Execution Time). La performance moyenne n'est pas significative dans un système temps réel dur.
Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts
[ Dernière édition du message le 10/02/2017 à 11:56:40 ]

Dr Pouet

Dans ce cas particulier, on parle de sûreté. C'est conceptuellement assez différent de la sécurité ... (avec en plus une subtile différence avec safety et security)
Après des décennies d'anglicismes, c'est en train de changer et on revient au bon français.

Donc sécurité : pour éviter les pannes et les accidents.
Sûreté : contre les intrusions, les malveillances.
Néanmoins on va être du coup obligé pendant plusieurs années de préciser le sens qu'on donne à ces mots...
[ Dernière édition du message le 10/02/2017 à 11:44:03 ]

Jimbass

En français, la sûreté est une caractéristique intrinsèque, démontrable, objective. On parle de "sûreté nucléaire".
La sécurité est un sentiment, subjectif. On parle de "forces de sécurité" dans les banlieues.
Dans le jargon technique (qui découle de la signification anglophone) la safety consiste à prémunir le système des défaillances (événements extérieurs, usure, défauts de conception, ...). La security consiste à protéger le système des attaques intentionnelles (espionnage, détournement, déni de service, ...)
Certaines techniques peuvent s'appliquer aux deux, mais pour l'instant ce sont des disciplines relativement séparées.
Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts
[ Dernière édition du message le 10/02/2017 à 11:52:11 ]

Dr Pouet

Pour ca on utilise des langages comme ADA ou du bon vieux C, avec lesquels on peut maîtriser toute la chaîne de production du code.
Ou le Z100 / SDL / System Description Language... qui permet de modéliser du multitâche avec des graphes d'état, des envois de messages, puis de simuler les comportements, identifier les cas de blocages, vérifier la bonne gestion des défaillances, et enfin de générer les exécutables.
Juste pour donner un ordre de grandeur : si on imprimait toute la doc nécessaire à la certification d'un avion, la masse de papier serait à peu près équivalente à la masse ... de l'avion lui-même. (Oui, c'est un gars d'Airbus qui me l'a dit.)
Tout à fait.
J'ai aussi un autre ordre de grandeur qui m'avait été donné par des gens d'Astrium travaillant dans les satellites et autres systèmes critiques. Il s'agit de la productivité globale d'un bonhomme dans une équipe de développement, donc y compris tests + doc + contrôle qualité + gestion de projet etc...
Logiciel de qualité industrielle (disons pour piloter une chaîne de montage de voitures) : 25 lignes par bonhomme et par jour.
Logiciel critique (sale de contrôle de satellite...) : 5 lignes.
Logiciel embarqué (pilotage d'avion, fusée ou satellite, appareil médical assurant une fonction critique) : 1 ligne.
Bref, on peut facilement diviser par 5 ou par 25 la productivité selon les méthodes de travail.

Dr Pouet

Perdu, c'est l'inverse.
En français, la sûreté est une caractéristique intrinsèque, démontrable, objective. On parle de "sûreté nucléaire".
La sécurité est un sentiment, subjectif. On parle de "forces de sécurité" dans les banlieues.
Non c'est toi qui a perdu !

Par exemple la DST signifiait Direction de la Sûreté du Territoire, protection et sûreté du territoire pour l'armée.
On parlait de "glace sécurit", de "pour votre sécurité ne vous penchez pas par la fenêtre"...
Mais le mot anglais security signifie sûreté, et safety se traduit en réalité par sécurité.
Ensuite le mauvais bon sens populaire est venu mettre le bazar.
Mais à nouveau on parle « d'étude de sécurité » pour vérifier la bonne redondance des systèmes, et de Politique de Sûreté des Systèmes Informatiques contre les intrusions et malveillances.
[ Dernière édition du message le 10/02/2017 à 12:04:08 ]

Jimbass

Ou le Z100 / SDL / System Description Language...
Je n'ai jamais vu ca, il faut que je me renseigne.
La mode chez les systémiers est encore au Model-Driven Engineering, à base de profils UML spécifiques.
Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts

Jimbass


https://fr.wiktionary.org/wiki/s%C3%BBret%C3%A9
https://fr.wiktionary.org/wiki/s%C3%A9curit%C3%A9
« Sécurité et sûreté ne sont pas la même chose ; le premier exprime un sentiment et l'autre un état d'assurance ; on a souvent de la sécurité sans être en sûreté ».
Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts

Anonyme



Dr Pouet

Citation de Dr :Ou le Z100 / SDL / System Description Language...
Je n'ai jamais vu ca, il faut que je me renseigne.
La mode chez les systémiers est encore au Model-Driven Engineering, à base de profils UML spécifiques.
Oui c'est vieux (1988). Et en plus c'est (forcément) lourd car très précis. Mais ça a été utilisé très tôt par Airbus.
Initialement c'était l'entreprise suédoise Télélogic qui faisait l'outil de SDL (Telelogic Tau) utilisé par Airbus. Le SDL ou Z100 est normalisé par ITU (sorte de IEEE orienté télécom et basé à Genève). Désormais c'est IBM qui a racheté Telelogic, et le SDL fait partie de leur catalogue "Rational" (donc avec UML etc. D'ailleurs visiblement il y aurait une nouvelle mouture Z120).
Truelle : non c'est ça :
https://fr.m.wikipedia.org/wiki/Specification_and_Description_Language
Pas un matériel, mais un "environnement de développement" qui peut produire des softs à destination de n'importe quelle plateforme, mais généralement des calculateurs embarqués.
Exemples :
https://books.google.fr/books?id=DkFtCQAAQBAJ&pg=PA6&lpg=PA6&dq=sdl+airbus&source=bl&ots=fqj7Mb6mSx&sig=YJ7XPU0TfUNVdZ7aN4JO1nAgxqE&hl=fr&sa=X&ved=0ahUKEwiMkY6ttIXSAhXLuBoKHR3QD8k4ChDoAQgdMAI#v=onepage&q=sdl%20airbus&f=false
[ Dernière édition du message le 10/02/2017 à 12:21:37 ]
- < Liste des sujets
- Charte