Discussion :

[MikeRowSoft]

Tiens tiens Update 1!?
Microsoft aurait-il réservé le service pack pour du support technique terminé?

[The_badger_man]

Tiens tiens Update 1!?
Microsoft aurait-il réservé le service pack pour du support technique terminé?

Les services pack (correction de bugs) n'existent plus depuis Visual Studio 2010.

Depuis Visual Studio 2012, il s'agit de mises à jour fonctionnelles.

[MikeRowSoft]

Les services pack (correction de bugs) n'existent plus depuis Visual Studio 2010.

Depuis Visual Studio 2012, il s'agit de mises à jour fonctionnelles.

Se qui veut dire mise à jour perpétuelle (upgrade incluse) comme Ubuntu Linux?
Les services packs se rapprochant plus des ISO de mise à jours de Debian Linux (sans upgrade il me semble)...

En tous cas, merci, se "n'est pas tombé dans les oreilles d'un sourd".

[Les voitures pour aveugles sont unes réalités]

[Olivier Famien]

Microsoft annonce la disponibilité de la préversion des outils R sur Visual Studio
ainsi que la sortie des outils Apache Cordova Update 7

En janvier 2015, Microsoft a annoncé l’acquisition de Revolution Analytcs, l’entreprise axée sur le développement de solutions open source basées sur les versions libres et open source des logiciels R.

Après avoir ajouté cette entreprise à la liste des entreprises acquises, le géant du système d’exploitation a entamé sa refonte en rebaptisant les outils Revolution R Open en Microsoft R Open et Revolution R Enterprise pour Hadoop, Linux et Teradata a été renommé en Microsoft R Serveur. Microsoft R Server Developer Edition est une version gratuite proposée aux développeurs avec des fonctionnalités semblables à la version commerciale.

Lors de l’annonce du renommage de Revolution R Open, Joseph Sirosh, vice-président du groupe Microsoft Data, avait déclaré que « Microsoft R Server sera inclus dans SQL Server 2016 comme étant SQL Server R Services ». En attendant la version finale de SQL Server 2016, Microsoft vient de donner une information qui ne fera que ravir les utilisateurs de Visual Studio, l’environnement de développement intégré (EDI) de Microsoft.

« Je suis ravi d’annoncer que Visual Studio parle maintenant une autre langue : R », a déclaré Shahrokh Mortazavi sur le billet de blog de la firme. R est un langage utilisé dans le domaine de l’analyse des données scientifiques et pour la représentation graphique de celles-ci. Les professionnels utilisant ce langage de programmation peuvent dorénavant utiliser les outils R en combinaison avec Visual Studio pour traiter et analyser leurs données. Pour cela, il suffit d’installer Visual Studio et ensuite ajouter les outils R à l’environnement de développement.

Ces outils qui sont disponibles en préversion prennent en charge avec les éléments suivants dans l’EDI :

• possibilité d’éditer les scripts R y compris les fenêtres et onglets détachables, la coloration syntaxique et bien plus encore ;
• le code R est pris en charge par Intellisense afin de faire des appels de méthode et propriétés et compléter le code de manière suggestive ;
• l’explorateur de variables prend également en charge les structures de données et examine aussi leurs valeurs ;
• tout comme avec les autres langages, il est possible de déboguer le code R en ajoutant des points d’arrêt, des piles d’appels, etc. ;
• plusieurs extensions couvrant différents aspects du langage R sont utilisables avec l’EDI ;
• les utilisateurs du langage R peuvent également utiliser la fenêtre de l’historique pour parcourir, afficher, sélectionner les commandes antérieurement exécutées ;
• la fenêtre interactive R fonctionne avec la console R directement dans Visual Studio. Les utilisateurs peuvent donc effectuer des boucles, évaluer, lire le code R directement dans la fenêtre ;
• il est possible d’installer les packages Markdown/knitr afin d’afficher les données en aperçu au format Word ou HTML et les exporter dans les mêmes formats ;
• les outils R pour Visual Studio supportent les packages des dépôts CRAN.

En plus de ces nouvelles fonctionnalités compatibles avec R, il faut également souligner qu’il est possible d'utiliser Visual Studio avec les packages disponibles sur les dépôts CRAN ou encore avec Microsoft R Open afin de disposer de certaines fonctionnalités telles que le support du traitement des processus sur des machines multiprocesseurs.

