GNAT for MS Visual Studio

GNAT for MS Visual Studio

[William J Thomas]

Excuse me but I've been off line for a few years so this may be an old 
topic.

But has anyone heard about the status of the GNAT version for MS Visual 
Studio?

In particular will it be a full blown "Visual Ada" type like thing with full 
GUI Builder support, or will it just be a .Net friendly thing? 

Re: GNAT for MS Visual Studio

[anon]

The only thing that comes to mind is: A# -- "Ada for .NET"

So, try looking at the following site, maybe it has what you are 
seeking.  It is based on the United States Air Force Academy 
version 2.01 for GNAT Ada 95 (link below).

    http://asharp.martincarlisle.com/

Compiler name: A# (Ada port to the Microsoft .NET Platform )
version:       ??? ( release number is not given )

Date:          May 2, 2006 updated June 6, 2006
Ada Specs:     Ada 2005 ( GNAT GAP 2005)



For Version 2.01 see:

    http://www.usafa.af.mil/df/dfcs/bios/mcc_html/a_sharp.cfm


Microsoft probability will never come out with Ada.


In <13duou81kg3sd1c@corp.supernews.com>, "William J Thomas" <wjthomas@wcvt.com> writes:
>Excuse me but I've been off line for a few years so this may be an old 
>topic.
>
>But has anyone heard about the status of the GNAT version for MS Visual 
>Studio?
>
>In particular will it be a full blown "Visual Ada" type like thing with full 
>GUI Builder support, or will it just be a .Net friendly thing? 
>
>

Re: GNAT for MS Visual Studio

[Rob Veenker]

FYI,

AdaCore is also working on GNATPro for .Net

See:
http://www.adacore.com/wp-content/uploads/2006/11/adacore_news_1106_web.pdf

anon wrote:

> The only thing that comes to mind is: A# -- "Ada for .NET"
> 
> So, try looking at the following site, maybe it has what you are
> seeking.  It is based on the United States Air Force Academy
> version 2.01 for GNAT Ada 95 (link below).
> 
>     http://asharp.martincarlisle.com/
> 
> Compiler name: A# (Ada port to the Microsoft .NET Platform )
> version:       ??? ( release number is not given )
> 
> Date:          May 2, 2006 updated June 6, 2006
> Ada Specs:     Ada 2005 ( GNAT GAP 2005)
> 
> 
> 
> For Version 2.01 see:
> 
>     http://www.usafa.af.mil/df/dfcs/bios/mcc_html/a_sharp.cfm
> 
> 
> Microsoft probability will never come out with Ada.
> 
> 
> In <13duou81kg3sd1c@corp.supernews.com>, "William J Thomas"
> <wjthomas@wcvt.com> writes:
>>Excuse me but I've been off line for a few years so this may be an old
>>topic.
>>
>>But has anyone heard about the status of the GNAT version for MS Visual
>>Studio?
>>
>>In particular will it be a full blown "Visual Ada" type like thing with
>>full GUI Builder support, or will it just be a .Net friendly thing?
>>
>>

Re: GNAT for MS Visual Studio

[William J Thomas]

I know AdaCore is working on it, it was in their news letter. I was hoping 
one of the ACTers had their ear to the rail and would respond.

"Rob Veenker" <veenker@xs4all.nl> wrote in message 
news:46dfbf1b$0$231$e4fe514c@news.xs4all.nl...
> FYI,
>
> AdaCore is also working on GNATPro for .Net
>
> See:
> http://www.adacore.com/wp-content/uploads/2006/11/adacore_news_1106_web.pdf
>
> anon wrote:
>
>> The only thing that comes to mind is: A# -- "Ada for .NET"
>>
>> So, try looking at the following site, maybe it has what you are
>> seeking.  It is based on the United States Air Force Academy
>> version 2.01 for GNAT Ada 95 (link below).
>>
>>     http://asharp.martincarlisle.com/
>>
>> Compiler name: A# (Ada port to the Microsoft .NET Platform )
>> version:       ??? ( release number is not given )
>>
>> Date:          May 2, 2006 updated June 6, 2006
>> Ada Specs:     Ada 2005 ( GNAT GAP 2005)
>>
>>
>>
>> For Version 2.01 see:
>>
>>     http://www.usafa.af.mil/df/dfcs/bios/mcc_html/a_sharp.cfm
>>
>>
>> Microsoft probability will never come out with Ada.
>>
>>
>> In <13duou81kg3sd1c@corp.supernews.com>, "William J Thomas"
>> <wjthomas@wcvt.com> writes:
>>>Excuse me but I've been off line for a few years so this may be an old
>>>topic.
>>>
>>>But has anyone heard about the status of the GNAT version for MS Visual
>>>Studio?
>>>
>>>In particular will it be a full blown "Visual Ada" type like thing with
>>>full GUI Builder support, or will it just be a .Net friendly thing?
>>>
>>> 

Re: GNAT for MS Visual Studio

[Jeffrey Creem]

William J Thomas wrote:
> Excuse me but I've been off line for a few years so this may be an old 
> topic.
> 
> But has anyone heard about the status of the GNAT version for MS Visual 
> Studio?
> 
> In particular will it be a full blown "Visual Ada" type like thing with full 
> GUI Builder support, or will it just be a .Net friendly thing? 
> 
> 

New announcement has gone up at the Adacore website since the time you 
asked. It does appear that they are supporting at least some level of 
integration with visual studio.

http://www.adacore.com/2007/09/10/adacore-first-to-bring-true-net-integration-to-ada/

Re: GNAT for MS Visual Studio

[William J Thomas]

Thank You,

Unfortunately my worst fears have come true.

No MS Visual Studio GUI building capability.

Tell me is there some secret government agency out there preventing Ada from 
having a good, reliable GUI builder on MS Windows?

I mean Windows is only some 90%+ of the market, so I can't believe that the 
Ada vendors for the last 25+ years have some how... (wait a minute, I know 
most of those vendors so I take that back).

It's just that I've been waiting for over two decades for this dream to come 
true, but it never has!

Please don't send me all sorts of suggestions on all of the wonderful "works 
well on Unix but crashes in 10 minutes on Windows Ada GUI products" out 
there. Actually I've had a few of them lure me in and let me do about a half 
hours worth of work just to dash all my hopes and gobel up all of my work, 
or let me save my work only to never let me back in with my saved files, or 
let me back in and display something not even closley resembling to what I 
last saved.

I paid over $4K in the 1980's for an Alsys 286 Compiler (but hey I did get 
4M of memory with it) , I would gladly pay $8K or $16K today for an Ada 
compiler and GUI builder compariable to the quality of a C# compiler and 
Visual Studio. I guess I'll just have to keep dreaming and keep coding (in 
Ada of course, how else could I afford an $8K compiler).

Bill 

Re: GNAT for MS Visual Studio

[Randy Brukardt]

"William J Thomas" <wjthomas@wcvt.com> wrote in message
news:13f3e0vbb05s47c@corp.supernews.com...
...
> No MS Visual Studio GUI building capability.
>
> Tell me is there some secret government agency out there preventing Ada
from
> having a good, reliable GUI builder on MS Windows?

I doubt that, I think it is more that many of us can't figure out precisely
what such a tool would offer over the tried-and-true command line tools.
(Yes, I do the vast majority of my programming from an MS-DOS window using
the same 1980s editor I've always used.) Sure, I can imagine some really
neat features, but those would be impractical (lousy response time,
unrealistic requirements, probably would need an incremental Ada compiler to
implement them).

We've seriously looked at this issue, and concluded that a decent
programming environment would take more than 3 man-years to create: longer
than implementing the majority of the Amendment changes to the language. And
only a few people would want to use it (me, and possibly you, and I don't
know of any others.), because they all want Visual Studio or Eclipse or
something else that isn't designed to work with Ada. As such, there is no
possibility of recouping the investment in time and money, so I think you'll
be waiting essentially forever on that one. (We are working on a simple
Windows programming environment, but it will not have anything fancy; it is
aimed simply to make our compiler more usable to those who can't handle a
command line. And the only reason we're doing that is that we can't update
the one we have currently - no source code.)

                                        Randy.

Re: GNAT for MS Visual Studio

[William J Thomas]

Randy,

I'm not talking about just a programming environment. I'm talking about a 
GUI builder, a program that allows me to develop graphically oriented 
programs, more specifically one that would allow me to develop MS Window 
Forms programs in the Ada Language!!!

I can get Visual FORTRAN and Visual Cobol all running under MS Visual 
Studio, all allowing me to develop much more graphically sophisticated (and 
usable) programs than I can ever dream of with any Ada compiler that now 
exists under the Windows environment.

It's not that difficult to understand what I want, I just want Visual Ada 
instead of C#. I want it running in the same environment, with all the Ada 
oriented IntelliSense, with tools to help me generate Help files, and an 
uncountable Class library all with Ada interfaces, with oodles and oodles of 
import pragmas. I want to be able drag and drop in a PageSetupDialog and 
watch it jump into the area under my form, I want to be able drag and drop a 
DataGridView and be intimidated by all of the Ada event routines I'll have 
to work with, I want to be able to drop in a FlowLayoutPanel and have it....

Do you get the picture Randy, and that's another thing I want is a 
PictureBox so I can go over to my property view and set the file path to my 
gif file. But I want it all inside MS Visual Studio. I want it to look and 
feel like every other language under Visual Studio except I want it to be 
Ada.

That's all.

And I wouldn't be so sure about the government agency. It's either a 
government agency or Satan himself that's keeping Ada from being a 
successful language in the Windows scheme of things. Or it could just be 
those evil Ada Vendors that have been blinded by the Lord because they have 
forsaken the quest of Ada proliferation and have drifted, some to the right 
and some to the left, none have stayed the course, none have reached the 
promise land, all have fallen short.

You know what I mean Randy.

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:fcv43c$8sg$1@jacob-sparre.dk...
> "William J Thomas" <wjthomas@wcvt.com> wrote in message
> news:13f3e0vbb05s47c@corp.supernews.com...
> ...
>> No MS Visual Studio GUI building capability.
>>
>> Tell me is there some secret government agency out there preventing Ada
> from
>> having a good, reliable GUI builder on MS Windows?
>
> I doubt that, I think it is more that many of us can't figure out 
> precisely
> what such a tool would offer over the tried-and-true command line tools.
> (Yes, I do the vast majority of my programming from an MS-DOS window using
> the same 1980s editor I've always used.) Sure, I can imagine some really
> neat features, but those would be impractical (lousy response time,
> unrealistic requirements, probably would need an incremental Ada compiler 
> to
> implement them).
>
> We've seriously looked at this issue, and concluded that a decent
> programming environment would take more than 3 man-years to create: longer
> than implementing the majority of the Amendment changes to the language. 
> And
> only a few people would want to use it (me, and possibly you, and I don't
> know of any others.), because they all want Visual Studio or Eclipse or
> something else that isn't designed to work with Ada. As such, there is no
> possibility of recouping the investment in time and money, so I think 
> you'll
> be waiting essentially forever on that one. (We are working on a simple
> Windows programming environment, but it will not have anything fancy; it 
> is
> aimed simply to make our compiler more usable to those who can't handle a
> command line. And the only reason we're doing that is that we can't update
> the one we have currently - no source code.)
>
>                                        Randy.
>
>
>
> 

Re: GNAT for MS Visual Studio

[Markus E L]

"William J Thomas" wrote:

> Randy,
>
> I'm not talking about just a programming environment. I'm talking about a 
> GUI builder, a program that allows me to develop graphically oriented 
> programs, more specifically one that would allow me to develop MS Window 
> Forms programs in the Ada Language!!!
>
> I can get Visual FORTRAN and Visual Cobol all running under MS Visual 
> Studio, all allowing me to develop much more graphically sophisticated (and 
> usable) programs than I can ever dream of with any Ada compiler that now 
> exists under the Windows environment.
>
> It's not that difficult to understand what I want, I just want Visual Ada 
> instead of C#. I want it running in the same environment, with all the Ada 
> oriented IntelliSense, with tools to help me generate Help files, and an 
> uncountable Class library all with Ada interfaces, with oodles and oodles of 
> import pragmas. I want to be able drag and drop in a PageSetupDialog and 
> watch it jump into the area under my form, I want to be able drag and drop a 
> DataGridView and be intimidated by all of the Ada event routines I'll have 
> to work with, I want to be able to drop in a FlowLayoutPanel and have it....
>
> Do you get the picture Randy, and that's another thing I want is a 
> PictureBox so I can go over to my property view and set the file path to my 
> gif file. But I want it all inside MS Visual Studio. I want it to look and 
> feel like every other language under Visual Studio except I want it to be 
> Ada.
>
> That's all.
>
> And I wouldn't be so sure about the government agency. It's either a 
> government agency or Satan himself that's keeping Ada from being a 
> successful language in the Windows scheme of things. Or it could just be 
> those evil Ada Vendors that have been blinded by the Lord because they have 
> forsaken the quest of Ada proliferation and have drifted, some to the right 
> and some to the left, none have stayed the course, none have reached the 
> promise land, all have fallen short.

Since you have so much money to spend (recently you've been talking
about around 16K $ for a license), I'm sure somebody can be found who
either extends existing builders (glade comes into mind) that they fit
your needs, or writes a completely new one. I'm sure we can talk about
such an undertaking if you get some more big spenders of your type
together.

(Though, at the moment I don't believe in that prospect).

Regards -- Markus

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Thu, 20 Sep 2007 23:27:14 -0400, William J Thomas wrote:

> I'm not talking about just a programming environment. I'm talking about a 
> GUI builder, a program that allows me to develop graphically oriented 
> programs, more specifically one that would allow me to develop MS Window 
> Forms programs in the Ada Language!!!

A resource file editor? Honestly, I never felt a necessity in anything more
elaborated than that.

To me a good IDE with a visual debugger is much more important. Visual
Studio had definitely reached that point, definitely better than GNAT GPS.
Though the latter has a par nice ideas, for example spec<->body switching,
hierarchical projects etc.

> I can get Visual FORTRAN and Visual Cobol all running under MS Visual 
> Studio, all allowing me to develop much more graphically sophisticated (and 
> usable) programs than I can ever dream of with any Ada compiler that now 
> exists under the Windows environment.

That depends on what do we understand under sophisticated? Because IMO one
necessary premise of making a "sophisticated" GUI is not to use anything
except very basic Win32 APIs. Consider a simple example, a list box which
does not crash your application after its content exceeds 32K lines in
which you can write at 1ms rate without blocking the rest of UI. This is
independent on whether it be in Ada or in C++.

> Do you get the picture Randy, and that's another thing I want is a 
> PictureBox so I can go over to my property view and set the file path to my 
> gif file.

When the file is 1GB large and located on the remote drive?

But what's wrong with DrawState with DST_BITMAP?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GNAT for MS Visual Studio

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1i884lvjjjkcg.3im0hk3wl8gi$.dlg@40tude.net...
> On Thu, 20 Sep 2007 23:27:14 -0400, William J Thomas wrote:
>
> > I'm not talking about just a programming environment. I'm talking about
a
> > GUI builder, a program that allows me to develop graphically oriented
> > programs, more specifically one that would allow me to develop MS Window
> > Forms programs in the Ada Language!!!
>
> A resource file editor? Honestly, I never felt a necessity in anything
more
> elaborated than that.
>
> To me a good IDE with a visual debugger is much more important. Visual
> Studio had definitely reached that point, definitely better than GNAT GPS.
> Though the latter has a par nice ideas, for example spec<->body switching,
> hierarchical projects etc.

I agree; that's the sort of things I was thinking about when I replied.
GUI's been done to death, and I don't think anyone in the Ada business ever
made any money off of it.

                             Randy.


                   Randy.

Re: GNAT for MS Visual Studio

[Randy Brukardt]

"William J Thomas" <wjthomas@wcvt.com> wrote in message
news:13f6eg0te46m2a3@corp.supernews.com...
> Randy,
>
> I'm not talking about just a programming environment. I'm talking about a
> GUI builder, a program that allows me to develop graphically oriented
> programs, more specifically one that would allow me to develop MS Window
> Forms programs in the Ada Language!!!

What's "Windows Forms"? I know all about the native GUI environment (that's
what Claw and several other GUI builders target), and .NET and some about
Silverlight, but never heard of anything else (nor have ever heard of anyone
wanting it, either).

> I can get Visual FORTRAN and Visual Cobol all running under MS Visual
> Studio, all allowing me to develop much more graphically sophisticated
(and
> usable) programs than I can ever dream of with any Ada compiler that now
> exists under the Windows environment.

That I don't doubt. But to work with Microsoft, you have to have *very* deep
pockets, and you can't care that they'll canabilize your work if you have
success. It's not practical for any Ada company (and probably nearly
impossible for a real open source one).

And of course building your own (as Aonix did way back, and as we [started
to do] did with Claw) is essentially a black hole. That is, it sucks up
money and resources that could be used on projects that people care enough
about to pay for.

> It's not that difficult to understand what I want, I just want Visual Ada
> instead of C#. I want it running in the same environment, with all the Ada
> oriented IntelliSense, with tools to help me generate Help files, and an
> uncountable Class library all with Ada interfaces, with oodles and oodles
of
> import pragmas. I want to be able drag and drop in a PageSetupDialog and
> watch it jump into the area under my form, I want to be able drag and drop
a
> DataGridView and be intimidated by all of the Ada event routines I'll have
> to work with, I want to be able to drop in a FlowLayoutPanel and have
it....
>
> Do you get the picture Randy, and that's another thing I want is a
> PictureBox so I can go over to my property view and set the file path to
my
> gif file. But I want it all inside MS Visual Studio. I want it to look and
> feel like every other language under Visual Studio except I want it to be
> Ada.

You want miracles. I can't say I blame you (this isn't that far from what we
were trying to accomplish with Claw), but I don't think it will happen.
Given the rate at which Microsoft evolves their stuff, simply keeping up
would be too much for the majority of Ada companies. (It surely would be too
much for ours.) The majority of (paying) Ada users don't use GUIs anyway
(something we found out with Claw) - the people on comp.lang.ada are not
that typical of the Ada user base as a whole (or at least of the ones that
keep Ada companies in business).

                              Randy.

