GNAT Pro for .NET

GNAT Pro for .NET

[george.priv]

Wonder if anyone has any experience with Ada .NET?  How well it is
integrated and what are the major issues you had with it?

Re: GNAT Pro for .NET

[Rob Veenker]

You may want to check out the MGNAT project at 
http://sourceforge.net/projects/asharp 

The GNAT Pro for .Net compiler used this project as a starting point. 

The compiler is kept in sync with the latest GNAT Pro compiler technology but there are limitations when it comes to code generation (due to .Net runtime). Also note that not all annexes are implemented.

You need to be aware of the way the Ada symbols (variables, procedures, functions etc.) are expressed in MSIL if you want to create Ada assemblies that will be used by other .Net languages. Using a .Net reflection tool or the object browser can be of great help.

Integration in the MS Visual Studio is great for debugging a mixed language application, but for my Ada programming I still use GPS :-)

Regards,
Rob Veenker

george.priv@gmail.com wrote:

> Wonder if anyone has any experience with Ada .NET?  How well it is
> integrated and what are the major issues you had with it?

Re: GNAT Pro for .NET

[george.priv]

On Nov 23, 11:36 am, Rob Veenker <veen...@xs4all.nl> wrote:
> You may want to check out the MGNAT project athttp://sourceforge.net/projects/asharp
>
> The GNAT Pro for .Net compiler used this project as a starting point.
>
> The compiler is kept in sync with the latest GNAT Pro compiler technology but there are limitations when it comes to code generation (due to .Net runtime). Also note that not all annexes are implemented.
>
> You need to be aware of the way the Ada symbols (variables, procedures, functions etc.) are expressed in MSIL if you want to create Ada assemblies that will be used by other .Net languages. Using a .Net reflection tool or the object browser can be of great help.
>
> Integration in the MS Visual Studio is great for debugging a mixed language application, but for my Ada programming I still use GPS :-)
>
> Regards,
> Rob Veenker
>
> george.p...@gmail.com wrote:
> > Wonder if anyone has any experience with Ada .NET?  How well it is
> > integrated and what are the major issues you had with it?
>
>

Thanks, Rob.  I've tried that, but there are some strange things in
the way Ada objects behave and with lack of documentation it's hard to
figure out.  In particular:
- Is it possible to mix native code from Ada with MSIL (like we do C++/
C# mix)?
- I was unable to get Initialize/Finalize being called for
Ada.Finalization.Controlled objects (given that destruction of objects
in .NET are non-deterministic, but still).
- Compiler won't let me implement IDisposable interface, am I looking
at right place (MSSyst.IDisposable)?

Thanks,

George Privalov.

Re: GNAT Pro for .NET

[Rob Veenker]

george.priv@gmail.com wrote:

> On Nov 23, 11:36 am, Rob Veenker <veen...@xs4all.nl> wrote:
>> You may want to check out the MGNAT project
>> athttp://sourceforge.net/projects/asharp
>>
>> The GNAT Pro for .Net compiler used this project as a starting point.
>>
>> The compiler is kept in sync with the latest GNAT Pro compiler technology
>> but there are limitations when it comes to code generation (due to .Net
>> runtime). Also note that not all annexes are implemented.
>>
>> You need to be aware of the way the Ada symbols (variables, procedures,
>> functions etc.) are expressed in MSIL if you want to create Ada
>> assemblies that will be used by other .Net languages. Using a .Net
>> reflection tool or the object browser can be of great help.
>>
>> Integration in the MS Visual Studio is great for debugging a mixed
>> language application, but for my Ada programming I still use GPS :-)
>>
>> Regards,
>> Rob Veenker
>>
>> george.p...@gmail.com wrote:
>> > Wonder if anyone has any experience with Ada .NET?  How well it is
>> > integrated and what are the major issues you had with it?
>>
>>
> 
> Thanks, Rob.  I've tried that, but there are some strange things in
> the way Ada objects behave and with lack of documentation it's hard to
> figure out.  In particular:
> - Is it possible to mix native code from Ada with MSIL (like we do C++/
> C# mix)?

I have not tested the integration in passing Ada objects but there is a way of extending MSIL classes using Ada. I believe there is even a tutorial on this.
To be able to call 'native' Ada code I still rely on the MS COM+ interface using GNATCOM and wrap this native COM object using interop services :-)
But you can also use pragma import / export ! 

