* GNAT for MS Visual Studio @ 2007-09-06 2:20 William J Thomas 2007-09-06 7:44 ` anon ` (2 more replies) 0 siblings, 3 replies; 103+ messages in thread From: William J Thomas @ 2007-09-06 2:20 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-06 2:20 GNAT for MS Visual Studio William J Thomas @ 2007-09-06 7:44 ` anon 2007-09-06 8:49 ` Rob Veenker 2007-09-11 3:15 ` Jeffrey Creem 2007-09-20 0:00 ` William J Thomas 2 siblings, 1 reply; 103+ messages in thread From: anon @ 2007-09-06 7:44 UTC (permalink / raw) 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? > > ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-06 7:44 ` anon @ 2007-09-06 8:49 ` Rob Veenker 2007-09-06 11:12 ` William J Thomas 0 siblings, 1 reply; 103+ messages in thread From: Rob Veenker @ 2007-09-06 8:49 UTC (permalink / raw) 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? >> >> ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-06 8:49 ` Rob Veenker @ 2007-09-06 11:12 ` William J Thomas 0 siblings, 0 replies; 103+ messages in thread From: William J Thomas @ 2007-09-06 11:12 UTC (permalink / raw) 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? >>> >>> ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-06 2:20 GNAT for MS Visual Studio William J Thomas 2007-09-06 7:44 ` anon @ 2007-09-11 3:15 ` Jeffrey Creem 2007-09-20 0:00 ` William J Thomas 2 siblings, 0 replies; 103+ messages in thread From: Jeffrey Creem @ 2007-09-11 3:15 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-06 2:20 GNAT for MS Visual Studio William J Thomas 2007-09-06 7:44 ` anon 2007-09-11 3:15 ` Jeffrey Creem @ 2007-09-20 0:00 ` William J Thomas 2007-09-21 0:46 ` Randy Brukardt 2 siblings, 1 reply; 103+ messages in thread From: William J Thomas @ 2007-09-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-20 0:00 ` William J Thomas @ 2007-09-21 0:46 ` Randy Brukardt 2007-09-21 3:27 ` William J Thomas 0 siblings, 1 reply; 103+ messages in thread From: Randy Brukardt @ 2007-09-21 0:46 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-21 0:46 ` Randy Brukardt @ 2007-09-21 3:27 ` William J Thomas 2007-09-21 17:31 ` Markus E L ` (2 more replies) 0 siblings, 3 replies; 103+ messages in thread From: William J Thomas @ 2007-09-21 3:27 UTC (permalink / raw) 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. > > > > ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-21 3:27 ` William J Thomas @ 2007-09-21 17:31 ` Markus E L 2007-09-21 18:13 ` Dmitry A. Kazakov 2007-09-22 1:59 ` Randy Brukardt 2 siblings, 0 replies; 103+ messages in thread From: Markus E L @ 2007-09-21 17:31 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-21 3:27 ` William J Thomas 2007-09-21 17:31 ` Markus E L @ 2007-09-21 18:13 ` Dmitry A. Kazakov 2007-09-22 1:42 ` Randy Brukardt 2007-09-22 1:59 ` Randy Brukardt 2 siblings, 1 reply; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-09-21 18:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-21 18:13 ` Dmitry A. Kazakov @ 2007-09-22 1:42 ` Randy Brukardt 0 siblings, 0 replies; 103+ messages in thread From: Randy Brukardt @ 2007-09-22 1:42 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-21 3:27 ` William J Thomas 2007-09-21 17:31 ` Markus E L 2007-09-21 18:13 ` Dmitry A. Kazakov @ 2007-09-22 1:59 ` Randy Brukardt 2007-09-22 5:19 ` Simon Wright 2007-09-22 14:42 ` Steve 2 siblings, 2 replies; 103+ messages in thread From: Randy Brukardt @ 2007-09-22 1:59 UTC (permalink / raw) "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. > > > > > > > > > > ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-22 1:59 ` Randy Brukardt @ 2007-09-22 5:19 ` Simon Wright 2007-09-22 14:42 ` Steve 1 sibling, 0 replies; 103+ messages in thread From: Simon Wright @ 2007-09-22 5:19 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-22 1:59 ` Randy Brukardt 2007-09-22 5:19 ` Simon Wright @ 2007-09-22 14:42 ` Steve 2007-09-24 8:14 ` Jean-Pierre Rosen 2007-09-25 2:32 ` Randy Brukardt 1 sibling, 2 replies; 103+ messages in thread From: Steve @ 2007-09-22 14:42 UTC (permalink / raw) "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. > ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-22 14:42 ` Steve @ 2007-09-24 8:14 ` Jean-Pierre Rosen 2007-09-25 1:44 ` Steve 2007-09-25 2:39 ` Randy Brukardt 2007-09-25 2:32 ` Randy Brukardt 1 sibling, 2 replies; 103+ messages in thread From: Jean-Pierre Rosen @ 2007-09-24 8:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-24 8:14 ` Jean-Pierre Rosen @ 2007-09-25 1:44 ` Steve 2007-09-25 6:41 ` Jean-Pierre Rosen ` (2 more replies) 2007-09-25 2:39 ` Randy Brukardt 1 sibling, 3 replies; 103+ messages in thread From: Steve @ 2007-09-25 1:44 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 1:44 ` Steve @ 2007-09-25 6:41 ` Jean-Pierre Rosen 2007-09-25 8:29 ` Michael Bode 2007-09-25 11:20 ` Markus E L 2 siblings, 0 replies; 103+ messages in thread From: Jean-Pierre Rosen @ 2007-09-25 6:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 1:44 ` Steve 2007-09-25 6:41 ` Jean-Pierre Rosen @ 2007-09-25 8:29 ` Michael Bode 2007-09-25 18:00 ` Jeffrey R. Carter 2007-09-25 11:20 ` Markus E L 2 siblings, 1 reply; 103+ messages in thread From: Michael Bode @ 2007-09-25 8:29 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 8:29 ` Michael Bode @ 2007-09-25 18:00 ` Jeffrey R. Carter 2007-09-25 18:31 ` Michael Bode 0 siblings, 1 reply; 103+ messages in thread From: Jeffrey R. Carter @ 2007-09-25 18:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 18:00 ` Jeffrey R. Carter @ 2007-09-25 18:31 ` Michael Bode 0 siblings, 0 replies; 103+ messages in thread From: Michael Bode @ 2007-09-25 18:31 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 1:44 ` Steve 2007-09-25 6:41 ` Jean-Pierre Rosen 2007-09-25 8:29 ` Michael Bode @ 2007-09-25 11:20 ` Markus E L 2007-09-26 2:23 ` Steve 2007-09-26 6:58 ` Ole-Hjalmar Kristensen 2 siblings, 2 replies; 103+ messages in thread From: Markus E L @ 2007-09-25 11:20 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 11:20 ` Markus E L @ 2007-09-26 2:23 ` Steve 2007-09-26 12:21 ` Markus E L 2007-09-26 6:58 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 103+ messages in thread From: Steve @ 2007-09-26 2:23 UTC (permalink / raw) "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 > > ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-26 2:23 ` Steve @ 2007-09-26 12:21 ` Markus E L 2007-09-28 0:49 ` Randy Brukardt 2007-09-28 2:43 ` Steve 0 siblings, 2 replies; 103+ messages in thread From: Markus E L @ 2007-09-26 12:21 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-26 12:21 ` Markus E L @ 2007-09-28 0:49 ` Randy Brukardt 2007-09-28 2:43 ` Steve 1 sibling, 0 replies; 103+ messages in thread From: Randy Brukardt @ 2007-09-28 0:49 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-26 12:21 ` Markus E L 2007-09-28 0:49 ` Randy Brukardt @ 2007-09-28 2:43 ` Steve 2007-09-28 9:36 ` Markus E L 1 sibling, 1 reply; 103+ messages in thread From: Steve @ 2007-09-28 2:43 UTC (permalink / raw) "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 > ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-28 2:43 ` Steve @ 2007-09-28 9:36 ` Markus E L 2007-09-29 15:59 ` Michael Bode 0 siblings, 1 reply; 103+ messages in thread From: Markus E L @ 2007-09-28 9:36 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-28 9:36 ` Markus E L @ 2007-09-29 15:59 ` Michael Bode 2007-09-29 16:50 ` Markus E L 0 siblings, 1 reply; 103+ messages in thread From: Michael Bode @ 2007-09-29 15:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-29 15:59 ` Michael Bode @ 2007-09-29 16:50 ` Markus E L 0 siblings, 0 replies; 103+ messages in thread From: Markus E L @ 2007-09-29 16:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 11:20 ` Markus E L 2007-09-26 2:23 ` Steve @ 2007-09-26 6:58 ` Ole-Hjalmar Kristensen 2007-09-26 13:35 ` Steve 1 sibling, 1 reply; 103+ messages in thread From: Ole-Hjalmar Kristensen @ 2007-09-26 6:58 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-26 6:58 ` Ole-Hjalmar Kristensen @ 2007-09-26 13:35 ` Steve 2007-09-26 14:06 ` Markus E L 2007-09-26 14:08 ` Dmitry A. Kazakov 0 siblings, 2 replies; 103+ messages in thread From: Steve @ 2007-09-26 13:35 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-26 13:35 ` Steve @ 2007-09-26 14:06 ` Markus E L 2007-09-27 18:26 ` Michael Bode 2007-09-28 2:29 ` Steve 2007-09-26 14:08 ` Dmitry A. Kazakov 1 sibling, 2 replies; 103+ messages in thread From: Markus E L @ 2007-09-26 14:06 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-26 14:06 ` Markus E L @ 2007-09-27 18:26 ` Michael Bode 2007-09-27 20:18 ` Markus E L 2007-09-28 6:45 ` Jean-Pierre Rosen 2007-09-28 2:29 ` Steve 1 sibling, 2 replies; 103+ messages in thread From: Michael Bode @ 2007-09-27 18:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-27 18:26 ` Michael Bode @ 2007-09-27 20:18 ` Markus E L 2007-09-28 6:45 ` Jean-Pierre Rosen 1 sibling, 0 replies; 103+ messages in thread From: Markus E L @ 2007-09-27 20:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-27 18:26 ` Michael Bode 2007-09-27 20:18 ` Markus E L @ 2007-09-28 6:45 ` Jean-Pierre Rosen 2007-09-29 9:18 ` michael bode 1 sibling, 1 reply; 103+ messages in thread From: Jean-Pierre Rosen @ 2007-09-28 6:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-28 6:45 ` Jean-Pierre Rosen @ 2007-09-29 9:18 ` michael bode 0 siblings, 0 replies; 103+ messages in thread From: michael bode @ 2007-09-29 9:18 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-26 14:06 ` Markus E L 2007-09-27 18:26 ` Michael Bode @ 2007-09-28 2:29 ` Steve 2007-09-28 9:23 ` Markus E L 2007-09-28 14:48 ` Ed Falis 1 sibling, 2 replies; 103+ messages in thread From: Steve @ 2007-09-28 2:29 UTC (permalink / raw) "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 > ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-28 2:29 ` Steve @ 2007-09-28 9:23 ` Markus E L 2007-09-30 14:50 ` Steve 2007-09-28 14:48 ` Ed Falis 1 sibling, 1 reply; 103+ messages in thread From: Markus E L @ 2007-09-28 9:23 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-28 9:23 ` Markus E L @ 2007-09-30 14:50 ` Steve 2007-10-02 3:50 ` Randy Brukardt 0 siblings, 1 reply; 103+ messages in thread From: Steve @ 2007-09-30 14:50 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-30 14:50 ` Steve @ 2007-10-02 3:50 ` Randy Brukardt 2007-10-02 11:06 ` Peter C. Chapin ` (2 more replies) 0 siblings, 3 replies; 103+ messages in thread From: Randy Brukardt @ 2007-10-02 3:50 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-02 3:50 ` Randy Brukardt @ 2007-10-02 11:06 ` Peter C. Chapin 2007-10-02 20:38 ` Maciej Sobczak 2007-10-03 2:03 ` GNAT for MS Visual Studio Steve 2 siblings, 0 replies; 103+ messages in thread From: Peter C. Chapin @ 2007-10-02 11:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-02 3:50 ` Randy Brukardt 2007-10-02 11:06 ` Peter C. Chapin @ 2007-10-02 20:38 ` Maciej Sobczak 2007-10-02 20:45 ` Pascal Obry 2007-10-03 5:20 ` Licensing again (was Re: GNAT for MS Visual Studio) Simon Wright 2007-10-03 2:03 ` GNAT for MS Visual Studio Steve 2 siblings, 2 replies; 103+ messages in thread From: Maciej Sobczak @ 2007-10-02 20:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-02 20:38 ` Maciej Sobczak @ 2007-10-02 20:45 ` Pascal Obry 2007-10-03 19:23 ` Maciej Sobczak 2007-10-03 5:20 ` Licensing again (was Re: GNAT for MS Visual Studio) Simon Wright 1 sibling, 1 reply; 103+ messages in thread From: Pascal Obry @ 2007-10-02 20:45 UTC (permalink / raw) To: Maciej Sobczak 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-02 20:45 ` Pascal Obry @ 2007-10-03 19:23 ` Maciej Sobczak 2007-10-03 19:40 ` Pascal Obry 0 siblings, 1 reply; 103+ messages in thread From: Maciej Sobczak @ 2007-10-03 19:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-03 19:23 ` Maciej Sobczak @ 2007-10-03 19:40 ` Pascal Obry 2007-10-03 20:08 ` Maciej Sobczak 2007-10-06 14:47 ` Matthew Heaney 0 siblings, 2 replies; 103+ messages in thread From: Pascal Obry @ 2007-10-03 19:40 UTC (permalink / raw) To: Maciej Sobczak 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-03 19:40 ` Pascal Obry @ 2007-10-03 20:08 ` Maciej Sobczak 2007-10-04 20:18 ` Maciej Sobczak 2007-10-05 20:15 ` GNAT for MS Visual Studio Simon Wright 2007-10-06 14:47 ` Matthew Heaney 1 sibling, 2 replies; 103+ messages in thread From: Maciej Sobczak @ 2007-10-03 20:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-03 20:08 ` Maciej Sobczak @ 2007-10-04 20:18 ` Maciej Sobczak 2007-10-04 20:21 ` Pascal Obry 2007-10-05 20:15 ` GNAT for MS Visual Studio Simon Wright 1 sibling, 1 reply; 103+ messages in thread From: Maciej Sobczak @ 2007-10-04 20:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-04 20:18 ` Maciej Sobczak @ 2007-10-04 20:21 ` Pascal Obry 2007-10-05 13:25 ` Maciej Sobczak 0 siblings, 1 reply; 103+ messages in thread From: Pascal Obry @ 2007-10-04 20:21 UTC (permalink / raw) To: Maciej Sobczak 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-04 20:21 ` Pascal Obry @ 2007-10-05 13:25 ` Maciej Sobczak 2007-10-06 10:50 ` concurrent access to containers (was: GNAT for MS Visual Studio) Georg Bauhaus 0 siblings, 1 reply; 103+ messages in thread From: Maciej Sobczak @ 2007-10-05 13:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: concurrent access to containers (was: GNAT for MS Visual Studio) 2007-10-05 13:25 ` Maciej Sobczak @ 2007-10-06 10:50 ` Georg Bauhaus 0 siblings, 0 replies; 103+ messages in thread From: Georg Bauhaus @ 2007-10-06 10:50 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-03 20:08 ` Maciej Sobczak 2007-10-04 20:18 ` Maciej Sobczak @ 2007-10-05 20:15 ` Simon Wright 1 sibling, 0 replies; 103+ messages in thread From: Simon Wright @ 2007-10-05 20:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-03 19:40 ` Pascal Obry 2007-10-03 20:08 ` Maciej Sobczak @ 2007-10-06 14:47 ` Matthew Heaney 2007-10-06 15:03 ` Pascal Obry 1 sibling, 1 reply; 103+ messages in thread From: Matthew Heaney @ 2007-10-06 14:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-06 14:47 ` Matthew Heaney @ 2007-10-06 15:03 ` Pascal Obry 2007-10-06 16:03 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 103+ messages in thread From: Pascal Obry @ 2007-10-06 15:03 UTC (permalink / raw) To: Matthew Heaney 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-06 15:03 ` Pascal Obry @ 2007-10-06 16:03 ` Dmitry A. Kazakov 2007-10-06 17:07 ` Pascal Obry 2007-10-06 16:17 ` Matthew Heaney 2007-10-07 3:19 ` Randy Brukardt 2 siblings, 1 reply; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-10-06 16:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-06 16:03 ` Dmitry A. Kazakov @ 2007-10-06 17:07 ` Pascal Obry 2007-10-06 18:30 ` Dmitry A. Kazakov 0 siblings, 1 reply; 103+ messages in thread From: Pascal Obry @ 2007-10-06 17:07 UTC (permalink / raw) To: mailbox 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-06 17:07 ` Pascal Obry @ 2007-10-06 18:30 ` Dmitry A. Kazakov 2007-10-06 20:32 ` Maciej Sobczak 0 siblings, 1 reply; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-10-06 18:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-06 18:30 ` Dmitry A. Kazakov @ 2007-10-06 20:32 ` Maciej Sobczak 2007-10-07 7:35 ` Dmitry A. Kazakov 0 siblings, 1 reply; 103+ messages in thread From: Maciej Sobczak @ 2007-10-06 20:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-06 20:32 ` Maciej Sobczak @ 2007-10-07 7:35 ` Dmitry A. Kazakov 2007-10-07 21:30 ` Maciej Sobczak 0 siblings, 1 reply; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-10-07 7:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 7:35 ` Dmitry A. Kazakov @ 2007-10-07 21:30 ` Maciej Sobczak 2007-10-08 7:50 ` Dmitry A. Kazakov 0 siblings, 1 reply; 103+ messages in thread From: Maciej Sobczak @ 2007-10-07 21:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 21:30 ` Maciej Sobczak @ 2007-10-08 7:50 ` Dmitry A. Kazakov 2007-10-08 10:32 ` Maciej Sobczak 0 siblings, 1 reply; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-10-08 7:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-08 7:50 ` Dmitry A. Kazakov @ 2007-10-08 10:32 ` Maciej Sobczak 2007-10-08 13:39 ` Maciej Sobczak 2007-10-08 15:10 ` Dmitry A. Kazakov 0 siblings, 2 replies; 103+ messages in thread From: Maciej Sobczak @ 2007-10-08 10:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-08 10:32 ` Maciej Sobczak @ 2007-10-08 13:39 ` Maciej Sobczak 2007-10-08 15:10 ` Dmitry A. Kazakov 1 sibling, 0 replies; 103+ messages in thread From: Maciej Sobczak @ 2007-10-08 13:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-08 10:32 ` Maciej Sobczak 2007-10-08 13:39 ` Maciej Sobczak @ 2007-10-08 15:10 ` Dmitry A. Kazakov 2007-10-08 20:40 ` Maciej Sobczak 1 sibling, 1 reply; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-10-08 15:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-08 15:10 ` Dmitry A. Kazakov @ 2007-10-08 20:40 ` Maciej Sobczak 2007-10-09 8:32 ` Dmitry A. Kazakov 0 siblings, 1 reply; 103+ messages in thread From: Maciej Sobczak @ 2007-10-08 20:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-08 20:40 ` Maciej Sobczak @ 2007-10-09 8:32 ` Dmitry A. Kazakov 0 siblings, 0 replies; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-10-09 8:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-06 15:03 ` Pascal Obry 2007-10-06 16:03 ` Dmitry A. Kazakov @ 2007-10-06 16:17 ` Matthew Heaney 2007-10-07 3:19 ` Randy Brukardt 2 siblings, 0 replies; 103+ messages in thread From: Matthew Heaney @ 2007-10-06 16:17 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-06 15:03 ` Pascal Obry 2007-10-06 16:03 ` Dmitry A. Kazakov 2007-10-06 16:17 ` Matthew Heaney @ 2007-10-07 3:19 ` Randy Brukardt 2007-10-07 7:21 ` Pascal Obry 2 siblings, 1 reply; 103+ messages in thread From: Randy Brukardt @ 2007-10-07 3:19 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 3:19 ` Randy Brukardt @ 2007-10-07 7:21 ` Pascal Obry 2007-10-07 7:49 ` Dmitry A. Kazakov ` (4 more replies) 0 siblings, 5 replies; 103+ messages in thread From: Pascal Obry @ 2007-10-07 7:21 UTC (permalink / raw) To: Randy Brukardt 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 7:21 ` Pascal Obry @ 2007-10-07 7:49 ` Dmitry A. Kazakov 2007-10-07 16:41 ` Georg Bauhaus ` (3 subsequent siblings) 4 siblings, 0 replies; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-10-07 7:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 7:21 ` Pascal Obry 2007-10-07 7:49 ` Dmitry A. Kazakov @ 2007-10-07 16:41 ` Georg Bauhaus 2007-10-07 17:44 ` Simon Wright ` (2 subsequent siblings) 4 siblings, 0 replies; 103+ messages in thread From: Georg Bauhaus @ 2007-10-07 16:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 7:21 ` Pascal Obry 2007-10-07 7:49 ` Dmitry A. Kazakov 2007-10-07 16:41 ` Georg Bauhaus @ 2007-10-07 17:44 ` Simon Wright 2007-10-08 9:52 ` Georg Bauhaus 2007-10-08 18:28 ` Pascal Obry 2007-10-07 21:48 ` Maciej Sobczak 2007-10-09 1:53 ` Randy Brukardt 4 siblings, 2 replies; 103+ messages in thread From: Simon Wright @ 2007-10-07 17:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 17:44 ` Simon Wright @ 2007-10-08 9:52 ` Georg Bauhaus 2007-10-08 10:42 ` Maciej Sobczak 2007-10-08 15:21 ` Dmitry A. Kazakov 2007-10-08 18:28 ` Pascal Obry 1 sibling, 2 replies; 103+ messages in thread From: Georg Bauhaus @ 2007-10-08 9:52 UTC (permalink / raw) 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?) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-08 9:52 ` Georg Bauhaus @ 2007-10-08 10:42 ` Maciej Sobczak 2007-10-08 10:59 ` Georg Bauhaus ` (2 more replies) 2007-10-08 15:21 ` Dmitry A. Kazakov 1 sibling, 3 replies; 103+ messages in thread From: Maciej Sobczak @ 2007-10-08 10:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-08 10:42 ` Maciej Sobczak @ 2007-10-08 10:59 ` Georg Bauhaus 2007-10-08 11:07 ` Georg Bauhaus 2007-10-08 18:44 ` Pascal Obry 2 siblings, 0 replies; 103+ messages in thread From: Georg Bauhaus @ 2007-10-08 10:59 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-08 10:42 ` Maciej Sobczak 2007-10-08 10:59 ` Georg Bauhaus @ 2007-10-08 11:07 ` Georg Bauhaus 2007-10-08 18:44 ` Pascal Obry 2 siblings, 0 replies; 103+ messages in thread From: Georg Bauhaus @ 2007-10-08 11:07 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-08 10:42 ` Maciej Sobczak 2007-10-08 10:59 ` Georg Bauhaus 2007-10-08 11:07 ` Georg Bauhaus @ 2007-10-08 18:44 ` Pascal Obry 2 siblings, 0 replies; 103+ messages in thread From: Pascal Obry @ 2007-10-08 18:44 UTC (permalink / raw) To: Maciej Sobczak 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-08 9:52 ` Georg Bauhaus 2007-10-08 10:42 ` Maciej Sobczak @ 2007-10-08 15:21 ` Dmitry A. Kazakov 1 sibling, 0 replies; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-10-08 15:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 17:44 ` Simon Wright 2007-10-08 9:52 ` Georg Bauhaus @ 2007-10-08 18:28 ` Pascal Obry 1 sibling, 0 replies; 103+ messages in thread From: Pascal Obry @ 2007-10-08 18:28 UTC (permalink / raw) To: Simon Wright 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 7:21 ` Pascal Obry ` (2 preceding siblings ...) 2007-10-07 17:44 ` Simon Wright @ 2007-10-07 21:48 ` Maciej Sobczak 2007-10-07 22:27 ` Jeffrey R. Carter 2007-10-09 1:53 ` Randy Brukardt 4 siblings, 1 reply; 103+ messages in thread From: Maciej Sobczak @ 2007-10-07 21:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 21:48 ` Maciej Sobczak @ 2007-10-07 22:27 ` Jeffrey R. Carter 2007-10-08 21:10 ` Simon Wright 0 siblings, 1 reply; 103+ messages in thread From: Jeffrey R. Carter @ 2007-10-07 22:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 22:27 ` Jeffrey R. Carter @ 2007-10-08 21:10 ` Simon Wright 0 siblings, 0 replies; 103+ messages in thread From: Simon Wright @ 2007-10-08 21:10 UTC (permalink / raw) "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! ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-07 7:21 ` Pascal Obry ` (3 preceding siblings ...) 2007-10-07 21:48 ` Maciej Sobczak @ 2007-10-09 1:53 ` Randy Brukardt 2007-10-09 21:01 ` Simon Wright 4 siblings, 1 reply; 103+ messages in thread From: Randy Brukardt @ 2007-10-09 1:53 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-09 1:53 ` Randy Brukardt @ 2007-10-09 21:01 ` Simon Wright 2007-10-09 22:48 ` Randy Brukardt ` (2 more replies) 0 siblings, 3 replies; 103+ messages in thread From: Simon Wright @ 2007-10-09 21:01 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-09 21:01 ` Simon Wright @ 2007-10-09 22:48 ` Randy Brukardt 2007-10-10 0:21 ` Jeffrey R. Carter 2007-10-10 4:57 ` Simon Wright 2007-10-10 7:46 ` Dmitry A. Kazakov 2 siblings, 1 reply; 103+ messages in thread From: Randy Brukardt @ 2007-10-09 22:48 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-09 22:48 ` Randy Brukardt @ 2007-10-10 0:21 ` Jeffrey R. Carter 0 siblings, 0 replies; 103+ messages in thread From: Jeffrey R. Carter @ 2007-10-10 0:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-09 21:01 ` Simon Wright 2007-10-09 22:48 ` Randy Brukardt @ 2007-10-10 4:57 ` Simon Wright 2007-10-10 7:46 ` Dmitry A. Kazakov 2 siblings, 0 replies; 103+ messages in thread From: Simon Wright @ 2007-10-10 4:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-09 21:01 ` Simon Wright 2007-10-09 22:48 ` Randy Brukardt 2007-10-10 4:57 ` Simon Wright @ 2007-10-10 7:46 ` Dmitry A. Kazakov 2 siblings, 0 replies; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-10-10 7:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Licensing again (was Re: GNAT for MS Visual Studio) 2007-10-02 20:38 ` Maciej Sobczak 2007-10-02 20:45 ` Pascal Obry @ 2007-10-03 5:20 ` Simon Wright 1 sibling, 0 replies; 103+ messages in thread From: Simon Wright @ 2007-10-03 5:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-02 3:50 ` Randy Brukardt 2007-10-02 11:06 ` Peter C. Chapin 2007-10-02 20:38 ` Maciej Sobczak @ 2007-10-03 2:03 ` Steve 2 siblings, 0 replies; 103+ messages in thread From: Steve @ 2007-10-03 2:03 UTC (permalink / raw) "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. > ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-28 2:29 ` Steve 2007-09-28 9:23 ` Markus E L @ 2007-09-28 14:48 ` Ed Falis 2007-09-29 2:32 ` Steve 1 sibling, 1 reply; 103+ messages in thread From: Ed Falis @ 2007-09-28 14:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-28 14:48 ` Ed Falis @ 2007-09-29 2:32 ` Steve 2007-09-29 6:53 ` Vadim Godunko 0 siblings, 1 reply; 103+ messages in thread From: Steve @ 2007-09-29 2:32 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-29 2:32 ` Steve @ 2007-09-29 6:53 ` Vadim Godunko 0 siblings, 0 replies; 103+ messages in thread From: Vadim Godunko @ 2007-09-29 6:53 UTC (permalink / raw) 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. ;-) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-26 13:35 ` Steve 2007-09-26 14:06 ` Markus E L @ 2007-09-26 14:08 ` Dmitry A. Kazakov 1 sibling, 0 replies; 103+ messages in thread From: Dmitry A. Kazakov @ 2007-09-26 14:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-24 8:14 ` Jean-Pierre Rosen 2007-09-25 1:44 ` Steve @ 2007-09-25 2:39 ` Randy Brukardt 2007-09-25 8:40 ` Michael Bode ` (2 more replies) 1 sibling, 3 replies; 103+ messages in thread From: Randy Brukardt @ 2007-09-25 2:39 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 2:39 ` Randy Brukardt @ 2007-09-25 8:40 ` Michael Bode 2007-09-25 11:28 ` Markus E L 2007-09-26 10:19 ` Pascal Obry 2 siblings, 0 replies; 103+ messages in thread From: Michael Bode @ 2007-09-25 8:40 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 2:39 ` Randy Brukardt 2007-09-25 8:40 ` Michael Bode @ 2007-09-25 11:28 ` Markus E L 2007-09-26 10:19 ` Pascal Obry 2 siblings, 0 replies; 103+ messages in thread From: Markus E L @ 2007-09-25 11:28 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 2:39 ` Randy Brukardt 2007-09-25 8:40 ` Michael Bode 2007-09-25 11:28 ` Markus E L @ 2007-09-26 10:19 ` Pascal Obry 2007-09-26 13:00 ` Michael Bode 2 siblings, 1 reply; 103+ messages in thread From: Pascal Obry @ 2007-09-26 10:19 UTC (permalink / raw) To: Randy Brukardt 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-26 10:19 ` Pascal Obry @ 2007-09-26 13:00 ` Michael Bode 0 siblings, 0 replies; 103+ messages in thread From: Michael Bode @ 2007-09-26 13:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-22 14:42 ` Steve 2007-09-24 8:14 ` Jean-Pierre Rosen @ 2007-09-25 2:32 ` Randy Brukardt 2007-09-25 8:27 ` Stephen Leake 1 sibling, 1 reply; 103+ messages in thread From: Randy Brukardt @ 2007-09-25 2:32 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-09-25 2:32 ` Randy Brukardt @ 2007-09-25 8:27 ` Stephen Leake 0 siblings, 0 replies; 103+ messages in thread From: Stephen Leake @ 2007-09-25 8:27 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* GNAT for MS Visual Studio @ 2007-10-12 22:03 Anatoly Chernyshev 2007-10-13 20:25 ` Maciej Sobczak 0 siblings, 1 reply; 103+ messages in thread From: Anatoly Chernyshev @ 2007-10-12 22:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-12 22:03 Anatoly Chernyshev @ 2007-10-13 20:25 ` Maciej Sobczak 2007-10-14 10:37 ` Simon Wright 0 siblings, 1 reply; 103+ messages in thread From: Maciej Sobczak @ 2007-10-13 20:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-13 20:25 ` Maciej Sobczak @ 2007-10-14 10:37 ` Simon Wright 2007-10-14 11:26 ` Markus E L 0 siblings, 1 reply; 103+ messages in thread From: Simon Wright @ 2007-10-14 10:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: GNAT for MS Visual Studio 2007-10-14 10:37 ` Simon Wright @ 2007-10-14 11:26 ` Markus E L 0 siblings, 0 replies; 103+ messages in thread From: Markus E L @ 2007-10-14 11:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
end of thread, other threads:[~2007-10-14 11:26 UTC | newest] Thread overview: 103+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-09-06 2:20 GNAT for MS Visual Studio William J Thomas 2007-09-06 7:44 ` anon 2007-09-06 8:49 ` Rob Veenker 2007-09-06 11:12 ` William J Thomas 2007-09-11 3:15 ` Jeffrey Creem 2007-09-20 0:00 ` William J Thomas 2007-09-21 0:46 ` Randy Brukardt 2007-09-21 3:27 ` William J Thomas 2007-09-21 17:31 ` Markus E L 2007-09-21 18:13 ` Dmitry A. Kazakov 2007-09-22 1:42 ` Randy Brukardt 2007-09-22 1:59 ` Randy Brukardt 2007-09-22 5:19 ` Simon Wright 2007-09-22 14:42 ` Steve 2007-09-24 8:14 ` Jean-Pierre Rosen 2007-09-25 1:44 ` Steve 2007-09-25 6:41 ` Jean-Pierre Rosen 2007-09-25 8:29 ` Michael Bode 2007-09-25 18:00 ` Jeffrey R. Carter 2007-09-25 18:31 ` Michael Bode 2007-09-25 11:20 ` Markus E L 2007-09-26 2:23 ` Steve 2007-09-26 12:21 ` Markus E L 2007-09-28 0:49 ` Randy Brukardt 2007-09-28 2:43 ` Steve 2007-09-28 9:36 ` Markus E L 2007-09-29 15:59 ` Michael Bode 2007-09-29 16:50 ` Markus E L 2007-09-26 6:58 ` Ole-Hjalmar Kristensen 2007-09-26 13:35 ` Steve 2007-09-26 14:06 ` Markus E L 2007-09-27 18:26 ` Michael Bode 2007-09-27 20:18 ` Markus E L 2007-09-28 6:45 ` Jean-Pierre Rosen 2007-09-29 9:18 ` michael bode 2007-09-28 2:29 ` Steve 2007-09-28 9:23 ` Markus E L 2007-09-30 14:50 ` Steve 2007-10-02 3:50 ` Randy Brukardt 2007-10-02 11:06 ` Peter C. Chapin 2007-10-02 20:38 ` Maciej Sobczak 2007-10-02 20:45 ` Pascal Obry 2007-10-03 19:23 ` Maciej Sobczak 2007-10-03 19:40 ` Pascal Obry 2007-10-03 20:08 ` Maciej Sobczak 2007-10-04 20:18 ` Maciej Sobczak 2007-10-04 20:21 ` Pascal Obry 2007-10-05 13:25 ` Maciej Sobczak 2007-10-06 10:50 ` concurrent access to containers (was: GNAT for MS Visual Studio) Georg Bauhaus 2007-10-05 20:15 ` GNAT for MS Visual Studio Simon Wright 2007-10-06 14:47 ` Matthew Heaney 2007-10-06 15:03 ` Pascal Obry 2007-10-06 16:03 ` Dmitry A. Kazakov 2007-10-06 17:07 ` Pascal Obry 2007-10-06 18:30 ` Dmitry A. Kazakov 2007-10-06 20:32 ` Maciej Sobczak 2007-10-07 7:35 ` Dmitry A. Kazakov 2007-10-07 21:30 ` Maciej Sobczak 2007-10-08 7:50 ` Dmitry A. Kazakov 2007-10-08 10:32 ` Maciej Sobczak 2007-10-08 13:39 ` Maciej Sobczak 2007-10-08 15:10 ` Dmitry A. Kazakov 2007-10-08 20:40 ` Maciej Sobczak 2007-10-09 8:32 ` Dmitry A. Kazakov 2007-10-06 16:17 ` Matthew Heaney 2007-10-07 3:19 ` Randy Brukardt 2007-10-07 7:21 ` Pascal Obry 2007-10-07 7:49 ` Dmitry A. Kazakov 2007-10-07 16:41 ` Georg Bauhaus 2007-10-07 17:44 ` Simon Wright 2007-10-08 9:52 ` Georg Bauhaus 2007-10-08 10:42 ` Maciej Sobczak 2007-10-08 10:59 ` Georg Bauhaus 2007-10-08 11:07 ` Georg Bauhaus 2007-10-08 18:44 ` Pascal Obry 2007-10-08 15:21 ` Dmitry A. Kazakov 2007-10-08 18:28 ` Pascal Obry 2007-10-07 21:48 ` Maciej Sobczak 2007-10-07 22:27 ` Jeffrey R. Carter 2007-10-08 21:10 ` Simon Wright 2007-10-09 1:53 ` Randy Brukardt 2007-10-09 21:01 ` Simon Wright 2007-10-09 22:48 ` Randy Brukardt 2007-10-10 0:21 ` Jeffrey R. Carter 2007-10-10 4:57 ` Simon Wright 2007-10-10 7:46 ` Dmitry A. Kazakov 2007-10-03 5:20 ` Licensing again (was Re: GNAT for MS Visual Studio) Simon Wright 2007-10-03 2:03 ` GNAT for MS Visual Studio Steve 2007-09-28 14:48 ` Ed Falis 2007-09-29 2:32 ` Steve 2007-09-29 6:53 ` Vadim Godunko 2007-09-26 14:08 ` Dmitry A. Kazakov 2007-09-25 2:39 ` Randy Brukardt 2007-09-25 8:40 ` Michael Bode 2007-09-25 11:28 ` Markus E L 2007-09-26 10:19 ` Pascal Obry 2007-09-26 13:00 ` Michael Bode 2007-09-25 2:32 ` Randy Brukardt 2007-09-25 8:27 ` Stephen Leake -- strict thread matches above, loose matches on Subject: below -- 2007-10-12 22:03 Anatoly Chernyshev 2007-10-13 20:25 ` Maciej Sobczak 2007-10-14 10:37 ` Simon Wright 2007-10-14 11:26 ` Markus E L
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox