From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a02:7122:: with SMTP id n34mr11741960jac.73.1557568694652; Sat, 11 May 2019 02:58:14 -0700 (PDT) X-Received: by 2002:aca:51d5:: with SMTP id f204mr2610267oib.78.1557568694324; Sat, 11 May 2019 02:58:14 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.fr7!futter-mich.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!136no323644itk.0!news-out.google.com!v189ni346itv.0!nntp.google.com!136no323643itk.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 11 May 2019 02:58:14 -0700 (PDT) In-Reply-To: <499e6e36-e476-40b4-b1c5-603332e12a58@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=101.164.108.182; posting-account=wavAeAoAAAAZF_sXSZepBukuPCBO0Zqt NNTP-Posting-Host: 101.164.108.182 References: <50adfe1e-7bee-4048-8523-1b41bd0c9fe3@googlegroups.com> <2569c28e-ccde-4f39-87c9-8799973ecdba@googlegroups.com> <302b73dc-7b45-4b40-9fc8-328498bc264b@googlegroups.com> <42d78678-874f-478c-a627-78219830acfe@googlegroups.com> <0ae11fcc-f151-41fb-a578-af5cd53e371c@googlegroups.com> <3bb6aa53-af56-41d5-a53b-30a47009cbb6@googlegroups.com> <499e6e36-e476-40b4-b1c5-603332e12a58@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.2.0 From: alby.gamper@gmail.com Injection-Date: Sat, 11 May 2019 09:58:14 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 7225 X-Received-Body-CRC: 2851389270 Xref: reader01.eternal-september.org comp.lang.ada:56291 Date: 2019-05-11T02:58:14-07:00 List-Id: On Saturday, May 11, 2019 at 7:15:33 AM UTC+10, Greg wrote: > Quick thoughts: >=20 > a) Use Nuget to install/reference the WinRT dependencies. But this does m= ean=20 > that each UWP app has its own copy of the WinRT dependencies. Not ideal i= n my=20 > view (unless of course you are diligent and update your refences regularl= y) and definably / probably NOT workable in a very disciplined IT environme= nt.=20 >=20 > This would be massively good, one less step (actually more than one) to g= et up and running with a real Ada/UWP app. Just so I'm clear ... you mean a= separate NuGet package for each Win10 SDK version, i.e. 1803/17134? Not su= re I've seen that methodology, but I'm sure it's used. And for example, my = personal stuff is running (now) Insiders with 18362 while my work laptop is= currently suffering with 16299. >=20 > b) I am not sure that a UWP app can be distributed with a "native DLL" vi= a=20 > Windows Store (as opposed to statically linking to a LIB). If it cant, do= you see any value in keeping the "UWP DLL" template ? Note that apps that = are side loaded (ie within a corporate env and NOT distributed via the Wind= ows Store) are not under the same restriction. >=20 > At first I thought, nah, I'd dump it because for my personal use cases (r= ight now, anyway), I don't really have a use for it. I was just trying to b= reak - sorry, I mean test :) - the different templates. But in enterprise s= ituations, where you often couldn't care less about Windows Store - sure, i= t'd be very valuable. I mean, I build "common" DLLs (.NET) all the time, ea= ch used by 3-4 different apps. Absolutely. >=20 > ... personally - and quite selfishly - I'd rather see Intellisense advanc= e (which you've mentioned in your READMEs I know) , Object Explorer support= of some kind, (probably the same thing, but then again I've never added th= at sort of extension support for a language before.) You know, the whole VS= kind of stuff we've all come to expect and love (I've never been one to sa= y, "hey, I'm a REAL developer - I don't NEED Intellisense" :)) Hi Greg Sounds like Nuget and Intellisense are my next priorities (Intellisense alw= ays was, just haven't found a good solution yet) A couple of point for each Nuget: 1) It probably makes sense for the WinRT Nuget to be versioned to the MS SD= K version. WinRT is after all is COM based, and linking in 19H1 libs when and trying t= o use features of 19H1 (inadvertently) when you are running 1803 will cause probl= ems. I have already created a 1809 branch on Git (current master is 19H1). So I = can go back and create branches for 1803, 1709 .. etc if needed. Note 19362 SDK= has been released ahead of the official Windows 10 19H1 release 2) Or I could/should do version checking within the WinRt bindings themselv= es and if their is a mismatch then raise an Ada exception before calling the a= ctual Api Intellisense:=20 Their a few ways of doing this, all with pros and cons, these being 1) Extend the current use of ANTLR, which at the moment is just being used = for syntax colouring and Outlining (BraceMatching and BraceCompletion are handl= ed outside of ANTLR since the functionality does not require a full lexer/pars= er) I am not convinced the above is doable ? 2) Use the Adacore ada_language_server in conjunction with the MS supplied Nuget package "Microsoft.VisualStudio.LanguageServer.Client" (which supplie= s a default implementation of a LSP client). This is fairly easy to implement, = However the experience (thru no fault of AdaCore) I believe is not ideal. This is b= ecause I believe (as a fallback) VS adds what it thinks are valid completions based on a dictionary of words= in the current document, which pollutes intellisense. (FYI) Note that AdaCore's implementation of Ada_Language_Server is reliant = upon their LibAdaLang/LangKit GitHub projects. 3) Develop/use a Ada-COM wrapper over the functionality provided by AdaCore= 's LibAdaLang and integrate this with the VS native Intellisense interfaces. T= his may sound a bit over the top, But it does allow mapping between the LibAdaLang suppli= ed AST to that expected by VS Intellisense native interfaces. The only problem/issue with this approach is that VS extensions (Like Visua= lAda) must target win32 (Since VS is actually a 32 bit app and It cant easily acc= ess a 64 bit app,COM dll). So building a LibAdaLang 32 bit library may be problem= atic. I believe this is possible, but reliant on availability of recent GCC 32 bi= t compilers. The above points are just food for thought (so to speak) Alex NOTE: Ive got a new release 1.2.1 ready which resolves the following issue you ha= d 1)UWP DLL project - link error (libgnat-8). This is actually caused by tryi= ng to generate both a GCC lib and a MS LIB and is caused by issue with the supplied MS ada.targ= ets file 2) UWP XML application dependencies are now resolved, and will build the XML project before the project, which is what is expected. 3) If you have not already encountered issues with install/uninstall functi= onality then these are now resolved (Note it really only makes sense to install/uni= nstall library based projects??