> - I was unable to get Initialize/Finalize being called for
> Ada.Finalization.Controlled objects (given that destruction of objects
> in .NET are non-deterministic, but still).
> - Compiler won't let me implement IDisposable interface, am I looking
> at right place (MSSyst.IDisposable)?

Have a look at the extend_dotnet_class tutorial. Here the MSSyst.IDisposible is indeed used as well. But the object is created outside of Ada.
Which version of Ada for .Net are you using? There should be something on this subject in the documentation as well.

> 
> Thanks,
> 
> George Privalov.

Regards,
Rob Veenker

Re: GNAT Pro for .NET

[george.priv]

Thanks for the info.

On Nov 24, 6:07 pm, Rob Veenker <veen...@xs4all.nl> wrote:
>
> I have not tested the integration in passing Ada objects but there is a way of extending MSIL classes using Ada. I believe there is even a tutorial on this.

Is these available online somewhere?

> To be able to call 'native' Ada code I still rely on the MS COM+ interface using GNATCOM and wrap this native COM object using interop services :-)
> But you can also use pragma import / export !
>

>
> Have a look at the extend_dotnet_class tutorial. Here the MSSyst.IDisposible is indeed used as well. But the object is created outside of Ada.
> Which version of Ada for .Net are you using? There should be something on this subject in the documentation as well.


Microsoft Visual C++ 2005   77626-009-0000007-41878
Microsoft Visual C++ 2005

Microsoft Visual Studio 2005 Tools for Applications
77626-009-0000007-41878
Microsoft Visual Studio 2005 Tools for Applications

Ada for .NET (A#)   Version 1.0.1000.1000
This incorporates the A# compiler (asharp.martincarlisle.com) into
Visual Studio 2005.



>
>
>
> > Thanks,
>
> > George Privalov.
>
> Regards,
> Rob Veenker

Re: GNAT Pro for .NET

[Rob Veenker]

george.priv@gmail.com wrote:

> Thanks for the info.
> 
> On Nov 24, 6:07 pm, Rob Veenker <veen...@xs4all.nl> wrote:
>>
>> I have not tested the integration in passing Ada objects but there is a
>> way of extending MSIL classes using Ada. I believe there is even a
>> tutorial on this.
> 
> Is these available online somewhere?

Not that I know of. I remember that there were some by Dr. Carlisle used in his SigAda tutorials and early mgnat distributions but since AdaCore implemented Ada for .Net towards the Ada 2005 standard, these samples no longer work (they used 'with type' instead of the new 'limited with')
I have now tried to convert the old 'extend .net class' sample to the GNAT GPL version and managed to get it working for .Net compact framework.
In the full .Net framework the compiler complains that declaring the new type is not allowed : 'stand-alone object of Java-convention tagged type not allowed'
If this is also true for the GNAT Pro version I will submit a bugreport :-)