Enfin, les outils R pour Visual Studio sont également compatibles avec Microsoft R Server et les SDK R qui permettent d’accéder aux données et espaces de travail et également sont utilisés pour publier des modèles sur Azure Machine Learning.

En marge de l’annonce portant sur les outils R pour Visual Studio, Microsoft a également annoncé la disponibilité de la 7^e mise à jour des outils Visual Studio pour Apache Cordova (TACO). Dans cette nouvelle mise à jour de TACO, la version 6.0.0 de Cordova est utilisée comme version par défaut.

Nous rappelons que Cordova est un framework open source permettant de créer des applications pour différentes plateformes (Android, Firefox OS, iOS, Ubuntu, Windows 8, etc.) en HTML, CSS et JavaScript.

Par ailleurs, il est maintenant possible de créer de nouveaux projets iconic pour des templates vierges, des templates pour onglets ou pour menus latéraux. À noter que plusieurs correctifs ont été introduits dans les outils Visual Studio pour Apache Cordova Update 7.

R Tools pour Visual Studio sur GitHub

Source : Blog plateforme de données (les outils R pour Visual Studio), Blog Visual Studio (les outils VS pour Apache Cordova Update 7)

Et vous ?

Avez-vous testé les outils R sur Visual Studio ? Êtes-vous satisfaits de cette implémentation ?

Que pensez-vous de la nouvelle mise à jour relative aux outils VS pour Apache Cordova ? Quels sont les éléments que vous souhaiteriez voir dans les prochaines versions ?

Voir aussi

Forum Visual Studio

[Olivier Famien]

Visual Studio 2015 Update 2 est disponible
l’EDI permet de générer des builds avec Gradle et offre la possibilité d’importer des projets Xcode

Depuis quelques jours, Visual Studio Update 2 est disponible. Dans cette nouvelle mise à jour, l’accent a été mis sur la stabilité, les performances et la fluidité des outils. De prime abord, l’on note que TACO, les outils pour Apache Cordova ont été améliorés.

Dans la version antérieure de TACO intégrée à Visual Studio, l’on rencontrait parfois des conflits avec NodeJS. Pour régler le problème, NodeJS a été intégré dans un bac à sable afin de séparer les processus avec les autres outils de l’EDI. Cela permet d’éviter des mauvaises surprises lors du développement des applications avec la plateforme NodeJS. Il faut rappeler que dans la version 7 de TACO, le gestionnaire de package Node a eu droit au même traitement.

En ce qui concerne les outils traditionnels de Visual Studio, l’on note que C++ a connu plusieurs améliorations. Au niveau du compilateur, Microsoft explique que les coroutines qui sont encore en phase expérimentale peuvent être utilisées en production maintenant. Nous rappelons que les coroutines sont similaires aux routines, mais se démarquent de ces dernières en ce sens qu’elles offrent la possibilité de suspendre et reprendre explicitement leur exécution en utilisant des opérations supplémentaires, alors que les routines s’achèvent généralement lorsque les processus parents prennent fin.

Toujours pour ce même langage, l’équipe de C++ a intégré dans cette version de Visual Studio Update 2 les fonctionnalités des bibliothèques qui ont été votées dans C++ 11, C++ 14 et C++ 17. Par ailleurs, la fonction de débogage ucrtbased.dll a été retirée de la version 14 SDK Microsoft.VCLibs. La firme explique avoir agi ainsi afin que les applications ne soient pas liées à une version spécifique du SDK pour Windows 10.

Toutefois, lorsque vous construirez vos applications, Visual Studio/MSBuild insèrera automatiquement ucrtbased.dll dans l’application Windows conçue. Mais pour les systèmes incompatibles à MS Build, il va falloir intégrer manuellement ucrtbased.dll au fichier de l’application locale. Enfin, pour ce qui est de l’EDI pour C++, Microsoft affirme que le moteur de base de données basé sur SQLite est maintenant utilisé par défaut.

Un clin d’œil a été également fait aux projets Android et iOS. Les développeurs C++ peuvent importer dans Visual Studio des projets Xcode et ceux qui le souhaitent peuvent générer des builds avec Gradle, l’outil privilégié des développeurs Android pour compiler des applications.