>
> That's all.
>
> And I wouldn't be so sure about the government agency. It's either a
> government agency or Satan himself that's keeping Ada from being a
> successful language in the Windows scheme of things. Or it could just be
> those evil Ada Vendors that have been blinded by the Lord because they
have
> forsaken the quest of Ada proliferation and have drifted, some to the
right
> and some to the left, none have stayed the course, none have reached the
> promise land, all have fallen short.
>
> You know what I mean Randy.
>
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:fcv43c$8sg$1@jacob-sparre.dk...
> > "William J Thomas" <wjthomas@wcvt.com> wrote in message
> > news:13f3e0vbb05s47c@corp.supernews.com...
> > ...
> >> No MS Visual Studio GUI building capability.
> >>
> >> Tell me is there some secret government agency out there preventing Ada
> > from
> >> having a good, reliable GUI builder on MS Windows?
> >
> > I doubt that, I think it is more that many of us can't figure out
> > precisely
> > what such a tool would offer over the tried-and-true command line tools.
> > (Yes, I do the vast majority of my programming from an MS-DOS window
using
> > the same 1980s editor I've always used.) Sure, I can imagine some really
> > neat features, but those would be impractical (lousy response time,
> > unrealistic requirements, probably would need an incremental Ada
compiler
> > to
> > implement them).
> >
> > We've seriously looked at this issue, and concluded that a decent
> > programming environment would take more than 3 man-years to create:
longer
> > than implementing the majority of the Amendment changes to the language.
> > And
> > only a few people would want to use it (me, and possibly you, and I
don't
> > know of any others.), because they all want Visual Studio or Eclipse or
> > something else that isn't designed to work with Ada. As such, there is
no
> > possibility of recouping the investment in time and money, so I think
> > you'll
> > be waiting essentially forever on that one. (We are working on a simple
> > Windows programming environment, but it will not have anything fancy; it
> > is
> > aimed simply to make our compiler more usable to those who can't handle
a
> > command line. And the only reason we're doing that is that we can't
update
> > the one we have currently - no source code.)
> >
> >                                        Randy.
> >
> >
> >
> >
>
>

Re: GNAT for MS Visual Studio

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> The majority of (paying) Ada users don't use GUIs anyway (something
> we found out with Claw) - the people on comp.lang.ada are not that
> typical of the Ada user base as a whole (or at least of the ones
> that keep Ada companies in business).

Our project is an embedded system without any UI at all, let alone a
GUI. It's kept quite a few developers in work for several years (more
than it should have done, but that's another matter, and definitely
not Ada's fault!)

We've used an embedded web server where appropriate for testing, but
it's definitely not deliverable (shame, really).

As to the development environment, people do tend to use GPS now
rather than Emacs (even I, an Emacs diehard, use it for debugging). We
have one engineer who uses vi and one (no longer on the project) who
used Notepad. Bizarre.

Re: GNAT for MS Visual Studio

[Steve]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:fd1so0$lmu$1@jacob-sparre.dk...
[snip]
> What's "Windows Forms"? I know all about the native GUI environment 
> (that's
> what Claw and several other GUI builders target), and .NET and some about
> Silverlight, but never heard of anything else (nor have ever heard of 
> anyone
> wanting it, either).
>

Windows forms are a set of classes that are part of the .NET framework. 
They make it _very_ easy to put together user interfaces.  If you want to 
try out a system that is similar to what you get with visual studio, go to:
http://www.icsharpcode.net/OpenSource/SD/

To find SharpDevelop.  SharpDevelop is a free IDE for C# VB and Boo .NET 
projects.

Visual Studio is in may ways better than SharpDevelop, but it's hard to beat 
free when you want to get an idea of how things work.

When creating a form in Visual Studio .NET, you drag and drop components 
from a tools window onto a form.  Visual Studo generates code in an 
InitializeComponent method that is called when a form is created.  You set 
up properties and events for the form by selecting the item on the form and 
changing values in a property editor.

This kind of interaction with building GUI applications is nothing new. 
It's similar to the way things have worked with Visual Basic and Delphi for 
a long time.  Sadly Ada is lacking in this area.

[snip]
>
> That I don't doubt. But to work with Microsoft, you have to have *very* 
> deep
> pockets, and you can't care that they'll canabilize your work if you have
> success. It's not practical for any Ada company (and probably nearly
> impossible for a real open source one).
>

This is where things get interesing.  I would agree with this view if you 
had to start from scratch.  But these days you don't have to.

For example Visual Studio 2005 allows you to customize the IDE.  There is a 
Visual Studio SDK (which is a free download from Microsoft).  The VS SDK 
allows you to create VS "Packages" that integrate with Visual Studio and may 
be used to support other languages.

I don't see a significant barrier to implementing VS Packages for building 
.NET forms in Ada, given that a compiler that produces .NET code is 
available.  The largest task would be the learning curve of working with the 
SDK.

[snip]
>> gif file. But I want it all inside MS Visual Studio. I want it to look 
>> and
>> feel like every other language under Visual Studio except I want it to be
>> Ada.
>
> You want miracles. I can't say I blame you (this isn't that far from what 
> we
> were trying to accomplish with Claw), but I don't think it will happen.
> Given the rate at which Microsoft evolves their stuff, simply keeping up
> would be too much for the majority of Ada companies. (It surely would be 
> too
> much for ours.) The majority of (paying) Ada users don't use GUIs anyway
> (something we found out with Claw) - the people on comp.lang.ada are not
> that typical of the Ada user base as a whole (or at least of the ones that
> keep Ada companies in business).
>

The reason the majority of Ada users don't use GUI's is that existing Ada 
GUI's suck.  I am a strong advocate of Ada for everything but the user 
interface, because creating a GUI user interface in Ada is just too damn 
hard.  I've tried using ObjectAda's GUI builder, GtkAda, Claw, and Gnavi. 
The all have one thing in common... nice try, but not even close.  It is 
readily apparent that none of the developers did any serious work with VB, 
Delphi, or one of the other easy GUI development environments.

GtkAda comes the closest to being a reasonable development environment, but 
every time I've tried using it on Windows, something doesn't work right.

If you open up sharpdevelop you can start creating forms immediately.  Drag 
and drop components onto a form, set their properties and so forth.  The 
same is true with Visual Basic and Delphi.  With these kind of environments 
you get immeidate feedback on what you're creating, and having to go add 
code is a secondary concern.  If the code happened to be Ada, I don't think 
most users would much care.

On a side note MFC (the Microsoft Foundation Class framework with Visual 
C++) also sucks.  I think the only reason it is used is because it is backed 
by a software giant.

Regards,
Steve
(The Duck)

>                              Randy.
>

Re: GNAT for MS Visual Studio

[Jean-Pierre Rosen]

Steve a �crit :
> When creating a form in Visual Studio .NET, you drag and drop components 
> from a tools window onto a form.  Visual Studo generates code in an 
> InitializeComponent method that is called when a form is created.  You set 
> up properties and events for the form by selecting the item on the form and 
> changing values in a property editor.
> 
> This kind of interaction with building GUI applications is nothing new. 
> It's similar to the way things have worked with Visual Basic and Delphi for 
> a long time.  Sadly Ada is lacking in this area.
> 
What you describe is exactly what you get with GtkAda/Glade. Ada lacks 
nothing when you know where to look for...

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GNAT for MS Visual Studio

[Steve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message 
news:rkr7df.7mp.ln@hunter.axlog.fr...
> Steve a �crit :
>> When creating a form in Visual Studio .NET, you drag and drop components 
>> from a tools window onto a form.  Visual Studo generates code in an 
>> InitializeComponent method that is called when a form is created.  You 
>> set up properties and events for the form by selecting the item on the 
>> form and changing values in a property editor.
>>
>> This kind of interaction with building GUI applications is nothing new. 
>> It's similar to the way things have worked with Visual Basic and Delphi 
>> for a long time.  Sadly Ada is lacking in this area.
>>
> What you describe is exactly what you get with GtkAda/Glade. Ada lacks 
> nothing when you know where to look for...
>

It is "almost" what you get with GtkAda/Glade.  Every time I have attempted 
the combination it has ended in frustration.

I am working in a Windows environment.

Every time I have attempted to use Glade to set up a GUI it starts out 
looking really impressive... better than some of the other GUI IDE's.

But then I find that the tool that is supposed to allow me to make changes 
to the GUI after the initial setup, doesn't work on Windows.  Or I start 
setting up windows, things start looking good, and then Glade crashes losing 
all of my edits.

When I first tried using Glade on Windows the file dialogs were far from 
standard for windows and very frustrating to work with.

I like Ada.  I really do.  But I would not recommend using Ada for a 
developing a GUI to anyone.
I would go so far as to recommend creating a separate "front end" in C# on 
.NET and a "back end" in Ada.  But that raises the issue of justifying using 
two separate programming languages for one applicaiton.

Maybe someday some eager beaver will create a visual studio package that 
generates Ada gui code for Visual Studio .NET.  That would (I believe) put 
Ada on an equal (or superior) footing with other programming languages for 
developing user interfaces.

Regards,
Steve
(The Duck)


> -- 
> ---------------------------------------------------------
>            J-P. Rosen (rosen@adalog.fr)
> Visit Adalog's web site at http://www.adalog.fr 

Re: GNAT for MS Visual Studio

[Jean-Pierre Rosen]

Steve a �crit :
> It is "almost" what you get with GtkAda/Glade.  Every time I have attempted 
> the combination it has ended in frustration.
> 
> I am working in a Windows environment.
> 
> Every time I have attempted to use Glade to set up a GUI it starts out 
> looking really impressive... better than some of the other GUI IDE's.
> 
> But then I find that the tool that is supposed to allow me to make changes 
> to the GUI after the initial setup, doesn't work on Windows.  Or I start 
> setting up windows, things start looking good, and then Glade crashes losing 
> all of my edits.
True, there is one problem with Glade on Windows. Since Windows has no 
official "diff" command, the round-trip engineering feature does not work.

It was easy for me, because I also have a Linux box on my desk. I 
develop the GUI on Linux, and run it on windows. I had zero 
compatibility problem...

> I like Ada.  I really do.  But I would not recommend using Ada for a 
> developing a GUI to anyone.
> I would go so far as to recommend creating a separate "front end" in C# on 
> .NET and a "back end" in Ada.  But that raises the issue of justifying using 
> two separate programming languages for one applicaiton.
Another option is Tcl/Tk. I have an application that uses it for its 
Gui, and I was quite happy with it. I didn't use the GUI builder (I know 
there is one), but it is relatively easy to design interfaces by hand.

A benefit of this approach is that you can keep all your layout in a 
text file which is totally external to your application. If you are 
showing what you've done to a client, and the client asks you to move 
some button, you can do immediately it with a text editor, without 
recompiling the program.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GNAT for MS Visual Studio

[Michael Bode]

"Steve" <nospam_steved94@comcast.net> writes:

> It is "almost" what you get with GtkAda/Glade.  Every time I have attempted 
> the combination it has ended in frustration.
>
> I am working in a Windows environment.
>
> Every time I have attempted to use Glade to set up a GUI it starts out 
> looking really impressive... better than some of the other GUI IDE's.
>
> But then I find that the tool that is supposed to allow me to make changes 
> to the GUI after the initial setup, doesn't work on Windows.  Or I start 
> setting up windows, things start looking good, and then Glade crashes losing 
> all of my edits.

I'm using Glade/GtkAda on Linux and Windows. I have had maybe a
handfull of Glade crashes, not more than I have experienced with
Visual C++. I have to admit that my copy of VC++ is 10 years old, so I
hope they have heard of layout managers other than 'absolute
position' by now, haven't they? I tried to install VC++ 2003 a month
ago on Vista, but that did not work (installer told me VC++ is not
compatible with Vista). At least my GtkAda app does work on Vista with
only one annoyance: you have to either disable Aero or the WIMP engine
to get menus working properly.

BTW: I don't use Gate but libglade. The glade file for my app has
about 21000 lines, loads in under 2s on my Thinkpad R51.

> When I first tried using Glade on Windows the file dialogs were far from 
> standard for windows and very frustrating to work with.

This is correct. I've written a wrapper (185 lines) around the file dialog that
uses the GTK one on Linux and the Windows one on Windows.

> I like Ada.  I really do.  But I would not recommend using Ada for a 
> developing a GUI to anyone.

If it wasn't for the license I'd fail to see why developing GUIs for
Windows + Linux with Ada was a problem. If you're developing GPL apps
that doesn't bother you, but otherwise there are more affordable solutions.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: GNAT for MS Visual Studio

[Jeffrey R. Carter]

Michael Bode wrote:
> 
> This is correct. I've written a wrapper (185 lines) around the file dialog that
> uses the GTK one on Linux and the Windows one on Windows.

Is this publicly available?

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

Re: GNAT for MS Visual Studio

[Michael Bode]

"Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes:

> Is this publicly available?

Not yet. If you're interested I can mail it to you with a
'do-what-you-want' license (i.e. none at all). Before I put it myself
on Adapower or such I should ask my boss, but this is really nothing
worth making a fuss about.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: GNAT for MS Visual Studio

[Markus E L]

"Steve" wrote:

> "Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message 
> news:rkr7df.7mp.ln@hunter.axlog.fr...
>> Steve a �crit :
>>> When creating a form in Visual Studio .NET, you drag and drop components 
>>> from a tools window onto a form.  Visual Studo generates code in an 
>>> InitializeComponent method that is called when a form is created.  You 
>>> set up properties and events for the form by selecting the item on the 
>>> form and changing values in a property editor.
>>>
>>> This kind of interaction with building GUI applications is nothing new. 
>>> It's similar to the way things have worked with Visual Basic and Delphi 
>>> for a long time.  Sadly Ada is lacking in this area.
>>>
>> What you describe is exactly what you get with GtkAda/Glade. Ada lacks 
>> nothing when you know where to look for...
>>
>
> It is "almost" what you get with GtkAda/Glade.  Every time I have attempted 
> the combination it has ended in frustration.
>
> I am working in a Windows environment.
>
> Every time I have attempted to use Glade to set up a GUI it starts out 
> looking really impressive... better than some of the other GUI IDE's.
>
> But then I find that the tool that is supposed to allow me to make changes 
> to the GUI after the initial setup, doesn't work on Windows.  Or I start 
> setting up windows, things start looking good, and then Glade crashes losing 
> all of my edits.
>
> When I first tried using Glade on Windows the file dialogs were far from 
> standard for windows and very frustrating to work with.
>
> I like Ada.  I really do.  But I would not recommend using Ada for a 
> developing a GUI to anyone.

Now, I did, we're selling the program and your advice is
nonsense. Admittedly we never bothered to do much more than _build_ on
Windows. The Development was done on Debian Woody and Sarge (and most
of the debugging to).

GtkAda + Gnat make a viable cross-platfrom environment. The snags one
encounters have nothing to do with your advice (but IMHO rather with
Ada: It is a great language, but GUIs can probably be easier built
when GC and real closures are present. I haven't ever bothered to work
out in detail my arguments regarding this, so I won't try to defend
this view here and now).

> I would go so far as to recommend creating a separate "front end" in C# on 
> .NET and a "back end" in Ada.  But that raises the issue of justifying using 
> two separate programming languages for one applicaiton.

It also raises the question wether this is really the price you want
to pay for being able to use a "GUI-Builder" (which IMHO produce too
static applications anyway ...). GUIs can be done w/o GUI Builder (or
one can use Glade on Linux to produce a GUI to be compiled on Windows)
and this might be much less painful than C#/Ada integration.

> Maybe someday some eager beaver will create a visual studio package that 
> generates Ada gui code for Visual Studio .NET.  That would (I believe) put 
> Ada on an equal (or superior) footing with other programming languages for 
> developing user interfaces.

I see that MS marketing already works. In your mind GUI developent is
impossible w/o Visual studio.

Regards -- Markus

Re: GNAT for MS Visual Studio

[Steve]

"Markus E L" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message news:xwir5zj8j2.fsf@hod.lan.m-e-leypold.de...
[snip]
>
> I see that MS marketing already works. In your mind GUI developent is
> impossible w/o Visual studio.

You're reading me wrong here.

C# or VB on Visual Studo, Delphi and  SharpDevelop are all comparable in 
terms of effort to create a GUI.  Unless Microsoft has purchased Borland or 
Imprise ... I'm not sure what they're calling it these days) Delphi is not a 
Microsoft product.

The Microsoft Foundataion Classes used with Visual C++ in visual studio are 
horrible.  It has been since it was first released.  Borland's OWL was 10x 
better than MFC.  It's ridiculous to develop user interfaces using MFC when 
so many better tools are available.

BTW: In my opinion:  Ada is the best general purpose programming language to 
date.

Earlier in this thread it was mentioned that AdaCore has produced a dot-net 
version of GNAT.

If you haven't learned about dot-net, and you program user interfaces for 
Windows, I would recommend doing so.  It is similar to Java and Java's 
virtual machine in nature, but better, and covers all of Windows.  If you're 
programming using .NET you have a wealth of class libraries available... 
regardless of the programming language.  It should be as easy to write GUI 
user interfaces with GNAT on .NET as it is to write them in C#, VB, or Boo.

What I was trying to point out (if anyone was listening) is that there are 
tools available (for tool builders, which I'm not... its just not my forte') 
that should make it relatively easy for tool builders to include support for 
interactively building .NET forms in the Visual Studio 2005 development 
environment.

It is impractical (as Randy mentioned) for Ada tool developers to create 
their own development environments with the same capabilites as Microsoft. 
But what is practical, is to make use of the tools that Microsoft has made 
available to customize their development environment.  The same is probably 
true of Eclipse, but I am much less familiar with Eclipse.

In general, I'm not a big Microsoft fan.  When I first learned about 
developing windows applications my response was "you're kidding!".  When VB 
and Delphi came out, it made things a lot better.  In my opinion .NET has 
finally brought windows development far closer to what it should have been 
in the first place.

I was reluctant to learn C#.  It was my understanding that it was basically 
just a Microsoft rip-off of Java (in my opinion they have a history of 
copying other peoples innovations and making them their own).

I try to keep on top of new technologies as they come out so reluctantly I 
read the ECMA standard for C#.  I was suprised to find that there are 
several things that I like a lot better than Java.

Ada is my preferred programming language.  If A# or GNAT for .NET give Ada a 
better shot at a larger market, maybe I'll be able to use it more.

Regards,
Steve
(The Duck)

>
> Regards -- Markus
>
> 

Re: GNAT for MS Visual Studio

[Markus E L]

"Steve" wrote:

> "Markus E L" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
> wrote in message news:xwir5zj8j2.fsf@hod.lan.m-e-leypold.de...
> [snip]
>>
>> I see that MS marketing already works. In your mind GUI developent is
>> impossible w/o Visual studio.
>
> You're reading me wrong here.
>
> C# or VB on Visual Studo, Delphi and  SharpDevelop are all comparable in 
> terms of effort to create a GUI.  Unless Microsoft has purchased Borland or 
> Imprise ... I'm not sure what they're calling it these days) Delphi is not a 
> Microsoft product.
>
> The Microsoft Foundataion Classes used with Visual C++ in visual studio are 
> horrible.  It has been since it was first released.  Borland's OWL was 10x 
> better than MFC.  It's ridiculous to develop user interfaces using MFC when 
> so many better tools are available.

> BTW: In my opinion:  Ada is the best general purpose programming language to 
> date.

In my opinion the "general purpose" doesn't apply any more, but let's
not argue about that: This has been beaten to death w/o any real
results in threads some months ago.

> Earlier in this thread it was mentioned that AdaCore has produced a dot-net 
> version of GNAT.
>
> If you haven't learned about dot-net, and you program user interfaces for 
> Windows, I would recommend doing so.  It is similar to Java and Java's 
> virtual machine in nature, but better, and covers all of Windows.  If you're 
> programming using .NET you have a wealth of class libraries available... 
> regardless of the programming language.  It should be as easy to write GUI 
> user interfaces with GNAT on .NET as it is to write them in C#, VB, or Boo.
>
> What I was trying to point out (if anyone was listening) is that there are 
> tools available (for tool builders, which I'm not... its just not my forte') 
> that should make it relatively easy for tool builders to include support for 
> interactively building .NET forms in the Visual Studio 2005 development 
> environment.

Obviously not easy enough to make building those tools into a viable
market. That might be due to the size of the market or the difficulty
/ ineconomy of maintaining such support over the years.

Still my point applies: You cannot imagin building GUIs w/o
"interactively building" etc. My suspicion why there is no market for
GUI builders is:

  - Coding is only a small part of a development project.

  - Building GUIs is hard with and without GUI builder, the hard part
    is not selecting the widgets and plugging them together, but (a)
    non widget related structuring of event processing and (b)
    plugging this to the rest of your application. GUI builder don't
    help there.

  - It's only too often the beginners that camour for GUI builder. But
    they (a) overestimate their productivity boost from having such a
    builder and (b) aren't willing to pay big bucks for it. In teams
    of larger projects it's certainly not the beginners that decide
    which tools are bought.

That would explain, why people urgently wanting a GUI builder of VS
integration are only a small fraction of the specific language /
developer community. And it would explain why there are such tools for
e.g. C# and Java, which have a larger community such that even the
small minority constitutes a viable market, whereas the Ada community
is small so that a GUI builder would not be viable.

I'm not sure that is right, I'm just speculating.


> It is impractical (as Randy mentioned) for Ada tool developers to create 
> their own development environments with the same capabilites as Microsoft. 

> But what is practical, is to make use of the tools that Microsoft has made 
> available to customize their development environment.  

? And you don't think the creeping featuritis and inevitable but fast
change of the MS tools wouldn't hit them then? I think they would,
actually I cannot imagine any worse environment for maintaining any
corpus of code than these "tools Microsoft has made" wheras plain old
make and a compiler ...

> The same is probably 
> true of Eclipse, but I am much less familiar with Eclipse.
>
> In general, I'm not a big Microsoft fan.  When I first learned about 
> developing windows applications my response was "you're kidding!".  When VB 
> and Delphi came out, it made things a lot better.  In my opinion .NET has 
> finally brought windows development far closer to what it should have been 
> in the first place.

Well -- The problem with windows is, that they are more often than not
the wrong interaction model: For the user as well as from the
application perspective (processing events instead of reading
input). This of course cannot be changed any more today since bad
practice has formed user expectation over the years. Bad practice: No
user manual, but overladen input forms, and no "direct interaction
metaphor".


> I was reluctant to learn C#.  It was my understanding that it was basically 
> just a Microsoft rip-off of Java (in my opinion they have a history of 
> copying other peoples innovations and making them their own).
>
> I try to keep on top of new technologies as they come out so reluctantly I 
> read the ECMA standard for C#.  I was suprised to find that there are 
> several things that I like a lot better than Java.
>
> Ada is my preferred programming language.  If A# or GNAT for .NET give Ada a 
> better shot at a larger market, maybe I'll be able to use it more.


Regards -- Markus

Re: GNAT for MS Visual Studio

[Randy Brukardt]

"Markus E L" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>
wrote in message news:u1wsudty5c.fsf@hod.lan.m-e-leypold.de...
...
> > But what is practical, is to make use of the tools that Microsoft has
made
> > available to customize their development environment.
>
> ? And you don't think the creeping featuritis and inevitable but fast
> change of the MS tools wouldn't hit them then? I think they would,
> actually I cannot imagine any worse environment for maintaining any
> corpus of code than these "tools Microsoft has made" wheras plain old
> make and a compiler ...

This was my point last week. We're pretty much done chasing Microsoft,
because we don't have the resources to keep up with the constant changes. I
don't think many companies do.

                              Randy.

Re: GNAT for MS Visual Studio

[Steve]

"Markus E L" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message news:u1wsudty5c.fsf@hod.lan.m-e-leypold.de...
>
> "Steve" wrote:
[snip]
>> What I was trying to point out (if anyone was listening) is that there 
>> are
>> tools available (for tool builders, which I'm not... its just not my 
>> forte')
>> that should make it relatively easy for tool builders to include support 
>> for
>> interactively building .NET forms in the Visual Studio 2005 development
>> environment.
>
> Obviously not easy enough to make building those tools into a viable
> market. That might be due to the size of the market or the difficulty
> / ineconomy of maintaining such support over the years.
>

That is the point that I question.  Prior to Microsoft opening up the VS for 
adding tools I am certain that that was true.  But who knows.  It might turn 
out that the amount of work required to able to build forms interactively is 
minimial.  That functionality already exists for multiple languages. 
Perhaps there are nice classes that just need to have the details of the 
language defined.  That sort of thing certainly didn't exist in the past, 
certainly not from Microsoft, but you never used to be able do download a 
compiler for free from Microsoft either.

> Still my point applies: You cannot imagin building GUIs w/o
> "interactively building" etc. My suspicion why there is no market for
> GUI builders is:
>

Actually, on the contrary I think this is one of the reason there is 
(almost) no market for Ada in the general computing community.

I went through the process of justifying the choice of language for a system 
several years ago.  At the time I was able to move things toward Ada.  Since 
then matters beyond my control have moved things toward C++ and C#.

In my experience, when the choice of a programming language has to be 
justified, any capability that choice A has over choice B is part of the 
consideration.  Sometimes the reasons are real, sometimes they are not. 
That's just the way things work.  Unfortunately with Ada the GUI generally 
goes in the disadvantage category.

Regards,
Steve
(The Duck)
>
>
> Regards -- Markus
> 

Re: GNAT for MS Visual Studio

[Markus E L]

"Steve" wrote:

> "Markus E L" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
> wrote in message news:u1wsudty5c.fsf@hod.lan.m-e-leypold.de...
>>
>> "Steve" wrote:
> [snip]
>>> What I was trying to point out (if anyone was listening) is that there 
>>> are
>>> tools available (for tool builders, which I'm not... its just not my 
>>> forte')
>>> that should make it relatively easy for tool builders to include support 
>>> for
>>> interactively building .NET forms in the Visual Studio 2005 development
>>> environment.
>>
>> Obviously not easy enough to make building those tools into a viable
>> market. That might be due to the size of the market or the difficulty
>> / ineconomy of maintaining such support over the years.
>>

> That is the point that I question.  

And that is the point where I question your wisdom regarding business
viability of products. Randy (who has much better insight and much
more experience than I do) already said practically everything that
could have been said.

> Prior to Microsoft opening up the VS for adding tools I am certain
> that that was true.

I'm not talking about closed or open interfaces. I'm talking about
_mutation_. About the fact that I would -- within a ten year product
cycle -- have to fiddle with my product all the time to adapt it to ne
strategies, extended APIs (so that it interacts with the rest of VS)
and so on.

> But who knows.  It might turn out that the amount of work required
> to able to build forms interactively is minimial.

So perhaps _you_ can make a flourishing business from that? If not,
you perhaps have to believe others (Randy) that they decided against
for very good reasons. As with the pudding: The proof is in the eating
-- I'll believe you're right, if I see someone doing the VS
integration you're demanding and succeeding. After his/her product is
on the market for some years I might even buy it enad perhaps use it. 

Until then, and that is the important point, I won't trust most of my
code to some GUI builder, because I know that Make and Emacs will be
there in 10 years, but the GUI builder might not. And I hate what
happens to my application when tool vendors go out of the market.

> That functionality already exists for multiple languages. 
> Perhaps there are nice classes that just need to have the details of the 
> language defined.  That sort of thing certainly didn't exist in the past, 
> certainly not from Microsoft, but you never used to be able do download a 
> compiler for free from Microsoft either.


>> Still my point applies: You cannot imagin building GUIs w/o
>> "interactively building" etc. My suspicion why there is no market for
>> GUI builders is:
>>

> Actually, on the contrary I think this is one of the reason there is 
> (almost) no market for Ada in the general computing community.

Actually this is one of the generic usenet arguments: "I have pet
peeve X. I think this is the reason why your interest Y has no market". 

Give me some corroboration.


> I went through the process of justifying the choice of language for a system 
> several years ago.  At the time I was able to move things toward Ada.  Since 
> then matters beyond my control have moved things toward C++ and C#.
>
> In my experience, when the choice of a programming language has to be 
> justified, any capability that choice A has over choice B is part of the 
> consideration.  Sometimes the reasons are real, sometimes they are not. 
> That's just the way things work.  Unfortunately with Ada the GUI generally 
> goes in the disadvantage category.

Actually I don't think so. At least for Gnat there is binding to a
portable tool kit. This is an advantage, not a disadvantage (at least
in some quarters).

Regards -- Markus

Re: GNAT for MS Visual Studio

[Michael Bode]

Markus E L
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Until then, and that is the important point, I won't trust most of my
> code to some GUI builder, because I know that Make and Emacs will be
> there in 10 years, but the GUI builder might not. And I hate what
> happens to my application when tool vendors go out of the market.

But you trust your code to some GUI library. And the library vendor
(or the main or single contributor to the libray OSS project) might go
out of business. Or he might change the license in some way you don't
like. 

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: GNAT for MS Visual Studio

[Markus E L]

Michael Bode wrote:

> Markus E L
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> Until then, and that is the important point, I won't trust most of my
>> code to some GUI builder, because I know that Make and Emacs will be
>> there in 10 years, but the GUI builder might not. And I hate what
>> happens to my application when tool vendors go out of the market.
>
> But you trust your code to some GUI library. And the library vendor
> (or the main or single contributor to the libray OSS project) might go
> out of business. Or he might change the license in some way you don't
> like. 

Absolutely right. A library, at least in theory, is forkable. If not
by the community, that it can be still maintained inhouse for a number
of years. This is exactly what I intend to do with GtkAda 2.4. for the
very project where I got bitten by the well known time travelling
license.

Personally I think it's more realistic to fork/maintain a library than
a tool, though you certainly are right with the point you're making.

Regards -- Markus

Re: GNAT for MS Visual Studio

[Ole-Hjalmar Kristensen]

MS Visual Studio GUI development reflects state of the art when I quit
actively working in the field more than 10 years ago. I am not impressed.
-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: GNAT for MS Visual Studio

[Steve]

"Ole-Hjalmar Kristensen" 
<ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message 
news:wvbrabr9hq0t.fsf@astra06.norway.sun.com...
> MS Visual Studio GUI development reflects state of the art when I quit
> actively working in the field more than 10 years ago. I am not impressed.

Unfortunately comparing Ada GUI development to MS Visual Studio makes me 
depressed (because I'd rather be doing GUI development in Ada!).

Steve

> -- 
>   C++: The power, elegance and simplicity of a hand grenade. 

Re: GNAT for MS Visual Studio

[Markus E L]

"Steve" wrote:

> "Ole-Hjalmar Kristensen" 
> <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message 
> news:wvbrabr9hq0t.fsf@astra06.norway.sun.com...
>> MS Visual Studio GUI development reflects state of the art when I quit
>> actively working in the field more than 10 years ago. I am not impressed.
>
> Unfortunately comparing Ada GUI development to MS Visual Studio makes me 
> depressed (because I'd rather be doing GUI development in Ada!).

Steve, 

I'd like to press my point: Have you ever seriously considered not
using a GUI builder but building a GUI "by hand", just instantiating
and inserting the widget where needed? It might seem tedious at the
beginning, but, in my experience doesn't make much more work in the
long run. Furthermore it provides opportunities too, because if highly
dynamic GUIs are required (e.g. Widgets being replaced or removed
dependent on the state of the program or editing process), GUI
builders can't provide that (whereas "manual instantiation" has no
problems), and there is also the opportunity to tweak layout,
alignment, colours and inserting modified custom widgets.

GUI builders are fine if you're programming for paper-shufflers:
Everything is a "form" than, as it was in the time of paper forms.

But interactive software needs to be smarter -- and that is what GUI
builders can't provide in my (admittedly limited and perhaps dated
experience). So if I end up anyway not being able to use the GUI
builder, I could as well learn how to use the tool kit in the language
proper.

That said, I admit, I often use Glade to mock up a GUI for discussion
and demo screenshots. But more often than not, I'm also putting that
into code manually after I found what I (or the client) has been
looking for. Might be peculiarity of mine, though.

Regards -- Markus

Re: GNAT for MS Visual Studio

[Michael Bode]

Markus E L
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> I'd like to press my point: Have you ever seriously considered not
> using a GUI builder but building a GUI "by hand", just instantiating
> and inserting the widget where needed?

I did that in my first GtkAda programs just to learn how things work
and then started to use Glade. It saves me much stupid typing.

> Furthermore it provides opportunities too, because if highly
> dynamic GUIs are required (e.g. Widgets being replaced or removed
> dependent on the state of the program or editing process), GUI
> builders can't provide that

You can easily combine both methods by designing the static components
of the GUI with the builder and leaving space where you can insert the
dynamic components programmatically. 

I find it rather difficult to imagine the layout of a window just
from reading code. 

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: GNAT for MS Visual Studio

[Markus E L]

Michael Bode wrote:

> Markus E L
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> I'd like to press my point: Have you ever seriously considered not
>> using a GUI builder but building a GUI "by hand", just instantiating
>> and inserting the widget where needed?
>
> I did that in my first GtkAda programs just to learn how things work
> and then started to use Glade. It saves me much stupid typing.
>
>> Furthermore it provides opportunities too, because if highly
>> dynamic GUIs are required (e.g. Widgets being replaced or removed
>> dependent on the state of the program or editing process), GUI
>> builders can't provide that

> You can easily combine both methods by designing the static components
> of the GUI with the builder and leaving space where you can insert the
> dynamic components programmatically. 

That's an idea, admittedly, though I've discovered, to my damage, it
also only will fly so far ...

> I find it rather difficult to imagine the layout of a window just
> from reading code.

Actually, I'm often drawing with paper and pencil. And since I'm
building all the time, usually after adding a handful of widgets,
there is no problem getting the necessary feedback what the state of
affairs is.

Actually I think, we don't contradict each other, really. Steve asked
for a GUI builder, asserting that none of those he tried works well. I
on the other side assert that even building by hand works well enough,
one don't _need_ a GUI builder in the long run. You say, that glade
works better than building the GUI manually in most cases, so actually
you're supporting my point: Steve could try building manually, or
faster by using Glade. But saying: I can't implement GUIs b/c I have
no fancy GUI builder is a NOP any way.

Regards -- Markus

Re: GNAT for MS Visual Studio

[Jean-Pierre Rosen]

Michael Bode a �crit :
> Markus E L
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
> 
>> I'd like to press my point: Have you ever seriously considered not
>> using a GUI builder but building a GUI "by hand", just instantiating
>> and inserting the widget where needed?
> 
> I did that in my first GtkAda programs just to learn how things work
> and then started to use Glade. It saves me much stupid typing.
> 
Interesting... I did it just the other way round. First used Glade to 
learn what code corresponded to casual interfaces, understand the 
general arrangement, etc. Then I started adding things by hand.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GNAT for MS Visual Studio

[michael bode]

Jean-Pierre Rosen schrieb:

> Interesting... I did it just the other way round. First used Glade to 
> learn what code corresponded to casual interfaces, understand the 
> general arrangement, etc. Then I started adding things by hand.

I simply started with tutorials and simple 'Hello World' programs, then 
added a few own widgets and moved on to the first programs that did 
something useful. And I was not impressed when I found out that on 
Windows Glade/Gate have problems when you edit the generated code. I 
solved that problem by avoiding Gate and using libglade instead.

Oh, I too add things by hand. There are cases when it makes sense to 
e.g. have arrays of widgets which you can create in a loop and handle in 
a common event handler.

Re: GNAT for MS Visual Studio

[Steve]

"Markus E L" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message news:ltfy11y10v.fsf@hod.lan.m-e-leypold.de...
> Steve,
>
> I'd like to press my point: Have you ever seriously considered not
> using a GUI builder but building a GUI "by hand", just instantiating
> and inserting the widget where needed? It might seem tedious at the
> beginning, but, in my experience doesn't make much more work in the
> long run. Furthermore it provides opportunities too, because if highly
> dynamic GUIs are required (e.g. Widgets being replaced or removed
> dependent on the state of the program or editing process), GUI
> builders can't provide that (whereas "manual instantiation" has no
> problems), and there is also the opportunity to tweak layout,
> alignment, colours and inserting modified custom widgets.
>

To me that's too much like asking the question:
  Have you seriously considered not using a programming language and 
compiler and just programming in machine code?

  When you have a visual tool for creating a user interface, you can do 
things like restructure a window to meet new requirements with very little 
effort.  In some cases you don't have to edit the code at all to bring about 
a significant change in appearance.

  Yes I have built up windows the hard way.  I have done so using GWindows. 
If you have a fairly static application, where the user interface changes 
infrequently, it isn't a very big deal.  But if you have an application that 
is revised frequently then if you don't have a visual tool for updating the 
UI after a relatively short time the UI degrades to something that is 
functional but just doesn't look good or is awkward to work with.

> GUI builders are fine if you're programming for paper-shufflers:
> Everything is a "form" than, as it was in the time of paper forms.
>
> But interactive software needs to be smarter -- and that is what GUI
> builders can't provide in my (admittedly limited and perhaps dated
> experience). So if I end up anyway not being able to use the GUI
> builder, I could as well learn how to use the tool kit in the language
> proper.

