Le topic de la programmation: Et envoyez des sioux!

[Tramb]

En quoi serait elle abandonnée plus vite ?
On ne parle pas de sauter sur la dernière techno à la mode mais de faire des choix pragmatiques.
Tous ceux cités par Dross le sont.

C'est pas *exactement* ce qui est arrivé à WinForms ? Un fad de quelques années puis au dodo en mode maintenance jusqu'à ce que ce soit débranché ?

De toute façon, je ne crois pas aux applis durables/importantes "qui n'auront jamais besoin d'être portées". Donc pas de WPF chez moi.

D'ailleurs C# dans 20 piges ? Still alive ? Les paris sont pris
Après j'en veux pas à Microsoft. Ils financent Peyton-Jones.

[Orhin]

De toute façon, je ne crois pas aux applis durables/importantes "qui n'auront jamais besoin d'être portées". Donc pas de WPF chez moi.

Ah mais je ne dis pas le contraire, les techno évoluent et un choix n'est valable qu'à un instant T.
Dans 10 ans, Dross devra surement migrer une partie de ses applicatifs.
Ce qui n'est pas une mauvaise chose.

D'ailleurs C# dans 20 piges ? Still alive ? Les paris sont pris

Bah ça fait 15 ans que le langage existe et sa popularité ne cesse de croitre.

Après entre Typescript qui bouffe des parts au JS, Kotlin qui commence à doucement s'installer, Rust qui attire du monde, dur de jouer madame Irma quant aux langages de demain.

[Dross]

Winform c'est aussi plus facile à manipuler au départ. Tu a l'outil graphique dans VS, et tu créer le code behind en quelques clics. Quand t'y connais rien en GUI, le temps de mise en place est très court, c'est pas pour rien que les étudiants arrivent a faire des trucs avec très rapidement.
Le problème ? Bah ça ne repose sur aucuns design pattern, et tu rentre vite dans les problèmes de ce fait. Nous on était déjà un peu plus avancé et on avait utilisé le pattern MVP, c'est mieux, mais pas aussi bien que le MVVM.

Si on avais voulu faire dès le départ l'application avec WPF/MVVM/Modulaire par PRISM, avec les connaissances qu'on avais alors on aurai certainement fait d'énormes bourdes car ce sont des frameworks assez conséquents, et ce n'est pas dit qu'on n'aurai pas été obligé de tout refaire par la suite (sans parler du fait, bah qu'on devais se former sur ces technos avant).
De plus, l'intérêt de certains patterns viennent avec l'expérience (et les erreurs/problèmes rencontrés).

Donc on a fait en winform et en parallèle on se formait au WPF, de toutes manières nos apps sont bien découplées donc la logique, elle, restait dans des lib .NET qu'on a réutilisé tel quel ensuite, c'est juste qu'une brique qu'on remplace au final. Puis on a pas migré bêtement en 1 pour 1 non plus, on a migré quand on ne se voyais pas réaliser les nouvelles fonctionnalités sur winform, en fait, le coût migration + fonctionnalités WPF a été bien inférieur que de faire lesdites fonctionnalités directement en winform.

Pareil pour Angular, j'avais regardé dès le départ, mais ça me semblait trop gratiné pour une équipe qui n'avais jamais fait de web (moi un peu), du coup Razor me semblait plus adapté, et ça nous a permis de valider des choses, faire du kilométrage avec.
Ce n'est pas un choix qu'on regrette : on fait dans l'itératif. Puis on a réglé les soucis restant en sortant la grosse artillerie.

[Tramb]

Après entre Typescript qui bouffe des parts au JS, Kotlin qui commence à doucement s'installer, Rust qui attire du monde, dur de jouer madame Irma quant aux langages de demain.

Moi je supporte Rust, qui apporte vraiment de la safety sans sacrifier la performance. Y compris pour la concurrence.
Je pense qu'il a un bel avenir (mais pas forcément pour ce qui vous intéresse), il met vraiment du neuf sur la table. On verra d'ici quelques années, si la team ne se plante pas en voulant faire trop, trop vite et ne font pas des conneries.

[TiNitro]

Dross fait dans un pragmatisme louable, avec une approche intelligente je trouve. c'est pertinent de tenir compte du niveau de l'equipe et de la courbe d'apprentissage.
et si une techno est pas pertinente tu ne t'attardes pas dessus, tu changes.

et quel que soit le langage dans 20 piges tu seras dans la misere

[war-p]

Moi je supporte Rust, qui apporte vraiment de la safety sans sacrifier la performance. Y compris pour la concurrence.
Je pense qu'il a un bel avenir (mais pas forcément pour ce qui vous intéresse), il met vraiment du neuf sur la table. On verra d'ici quelques années, si la team ne se plante pas en voulant faire trop, trop vite et ne font pas des conneries.

Tiens en parlant de rust, t'as fait un peu de cross-compilation? (J'ai un petit souci avec ça )

