Bonjour à tous,
Ce site semble très orienté DSL mais comme on y parle aussi a priori de VSX en général...
Je suis actuellement en cours de démarrage d'un projet VS Shell 2008 afin de fournir un IDE à un langage très spécifique que nous venons de développer. J'ai examiné les différentes manières de développer des "language services" et je tombe sur un problème majeur: les sources de ce langage sont nécessairement écrites en Unicode. La méthode "Babel Managé" est donc exclue car l'outil MPLEX ne supporte pas Unicode (info bien cachée tout en bas de la documentation PDF et absente de la doc du SDK). Restent Babel natif et MPF sans Babel. J'ai déjà commenté à ce sujet auprès de Craig Skibo et James Lau:
Thanks Craig and Hi James,
So I have additional questions...
Since the managed version of Babel (i.e. MPLEX) doesn't support Unicode, it seems that I have now the choice between two strategies:
1. Using the non-managed version of Babel
I can't use the recommended versions of Bison and Flex because they don't support Unicode either. Ditto for the official versions of Lex and Yacc. However, I have a Lex/Yacc compatible tool that supports Unicode and that is able to generate C++ code. This is the tool I used to generate a .Net version of the parser for our custom language. It was initially targeting Java but we ported it to J# without any problem.
This could be the way to go but I'm reluctant to implement a non-managed solution. Future versions of Visual Studio are supposed to be re-written in managed code - is this correct? - so what about support in these future versions for extensions written in native code? I need to be sure that I will not have to rework the whole project.
Another issue is that the documentation doesn't tell a lot about the structure of the generated custom parser and lexer. Quoting the doc:
The tools used to compile a lexer and a parser must generate C++ code, and they must be executable from the command line.
That is not much :-) . There's no detailed information about what Babel does when invoking the parser and the lexer and about what it is expecting regarding the program interface.
PS: Ironically enough, the VSTextBuffer object in VS supports Unicode only. So one would expect that the tools for producing language services would also "naturally" support Unicode :-) .
2. Using the MPF only and providing a ready-made parser
This should obviously work since this approach gives control on the whole production chain. But this is the less productive solution since I'll have to take charge of everything [NB: Nous avons déjà un parseur et un interpréteur fonctionnels pour le langage - mais seront-ils adaptés pour le projet VS Shell?].
However, I'm a bit bothered when reading this (Managed-Code Language Services with the MPF | Managed Language Service Overview):
The Visual Studio SDK Managed Language Services relies on Bison and Flex, two open-source tools for parsing and scanning that are available freely on the Internet.
Since Bison and Flex do not support Unicode, this could be a show stopper. However, when reading " The Language Service Parser and Scanner" section, I can find the following statement:
How you implement a scanner and parser for your language service is entirely up to you.
And actually, the documentation gives a description of the interfaces that must be supported by the lexer and the parser. So I guess that the above statements about Bison and Flex are totally irrelevant? I don't understand.
----
For both solutions, one thing has struck me, though. Beside the description of the VS text buffer, the word Unicode never appears in the VS SDK documentation. After all, we are now working with a technology that understands Unicode text only. When I started to explore the SDK in order to chose a solution for this Visual Studio Shell project, I didn't even imagine that I would have problems because my source code is Unicode. I realized this only when reaching the bottom of the MPLEX.PDF file (which is pretty well hidden, by the way :-) ).
So if you could give me clear directions about how to implement language services for a language whose source code is Unicode, I would really appreciate it.
Aucune réponse à ce jour. Est-ce que quelqu'un a été confronté à ce problème? Quelle solution avez-vous choisie? Je serai présent à la journée VSX du 16 et j'espère rencontrer quelqu'un avec qui je puisse discuter de la question afin de choisir la bonne solution.
Cordialement.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
PS: La page "composition de messages" de Community Server sur ce site ne fonctionne pas bien (icônes manquantes, toolbar incomplète, fonctions inactives... J'utilise aussi CS (2.1) et je n'ai pas ces problèmes).