If the components that are placed on forms are dynamic, and there is 
automatic interaction between the components on a form (like there is with 
.NET) then things can be very dynamic.

Most of the applications I work on have to do with sawmill automation. 
Scanning logs at various stages of processing and optimizing the breakdown 
decisions and process.  The application requires a lot of configuration to 
describe the machinery, the products being produced, and rules on how to cut 
things.  There are dozens of dialogs in the system.  Trying to maintain 
these using hand coded windows is just plain silly.  Parts of the system are 
very dynamic... displaying 3d images of material being processed, diagnostic 
information, etc.

Regards,
Steve
(The Duck)

>
> That said, I admit, I often use Glade to mock up a GUI for discussion
> and demo screenshots. But more often than not, I'm also putting that
> into code manually after I found what I (or the client) has been
> looking for. Might be peculiarity of mine, though.
>
> Regards -- Markus
>

Re: GNAT for MS Visual Studio

[Markus E L]

"Steve" wrote:

> "Markus E L" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
> wrote in message news:ltfy11y10v.fsf@hod.lan.m-e-leypold.de...
>> Steve,
>>
>> I'd like to press my point: Have you ever seriously considered not
>> using a GUI builder but building a GUI "by hand", just instantiating
>> and inserting the widget where needed? It might seem tedious at the
>> beginning, but, in my experience doesn't make much more work in the
>> long run. Furthermore it provides opportunities too, because if highly
>> dynamic GUIs are required (e.g. Widgets being replaced or removed
>> dependent on the state of the program or editing process), GUI
>> builders can't provide that (whereas "manual instantiation" has no
>> problems), and there is also the opportunity to tweak layout,
>> alignment, colours and inserting modified custom widgets.
>>
>
> To me that's too much like asking the question:
>   Have you seriously considered not using a programming language and 
> compiler and just programming in machine code?

I thought so. Hence (a) my comment that you're caught in this
Microsoft mind set and (b) my attempt to make you reconsider: The
relationship between a Toolkit and a GUI builder, IMHO, is not
analogous to that between assembler and a ("high level") programming
language.

But, as I see it, at the moment there are few things to convince you
otherwise. So please understand my comments as comments, not as an
attempt to convince you.

>   When you have a visual tool for creating a user interface, you can do 
> things like restructure a window to meet new requirements with very little 
> effort.  In some cases you don't have to edit the code at all to bring about 

The thing that comes into my mind is, that (a) the requirements should
have been fixed much earlier and (b) restructuring is handled by
moving constructor calls.

Furthermore the very situation that is difficult to handle, that you
have integrated widgets into an abstraction (like "customer data
browser") cannot be handled with GUI builders at all and in this
situation it is improbable that you will move widgets over the
abstraction boundary.

So then w/o a GUI builder I'm only moving a call

   New_Cusomer_Browser(...)

to another place, with a GUI builder I haven't built an abstraction
from the very beginning.

That is perhaps the main point in my slightly jumbled commentary: GUI
builders don't allow you to build abstractions. Using GUI builders
doesn't scale and doesn't promote reuse (of GUI subsystems).

> a significant change in appearance.

If editing code is a pain for you, then you have a point. Only that I
personally, don't trust programmers that have a difficult relationship
to editing code -- it's their business. 

>   Yes I have built up windows the hard way.  I have done so using GWindows. 
> If you have a fairly static application, where the user interface changes 
> infrequently, it isn't a very big deal.  But if you have an application that 
> is revised frequently then if you don't have a visual tool for updating the 
> UI after a relatively short time the UI degrades to something that is 
> functional but just doesn't look good or is awkward to work with.


W/o knowing the details it's hard to say what went wrong. Of course
structuring GUIs so that they stay maintainable is an art on itself,
very much like structuring programs so that they stay maintainable
(the key is modularization).

With GUIs the GUI builders don't help you in the task. They just help
the GUI keeps looking nice. The business logic behind will get jumbled
anyway.

Furthermore: I'd be surprised if, even with a GUI build you could just
pick an element out of context and move it to some far away place.

That _only_ works, if you're having something that resembles paper
forms, which in turn IMHO hardly deserve the name GUI. But if you
e.g. have a browser for status records for network nodes, you'll
hardly ever move GUI elements from there into some other context,
since you need access to the network nodes status to show the widget
element.

Which gives me the idea that GUI builders tend to promote spaghetti
code in the underlying application.

>> GUI builders are fine if you're programming for paper-shufflers:
>> Everything is a "form" than, as it was in the time of paper forms.
>>
>> But interactive software needs to be smarter -- and that is what GUI
>> builders can't provide in my (admittedly limited and perhaps dated
>> experience). So if I end up anyway not being able to use the GUI
>> builder, I could as well learn how to use the tool kit in the language
>> proper.
>
> If the components that are placed on forms are dynamic, and there is 
> automatic interaction between the components on a form (like there is with 
> .NET) then things can be very dynamic.

If you define this as "dynamic", yes. I doubt really complicated stuff
can be specified by interacting with the mouse.


> Most of the applications I work on have to do with sawmill automation. 
> Scanning logs at various stages of processing and optimizing the breakdown 
> decisions and process.  The application requires a lot of configuration to 
> describe the machinery, the products being produced, and rules on how to cut 
> things.  There are dozens of dialogs in the system.  

Dialogs. Complicated, sequential forms. No direct inteaction
interface. There you are.

> Trying to maintain these using hand coded windows is just plain
> silly.  Parts of the system are very dynamic... displaying 3d images
> of material being processed, diagnostic information, etc.

This is not what I call dynamic.

BTW: Nobody asked you to maintain your system "using hand coded
windows". If you don't want and have a GUI builder, please don't. But
you asked for a GUI builder that isn't there, implicating live is to
complicated w/o one. I still doubt it is.


Regards -- Markus

Re: GNAT for MS Visual Studio

[Steve]

"Markus E L" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message news:4xsl4zw3bp.fsf@hod.lan.m-e-leypold.de...
>
> "Steve" wrote:
>>
>> To me that's too much like asking the question:
>>   Have you seriously considered not using a programming language and
>> compiler and just programming in machine code?
>
> I thought so. Hence (a) my comment that you're caught in this
> Microsoft mind set and (b) my attempt to make you reconsider: The
> relationship between a Toolkit and a GUI builder, IMHO, is not
> analogous to that between assembler and a ("high level") programming
> language.
>

BTW: I mentioned to my co-workers that I had been described as being 
pro-Microsoft.  They laughed out loud.  You certainly have the wrong idea.

IMNSHO the tools and techniques for software design and development continue 
to change over time.  It is important be aware of and keep an open mind 
about new methods as they appear.  Not doing so will render you obsolete.

Every time the next great tool comes out, I take note.  First I don't spend 
much time learning the details, since many of these great revelations fade 
after a short period of time.  But after the tool has been out for a while I 
investigate it on my own, ignoring they hype, and make my own judgement as 
to whether or not the tools is really a good thing.

This is how I came to appreciate Ada, and this is how I came to appreciate 
visual GUI development tools.

> The thing that comes into my mind is, that (a) the requirements should
> have been fixed much earlier and (b) restructuring is handled by
> moving constructor calls.

That works well for software requirements that are static, and don't evolve 
over time.

> Furthermore the very situation that is difficult to handle, that you
> have integrated widgets into an abstraction (like "customer data
> browser") cannot be handled with GUI builders at all and in this
> situation it is improbable that you will move widgets over the
> abstraction boundary.
>
> So then w/o a GUI builder I'm only moving a call
>
>   New_Cusomer_Browser(...)
>
> to another place, with a GUI builder I haven't built an abstraction
> from the very beginning.
>
> That is perhaps the main point in my slightly jumbled commentary: GUI
> builders don't allow you to build abstractions. Using GUI builders
> doesn't scale and doesn't promote reuse (of GUI subsystems).

With the .NET framework you can create a base form and derive other forms 
from the base form.  If that doesn't promote re-use, I don't know what does.

> If editing code is a pain for you, then you have a point. Only that I
> personally, don't trust programmers that have a difficult relationship
> to editing code -- it's their business.
>

My business isn't editing code.  My business is producing and maintaining 
applications in the most cost effective way possible.  Sure programmers can 
create code for maintaining GUI's with code.  They can also write their own 
databases and code in machine code.

But usually the most cost effective way to develop things is to take 
advantage of high level tools that do much of the job for you.

With a decent GUI development tool I can generate most of the code required 
to maintain the GUI automatically.  Doing so by hand is ceratainly possible, 
but it is much less productive.  If the tool doesn't sigificantly reduce the 
amount of effort do generate the UI... don't use it!  It's not a good tool. 
If the tool does significantly reduce the amount of effort to generate the 
UI, you don't use it, and you're in a competetive environment, you won't 
continue to compete for long.

> W/o knowing the details it's hard to say what went wrong. Of course
> structuring GUIs so that they stay maintainable is an art on itself,
> very much like structuring programs so that they stay maintainable
> (the key is modularization).
>

If the effort to develop a GUI interface takes days, weeks, or months. 
Careful design is critical.  The resources invested in development are 
significant, and it is important to get it right the first time.

If the effor to develop the GUI part of the interface takes minutes, careful 
design OF THE GUI is less critical.  The design of the business part of the 
application is still critical, but since changing the GUI is trivial it 
becomes less importaint to get it right the first time.

In my experience there have been may occasions where conventional wisdom has 
been to present information a particular manner.  Then for some unforseen 
reason a different view of the same information that is much more intuitive 
comes to light.  If the GUI is independent of the business part of the 
application it isn't a big deal and it is tivial to adapt.  If the GUI is 
closely tied to the business part of the application your hands may be tied.

> That _only_ works, if you're having something that resembles paper
> forms, which in turn IMHO hardly deserve the name GUI. But if you
> e.g. have a browser for status records for network nodes, you'll
> hardly ever move GUI elements from there into some other context,
> since you need access to the network nodes status to show the widget
> element.
>

In my experience the GUI builders do most, but not all of the work for you. 
You still have to write code for the pieces that tie things together.  With 
a good GUI builder, more than 90% of the GUI code will be generated 
automatically.

> Which gives me the idea that GUI builders tend to promote spaghetti
> code in the underlying application.

Spaghetti code can be generated equally well by either technique.

>>> GUI builders are fine if you're programming for paper-shufflers:
>>> Everything is a "form" than, as it was in the time of paper forms.
>>>
>>> But interactive software needs to be smarter -- and that is what GUI
>>> builders can't provide in my (admittedly limited and perhaps dated
>>> experience). So if I end up anyway not being able to use the GUI
>>> builder, I could as well learn how to use the tool kit in the language
>>> proper.
>>
>> If the components that are placed on forms are dynamic, and there is
>> automatic interaction between the components on a form (like there is 
>> with
>> .NET) then things can be very dynamic.
>
> If you define this as "dynamic", yes. I doubt really complicated stuff
> can be specified by interacting with the mouse.
>

You may still have to do a little coding to handle the dynamic parts.  But 
just because you have to write 50 lines of code by hand, doesn't mean you 
can't have the other 500 generated automatically.

>> Most of the applications I work on have to do with sawmill automation.
>> Scanning logs at various stages of processing and optimizing the 
>> breakdown
>> decisions and process.  The application requires a lot of configuration 
>> to
>> describe the machinery, the products being produced, and rules on how to 
>> cut
>> things.  There are dozens of dialogs in the system.
>
> Dialogs. Complicated, sequential forms. No direct inteaction
> interface. There you are.
>

A pretty quick judgment for never having seen our application.

