IdentifiantMot de passe
Loading...
Mot de passe oubli� ?Je m'inscris ! (gratuit)

Vous �tes nouveau sur Developpez.com ? Cr�ez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et �tre connect� pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Cr�ez-en un en quelques instants, c'est enti�rement gratuit !

Si vous disposez d�j� d'un compte et qu'il est bien activ�, connectez-vous � l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oubli� ?
Cr�er un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Olivier Famien

380PARTAGES

4  0 
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 7e 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
Vous avez lu gratuitement 0 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer � vous proposer des publications.

Une erreur dans cette actualit� ? Signalez-nous-la !

Avatar de JolyLoic
R�dacteur/Mod�rateur https://www.developpez.com
Le 06/04/2016 � 20:40
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...
3  0 
Avatar de Aurelien.Regat-Barrel
Expert �minent s�nior https://www.developpez.com
Le 06/04/2016 � 10:29
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!).

Citation Envoy� par Olivier Famien Voir le message
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).
1  0 
Avatar de Jonyjack
Membre averti https://www.developpez.com
Le 06/04/2016 � 14:25
Citation Envoy� par Aurelien.Regat-Barrel Voir le message
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#
1  0 
Avatar de Aurelien.Regat-Barrel
Expert �minent s�nior https://www.developpez.com
Le 06/04/2016 � 14:46
Citation Envoy� par Jonyjack Voir le message
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).
1  0 
Avatar de kilroyFR
Membre �prouv� https://www.developpez.com
Le 06/04/2016 � 15:18
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.
1  0 
Avatar de Aurelien.Regat-Barrel
Expert �minent s�nior https://www.developpez.com
Le 06/04/2016 � 16:58
Citation Envoy� par kilroyFR Voir le message
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).
1  0 
Avatar de kilroyFR
Membre �prouv� https://www.developpez.com
Le 06/04/2016 � 19:04
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.
1  0 
Avatar de kilroyFR
Membre �prouv� https://www.developpez.com
Le 06/04/2016 � 22:17
Merci de tes reponses claires !

Perso je vais attendre encore quelques ann�es que ca se stabilise tout en surveillant regulierement comment ca evolue.
1  0 
Avatar de Aurelien.Regat-Barrel
Expert �minent s�nior https://www.developpez.com
Le 07/04/2016 � 18:15
Citation Envoy� par kilroyFR Voir le message
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� !

Citation Envoy� par kilroyFR Voir le message
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�.

Citation Envoy� par JolyLoic Voir le message
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...).
1  0 
Avatar de JolyLoic
R�dacteur/Mod�rateur https://www.developpez.com
Le 09/04/2016 � 13:27
Citation Envoy� par Aurelien.Regat-Barrel Voir le message

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...
Citation Envoy� par Aurelien.Regat-Barrel Voir le message

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�...
1  0