[Tramb]

Tiens en parlant de rust, t'as fait un peu de cross-compilation? (J'ai un petit souci avec ça )

J'ai fait des tentatives un peu trop tôt, et maintenant j'attends que ce soit un peu débroussaillé et que nostd soit bien consolidé.

[vectra]

J'ai fait des tests sous CLion hier.
La complétion marche pleinement, mais bizarrement, avec des options qui n'ont rien à voir. Faut que j'étudie un peu les détails pour comprendre mieux ce qui se passe.

Par contre, je retire ce que j'ai dit pour les problèmes de perf de la solution emacs irony+company: avec CLion, le projet est entré dans une phase d'indexation de ouf' guedin qui a duré un bon moment, le processus java occuppant alors 100% de tous les cores du CPU. J'imagine qu'il a généré un index statique pour cacher les résultats, en espérant qu'il s'update facilement par la suite.

J'y reviendrai plus tard, mais j'ai d'abord une autre question plus urgente (cross-post topic des CGs):



Je dois commander 2 PC pour le boulot. Je vais devoir programmer de l'OpenGL avec: rien de méchant, mais j'aimerais que ça booste un peu pour pas trop cher.
Ma question: puis-je me contenter des circuits intégrés au Core i5 8600, ou devrais-je plutôt inverstir dans des CG séparées?

Si oui, j'aimerais bien contenir le prix sans pour autant faire des sacrifices. J'ai vu ça:
https://www.materiel.net/carte-graph...go-126547.html

Ca vaut quoi à peu près? J'insiste pour rappeler qu'il ne s'agira que de faire de l'OpenGL sans shaders a priori, et sans CUDA.
Tant mieux d'ailleurs, parce que 14Go de BP mémoire, c'est tellement le foutage de gueule que ça fait moins bien qu'un CPU.

J'ai fait une recherche sur le GPU intégré au CPU: c'est pas dégueu du tout en fait:
https://www.notebookcheck.net/Intel-....257928.0.html

[Orhin]

Par contre, je retire ce que j'ai dit pour les problèmes de perf de la solution emacs irony+company: avec CLion, le projet est entré dans une phase d'indexation de ouf' guedin qui a duré un bon moment, le processus java occuppant alors 100% de tous les cores du CPU. J'imagine qu'il a généré un index statique pour cacher les résultats, en espérant qu'il s'update facilement par la suite.

Ouais la première indexation sur un projet "neuf" est un poil longue, par contre elle est conservée par la suite et se met à jour quasi instantanément.

[Tramb]

J'ai fait des tests sous CLion hier.
La complétion marche pleinement, mais bizarrement, avec des options qui n'ont rien à voir. Faut que j'étudie un peu les détails pour comprendre mieux ce qui se passe.

Par contre, je retire ce que j'ai dit pour les problèmes de perf de la solution emacs irony+company: avec CLion, le projet est entré dans une phase d'indexation de ouf' guedin qui a duré un bon moment, le processus java occuppant alors 100% de tous les cores du CPU. J'imagine qu'il a généré un index statique pour cacher les résultats, en espérant qu'il s'update facilement par la suite.

J'y reviendrai plus tard, mais j'ai d'abord une autre question plus urgente (cross-post topic des CGs):