>> Trying to maintain these using hand coded windows is just plain
>> silly.  Parts of the system are very dynamic... displaying 3d images
>> of material being processed, diagnostic information, etc.
>
> This is not what I call dynamic.

Describe just what you conder to be dynamic.

> BTW: Nobody asked you to maintain your system "using hand coded
> windows". If you don't want and have a GUI builder, please don't. But
> you asked for a GUI builder that isn't there, implicating live is to
> complicated w/o one. I still doubt it is.

The viewpoint you are presenting reminds me of a paper that circulated on 
the Internet many many moons ago.  It was entitled something like "Real 
Programmers Don't use Pascal".  IIRC it said something like: Real 
programmers don't use Pascal, they use FORTRAN.  If it can't be programmed 
in FORTRAN they use machine code.  If it can't be programmed in machine 
code, it isn't worth doing.

In my programmers Utopia, a GUI Ada tool would magically appear.  People 
(like me) who constantly experiment with different development tools would 
try it and discover the wonders of Ada.  The market share of Ada would grow, 
Ada vendord would thrive, and Ada would gain mainstream acceptance.

Regards,
Steve
(The Duck)

>
>
> Regards -- Markus 

Re: GNAT for MS Visual Studio

[Randy Brukardt]

"Steve" <nospam_steved94@comcast.net> wrote in message
news:YcCdnaCp_dEWKmLbnZ2dnUVZ_qqgnZ2d@comcast.com...
...
> > That is perhaps the main point in my slightly jumbled commentary: GUI
> > builders don't allow you to build abstractions. Using GUI builders
> > doesn't scale and doesn't promote reuse (of GUI subsystems).
>
> With the .NET framework you can create a base form and derive other forms
> from the base form.  If that doesn't promote re-use, I don't know what
does.

Whether that is really reuse depends on what you mean by "derive". If the
derivation is one-time (a copy), then there is little effective reuse,
because every change to the base would have to be manually reflected in the
copies. (This is the only kind of derivation I have seen in GUI builders,
admittedly I haven't looked at many.) And as you have pointed out, a system
that doesn't change is not very likely.

OTOH, what I want (and have done in some of my Claw programs) is to create a
dialog (could call it a form if you like) that takes parameters. In my case,
it was a name and a registry location. Thus, the dialog would work the same
way for each use, but get data (and have an appropriate title) from
different locations for different uses. It turned out that writing that
abstract GUI module by hand (once) allowed it to be used twenty or so times:
in GUI builder code. And of course fixing a bug in it will fix all of the
uses at once.

I could have used the GUI builder to create it, but I would have ended up
with twenty copies that would each have to have been changed for any minor
correction -- which hardly would have saved any development time.

...
...
> If the effort to develop a GUI interface takes days, weeks, or months.
> Careful design is critical.  The resources invested in development are
> significant, and it is important to get it right the first time.
>
> If the effor to develop the GUI part of the interface takes minutes,
careful
> design OF THE GUI is less critical.  The design of the business part of
the
> application is still critical, but since changing the GUI is trivial it
> becomes less importaint to get it right the first time.

But there is no possibility of the GUI taking minutes. You have to at the
very least type in the names of the labels for the controls/widgets,
possibly define some of the data types, etc. Only the very smallest GUIs can
be done in "minutes". (There is one exception: the direct conversion of a
record type into a dialog, which can be automated if you don't care about
the result apperance. But that only would work for very simple systems - no
menus or dynamism is possible for that.)

...
> In my programmers Utopia, a GUI Ada tool would magically appear.

You should say "an Ada GUI tool THAT I FIND ACCEPTABLE", because of course
there are many Ada GUI tools out there. You said you tried them and didn't
like them, which surely is a reasonable opinion, but you should at least
acknowledge that others may find them quite useful.

> People (like me) who constantly experiment with different development
tools would
> try it and discover the wonders of Ada.  The market share of Ada would
grow,
> Ada vendord would thrive, and Ada would gain mainstream acceptance.

My experience in the Ada business suggests that no single 'X' could be a
magic bullet that would increase the acceptance of Ada. If you actually
tried to make 'X' available, by the time you got it done, the world would
have moved on. (i.e. Claw). If there is any magic way to increase Ada usage,
it would be to get ahead of the curve on something (multi-core comes to
mind: us Ada people have been doing that sort of programming for 25 years)
and market it for all it is worth.

But my personal, cynical view is that Ada cannot really succeed, because few
are really interested in doing things well. (IMHO, that's what's Ada is
really about, even if we don't always get that right.) Most only care enough
to hack something out to get by. And Ada will never be about hacking
something out.

Of course, there are enough people who do care about doing things well to
keep Ada around. But it probably will remain a niche language.

                               Randy.

Re: GNAT for MS Visual Studio

[Peter C. Chapin]

Randy Brukardt wrote:

> Of course, there are enough people who do care about doing things well to
> keep Ada around. But it probably will remain a niche language.

It's kind of sad when quality is a niche. Although I do understand the
dynamics that make it so.

Peter

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 2 Pa , 05:50, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> If there is any magic way to increase Ada usage,
> it would be to get ahead of the curve on something (multi-core comes to
> mind: us Ada people have been doing that sort of programming for 25 years)

And during these 25 years you have made it actually difficult (!) to
leverage the power of multitasking. The fact that I cannot have
concurrent tasks operating in read-only mode on the shared container
is a fatal mistake. This is something even C++ can do, which
ironically does not even officially support threads.

Unfortunately, it's not the Ada people that can do this. The game is
driven by CPU vendors themselves, because it is them who show
directions.

One of such directions is this:

http://osstbb.intel.com/

I very much appreciate the experience that the Ada community gathered
in the area of multitasking in the context of RT systems, but this is
not enough to gain significant visibility in the multicore game. It
just seems to be a different business and one of the places where this
divergence is clearly visible is that after these 25 years you still
miss the lock-free-algorithms boat.

In short: multicore is about performance, not about Ravenscar.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Pascal Obry]

Maciej Sobczak a �crit :
> And during these 25 years you have made it actually difficult (!) to
> leverage the power of multitasking. The fact that I cannot have
> concurrent tasks operating in read-only mode on the shared container
> is a fatal mistake. This is something even C++ can do, which
> ironically does not even officially support threads.

????? I must be missing your point as this is definitely possible with
Ada tasking.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 2 Pa , 22:45, Pascal Obry <pas...@obry.net> wrote:

> > The fact that I cannot have
> > concurrent tasks operating in read-only mode on the shared container
> > is a fatal mistake. This is something even C++ can do, which
> > ironically does not even officially support threads.
>
> ????? I must be missing your point as this is definitely possible with
> Ada tasking.

It is not::

http://www.adaic.org/standards/05aarm/html/AA-A-18.html

4.o/2:

"Library packages must be reentrant - multiple tasks can use the
packages as long as they operate on separate containers. Thus, it is
only necessary for a user to protect a container if a single container
needs to be used by multiple tasks."

There is no distinction between "use" and "modification", even though
one might try to deduce it from the fact that in some container
operations the container itself is passed as "in" parameter. Without
this distinction spelled out black on white the only thing the
programmer can do is to protect the container systematically whenever
he performs *any* operation on it.

John Barnes writes about this in the relevant chapter of "Programming
in Ada 2005" as well.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Pascal Obry]

Maciej Sobczak a �crit :
> It is not::
> 
> http://www.adaic.org/standards/05aarm/html/AA-A-18.html

"use" here does not mean "modification". I don't even start to
understand what could be wrong to have two tasks "reading" the same
container. The container won't change, so this can't be a problem.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 3 Pa , 21:40, Pascal Obry <pas...@obry.net> wrote:

> The container won't change, so this can't be a problem.

The visible state of the container might not change, but the container
is free to do some accounting, for example with cursors, to ensure the
ability to catch any misuse.

I understand your point entirely, but I don't see it in AARM.

There is one thing that might help here - the documentation of the
given library implementation.

Anybody knows what are the guarantees provided by GNAT?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 3 Pa , 22:08, Maciej Sobczak <see.my.homep...@gmail.com> wrote:

> > The container won't change, so this can't be a problem.
>
> The visible state of the container might not change, but the container
> is free to do some accounting, for example with cursors, to ensure the
> ability to catch any misuse.
>
> I understand your point entirely, but I don't see it in AARM.

There is more to it:

http://www.adaic.org/standards/05aarm/html/AA-A.html

3/2:

"The implementation shall ensure that each language- defined
subprogram is reentrant  in the sense that concurrent calls on the
same subprogram perform as specified, so long as all parameters that
could be passed by reference denote nonoverlapping objects."

Which means that I cannot call *any* of containers' subprogram
concurrently with the same container as a parameter (unless it's
passed by value, which is not the case, because containers are
tagged).

If this restriction is not true for containers (as one would actually
expect if multicore is of any interest), then some explicit big-font
exception should be somewhere there either in A or A.18.x. Nothing
like this exist, so A-3/2 holds.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Pascal Obry]

Maciej Sobczak a �crit :
> http://www.adaic.org/standards/05aarm/html/AA-A.html
> 
> 3/2:
> 
> "The implementation shall ensure that each language- defined
> subprogram is reentrant  in the sense that concurrent calls on the
> same subprogram perform as specified, so long as all parameters that
> could be passed by reference denote nonoverlapping objects."

Fine but we are speaking about "reading" only the parameters. This does
not apply.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 4 Pa , 22:21, Pascal Obry <pas...@obry.net> wrote:

> >http://www.adaic.org/standards/05aarm/html/AA-A.html
>
> > 3/2:
>
> > "The implementation shall ensure that each language- defined
> > subprogram is reentrant  in the sense that concurrent calls on the
> > same subprogram perform as specified, so long as all parameters that
> > could be passed by reference denote nonoverlapping objects."
>
> Fine but we are speaking about "reading" only the parameters. This does
> not apply.

I understand you, but I don't see this exclusion in the paragraph
above.

What I see is "subprogram", "calling", "parameter" and "overlapping".
I don't see *any* distinction between reading and writing.

I other words, the obvious guarantee that both of us would like to see
in AARM is not there and what *is* there indicates the contrary.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: concurrent access to containers (was: GNAT for MS Visual Studio)

[Georg Bauhaus]

On Fri, 2007-10-05 at 06:25 -0700, Maciej Sobczak wrote:
> On 4 Pa , 22:21, Pascal Obry <pas...@obry.net> wrote:
> 
> > >http://www.adaic.org/standards/05aarm/html/AA-A.html
> >
> > > 3/2:
> >
> > > "The implementation shall ensure that each language- defined
> > > subprogram is reentrant  in the sense that concurrent calls on the
> > > same subprogram perform as specified, so long as all parameters that
> > > could be passed by reference denote nonoverlapping objects."
> >
> > Fine but we are speaking about "reading" only the parameters. This does
> > not apply.
> 
> I understand you, but I don't see this exclusion in the paragraph
> above.
> 
> What I see is "subprogram", "calling", "parameter" and "overlapping".
> I don't see *any* distinction between reading and writing.
> 
> I other words, the obvious guarantee [...]

I don't think it is obvious that something of this sort
should be guaranteed (read-only access from multiple tasks is
possible, and trouble free). For example, algorithms used
by search engines or by distributed databases do not
necessarily shy away from copying shared data. So nothing is
physically shared in these systems and algorithms at the level
will be free of concurrent access even though the system
is concurrent. It still works on exactly one virtually shared
set of data...

Should standard container design assume it makes sense to
restrict implementers by assuming one specific computer
architecture like shared memory with multiple CPUs?

Or should standard container design assume that multiple
copies of data will be ubiquitous given current hardware options?

Can an Ada standard library assume that there is a compare
and swap operation available on typical 8bit or 16bit CPUs?
What if there isn't?

Re: GNAT for MS Visual Studio

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 3 Pa , 21:40, Pascal Obry <pas...@obry.net> wrote:
>
>> The container won't change, so this can't be a problem.
>
> The visible state of the container might not change, but the
> container is free to do some accounting, for example with cursors,
> to ensure the ability to catch any misuse.

If the library is not protected internally against concurrent access
then it would be a clever implementation that could guarantee even to
detect misuse. I suppose it could do something involving pragma Atomic
and a use count.

I had thought that the Booch Components would be readably shared, but
not so -- the Unbounded and Unmanaged forms maintain a simple internal
cache which isn't atomic and could be trashed by concurrent access.

> There is one thing that might help here - the documentation of the
> given library implementation.

The only info you can rely on is that in the standard, of course.

Re: GNAT for MS Visual Studio

[Matthew Heaney]

On Oct 3, 2:40 pm, Pascal Obry <pas...@obry.net> wrote:
>
> "use" here does not mean "modification". I don't even start to
> understand what could be wrong to have two tasks "reading" the same
> container. The container won't change, so this can't be a problem.

No, this is incorrect.  The container keeps track of nested calls
(e.g. Query_Element, Iterate) using a count, in order to prevent
container misuse (e.g. deleting the element while it's being
queried).  So even though the logical view of the container doesn't
change, then physical view does change, and so the standard requires
that multiple tasks accessing a container must be properly
synchronized, even when the access is read-only.

Re: GNAT for MS Visual Studio

[Pascal Obry]

Matthew Heaney a écrit :
> No, this is incorrect.  The container keeps track of nested calls
> (e.g. Query_Element, Iterate) using a count, in order to prevent
> container misuse (e.g. deleting the element while it's being
> queried).  So even though the logical view of the container doesn't
> change, then physical view does change, and so the standard requires
> that multiple tasks accessing a container must be properly
> synchronized, even when the access is read-only.

Outch! Big mistake to require this to me :(

Maybe something like "Don’t let best be enemy of good" !

That's probably the first time I'm very surprised and annoy by an Ada
design decision. It seems that there is good reasons... but frankly not
something really user friendly to me :(

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Sat, 06 Oct 2007 17:03:44 +0200, Pascal Obry wrote:

> Matthew Heaney a ļæ½crit :

>> No, this is incorrect.  The container keeps track of nested calls
>> (e.g. Query_Element, Iterate) using a count, in order to prevent
>> container misuse (e.g. deleting the element while it's being
>> queried).  So even though the logical view of the container doesn't
>> change, then physical view does change, and so the standard requires
>> that multiple tasks accessing a container must be properly
>> synchronized, even when the access is read-only.
> 
> Outch! Big mistake to require this to me :(

Why? The container type is not protected, thus you cannot expect it
functioning as if it were the latter.

BTW, I guess if placing a container into a protected object and accessing
it from a function of, might be erroneous on a multi-core platform. Here
two permissions collide: a protected object function can share, the
object's container component cannot. The compiler should change the
implementation of either. Would it?

> Maybe something like "Donļæ½t let best be enemy of good" !

It is rather "We didn't want to change the language to much," like by
making protected types tagged, by introducing pure functions, by allowing
in-out function parameters. It was not the best, not even good...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GNAT for MS Visual Studio

[Pascal Obry]

Dmitry A. Kazakov a ļæ½crit :
> Why? The container type is not protected, thus you cannot expect it
> functioning as if it were the latter.

Please read the thread we are just talking about *read* access to the
container.

   type Whatever is tagged record
      ...
   end record;

You can definitely read an object of type Whatever from multiple tasks.
You don't have to use a protected object.

You can also read the memory pointed to any access type from multiple
tasks. You don't have to use a protected object.

So I was expecting the same from a container.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Sat, 06 Oct 2007 19:07:24 +0200, Pascal Obry wrote:

>    type Whatever is tagged record
>       ...
>    end record;
> 
> You can definitely read an object of type Whatever from multiple tasks.
> You don't have to use a protected object.
>
> You can also read the memory pointed to any access type from multiple
> tasks. You don't have to use a protected object.

AFAIK, ARM is silent about this. The most close reference is 9(8):

"In addition, tasks can communicate indirectly by reading and updating
(unprotected) shared variables, presuming the access is properly
synchronized through some other kind of task interaction."

Note: "properly synchronized." Unsynchronized reading and updating are
explicitly classified as erroneous execution in 9.10. But nothing is said
about reading and reading.

As a thought experiment (admittedly unrealistic) consider Ada tasks running
on a multi-core processor assessing at low level shared core memory (with
destructive reads).

My guess is that at least pragma Atomic_Components (Whatever); is required.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 6 Pa , 20:30, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >    type Whatever is tagged record
> >       ...
> >    end record;
>
> > You can definitely read an object of type Whatever from multiple tasks.
> > You don't have to use a protected object.
>
> > You can also read the memory pointed to any access type from multiple
> > tasks. You don't have to use a protected object.
>
> AFAIK, ARM is silent about this. The most close reference is 9(8):
>
> "In addition, tasks can communicate indirectly by reading and updating
> (unprotected) shared variables, presuming the access is properly
> synchronized through some other kind of task interaction."

Note that introducing some causal ordering (a.k.a. signalling) is
enough to make it safe.

Consider a main task that populates the shared object *and then*
starts N tasks that concurrently read the shared data (the main task
does not interfere with the data anymore). There is a causal
relationship between populating and reading which is guaranteed by
task activation. See 9.10/4. The tasks can safely read the data.

In other words, it is perfectly imaginable to set up a set of tasks
that concurrently read the same data without any additional hassle
like protected objects. So - Pascal is right that this is in principle
possible.
At the same time this is explicitly forbidden for containers.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Sat, 06 Oct 2007 13:32:47 -0700, in comp.lang.ada you wrote:

> On 6 Pa , 20:30, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>>    type Whatever is tagged record
>>>       ...
>>>    end record;
>>
>>> You can definitely read an object of type Whatever from multiple tasks.
>>> You don't have to use a protected object.
>>
>>> You can also read the memory pointed to any access type from multiple
>>> tasks. You don't have to use a protected object.
>>
>> AFAIK, ARM is silent about this. The most close reference is 9(8):
>>
>> "In addition, tasks can communicate indirectly by reading and updating
>> (unprotected) shared variables, presuming the access is properly
>> synchronized through some other kind of task interaction."
> 
> Note that introducing some causal ordering (a.k.a. signalling) is
> enough to make it safe.
>
> Consider a main task that populates the shared object *and then*
> starts N tasks that concurrently read the shared data (the main task
> does not interfere with the data anymore). There is a causal
> relationship between populating and reading which is guaranteed by
> task activation. See 9.10/4. The tasks can safely read the data.
> 
> In other words, it is perfectly imaginable to set up a set of tasks
> that concurrently read the same data without any additional hassle
> like protected objects. So - Pascal is right that this is in principle
> possible.
> At the same time this is explicitly forbidden for containers.

I don't see any difference for containers. When reads are synchronized (by
whatever means) then everything is OK, so would be container reading.

[ For protected objects, it seems that functions do not signal, so I guess
it might be illegal to read a container component of a protected object
from its function unless the compiler chooses another implementation for
access from protected functions. This looks weird to me.]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 7 Pa , 09:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> I don't see any difference for containers. When reads are synchronized (by
> whatever means) then everything is OK, so would be container reading.

The difference is that you *don't* read a container. Instead, you
*call some function with some tagged object as a parameter*. This is
in some circles called "encapsulation", which can be translated as
"you have no idea what is really going on". ;-)