En marge des améliorations au niveau de C++, plusieurs perfectionnements ont été apportés aux fonctionnalités C# et Visual Basic. Il est maintenant possible d’initialiser la fenêtre interactive C# pour un projet afin de permettre un accès instantané aux types du projet. De même, vous pouvez envoyer des paramètres à la fenêtre interactive afin de tester une partie de votre code. Pour ce faire, vous devez utiliser la nouvelle commande « Execute In Interactive ».

En plus de ces ajouts, il faut noter que le framework .Net 4.6.1 utilisé pour développer les applications Windows Forms et WPF a accueilli le nouvel outil ClickOnce Bootstrapper. C’est un package qui permet de déployer facilement les applications développées avec le framework .Net 4.6.

L’extension de Nuget, le gestionnaire de package pour Visual Studio, a été améliorée avec la prise en charge des actions pour générer des builds pour Android et iOS ainsi que la possibilité d’exécuter ce gestionnaire de package dans les environnements Linux et Apple.

Parler de Visual Studio 2015 sans aborder principalement la plateforme Windows universelle laisserait un gout d’inachevé dans cette nouvelle version. En effet, dans cette nouvelle mise à jour, de nouveaux outils ont vu le jour. Ce sont Universal Windows SDK Version Picker pour sélectionner la version du SDK Windows ciblée avec la version minimum du système sur lequel vos applications fonctionneront, un débogueur des processus de tâches en arrière-plan dans les applications Windows universelles et des améliorations des outils de gestion des packages sur le store des applications Windows en sorte que lorsque des applications ont été associées au magasin en ligne, vous n’ayez plus à signer à nouveau pour créer un package pour une application sur le store.

À côté de ces éléments, plusieurs autres éléments tels que les correctifs de bogues, de nouvelles fonctionnalités et l’amélioration des performances de certains outils ont été implémentés

Source : Visual Studio News

Et vous ?

Avez-vous testé cette nouvelle version de Visual Studio ? Comment la trouvez-vous ?

Quelles sont les fonctionnalités que vous aimez le plus ou le moins ?

Voir aussi

Forum Visual Studio

[Aurelien.Regat-Barrel]

Bonjour,

Une autre nouveauté importante de l'Update 2 pour C++ concerne les modules (création de "packages" en C++ au lieu des classiques fichiers headers). Des améliorations importantes ont été faites pour les rendre utilisables (c'est ce qu'ils disent, moi j'ai pas pu tester encore!).

Nous rappelons que les coroutines sont similaires aux routines, mais se démarquent de ces dernières en ce sens qu’elles offrent la possibilité de suspendre et reprendre explicitement leur exécution en utilisant des opérations supplémentaires, alors que les routines s’achèvent généralement lorsque les processus parents prennent fin.

Je n'ai pas trouvé ce passage très clair, aussi je partage ma propre explication Une coroutine c'est une fonction qui peut être interrompue dans son exécution qu'elle reprendra là où elle l'avait laissé à son prochain appel. Une fonction classique termine son exécution lors d'un appel à "return". Dans le cas d'une coroutine, si elle return, alors oui c'est fini. Mais elle peut aussi rendre la main à l'appelant en plein milieu de son exécution, pour reprendre ensuite (lors de son prochain appel) là où elle s'était arrêté (au lieu de tout recommencer au début). La coroutine est en quelque sorte au thread ce que le thread est au processus.

L'intérêt concerne la programmation asynchrone. Au lieu de découper la logique du code en deux parties (par exemple : lecture des données sur une socket, puis traitement des données reçues), on simule une exécution synchrone classique. Sauf que au lieu de rester bloqué sur un opération d'E/S (lecture de la socket), on rend la main à l'appelant qui peut faire autre chose pendant ce temps. Ca évite de créer des threads à tout bout de champ (l'idée est d'avoir des milliers de coroutines) ou d'avoir un code asynchrone difficile à lire (éclaté en plein de callbacks).

[Jonyjack]

Je n'ai pas trouvé ce passage très clair, aussi je partage ma propre explication Une coroutine c'est une fonction qui peut être interrompue dans son exécution qu'elle reprendra là où elle l'avait laissé à son prochain appel. Une fonction classique termine son exécution lors d'un appel à "return". Dans le cas d'une coroutine, si elle return, alors oui c'est fini. Mais elle peut aussi rendre la main à l'appelant en plein milieu de son exécution, pour reprendre ensuite (lors de son prochain appel) là où elle s'était arrêté (au lieu de tout recommencer au début). La coroutine est en quelque sorte au thread ce que le thread est au processus.