> 
>> To be able to call 'native' Ada code I still rely on the MS COM+
>> interface using GNATCOM and wrap this native COM object using interop
>> services :-) But you can also use pragma import / export !
>>
> 
>>
>> Have a look at the extend_dotnet_class tutorial. Here the
>> MSSyst.IDisposible is indeed used as well. But the object is created
>> outside of Ada. Which version of Ada for .Net are you using? There should
>> be something on this subject in the documentation as well.
> 
> 
> Microsoft Visual C++ 2005   77626-009-0000007-41878
> Microsoft Visual C++ 2005
> 
> Microsoft Visual Studio 2005 Tools for Applications
> 77626-009-0000007-41878
> Microsoft Visual Studio 2005 Tools for Applications
> 
> Ada for .NET (A#)   Version 1.0.1000.1000
> This incorporates the A# compiler (asharp.martincarlisle.com) into
> Visual Studio 2005.
> 

Ok, the compiler from sourceforge is a good place to start. I used it for our projects too but we needed to have a commercial support so that's why AdaCore has now developed the GNAT Pro version.
I'm not sure if Dr. Martin Carlisle is still working on the sourceforge version. It has been untouched for quite some time now.

The GPL 2008 version on the libre site (libre.adacore.com) is also a good option. There were some issues with the integration in the MS Visual Studio but I have posted a fix for this in a previous thread.

This compiler also has some examples that demonstrate mixed language and .Net class extension usage.

>>
>>
>> > Thanks,
>>
>> > George Privalov.


Regards,
Rob Veenker

Re: GNAT Pro for .NET

[Brad Moore]

george.priv@gmail.com wrote:
> Wonder if anyone has any experience with Ada .NET?  How well it is
> integrated and what are the major issues you had with it?

I've been involved in a port of a number-crunching system originally
written in Ada 83 from a different compiler vendor running on Unix, to 
Gnat on Windows in Ada 95, and then most recently to .NET in Ada 2005 
using Gnat Pro for .NET. I say port, but for the most part it was simply
a matter of setting the compiler switches for Ada 95, and Ada 2005,
and recompiling, though we have been introducing new language features
during maintenance of the system.

The original system features several tasks with rendezvous, and heavy 
use of the Ada math libraries. There is no GUI involved.

My experiences from these ports are;

Port 1) Ada 83 SCO Unix (non-Gnat vendor) to Win32 Gnat in Ada 95

- Issues relating to compiler vendor switch:
     None come to mind

_ Issues relating to language switch, Ada 83 - Ada 95
    1)  We had a generic protected queue, which had used the Ada 95
        reserved word "protected" in its variable names. We had to
        change the name of the variables to something else.
        (A very trivial change)
    2)  The generic would accept an unconstrained type as a formal
        parameter. In Ada 95, we had to add the box notation to the
        formal paramter.

        eg. Instead of;

        generic
              type Element_Type is private;
        package P is

we had to write;
        generic
              type Element_Type (<>) is private;
        package P is
...
       Another very trivial change.

     3) We had used passive tasks in a couple of places. In Ada 95, we
        replaced these library units with protected types.
        This was a bit more work, but the end result was satisfying and
        a better result.

- Issues relating to operating system switch: Unix to Windows
     This was probably the biggest impact, though we had isolated OS
     routines, so changes were quite localized. The biggest challenge
     was finding a replacement for Unix's memory mapped array feature,
     which Windows didn't seem to have matching support for.

- Issues relating to change from services being invoked by CORBA to
   interface accessed via a DLL.
    The use of the Interfaces.C library routines was very helpful.
    To invoke the DLL from .NET, a .NET wrapper was needed to complete
    the interface.

-------------------------------------------------

Port 2: Ada 95 Windows to Ada 2005 .NET


- Issues relating to the language switch. (Ada 95 to Ada 2005)
    None: Or at least I don't recall there being any.
    We have now incorporated new language features including interfaces,
    Ada.Directories, containers, object prefix notation, to name a few.
    These mostly come as enhancements needed for maintenance, and are
    unrelated to the actual port.


- Issues going from win32 to .NET
    For the most part we didn't need to make any significant code
    changes. There are a few libraries that weren't implemented in .NET
    Ada. The ones that
    come to mind are Ada.Direct_IO and Ada.Directories I believe, though
    there are other libraries that come with Gnat that provided suitable
    workarounds. There may have been some other minor issues, but we
    found workarounds for everything. The application runs well in .NET.
    We no longer needed the .NET wrapper around our DLL, which simplified
    things. We had to get rid of our Interfaces.C pragmas and replace
    with similar vendor specific pragmas for interfacing to .NET.
    I believe the full list of issues/differences between .NET Gnat Pro
    and Windows Gnat Pro can be obtained from Adacore.