Reading works fine when you see the data directly, because you can
ensure full compliance with the rules. This is not true with
containers.

> [ For protected objects, it seems that functions do not signal

I would expect that protected procedures and entries signal functions,
but after careful reading of 9/2-9.b I'm puzzled.

What is a shared data outside the protected object?
If I have an access variable that is kept inside the protected object
- is the object (the target) considered to be inside the protected
object as well?
If not, and the target is not protected, then *lot's* of patterns
don't work and the whole world breaks into pieces, so I assume that
the target object is considered to be protected, not just the access
variable.

But since the object cannot know whether it is referenced and from
where, then I assume that I actually don't have to keep anything in
the protected object and I can use its subprograms to synchronize
access to some object that lives outside of it.
In which case 9/2-9.b is complete non-sense.

What am I missing?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Sun, 07 Oct 2007 14:30:20 -0700, Maciej Sobczak wrote:

> On 7 Pa , 09:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> I don't see any difference for containers. When reads are synchronized (by
>> whatever means) then everything is OK, so would be container reading.
> 
> The difference is that you *don't* read a container. Instead, you
> *call some function with some tagged object as a parameter*. This is
> in some circles called "encapsulation", which can be translated as
> "you have no idea what is really going on". ;-)

It is called "higher level language," which translates to "you cannot have
ideas even if you just do 'a read'". I.e. there is no difference.

>> [ For protected objects, it seems that functions do not signal
> 
> I would expect that protected procedures and entries signal functions,
> but after careful reading of 9/2-9.b I'm puzzled.
> 
> What is a shared data outside the protected object?
> If I have an access variable that is kept inside the protected object
> - is the object (the target) considered to be inside the protected
> object as well?

Certainly not.

> If not, and the target is not protected, then *lot's* of patterns
> don't work and the whole world breaks into pieces, so I assume that
> the target object is considered to be protected, not just the access
> variable.

Maybe those patterns are just wrong? (:-)) If you use an access
discriminant or component in a protected object, then the target shall not
be accessible otherwise than through a protected action traversing this
object.

I don't see any problems with procedures and entries, functions are my
concern.

> But since the object cannot know whether it is referenced and from
> where, then I assume that I actually don't have to keep anything in
> the protected object and I can use its subprograms to synchronize
> access to some object that lives outside of it.
> In which case 9/2-9.b is complete non-sense.

I am not sure what you mean here. You can safely access things outside
protected objects from protected actions. You can also use stateful
protected objects to enforce serialization (for example, by creating a
semaphore).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 8 Pa , 09:50, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> It is called "higher level language," which translates to "you cannot have
> ideas even if you just do 'a read'". I.e. there is no difference.

There is - others already explained that containers do some
bookkeeping even when they are "just" read. This bookkeeping is hidden
from you.

> > What is a shared data outside the protected object?
> > If I have an access variable that is kept inside the protected object
> > - is the object (the target) considered to be inside the protected
> > object as well?
>
> Certainly not.

Then certainly everything is FUBARed.

Consider a container inside the protected object. The container
presumably has access variables to actual contained objects (to
elements) - some containers just cannot be implemented any other way.
If the target objects are considered to be OUTside of the protected
object and thus unprotected, then I'm looking forward to see an
explanation how the synchronized manipulation of these contained
objects is supposed to work.

> Maybe those patterns are just wrong? (:-)) If you use an access
> discriminant or component in a protected object, then the target shall not
> be accessible otherwise than through a protected action traversing this
> object.

Yes. But is this guaranteed? AARM seems to say that objects outside of
the protected objects are not synchronized. Is the target object
covered or not?

Consider this:

protected P is
   procedure Set (I : Integer);
   function Get return Integer;
end P;

Value : Integer;
protected body P is
   procedure Set (I : Integer) is
   begin
      Value := I;
   end Set;

   function Get return Integer is
   begin
      return Value;
   end Get;
end P;

Assume that users only interact with the protected object (Value can
be in the package body, etc.).
Is it compliant? As far as I understand AARM (9.10/9.b), it is not.
Value is OUTside of the protected object.

If it's not, then just adding access value to Value will not make any
difference, unless access values have some implicit magic properties
in the area of memory consistency.

> I don't see any problems with procedures and entries, functions are my
> concern.

See above. Is it "kosher"? If yes, then 9.10/9.b is unclear to me. If
not, then there is no way to synchronize a container that is
implemented in terms of references (linked lists, etc.).

> I am not sure what you mean here. You can safely access things outside
> protected objects from protected actions.

Can you confront it with 9.10/9.b?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 8 Pa , 12:32, Maciej Sobczak <see.my.homep...@gmail.com> wrote:


> Consider a container inside the protected object. The container
> presumably has access variables to actual contained objects (to
> elements) - some containers just cannot be implemented any other way.
> If the target objects are considered to be OUTside of the protected
> object and thus unprotected, then I'm looking forward to see an
> explanation how the synchronized manipulation of these contained
> objects is supposed to work.

Problem solved. The "missing part" is actually on the same page in
AARM, just few paragraphs later:

http://www.adaic.org/standards/05aarm/html/AA-9-10.html

14, 14.a, 14.b.

The latter is particularly significant, meaning that my example with
protected object used for protecting global variable is compliant.

It's not signalling which is important, but sequential execution and
signalling is not the only way to enforce sequential execution.

Still, 9.b and 14.b don't seem to be consistent with each other.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Mon, 08 Oct 2007 03:32:44 -0700, Maciej Sobczak wrote:

> On 8 Pa , 09:50, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> It is called "higher level language," which translates to "you cannot have
>> ideas even if you just do 'a read'". I.e. there is no difference.
> 
> There is - others already explained that containers do some
> bookkeeping even when they are "just" read. This bookkeeping is hidden
> from you.

There is no difference, because in a higher level language reading might do
bookkeeping as well. 

The contract is silent about what happens when you are not allowed to
access the object. Anything can.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 8 Pa , 17:10, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> There is no difference, because in a higher level language reading might do
> bookkeeping as well.

But the object model would be formulated accordingly to take this into
account.
In Ada, the object model and concurrency model are formulated in such
a way that "reading" an encapsulated container is meaningless and
therefore inconclusive.
We cannot say "I only read this container" and expect anything based
on AARM, because there is nothing in AARM that would give any meaning
to this "reading".
Calling a subprogram is not "reading".

> The contract is silent about what happens when you are not allowed to
> access the object. Anything can.

Yes.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Mon, 08 Oct 2007 13:40:57 -0700, Maciej Sobczak wrote:

> We cannot say "I only read this container" and expect anything based
> on AARM, because there is nothing in AARM that would give any meaning
> to this "reading".

Well, I agree that "reading" need to be clarified, but as I said before,
IMO the problem is deeper. First we need to define pure subprograms and
sharable objects. Then we would be able to say, for example, that reading
an Integer is safe because in-instances are sharable and all methods of are
pure. Then we could proceed to aggregation types and their operations. Only
after that we could say that reading an Integer component of a record type
is safe. A read-safe container type could be specified in the same way.

> Calling a subprogram is not "reading".

Right, the reverse is true: "reading" is calling a [maybe built-in]
subprogram "Read."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GNAT for MS Visual Studio

[Matthew Heaney]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 356 bytes --]

On Oct 6, 10:03 am, Pascal Obry <pas...@obry.net> wrote:
> Matthew Heaney a écrit :
>
> Outch! Big mistake to require this to me :(

Well, this particular issue was hotly debated.  I lobbied to allow
multiple readers to safely access the container simultaneously, but
the ARG decided otherwise.  Hey, you win some and you lose some.

-Matt

Re: GNAT for MS Visual Studio

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]

"Pascal Obry" <pascal@obry.net> wrote in message
news:4707A3D0.3070702@obry.net...
> Matthew Heaney a �crit :
> > No, this is incorrect.  The container keeps track of nested calls
> > (e.g. Query_Element, Iterate) using a count, in order to prevent
> > container misuse (e.g. deleting the element while it's being
> > queried).  So even though the logical view of the container doesn't
> > change, then physical view does change, and so the standard requires
> > that multiple tasks accessing a container must be properly
> > synchronized, even when the access is read-only.
>
> Outch! Big mistake to require this to me :(
>
> Maybe something like "Don't let best be enemy of good" !
>
> That's probably the first time I'm very surprised and annoy by an Ada
> design decision. It seems that there is good reasons... but frankly not
> something really user friendly to me :(

If you want dangerously unsafe containers, you are welcome to write them
yourself. But they don't belong in the standard (surely not as the sole
example of containers).

For me, the most important advantage of the containers is that they can be
made safe (in the absence of unsafe operations on an object containing a
container). It's not necessary to have any operations that fail to detect
dangling cursors and the like -- this is a big advantage over directly using
access types to create a list or vector. But such implementations require
housekeeping even for reading.

Similarly, the case that Matt mentioned would make it trivial to have
undetected errors that could cause serious trouble down the road. We were
explicitly asked to minimize the cases of erroneous execution (that is,
totally unpredictable result); it's quite possible that the containers would
have been rejected altogether if we had not followed that recommendation.

The implementations that I've been planning to use for the containers would
require locking in order to provide any task safety -- meaning that I would
have had to either give up on safety or performance -- not a good trade-off.

The containers having different rules than those for *all* other Ada
libraries (including things like matrix operations) would be weird, to say
the least.

Anyway, the point is that a lot of thought and debate went into this
decision. We also started a project to create a set of protected containers
for multitasking use (not much is happening with it, though, as its priority
is lower than the ASIS update and fixing bugs in the standard).

                      Randy.

Re: GNAT for MS Visual Studio

[Pascal Obry]

Randy Brukardt a �crit :
> If you want dangerously unsafe containers, you are welcome to write them
> yourself. But they don't belong in the standard (surely not as the sole
> example of containers).

I love those nonsense ! How can something that is only read be unsafe!!!
And please between "dangerously unsafe containers" and "concurrent read
access containers" I think there is some room. Why always having such
strong and extreme position????

Look it is not that unusual to have a container populated for a
simulation that after initialization point does not need to be updated
but only *read*. I have many concurrent simulations like this. I would
have expected to be able to use the containers in this case.

The recurrent saying "if you don't like this, do it yourself" in
comp.lang.ada is just a big mistake for Ada as a whole. This decision is
just counter intuitive for anybody having done a bit of computer science :(

Anyway I had to say that :)

Now maybe some operations could be made safe, like those not using
cursors. For example, in Ada.Containers.Vectors:

   function Element
     (Container : Vector;
      Index     : Index_Type) return Element_Type;

Why this could not be made safe ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Sun, 07 Oct 2007 09:21:40 +0200, Pascal Obry wrote:

> Now maybe some operations could be made safe, like those not using
> cursors. For example, in Ada.Containers.Vectors:
> 
>    function Element
>      (Container : Vector;
>       Index     : Index_Type) return Element_Type;
> 
> Why this could not be made safe ?

It can, but it is useless as long this safety is not expressed by the
contract of Vector. So the choices are:

1. to make all operations safe
2. to declare a safe subtype of Vector with only safe operations available
3. to introduce the notion of "safe operation" and to declare Element "safe
operation," using a pragma.

Neither works. 1) is distributed overhead, 2) is impossible due to the
language limitations, 3) is a mess [and possibly distributed overhead].

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GNAT for MS Visual Studio

[Georg Bauhaus]

Pascal Obry wrote:
> Randy Brukardt a �crit :
>> If you want dangerously unsafe containers, you are welcome to write them
>> yourself. But they don't belong in the standard (surely not as the sole
>> example of containers).
> 
> I love those nonsense ! How can something that is only read be unsafe!!!

I think because objects may involve access values, be passed
by reference, etc. (The sentence corresponding to this thread
in Barnes (2006) is brief and illuminating, bottom of page 642.)

Then there is separate compilation which for a start cannot in general
know about a Vector reference being used read-only in a program?

I guess Randy did hint at implementation issues and possibilities.


> And please between "dangerously unsafe containers" and "concurrent read
> access containers" I think there is some room. Why always having such
> strong and extreme position????

There was a question about concurrent reads from protected
objects and why concurrent function calls on a protected object
(in GNAT) still use a semaphore. Any news on this related issue?
(IIRC, Stephen Leake wanted to ask AdaCore about this. )

The moment a Container could potentially be updated the read
only model suffers. How could we express a countermeasure in Ada,
e.g. a Freeze operation suitably defined, but not involving
a protected object? At what cost?

I imagine that a red-black tree used for implementing Ordered_Map
might be in a surprising state when an Insert by a potential task B
is interrupted by a reading task A. So we would have to have a
way to express, at compile time, that there is no such B
when A is about to start.
Maybe this could justify relaxing the protection requirements.

Re: GNAT for MS Visual Studio

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> Look it is not that unusual to have a container populated for a
> simulation that after initialization point does not need to be
> updated but only *read*. I have many concurrent simulations like
> this. I would have expected to be able to use the containers in this
> case.

I suppose you could just copy the initialized container! (depends
rather on the size, of course).

task body T is
  C : Container;
begin
  accept Start (Using : Container) do
    C := Using;
  end Start;

--S

Re: GNAT for MS Visual Studio

[Georg Bauhaus]

On Sun, 2007-10-07 at 18:44 +0100, Simon Wright wrote:
> Pascal Obry <pascal@obry.net> writes:
> 
> > Look it is not that unusual to have a container populated for a
> > simulation that after initialization point does not need to be
> > updated but only *read*. I have many concurrent simulations like
> > this. I would have expected to be able to use the containers in this
> > case.
> 
> I suppose you could just copy the initialized container! (depends
> rather on the size, of course).

Or even copy the container's elements to the most
efficient data structure we have for read only data.
Matt has explained many times that generic algorithms for
containers work with arrays, too.

What are typical use cases for containers? Do we have a
collection of use cases?
Are there others than the simulation Pascal has been mentioning?
(I guess theses are larger data sets and a few updates every
now and then?)

More use cases will warrant writing one of the alternative
container implementations that the Ada docs are suggesting.

(And BTW, how many caches of what sizes can we expect to be
present in upcoming releases of multicore CPU systems? Will this
be enough justification for requiring unlocked concurrent reads,
or shared single memory tricks in standard containers?
What about the likely properties of multiprocessor Sparc
systems? How will cell processors evolve and what does this mean
for Ada's standard containers?)

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 8 Pa , 11:52, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>

> Or even copy the container's elements

Memory is cheap. :-)

What if there is *not* enough memory? I have a data structure that
takes 1GB and 100 tasks that read it.