Merci c'est plus clair en effet ! Ca me fait penser au "yield" de C#

[Aurelien.Regat-Barrel]

Merci c'est plus clair en effet ! Ca me fait penser au "yield" de C#

Et pour cause, c'est exactement ça ! Sauf qu'en C++ les mots-clés retenus sont finalement co_await, co_return et co_yield (afin d'éviter d'entrer en collision avec ces symboles dans du code existant).

[kilroyFR]

J'avoue que concernant les MODULES en C++ je n'ai pas bien compris la reelle utilité par rapport a un .h/.lib habituel...

faire
IMPORT myModule;
ou
#include <myModule.h>

Je suis preneur de toute explication qui me donnerait une vision sur le reel benefice de ce qui s'apparente plus a une nouvelle syntaxe (inutile ?) qu'autre chose.

[Aurelien.Regat-Barrel]

J'avoue que concernant les MODULES en C++ je n'ai pas bien compris la reelle utilité par rapport a un .h/.lib habituel...

faire
IMPORT myModule;
ou
#include <myModule.h>

Je suis preneur de toute explication qui me donnerait une vision sur le reel benefice de ce qui s'apparente plus a une nouvelle syntaxe (inutile ?) qu'autre chose.

Le premier intérêt est au niveau du temps de compilation : ton header est parsé une seule fois lorsque tu build ton projet au lieu de l'être à chaque inclusion (utilisation d'un fichier pré-parsé binaire à la place, un peu comme un PCH).

Il y a d'autres intérêts, présentés dans le papier de Microsoft (lire l'intro):

1. componentization;
2. isolation from macros;
3. scalable build;
4. support for modern semantics-aware developer tools.
5. Furthermore, the proposal reduces opportunities for violations of the One Definition Rule (ODR), and increases practical type-safe linking. An implementation of these suggestions is ongoing in the Microsoft C++ compiler.

et aussi du côté de clang:
http://clang.llvm.org/docs/Modules.h...-current-model

Une autre façon d'aborder le sujet est qu'un langage moderne ne peut pas reposer sur un mécanisme aussi primaire que l'inclusion textuelle (qui déstabilise beaucoup de débutants).

[kilroyFR]

ouep je suis pas vraiment convaincu - c'est compliqué pour un debutant de comprendre les inclusions de .h ?
Ca me fait penser a ceux qui ne veulent pas faire du SQL parce que c'est jugé trop compliqué mais par contre utilisent des BDD noSql type MongoDb avec des syntaxes barbares completement illisibles, non normées etc.

Pour l'optimisation des temps de compil il y a les entetes pre-compilées. Visiblement quelque chose qui va en plus encore bouger

1. componentization = comme une librairie donc ? (librairie ca fait pas moderne certainement)
2. isolation from macros = en quoi les macros posent pb en debut de fichier - ca permet d'eviter de traiter N fois le meme fichier d'entete au contraire !
3. scalable build => entetes precompilées ca sert a ca pourtant
4. support for modern semantics-aware developer tools => là on est plutot dans des "concepts" qui me paraissent tres abstraits
Furthermore, the proposal reduces opportunities for violations of the One Definition Rule (ODR), and increases practical type-safe linking => idem 4

"qu'un langage moderne ne peut pas reposer sur un mécanisme aussi primaire que l'inclusion textuelle (qui déstabilise beaucoup de débutants)."
=> alors pour ne pas comprendre les principes d'inclusion textuelles on invente autre chose encore plus illisible.
J'ai l'impression qu'il aurait ete utile de rapprocher le C++ des autres langages "modernes" L4G style C#, Java (ajouter les proprietés etc.)

J'ai plus l'impression qu'ils ont essayé de placer les mots clés a la mode du moment 'scalable', 'isolation', 'component', 'modern' ...qu'un reel gain de productivité ou d'architecture logiciel.
Par ailleurs dans le document : http://clang.llvm.org/docs/Modules.h...-current-model
il y a plus de problemes non resolus que de REELS problemes resolus (pas de gestion de namespace donc conflits potentiels, pas de versioning, description des fonctions non lisibles dans les fichiers binaires de 'package').
Autant faire des nugets de librairies + entetes precompilées et on a tous les avantages sans les inconvenients.


Merci pour le lien vers site microsoft je vais quand meme le relire dans les details.

[JolyLoic]