Je dois commander 2 PC pour le boulot. Je vais devoir programmer de l'OpenGL avec: rien de méchant, mais j'aimerais que ça booste un peu pour pas trop cher.
Ma question: puis-je me contenter des circuits intégrés au Core i5 8600, ou devrais-je plutôt inverstir dans des CG séparées?

Si oui, j'aimerais bien contenir le prix sans pour autant faire des sacrifices. J'ai vu ça:
https://www.materiel.net/carte-graph...go-126547.html

Ca vaut quoi à peu près? J'insiste pour rappeler qu'il ne s'agira que de faire de l'OpenGL sans shaders a priori, et sans CUDA.
Tant mieux d'ailleurs, parce que 14Go de BP mémoire, c'est tellement le foutage de gueule que ça fait moins bien qu'un CPU.

J'ai fait une recherche sur le GPU intégré au CPU: c'est pas dégueu du tout en fait:
https://www.notebookcheck.net/Intel-....257928.0.html

Tu vas faire quoi ? Dessiner des visualisations de données ?

[vectra]

Utiliser VTK à fond. Pas forcément à fond, mais bien quand-même. Or c'est pas vraiment optimisé.
Visu 3D de partout, dans un contexte médical, un peu comme dans mes travaux plus anciens.

Chez moi, avec une 1060, ça tourne de folie quoi que je foute dedans, et ça a toujours été le cas avec mes CGs précédentes.
Mais vu mes contraintes de budget pour mon PC du boulot, c'est niet pour me prendre une carte à 200 euros.

Au taf, sur la machine à remplacer, j'ai actuellement une vieille Quadro FX 1800, un truc avec 3 sorties displayport, mais seulement 40Go/s de BP mémoire (soit autant qu'un CPU récent). Eh ben ça rame très vite dès que j'augmente la taille de la fenêtre de visu, même avec pas grand-chose dedans en plus...

La question que je me posais, c'était:
* est-ce que le GPU intégré va suffir à faire tourner ma visu en 2560*1440? Sachant qu'il parvient à faire fonctionner du Team Fortress à 60fps+ en résolution pas trop élevée?
* si non, quelle CG prendre à 40-80 euros max pour avoir à peu près des performances de CG moyenne capables de terrasser l'iGPU (s'il y en a) ?

[Tramb]

C'est sûr que si tu veux rendre des tomographies de 150GB sans des optis spécifiques, ça peut être chaud.
Mais sinon ça devrait aller.
T'as un exe à essayer ?

[vectra]

Nan nan, je fais plus ça.
Ca reste assez 'basique' en comparaison de ma thèse en ce qui concerne la taille des données qui finissent sur un affichage.

Si tu as VTK installé sur ta machine (et de préférence en nunux), oui, je dois pouvoir passer des exécutables "qui font à peu près" ce que je veux faire avec la même blibliothèque.
Mais grosso-modo, j'aimerais une carte de jeu minimale pour faire du Starcraft 2 en 2560*1920 à bonne vitesse, ça devrait à peu près couvrir mes besoins.

Si mon iGPU peut le faire, tant mieux,
Si cette CG coûte plus de 50-80€, tant pis
et s'il peut faire 'le job' à peu près en attendant qu'on ait le pèze pour acheter une CG correcte, ça risque de finir comme ça.

[Tramb]

Je voulais essayer sur un Intel intégré antérieur mais pour le coup, c'est sûr. Impossible de jouer à SC2 dans une telle résolution avec plus de 1 SPF (:D).
Par contre tu as ramené le problème à un truc plus trouvable sur Internet, comme ça

[vectra]

Y'a un exemple "arbre de noel" dans les tests unitaires de VTK qui fait grosso-modo l'étendue de ce que je veux faire (grosso surtout).
Je ne t'infligerai pas la haine que c'est de tout compiler pour y parvenir, mais je peux t'envoyer l'exécutable. Si tu as un unix pas trop vieux, avec deux ou trois paquets, ça devrait passer direct (les libs vtk, donc).

[Tramb]

Je suis en train de build le git, c'est quel test exactement ?

[vectra]