> What are typical use cases for containers? Do we have a
> collection of use cases?

A container of use cases will be needed to store them. ;-)
BTW - Does it count as a use-case itself?

> Are there others than the simulation Pascal has been mentioning?

A dictionary?

> More use cases will warrant writing

I don't think this is a good approach - it's a chicken&egg problem.
If there are no containers to do the job, then programmers will
successfully do this job with other languages and they will never
express their use cases here, so you will not find any justification
for implementing them in Ada, thus scaring even more programmers off
and so on.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Georg Bauhaus]

On Mon, 2007-10-08 at 03:42 -0700, Maciej Sobczak wrote:

> If there are no containers to do the job, then programmers will
> successfully do this job with other languages and they will never
> express their use cases here, so you will not find any justification
> for implementing them in Ada, thus scaring even more programmers off
> and so on.

Agreed, but certainly it will be interesting to learn about alleged
types of container usage in other languages. (Besides arrays.
I'm not sure it makes sense to compare arrays in Fortran, APL,
or Ada to arrays in C++'s STL, say).

Re: GNAT for MS Visual Studio

[Georg Bauhaus]

On Mon, 2007-10-08 at 03:42 -0700, Maciej Sobczak wrote:
> On 8 Pa , 11:52, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>

> > Are there others than the simulation Pascal has been mentioning?
> 
> A dictionary?

Good example, I think, because analysis will have to consider two times.
I'm assuming that after loading the dictionary, no changes are made.

Likely, a program will iterate these steps:

1)  protect read access
2)  find the key and possibly deliver the value

What are the relative times?

(I have a program of this sort, using rather large dictionaries,
as a Java webapp. Maybe I can compare its times to an AWS based
solution.)

Re: GNAT for MS Visual Studio

[Pascal Obry]

Maciej Sobczak a �crit :
> A dictionary?

Exactly, I was talking about dictionaries.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Mon, 08 Oct 2007 11:52:21 +0200, Georg Bauhaus wrote:

> What are typical use cases for containers? Do we have a
> collection of use cases?
> Are there others than the simulation Pascal has been mentioning?
> (I guess theses are larger data sets and a few updates every
> now and then?)

Don't forget locking scenarios. Decisive is whether the thing is 1-1, 1-n,
m-1, m-n reading-updating. No less important is composability when A)
accesses are merged together in a sequence of actions upon which the access
level can be upgraded from read to update or downgraded; when B) accesses
to independent objects are intermixed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GNAT for MS Visual Studio

[Pascal Obry]

Simon Wright a �crit :
> I suppose you could just copy the initialized container! (depends
> rather on the size, of course).

Not really an option when the container is large.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 7 Pa , 09:21, Pascal Obry <pas...@obry.net> wrote:

> The recurrent saying "if you don't like this, do it yourself" in
> comp.lang.ada is just a big mistake for Ada as a whole.

Yes. Especially when it's intermixed with claims that Ada allows to
finish the project earlier when compared to "other" languages.

Sorry, but reinventing every wheel have *never* made any project
faster. Not only because it's just directly more work - there is also
indirectly more work with all the new bugs that get introduced on the
way.
Implement my own container? Is this what high-level programming is
about?

Sorry, I had to say that.

> Now maybe some operations could be made safe, like those not using
> cursors. For example, in Ada.Containers.Vectors:
>
>    function Element
>      (Container : Vector;
>       Index     : Index_Type) return Element_Type;
>
> Why this could not be made safe ?

I believe it could.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> On 7 Pa , 09:21, Pascal Obry <pas...@obry.net> wrote:
> 
>> The recurrent saying "if you don't like this, do it yourself" in
>> comp.lang.ada is just a big mistake for Ada as a whole.
> 
> Yes. Especially when it's intermixed with claims that Ada allows to
> finish the project earlier when compared to "other" languages.

Most of the data that supports that claim comes from the use of Ada 83, 
which had very little in the way of a standard library, so users had to 
write almost everything themselves. It seems likely, therefore, that it 
will continue to be true for Ada today, even if you have to write a data 
structure yourself.

> Sorry, but reinventing every wheel have *never* made any project
> faster. Not only because it's just directly more work - there is also
> indirectly more work with all the new bugs that get introduced on the
> way.
> Implement my own container? Is this what high-level programming is
> about?

There's really no need to reinvent the wheel in this case. There are 
plenty of Ada libraries available. The PragmAda Reusable Components, for 
example, have data structures that may safely be read by multiple tasks, 
IIRC.

-- 
Jeff Carter
"I'm a kike, a yid, a heebie, a hook nose! I'm Kosher,
Mum! I'm a Red Sea pedestrian, and proud of it!"
Monty Python's Life of Brian
77

Re: GNAT for MS Visual Studio

[Simon Wright]

"Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes:

> There's really no need to reinvent the wheel in this case. There are
> plenty of Ada libraries available. The PragmAda Reusable Components,
> for example, have data structures that may safely be read by
> multiple tasks, IIRC.

Perhaps I should take the caching feature out of the BCs .. I have no
evidence that they actually make an improvement in practice!

Re: GNAT for MS Visual Studio

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5624 bytes --]

"Pascal Obry" <pascal@obry.net> wrote in message
news:47088904.1090201@obry.net...
> Randy Brukardt a �crit :
> > If you want dangerously unsafe containers, you are welcome to write them
> > yourself. But they don't belong in the standard (surely not as the sole
> > example of containers).
>
> I love those nonsense ! How can something that is only read be unsafe!!!
> And please between "dangerously unsafe containers" and "concurrent read
> access containers" I think there is some room. Why always having such
> strong and extreme position????

You have to consider the whole of the containers, not individual operations.
There are so many operations that having special rules for each one would be
a nightmare.

In any case, one size of container does not fit all. Having safe containers
that have write operations (whether they are used or not) requires having
checking, and that checkings needs to do bookkeeping. That means that safe
containers with multi-read access are going to require locks somewhere;
that's enough of a performance hit that it's dubious that it should be
required for the "base" containers.

If you are willing to have unsafe containers, then you don't need locks.
That's all I was talking about, and there is nothing extreme about that
position. The only thing that could be potentially called extreme is the
insistence on the possibility of safe containers. But is anyone really
against safety?

> Look it is not that unusual to have a container populated for a
> simulation that after initialization point does not need to be updated
> but only *read*. I have many concurrent simulations like this. I would
> have expected to be able to use the containers in this case.

The containers are only expected to be useful in 80% of the cases. The plan
is that there will be additional famiilies of containers to cover other
common use cases (particularly task-safe uses). We simply didn't have time
to expend effort on those additional families for the Amendment.