Le problèmes des PCH, c'est qu'ils ne sont pas composables. Tu ne peux pas dire je prend le PCH lié à la lib A, et celui de la lib B, et je les fait tourner ensemble. Tu es obligé de faire un PCH spécifique qui ne marche que quand tu utilises A puis B.

Donc les PCH sont spécifiques à chaque projet, et doivent être générés dans chaque cas. Et se pose la question de savoir ce qu'on met dedans, et ce qu'on garde sous forme de #include en dehors du PCH. Si on n'en met pas assez, on est trop lent, si on en met trop, à chaque compilation incrémentale, on va devoir re-générer l'ensemble du PCH et perdre du temps.

On peut voir les modules comme des PCH mais qui sont composables, et où tu aurais un PCH par header (ou groupe de headers étroitement liés). Tu as généré le code précompilé pour A, celui pour B, tu peux les utiliser séparément ou ensemble, dans l'ordre que tu veux. Du coup, quand tu livres ta bibliothèque, tu livres le précompilé avec qui peut directement être réutilisé. Jamais tu n'auras besoin de le code client de parser les headers de cette bibliothèque. Pourquoi peut-on faire ça avec les modules, mais pas avec les PCH ? Voir ma réponse à la seconde question.

isolation from macros = en quoi les macros posent pb ?

Ce sont elles qui empêchent toute composabilité. Quand tu inclues un .h dans ton code, la manière de l'interpréter dépend de l'ensemble des macros définies au moment où tu l'inclues. Qui n'a jamais eu sous windows un problème pour inclure un header d'une bibliothèque third party après un #include <windows.h> parce ce dernier définit une macro min... L'idée de base est qu'un module ne dépende pas des macros définies avant qu'il soit importé, et qu'en retour, il ne pollue pas l'environnement avec ses propres macros. Et là, la modularité commence à apparaître.
Je dis "l'idée de base" parce que certains aimeraient bien pouvoir dire que sélectivement, telle ou telle macro définie dans un module pourrait être visible de l'extérieur. C'est en discussion.

il y a plus de problemes non resolus que de REELS problemes resolus (pas de gestion de namespace donc conflits potentiels, pas de versioning, description des fonctions non lisibles dans les fichiers binaires de 'package').

Je ne pense pas qu'il s'agisse forcément de réels problèmes, mais d'une simple description de ce que les modules ne sont pas, pour éviter les confusions :

Namespaces : Certains langages (Java par exemple) lient structure physique du code (modules, fichiers source) et structure logique (namespaces, classes). D'autres ne le font pas (C# par exemple). La proposition de module pour le C++ choisi de ne pas le faire. Ce n'est en rien une limitation, mais un choix qui fait sens en C++ (sinon, comment ajouter une spécialisation de std::hash ?).
Versionning : On a déjà tous des outils pour gérer les versions, tu as parlé de nuget par exemple, je ne vois pas trop quel rôle les modules pourraient jouer là dedans, à part éventuellement en terme de réflexion, qui peut toujours s'ajouter.
Binary distribution : C'est un problème potentiel. Mais d'un autre côté, les autres langages ont bien réussi à résoudre ce problème. Quand on distribue une assembly .NET, c'est bien un binaire qu'on distribue, et ça fait déjà 15 ans que ça dure sans problèmes. Ce qui va être plus dur est d'avoir un format compatible entre différents vendeurs (Microsoft a proposé d'open-sourcer le sien, Clang a dit qu'il était hors de question qu'ils l'utilisent). Mais la situation ne sera pas pire que ce qu'elle est aujourd'hui : On risque de devoir quand même compiler une bibliothèque pour le compilo qu'on utilise, comme on le fait aujourd'hui. C'est juste qu'on risque aussi de ne pas avoir besoin de le faire, si le mainteneur de la bibliothèque nous fourni un module compilé pour notre compilateur, chose qui était très difficile avant, à cause des multiplicités de gestions de macros. Donc la situation ne devient pas parfaite, mais elle s'améliore quand même.

Et sinon, pour avoir expliqué à pas mal de débutants, oui, les #include, c'est compliqué. Et parfois même des professionnels aguerris galèrent pendant des heures pour faire un #include dans certains contextes...

[kilroyFR]

Merci de tes reponses claires !

Perso je vais attendre encore quelques années que ca se stabilise tout en surveillant regulierement comment ca evolue.

[Aurelien.Regat-Barrel]