Regards,
Brad Moore

Re: GNAT Pro for .NET

[george.priv]

On Nov 26, 2:05 am, Brad Moore <brad.mo...@shaw.ca> wrote:
> george.p...@gmail.com wrote:
> > Wonder if anyone has any experience with Ada .NET?  How well it is
> > integrated and what are the major issues you had with it?
>
> I've been involved in a port of a number-crunching system originally
> written in Ada 83 from a different compiler vendor running on Unix, to
> Gnat on Windows in Ada 95, and then most recently to .NET in Ada 2005
> using Gnat Pro for .NET. I say port, but for the most part it was simply
> a matter of setting the compiler switches for Ada 95, and Ada 2005,
> and recompiling, though we have been introducing new language features
> during maintenance of the system.
>
> The original system features several tasks with rendezvous, and heavy
> use of the Ada math libraries. There is no GUI involved.
>
> My experiences from these ports are;
>
> Port 1) Ada 83 SCO Unix (non-Gnat vendor) to Win32 Gnat in Ada 95
>
> - Issues relating to compiler vendor switch:
>      None come to mind
>
> _ Issues relating to language switch, Ada 83 - Ada 95
>     1)  We had a generic protected queue, which had used the Ada 95
>         reserved word "protected" in its variable names. We had to
>         change the name of the variables to something else.
>         (A very trivial change)
>     2)  The generic would accept an unconstrained type as a formal
>         parameter. In Ada 95, we had to add the box notation to the
>         formal paramter.
>
>         eg. Instead of;
>
>         generic
>               type Element_Type is private;
>         package P is
>
> we had to write;
>         generic
>               type Element_Type (<>) is private;
>         package P is
> ...
>        Another very trivial change.
>
>      3) We had used passive tasks in a couple of places. In Ada 95, we
>         replaced these library units with protected types.
>         This was a bit more work, but the end result was satisfying and
>         a better result.
>
> - Issues relating to operating system switch: Unix to Windows
>      This was probably the biggest impact, though we had isolated OS
>      routines, so changes were quite localized. The biggest challenge
>      was finding a replacement for Unix's memory mapped array feature,
>      which Windows didn't seem to have matching support for.
>
> - Issues relating to change from services being invoked by CORBA to
>    interface accessed via a DLL.
>     The use of the Interfaces.C library routines was very helpful.
>     To invoke the DLL from .NET, a .NET wrapper was needed to complete
>     the interface.
>
> -------------------------------------------------
>
> Port 2: Ada 95 Windows to Ada 2005 .NET
>
> - Issues relating to the language switch. (Ada 95 to Ada 2005)
>     None: Or at least I don't recall there being any.
>     We have now incorporated new language features including interfaces,
>     Ada.Directories, containers, object prefix notation, to name a few.
>     These mostly come as enhancements needed for maintenance, and are
>     unrelated to the actual port.
>
> - Issues going from win32 to .NET
>     For the most part we didn't need to make any significant code
>     changes. There are a few libraries that weren't implemented in .NET
>     Ada. The ones that
>     come to mind are Ada.Direct_IO and Ada.Directories I believe, though
>     there are other libraries that come with Gnat that provided suitable
>     workarounds. There may have been some other minor issues, but we
>     found workarounds for everything. The application runs well in .NET.
>     We no longer needed the .NET wrapper around our DLL, which simplified
>     things. We had to get rid of our Interfaces.C pragmas and replace
>     with similar vendor specific pragmas for interfacing to .NET.
>     I believe the full list of issues/differences between .NET Gnat Pro
>     and Windows Gnat Pro can be obtained from Adacore.
>
> Regards,
> Brad Moore

Thanks for the info. I played a little with free version but seems
that it has some issues.  Maybe it's just lack of documentation.  I am
considering investing in Gnat Pro next year, so it is nice to know in
advance.

Regards,

George Privalov.