Je l'ai pas sous la main :XXX
De mémoire, MedicalTest3 ou un truc du genre. Dans MedicalImage/C++ je crois, et dans la partie Testing, il me semble.
Il faut l'ensemble des paquetages vtk (dont Data), et activer les tests unitaires dans le ccmake.

Je ne peux hélas pas vérifier ici :/
De mémoire, sur une 960 et une 1060, on pète les 200fps au moins. En gros, avec une carte pas trop manchotte, quelle qu'elle soit, ça passe crème. La seule difficulté est de trouver du neuf en baissant assez le curseur de prix, mais pas trop (une CG à 50 euros à 14Go/s de BP mémoire, il fallait oser le faire. De la DDR3, comme-même).

En tous cas, merci beaucoup
Tu as un Coffee Lake et un écran sur l'iGPU?

[Tramb]

Bon j'ai testé Medical2 et Medical3 avec headsq et ça tourne nickel (à la VBL) en 1080P sur mon iGP 3rd gen bien antérieur à ce que tu prévois.
A mon avis t'es serein pour bosser avec on Coffee Lake, et tu peux repousser l'achat d'une CG dédiée.

[Nilsou]

Essaie QtCreator, c'est gratos,

J'en ai pas mal entendu parler, notamment via un collègue qui l'utilise maintenant au jour le jour.
J'avoue que pour l'instant ça m’embête un peu que l'outil ai été conçu avant tout par Qt pour Qt... surtout vu la trajectoire de Qt... Au départ la communauté ne nourrissait qu'un doute (légitime) vis à vis du statut d'entreprise à but lucratif de la société (pour un outil qui influence beaucoup le monde du libre, c'est embêtant) et ce doute fut confirmé lors du rachat par Nokia puis de la tambouille autour de the qt company pour finir par atteindre son apogée lors de l'entrée en bourse de la chose sous le contrôle de "Digia"...

Bref, vu ses évolutions de propriétaire et l'instabilité inhérente à sa présence en bourse depuis 2016, il y a de quoi trouver la chose un poil douteuse vis à vis de sa stabilité long terme (contrairement à Eclipse, fondation à but non lucratif absolument insubmersible). Ce qui n'est pas un soucis quand je développe chez moi, mais ce qui est un problème quand je doit réfléchir au outils qui vont forger les 15 prochaines années d'enseignement et de recherche d'un laboratoire...

(C'est pour ça que je n'étais pas très content, d'ailleurs, de la direction prise par le Projet Gnome (voir topic des Linuxien), qui avait été fondé comme alternative au soucis de QT et qui tient le cap depuis bien longtemps mais qui part un peu en sucette dernièrement.)

Après en pratique QTcreator semble remplir ce que je demande... je vais quand même y jeter un coups d’œil plus approfondi.

[vectra]

> Tramb:

[Nilsou]

[Tramb]

J'en ai pas mal entendu parler, notamment via un collègue qui l'utilise maintenant au jour le jour.
J'avoue que pour l'instant ça m’embête un peu que l'outil ai été conçu avant tout par Qt pour Qt... surtout vu la trajectoire de Qt... Au départ la communauté ne nourrissait qu'un doute (légitime) vis à vis du statut d'entreprise à but lucratif de la société (pour un outil qui influence beaucoup le monde du libre, c'est embêtant) et ce doute fut confirmé lors du rachat par Nokia puis de la tambouille autour de the qt company pour finir par atteindre son apogée lors de l'entrée en bourse de la chose sous le contrôle de "Digia"...

Bref, vu ses évolutions de propriétaire et l'instabilité inhérente à sa présence en bourse depuis 2016, il y a de quoi trouver la chose un poil douteuse vis à vis de sa stabilité long terme (contrairement à Eclipse, fondation à but non lucratif absolument insubmersible). Ce qui n'est pas un soucis quand je développe chez moi, mais ce qui est un problème quand je doit réfléchir au outils qui vont forger les 15 prochaines années d'enseignement et de recherche d'un laboratoire...