ouep je suis pas vraiment convaincu - c'est compliqué pour un debutant de comprendre les inclusions de .h ?

Il faut croire que oui. Le débutant en C++ n'est pas forcément un débutant en programmation. Il semble - d'après les retours que j'ai eu et que Loïc semble confirmer aussi - que ce système est complètement incompréhensible pour les développeur C#/Java par exemple. L'autre impact négatif du préprocesseur c'est qu'au niveau des outils basés sur le parsing de code, il contribue à rendre les choses encore plus complexes à faire correctement. Cela expliquerait en partie les lacunes de C++ à ce niveau.

La remarque sur l'ODR n'est malheureusement pas un "concept très abstrait", mais une réalité douloureuse. Sous VC++ par exemple, il est facile (moins qu'avant grâce à quelques précautions prises par MS) d'avoir des problèmes avec la STL si tu désactives les checked iterators sur certains projets et pas d'autres via un define (indirect) différent de _ITERATOR_DEBUG_LEVEL. Et la conséquence, ce sont des crashs incompréhensibles à l'exécution... C'est très complexe à identifier même pour un développeur confirmé !

Autant faire des nugets de librairies + entetes precompilées et on a tous les avantages sans les inconvenients.

Note que les PCH (VC++ en tous cas) ne peuvent pas être livrés car ils sont spécifiques à la machine de build (et même à la version mineure du compilo).

Mais ce n'est pas le sujet : il n'est en effet pas question de générer des modules qui soit livrables / redistribuables sous forme binaire. Le but est d'amorcer le mouvement vers un meilleur système. Le système actuel fonctionne on est d'accord, mais montre vite ses limites sur des gros projets. Les PCH ont été rapidement inventés pour améliorer les choses, mais il s'agit plus d'un hack que d'une vraie solution (Loïc l'a très bien exposé). Donc si tu veux, on peut voir cette proposition comme la normalisation d'un meilleur système de PCH Encore une fois, cela intervient juste lors de la compilation. On ne redistribue pas le fichier IFC généré.

Ce qui va être plus dur est d'avoir un format compatible entre différents vendeurs (Microsoft a proposé d'open-sourcer le sien, Clang a dit qu'il était hors de question qu'ils l'utilisent)

Ce qui pousse Microsoft à documenter son format c'est aussi de ne pas se faire taxer de solution fermée / propriétaire. Ce que clang (Google en fait) craint, c'est que l'approche MS s'impose par rapport à la leur. Car in fine c'est un peu les besoins de Microsoft vs les besoins de Google cette histoire (Google fait beaucoup de distribution de compilation...).

[JolyLoic]

Mais ce n'est pas le sujet : il n'est en effet pas question de générer des modules qui soit livrables / redistribuables sous forme binaire. Le but est d'amorcer le mouvement vers un meilleur système.

Sur ce point, je suis loin d'être convaincu. Je pense que les gens qui livrent déjà leurs bibliothèques sous forme binaire vont regarder ça de près...

Ce qui pousse Microsoft à documenter son format c'est aussi de ne pas se faire taxer de solution fermée / propriétaire. Ce que clang (Google en fait) craint, c'est que l'approche MS s'impose par rapport à la leur. Car in fine c'est un peu les besoins de Microsoft vs les besoins de Google cette histoire (Google fait beaucoup de distribution de compilation...).

Ce que je voudrais éviter, c'est que ça se fasse au détriment des utilisateurs et des outils autour du C++, surtout si le point précédent devient avéré...

[Aurelien.Regat-Barrel]

Sur ce point, je suis loin d'être convaincu. Je pense que les gens qui livrent déjà leurs bibliothèques sous forme binaire vont regarder ça de près...

C'est clair. Moi le premier je compte évaluer la possibilité de packager le fichier .ifc avec sa dll.

Après, officiellement, c'est pas la position défendue par Microsoft (GDR). Malgré tout ça reste un point qui irrite du monde. Google comme tu l'as dit. Mais y'a le mec de SONY qui, je sais pas pourquoi, était furax à l'idée que les utilisateurs puissent tripatouiller le format ifc de MS.

C'est un peu dommage, car sur le papier, c'est prometteur ce format. C'est - si j'ai bien compris - le fruit de beaucoup d'années de travail de la part de GDR, bien avant qu'il soit chez MS (format binaire de représentation d'un AST C++).