The standard rule in Ada, for *any* subprogram (in the absense of
documentation to the contrary), is that it must be called with
non-overlapping actual parameters if used from multiple tasks (or some
synchronization be used). You must never expect concurrent read to work
unless it is in the contract. It's most consistent to apply that to all of
the "base" library routines. (And yes, I think all user-written code should
either work when called by multiple tasks (for different objects) or be
documented that it doesn't work.)

> The recurrent saying "if you don't like this, do it yourself" in
> comp.lang.ada is just a big mistake for Ada as a whole. This decision is
> just counter intuitive for anybody having done a bit of computer science
:(

I don't buy this. Expecting that everything that you might want to do is
already done for you is a mark of a newbie. If it was that easy to program,
there would be no need for software professionals (or computer science).
There's a heck of a lot more to programming than just making a bunch of
subprogram calls.  The whole point is to know when it is better to do it
yourself, by knowing what the requirements of your application and whatever
is available.

In the specific case of the containers, there is no possibility of the
standard defining every possible combination of performance/memory
management/concurrency control (and I've probably forgotten some
properties). If you have strong needs in one of those areas, then you will
probably need to write something yourself. It is folly to expect the
predefined library to do everything for you. (Moreover, most of the time, it
is just premature optimization anyway; the predefined containers will be
fine.)

If you need concurrent access, then you should use the protected containers.
It's legitimate to gripe that they don't exist yet - it is annoying that the
standard for the protected containers isn't progressing faster, because it
is obvious that there is a need for such things. (It's tied up with the
bounded containers and various other forms. And so far as I know, no one has
tried to define in RM language what it means for a container to be
protected.)

> Anyway I had to say that :)
>
> Now maybe some operations could be made safe, like those not using
> cursors. For example, in Ada.Containers.Vectors:
>
>    function Element
>      (Container : Vector;
>       Index     : Index_Type) return Element_Type;
>
> Why this could not be made safe ?

It could, so long as you don't allow it to be combined with any other
container operation. Trying to define that in RM wording seems difficult to
me (all resource sharing issues are very hard to define in proper standards
language). Witness the thread on the meaning of 9.10.

Moreover, as I previously mentioned, it would be inconsistent with the
"normal" usage of Ada routines. It's a lot easier to remember to never
concurrently access a "basic" container than to try to remember the specific
cases where concurrent access is allowed. I personally think that such a
rule would lead to more (not less) container misuses, and quite likely
pressure on vendors to go beyond the standard in this area.

It would be easier to correctly use "protected" (task-safe) containers in
concurrent uses than ones that only allowed a small amount of concurrency.
Not everyone is an expert in concurrency, after all.

In any case, there is a master plan here; the problem is mostly a lack of
resources to execute that plan. (Sigh, I sound like a broken record on that
topic -- it applies equally to Ada itself and to Janus/Ada.)

                                  Randy.

Re: GNAT for MS Visual Studio

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> It would be easier to correctly use "protected" (task-safe)
> containers in concurrent uses than ones that only allowed a small
> amount of concurrency.  Not everyone is an expert in concurrency,
> after all.

Clearly one can protect a single container, either by wrapping it in
(for example) a protected object; or by providing an internal
mechanism.

But it's been my experience that applications that involve containers
at all usually involve more than one container, in the same way that a
database application usually involves more than one table. With either
implementation technology, you have to preserve integrity. And in the
Ada case, that means locking more than one container object at the
same time.

The BCs had a form where each container object was constrained by (an
access to) a sharable mutex object; so you could form a group of
container objects with a common mutual exclusion mechanism.

But the only way I could see to make this work was to grab the mutex
using an open protocol:

   grab the mutex;
   manipulate the containers;
   release the mutex;

and once you've done that, there's no point in having the containers
mutex-aware -- just use the plain sort, with external mutex. Which is
why the BCs no longer have support for concurrency.

Re: GNAT for MS Visual Studio

[Randy Brukardt]

"Simon Wright" <simon.j.wright@mac.com> wrote in message
news:m2d4vo80jj.fsf@mac.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
> > It would be easier to correctly use "protected" (task-safe)
> > containers in concurrent uses than ones that only allowed a small
> > amount of concurrency.  Not everyone is an expert in concurrency,
> > after all.
>
> Clearly one can protect a single container, either by wrapping it in
> (for example) a protected object; or by providing an internal
> mechanism.
>
> But it's been my experience that applications that involve containers
> at all usually involve more than one container, in the same way that a
> database application usually involves more than one table. With either
> implementation technology, you have to preserve integrity. And in the
> Ada case, that means locking more than one container object at the
> same time.

I think that depends on how coupled the application is. For instance, my
spam filter has message tokens that move throughout the system, and the only
synchronized containers needed are the queues for those tokens. Each task is
waiting on a specific queue, operates on the token it receives, and then
puts the token back on a particular queue. No multi-access needed here. I
wrote the queues manually, but I probably would have used a protected
container if one was available.

So, the net effect is that YMMV: every application is different, and they
have different needs. One size never fits all. At best, we can fit most.

                              Randy.

Re: GNAT for MS Visual Studio

[Jeffrey R. Carter]

Randy Brukardt wrote:
> 
> I think that depends on how coupled the application is. For instance, my
> spam filter has message tokens that move throughout the system, and the only
> synchronized containers needed are the queues for those tokens. Each task is
> waiting on a specific queue, operates on the token it receives, and then
> puts the token back on a particular queue. No multi-access needed here. I
> wrote the queues manually, but I probably would have used a protected
> container if one was available.

I know of concurrent real-time systems that have used 
PragmARC.Queue_Bounded_Blocking, and concurrent non-real-time systems 
that have used PragmARC.Queue_Unbounded_Blocking, successfully. These 
are basically unprotected queues wrapped in a protected type.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14

Re: GNAT for MS Visual Studio

[Simon Wright]

Simon Wright <simon.j.wright@mac.com> writes:

> Which is why the BCs no longer have support for concurrency.

What I should have said is that the Containers don't have support for
concurrency. There are semaphores, mutexes and locks.

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Tue, 09 Oct 2007 22:01:52 +0100, Simon Wright wrote:

> The BCs had a form where each container object was constrained by (an
> access to) a sharable mutex object; so you could form a group of
> container objects with a common mutual exclusion mechanism.
> 
> But the only way I could see to make this work was to grab the mutex
> using an open protocol:
> 
>    grab the mutex;
>    manipulate the containers;
>    release the mutex;
> 
> and once you've done that, there's no point in having the containers
> mutex-aware -- just use the plain sort, with external mutex. Which is
> why the BCs no longer have support for concurrency.

I think that a potential way out could be protected actions on multiple
objects. Provided, protected types were normal [tagged] types and protected
entries and procedures were normal subprograms:

type A is protected ...;
type B is protected ...;

entry Swap (X : in out A; Y : in out B);
   -- The primitive protected operation/entry of A and B has a queue,
   -- starts one protected action on both A and B, sees the members
   -- of both.

[This requires multiple dispatch, of course]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Licensing again (was Re: GNAT for MS Visual Studio)

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> http://osstbb.intel.com/

Following this up I see

  http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html

which is a refreshingly clear statement!

--S

Re: GNAT for MS Visual Studio

[Steve]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:fdsf0r$q0t$1@jacob-sparre.dk...
> "Steve" <nospam_steved94@comcast.net> wrote in message
> news:YcCdnaCp_dEWKmLbnZ2dnUVZ_qqgnZ2d@comcast.com...
> ...
>> > That is perhaps the main point in my slightly jumbled commentary: GUI
>> > builders don't allow you to build abstractions. Using GUI builders
>> > doesn't scale and doesn't promote reuse (of GUI subsystems).
>>
>> With the .NET framework you can create a base form and derive other forms
>> from the base form.  If that doesn't promote re-use, I don't know what
> does.
>
> Whether that is really reuse depends on what you mean by "derive". If the
> derivation is one-time (a copy), then there is little effective reuse,
> because every change to the base would have to be manually reflected in 
> the
> copies. (This is the only kind of derivation I have seen in GUI builders,
> admittedly I haven't looked at many.) And as you have pointed out, a 
> system
> that doesn't change is not very likely.
>

What I mean by derive is in the sense of deriving classes.  A "form" in .NET 
is derived from a base form class.  You may add various controls to a form 
using visual tools.  When you derive one form from another, you get the 
controls from the original form in addition to any controls you add to the 
derived form.  If you add controls to the base form, they show upon all of 
the derived forms.

> OTOH, what I want (and have done in some of my Claw programs) is to create 
> a
> dialog (could call it a form if you like) that takes parameters. In my 
> case,
> it was a name and a registry location. Thus, the dialog would work the 
> same
> way for each use, but get data (and have an appropriate title) from
> different locations for different uses. It turned out that writing that
> abstract GUI module by hand (once) allowed it to be used twenty or so 
> times:
> in GUI builder code. And of course fixing a bug in it will fix all of the
> uses at once.

With .NET to create a form you create an instance of a class and call the 
ShowWindow method.  After creating the instance you can do anything you want 
to tailor it's behavior prior to calling ShowWindow.

>
> I could have used the GUI builder to create it, but I would have ended up
> with twenty copies that would each have to have been changed for any minor
> correction -- which hardly would have saved any development time.
>
> ...
> ...
>> If the effort to develop a GUI interface takes days, weeks, or months.
>> Careful design is critical.  The resources invested in development are
>> significant, and it is important to get it right the first time.
>>
>> If the effor to develop the GUI part of the interface takes minutes,
> careful
>> design OF THE GUI is less critical.  The design of the business part of
> the
>> application is still critical, but since changing the GUI is trivial it
>> becomes less importaint to get it right the first time.
>
> But there is no possibility of the GUI taking minutes. You have to at the
> very least type in the names of the labels for the controls/widgets,
> possibly define some of the data types, etc. Only the very smallest GUIs 
> can
> be done in "minutes". (There is one exception: the direct conversion of a
> record type into a dialog, which can be automated if you don't care about
> the result apperance. But that only would work for very simple systems - 
> no
> menus or dynamism is possible for that.)

What I should have said was something like GUI elements.  Certainly creating 
an entire interface will take more than minutes, but creating each 
individual form may only take minutes.  Creating the entire interface may 
take days or weeks with a high level tool.

> ...
>> In my programmers Utopia, a GUI Ada tool would magically appear.
>
> You should say "an Ada GUI tool THAT I FIND ACCEPTABLE", because of course
> there are many Ada GUI tools out there. You said you tried them and didn't
> like them, which surely is a reasonable opinion, but you should at least
> acknowledge that others may find them quite useful.
>

I acknowledge that these tools may be useful.  But the fact that some 
programmers consider hand coding to be comparable to using the tools is not 
a strong indication of their usefulness.

>> People (like me) who constantly experiment with different development
> tools would
>> try it and discover the wonders of Ada.  The market share of Ada would
> grow,
>> Ada vendord would thrive, and Ada would gain mainstream acceptance.
>
> My experience in the Ada business suggests that no single 'X' could be a
> magic bullet that would increase the acceptance of Ada. If you actually
> tried to make 'X' available, by the time you got it done, the world would
> have moved on. (i.e. Claw). If there is any magic way to increase Ada 
> usage,
> it would be to get ahead of the curve on something (multi-core comes to
> mind: us Ada people have been doing that sort of programming for 25 years)
> and market it for all it is worth.
>

I agree there is no magic bullet.  But there certainly are a number of 
impediments that may be removed.

I have watched a number of obstacles to choosing Ada disappear as the 
language has evolved:

  Ada 95 - Added OOP (tagged types)
               - Added protected types
               - Added interfaces to other languages
  Ada 2005 - Added interface inheritance
                  - Added a standard container library

> But my personal, cynical view is that Ada cannot really succeed, because 
> few
> are really interested in doing things well. (IMHO, that's what's Ada is
> really about, even if we don't always get that right.) Most only care 
> enough
> to hack something out to get by. And Ada will never be about hacking
> something out.
>

Personally I try to be more optimistic.  We have all seen things change 
radically in relatively short periods of time.  Remember how quickly Java 
(formerly Oak) came to the forefront?

There have been echo's of SPARK in the popular computing magazines that have 
interested people who are tired of many of the software development mishaps 
that seem to be happening these days.

Maybe the folks at Microsoft will get tired of trying to patch Windows using 
programming languages that are inherently unsafe and give Ada a shot on a 
pilot project.  You never know.

Steve
(The Duck)

> Of course, there are enough people who do care about doing things well to
> keep Ada around. But it probably will remain a niche language.
>
>                               Randy.
>

Re: GNAT for MS Visual Studio

[Ed Falis]

Steve wrote:
.
> Most of the applications I work on have to do with sawmill automation.
> Scanning logs at various stages of processing and optimizing the
> breakdown
> decisions and process.  The application requires a lot of
> configuration to
> describe the machinery, the products being produced, and rules on how
> to cut
> things.  There are dozens of dialogs in the system.  Trying to
> maintain
> these using hand coded windows is just plain silly.  Parts of the
> system are
> very dynamic... displaying 3d images of material being processed,
> diagnostic
> information, etc.

I realize this question is a bit OT, but are you doing these apps in
Ada?

- Ed

Re: GNAT for MS Visual Studio

[Steve]

"Ed Falis" <falis@verizon.net> wrote in message 
news:PM00043B332C21FE47@tilopa.unknown.dom...
> Steve wrote:
> .
>> Most of the applications I work on have to do with sawmill automation.
>> Scanning logs at various stages of processing and optimizing the
>> breakdown
>> decisions and process.  The application requires a lot of
>> configuration to
>> describe the machinery, the products being produced, and rules on how
>> to cut
>> things.  There are dozens of dialogs in the system.  Trying to
>> maintain
>> these using hand coded windows is just plain silly.  Parts of the
>> system are
>> very dynamic... displaying 3d images of material being processed,
>> diagnostic
>> information, etc.
>
> I realize this question is a bit OT, but are you doing these apps in
> Ada?

We were doing the optimization part of the software in Ada.  Most of the GUI 
was developed in Delphi.  If there had been a decent GUI development system 
for Ada, we would have used it.  The need for multiple development platforms 
is IMHO one of the reasons that our new generation of software does not 
include Ada.

Steve

>
> - Ed 

Re: GNAT for MS Visual Studio

[Vadim Godunko]

On Sep 29, 6:32 am, "Steve" <nospam_steve...@comcast.net> wrote:
>
> If there had been a decent GUI development system
> for Ada, we would have used it.  The need for multiple development platforms
> is IMHO one of the reasons that our new generation of software does not
> include Ada.
>
This is a reasons why we are start development an Ada binding for Qt.
I known at least two projects which use QtAda for GUI. One project
even rewrite existing Delphi GUI on Ada with QtAda. ;-)

Re: GNAT for MS Visual Studio

[Dmitry A. Kazakov]

On Wed, 26 Sep 2007 06:35:35 -0700, Steve wrote:

> Unfortunately comparing Ada GUI development to MS Visual Studio makes me 
> depressed (because I'd rather be doing GUI development in Ada!).

Hmm, actually Studio sufficiently worsened in that respect. Since the
version 5.0, I believe, the resource editor became just mad. It removes
your editing, creates new include files, uses wrong fonts in the dialog
boxes, replaces symbolic constants (#defines) with their values(!) etc.
Before I edit anything in the rc-file, I am forced to save it in a notepad.
Having editing finished I compare differences and restore what was
corrupted.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GNAT for MS Visual Studio

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
news:rkr7df.7mp.ln@hunter.axlog.fr...
> Steve a �crit :
...
> > This kind of interaction with building GUI applications is nothing new.
> > It's similar to the way things have worked with Visual Basic and Delphi
for
> > a long time.  Sadly Ada is lacking in this area.
> >
> What you describe is exactly what you get with GtkAda/Glade. Ada lacks
> nothing when you know where to look for...

He said specifically that GtkAda didn't work well for him on Windows.

Mine own experience has been that GtkAda programs are ugly Windows programs
(as are Java GUI ones). Of course, that's less of a problem these days when
virtually all programs have abandoned sane, clean appearing GUIs in favor of
masses of indescribable eye candy. I've pretty much given up
buying/downloading any software because the vast majority is either horrible
or ugly or slow or all three. (I write the vast majority of what I need in
Ada -- that's probably one of the signs of oncoming insanity. ;-)

                                     Randy.

Re: GNAT for MS Visual Studio

[Michael Bode]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Mine own experience has been that GtkAda programs are ugly Windows programs
> (as are Java GUI ones). Of course, that's less of a problem these days when
> virtually all programs have abandoned sane, clean appearing GUIs in favor of
> masses of indescribable eye candy. 

Maybe I'm kind of strange (I switch any Windows box I use back to W2k
Look & Feel) but neither Gimp nor Eclipse nor Netbeans looks
particularly ugly to me on Windows. The XP standard teletubby GUI
surely does however. My favorite are the gimmicks you get when you buy
a camera or scanner. Everyone tries to invent a whole new guy paradigm
with every single app. Totally useless crap. What a relief is Linux
where you have one GUI (xsane) for any scanner you connect. 

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: GNAT for MS Visual Studio

[Markus E L]

"Randy Brukardt" wrote:

> "Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
> news:rkr7df.7mp.ln@hunter.axlog.fr...
>> Steve a �crit :
> ...
>> > This kind of interaction with building GUI applications is nothing new.
>> > It's similar to the way things have worked with Visual Basic and Delphi
> for
>> > a long time.  Sadly Ada is lacking in this area.
>> >
>> What you describe is exactly what you get with GtkAda/Glade. Ada lacks
>> nothing when you know where to look for...
>
> He said specifically that GtkAda didn't work well for him on Windows.
>
> Mine own experience has been that GtkAda programs are ugly Windows programs
> (as are Java GUI ones). 

I have to contradict. My experience is otherwise. Perhaps the style
engines got better or I'm doing more tweaking to get a GUI that looks
well on both platforms.


> Of course, that's less of a problem these days when
> virtually all programs have abandoned sane, clean appearing GUIs in favor of
> masses of indescribable eye candy. I've pretty much given up
> buying/downloading any software because the vast majority is either horrible
> or ugly or slow or all three. (I write the vast majority of what I need in
> Ada -- that's probably one of the signs of oncoming insanity. ;-)

s/insanity/age/ :-)

Regards -- Markus

Re: GNAT for MS Visual Studio

[Pascal Obry]

Randy,

> Mine own experience has been that GtkAda programs are ugly Windows programs
> (as are Java GUI ones). 

That's not at all my experience. These days Gtk+ come with libwimp.dll
on  Windows which makes all Gtk+ applications using the Windows native
widgets. Look at GPS and The Gimp on Windows for example... The GUI just
looks good to me. Probably not perfect but far from what Java is
delivering on Windows!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT for MS Visual Studio

[Michael Bode]

Pascal Obry <pascal@obry.net> writes:

> That's not at all my experience. These days Gtk+ come with libwimp.dll
> on  Windows which makes all Gtk+ applications using the Windows native
> widgets. Look at GPS and The Gimp on Windows for example... The GUI just
> looks good to me. Probably not perfect but far from what Java is
> delivering on Windows!

Swing has pluggable look & feel too. If you switch on 'platform look &
feel' you get Windows look on Windows and GTK look with theming on
Linux. Maybe many Java programs simply use 'Metal' l&f because it
looks the same on all platforms, but that's easy to change with 2-3
lines of code.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: GNAT for MS Visual Studio

[Randy Brukardt]

"Steve" <nospam_steved94@comcast.net> wrote in message
news:QISdna5WdIMntGjbnZ2dnUVZ_rCtnZ2d@comcast.com...
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:fd1so0$lmu$1@jacob-sparre.dk...
...
> When creating a form in Visual Studio .NET, you drag and drop components
> from a tools window onto a form.  Visual Studo generates code in an
> InitializeComponent method that is called when a form is created.  You set
> up properties and events for the form by selecting the item on the form
and
> changing values in a property editor.
>
> This kind of interaction with building GUI applications is nothing new.
> It's similar to the way things have worked with Visual Basic and Delphi
for
> a long time.  Sadly Ada is lacking in this area.

There's nothing new here, and indeed, the overall design of the Claw builder
includes features like this. We only built about 15% of it before the world
changed too much to make much sense in continuing. I understand that users
don't care about such things, but please don't claim we were not aware of
what sort of things are possible.

...
> [snip]
> >
> > That I don't doubt. But to work with Microsoft, you have to have *very*
> > deep
> > pockets, and you can't care that they'll canabilize your work if you
have
> > success. It's not practical for any Ada company (and probably nearly
> > impossible for a real open source one).
>
> This is where things get interesing.  I would agree with this view if you
> had to start from scratch.  But these days you don't have to.
>
> For example Visual Studio 2005 allows you to customize the IDE.  There is
a
> Visual Studio SDK (which is a free download from Microsoft).  The VS SDK
> allows you to create VS "Packages" that integrate with Visual Studio and
may
> be used to support other languages.

I think you miss my point. Surely this sort of stuff exists, and has for a
long time. The problem is that Microsoft comes out with a new "greatest
thing" every year or two, and keeping up is just too much for most (all) Ada
vendors. Look at interfaces: Win32, MFC, .NET (several flavors), and now
Silverlight. All different; much of the work done with one will not
translate to another. Same with the programming tools: pretty much all of
the work we did integrating with previous Microsoft debuggers is not longer
of any value. You have to have a lot of money/customers in order to be able
to replace your products completely every couple of years.

I'm completely amazed that Adacore thinks (I presume, I doubt that they're
into throwing money away) that they can recoup an investment in .NET
(something which is likely to be obsolete in a few years as MS moves on to
the next big thing).

...
> The reason the majority of Ada users don't use GUI's is that existing Ada
> GUI's suck.  I am a strong advocate of Ada for everything but the user
> interface, because creating a GUI user interface in Ada is just too damn
> hard.  I've tried using ObjectAda's GUI builder, GtkAda, Claw, and Gnavi.
> The all have one thing in common... nice try, but not even close.  It is
> readily apparent that none of the developers did any serious work with VB,
> Delphi, or one of the other easy GUI development environments.

There is a good reason in the case of Claw: we purposely never tried any
other environments because we didn't want to be sued for copying them.
Moreover, we emphisized getting the bindings right; we never were able to
put the kind of effort into the Builder that we wanted to. (Remember, we
only implemented 15% of it, and almost none of the automated features,
including the dialog/property sheet generators, toolbar generators, and the
like.)

If we had built the Builder first, we would have ended up with a fancy
program that generated code for a binding that did work or didn't even
exist. It wouldn't have made any sense - no one would ever have used (or
been able to use) Claw.

                        Randy.

Re: GNAT for MS Visual Studio

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> If we had built the Builder first, we would have ended up with a fancy
> program that generated code for a binding that did work or didn't even
> exist. It wouldn't have made any sense - no one would ever have used (or
> been able to use) Claw.

Which is where GtkAda/Glade is now, on Windows.

-- 
-- Stephe

GNAT for MS Visual Studio

[Anatoly Chernyshev]

OK, I had no time to dig through all 99 posts. But I have my 2 cents
to contribute. I decided to myself long time ago that if I ever need
an interface for Ada program, that would be Visual Basic COM server
communicating with the Ada core through GNATCOM.

How it works: Ada core sends the commands to the VB server to show
certain information to the user. VB server is capable only of getting
the commands from the user and storing them in a buffer (simple array
of integers; each integer corresponds to a command). Only when the Ada
program decides to do so, it retrieves the commands from VB server and
processes them accordingly.

The best part of this "amateur architecture": if anyone hates the
particular implementation of the interface, he can always write his
own (text mode, Tcl/Tk, hardware, you name it). For example: I want to
program a Civilization-like game, but I don't want to get bogged in
fancy 3D interface quite yet. So I write quick text- mode interface,
where the green rectangle is e.g. forest, blue - water, etc., and the
units encoded with ASCII symbols... Now, when I'm satisfied with the
game engine, I may ask graphical savvy somebody to build the beautiful
interface in VB and then combine the both with a GNATCOM.

Well, talk is cheap... I have a complete Ada-VB program to model dunes
growth which implements the principles above. If anyone is interested
to take a look at it, drop me a line at achernyshev [doggie] g--m--a--
i--l [period] com. It comes complete with compiled executables,
sources and even documentation.

Re: GNAT for MS Visual Studio

[Maciej Sobczak]

On 13 Pa , 00:03, Anatoly Chernyshev <achernys...@gmail.com> wrote:

> I decided to myself long time ago that if I ever need
> an interface for Ada program, that would be Visual Basic COM server
> communicating with the Ada core through GNATCOM.

Makes sense. Java<->Ada makes sense as well. Same for Tcl/Tk<->Ada,
etc.

But for me the really interesting alternative, and fundamentally
different from the above, seems to be AWS. It can be embedded in the
core application.
Surely, not all GUI concepts have direct equivalents in html-based
solutions, but there is a wide range of applications where it would be
Just Fine.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: GNAT for MS Visual Studio

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 13 Pa , 00:03, Anatoly Chernyshev <achernys...@gmail.com> wrote:
>
>> I decided to myself long time ago that if I ever need
>> an interface for Ada program, that would be Visual Basic COM server
>> communicating with the Ada core through GNATCOM.
>
> Makes sense. Java<->Ada makes sense as well. Same for Tcl/Tk<->Ada,
> etc.
>
> But for me the really interesting alternative, and fundamentally
> different from the above, seems to be AWS. It can be embedded in the
> core application.
>
> Surely, not all GUI concepts have direct equivalents in html-based
> solutions, but there is a wide range of applications where it would
> be Just Fine.

I don't know whether AWS requires access to a file system, SSL etc,
but for a small-footprint alternative that doesn't (and that
definitely comes with GNAT-modified GPL!) see <a
href="http://embed-web-srvr.sourceforge.net>EWS</a>.

--S

Re: GNAT for MS Visual Studio

[Markus E L]

Simon Wright wrote:

> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>
>> On 13 Pa , 00:03, Anatoly Chernyshev <achernys...@gmail.com> wrote:
>>
>>> I decided to myself long time ago that if I ever need
>>> an interface for Ada program, that would be Visual Basic COM server
>>> communicating with the Ada core through GNATCOM.
>>
>> Makes sense. Java<->Ada makes sense as well. Same for Tcl/Tk<->Ada,
>> etc.
>>
>> But for me the really interesting alternative, and fundamentally
>> different from the above, seems to be AWS. It can be embedded in the
>> core application.
>>
>> Surely, not all GUI concepts have direct equivalents in html-based
>> solutions, but there is a wide range of applications where it would
>> be Just Fine.
>
> I don't know whether AWS requires access to a file system, SSL etc,
> but for a small-footprint alternative that doesn't (and that
> definitely comes with GNAT-modified GPL!) see <a
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Hear, hear.

(Just to make it hearable that there are still people out there in the
darkness who appreciate the GMGPL: Thank's to all who still release
their stuff as GMGPL).

Regards -- Markus