(C'est pour ça que je n'étais pas très content, d'ailleurs, de la direction prise par le Projet Gnome (voir topic des Linuxien), qui avait été fondé comme alternative au soucis de QT et qui tient le cap depuis bien longtemps mais qui part un peu en sucette dernièrement.)

Après en pratique QTcreator semble remplir ce que je demande... je vais quand même y jeter un coups d’œil plus approfondi.

Certes mais c'est un IDE, pas une lib, là. Ça se remplace quand vous voulez par Emacs, Eclipse, ou NouveauTrucTropBien. Même CLion pour les militants radicaux de JetBeans.

Et à mon avis Qt a bien besoin de sa communauté gratos, s'ils révoquaient les licenses Open Source, ils seraient morts pronto.

[Nilsou]

Pas faux, nous c'est plutôt pour des histoires de tutos à faire pour les étudiants, de fichiers de projets et autres fichiers de modèle d'indentation qui sont généralement spécifique à une IDE. etc etc ...
Sur les lib, par contre, c'est évidemment bien plus handicapant, c'est certains Mais dans tout les cas on ne peut pas vraiment se permettre de suivre la vague de la hype et de sauter sur une autre tout les 6 mois.

[Tramb]

Pas faux, nous c'est plutôt pour des histoires de tutos à faire pour les étudiants, de fichiers de projets et autres fichiers de modèle d'indentation qui sont généralement spécifique à une IDE. etc etc ...
Sur les lib, par contre, c'est évidemment bien plus handicapant, c'est certains Mais dans tout les cas on ne peut pas vraiment se permettre de suivre la vague de la hype et de sauter sur une autre tout les 6 mois.

Ca me rappelle la discussion plus haut sur .NET
Du coup, Emacs ? En académique ça passe bien, les étudiants n'ont pas le choix

[ducon]

Une fois sortis, ils vous maudissent et passent à Windev.

[Tramb]

En Français. Oui môssieur.

[vectra]

Je commence à prendre un peu mes marques sur CLion, mais c'est pas encore gagné.
J'ai déjà commencé à importer ma Keymap custom en me basant sur la config Emacs déjà intégrée.

Un truc qui m'indispose, c'est la gestion des fichiers. Je veux pouvoir sauver les fichiers un à un, séparément, et ne pas sauver de fichiers quand je fais des conneries.
J'ai déjà trouvé 'Save Document' et désactivé 'Save All', mais je n'arrive pas à empêcher un 'Save All' quand je ferme l'IDE.
De plus, j'aimerais bien savoir exactement quels fichiers ont été modifiés. Sous emacs, un buffer qui diffère de l'état du fichier sur disque est clairement indiqué comme tel, et j'ai pas vu d'indication sous CLion.

Je pense que le minimum serait d'avoir un mode qui affiche les modifications par rapport au dernier commit Git. Vs.code le faisait très bien en changeant la couleur de fond par exemple...


En apparté, j'avais également mal compris la tarification de CLion: c'est 89€ pour une licence à vie. Les paiements suivants (dégressifs uniquement si ininterrompus ) ne sont utiles que pour avoir accès aux versions suivantes du logiciel, qui peuvent ne pas être indispensables (si on est sûrs de rester en C++11 par exemple).
Ca fait un peu mal au derche la première année (et également froisser les habitués du free software dont je fais partie) mais pour un dev' californien, c'est rien du tout. Et ça reste un investissement très défendable pour un pro français, dès lors qu'il a la garantie de pouvoir bosser assez longtemps en C++ (ce ne fut hélas pas mon cas).
Y'avait également la possibilité de payer au mois, mais sans licence accordée avant un an de paiements ininterrompus. Là, pour l'instant, la licence académique m'est offerte, donc je ne perds rien à essayer.

[Helix]

J'avais testé CLion mais lorsque j'utilisais la bibliothèque CImg ( un énorme .h ) l'indexation était sans fin. J'ai finalement renoncé.

[vectra]

A CImg?
C'est sympa comme lib, mais évitable.

[Tramb]

CLion, franchement bof, je trouve. Surtout vu le prix.
Ils feraient mieux de faire leurs IDE Java en C++ que de faire leur IDE C++ en Java :D