GUI was Re: why Ada is so unpopular ?

GUI was Re: why Ada is so unpopular ?

[Robert C. Leif]

Since the subject of this discussion is GUI's, I changed the subject.  Since
we lack both the resources and probably the human engineering expertise to
develop a GUI, instead of inventing a new GUI for Ada; why not use a
language neutral technology?  XML has many sublanguages that are
appropriate.  In fact, it would be possible to use presently existing
technology like GtkAda or better yet CLAW to create the simplest version of
Scalable Vector Graphics or a thick binding to an existing version, such as
that available from Adobe. This could then serve as a foundation to host
XForms. 

In fact by using XML schemas and Ada packages that have identical
data-types, one might have two versions of the same GUI.  The first would be
an XML version powered as much as possible by Ada and the second would be an
Ada version with minimal code in other languages.  In short, the simplest
approach is to use the designs and data-types from the World Wide Web
Consortium, www.w3.org

If successful, this might even increase the popularity of Ada.  Ada is now
worse than unpopular; most of the programming community does not realize
that it exists; and the others think that Ada is only useful for military
projects.  Parenthetically, the real reason Ada is not popular is that we do
not have a hero who has become filthy rich using it. 

Bob Leif
-----------------------------------------------------------
Message: 5
Date: Mon, 19 Jan 2004 13:28:30 GMT
From: Marin David Condic <nobody@noplace.com>
Subject: Re: why ada is so unpopular ?
To: comp.lang.ada@ada-france.org
Message-ID: <400BDB7C.40100@noplace.com>
Content-Type: text/plain; charset=us-ascii; format=flowed

Preben Randhol wrote:
> 
> Well if you look at Java you see that the GUI isn't the same in all
> platforms and IMHO the GUI is butt-ugly.
> 
Java's GUI may or may not be butt-ugly. But one thing it is: It's 
_Java's_ GUI and as it evolves, Java users pretty much get full access 
to whatever new features are added without having to wait for some 
binding to catch up.


> The only benifit of a special Ada GUI would be portability and not
> having to use C library.
> 

Portability would be one thing, but not the only thing. "Product 
Distinction" would be another: An Ada GUI could go its own way and do 
things "The Ada Way" from the programmer's perspective and might even 
provide a unique "Look & Feel" to Ada apps. (People might then actually 
*care* that their apps were done with Ada, eh?) You'd also benefit from 
the fact that (as observed above for Java) it would be _Ada's_ GUI and 
there would be no waiting around for some binding to catch up. It goes 
its own direction, develops its own look-and-feel and might start 
developing features that user's of other languages would wish *they* had 
available to them. (Hint: Switch to Ada and you can have them.)

I've tinkered with GtkAda and - while it is a good and useful thing - I 
can observe that there seem to be some features that Gtk has (under 
Gnome?) that are simply not available through GtkAda. One might want to 
use those features - but its either roll your own, wait for GtkAda to 
catch up or go use C/C++ like the entire rest of the world does. What do 
you suppose most programmers do? (Hint: Look at the relative popularity 
of C/C++ to that of Ada.)

This is always the problem that Ada has with bindings, etc. It's playing 
the "Me Too!!!!" catch-up game. The best you can hope for then is to 
come in second-place. That's why Ada ought to be developing a library of 
its own to supply a GUI and the other things that seem to come along for 
the ride with C++ or Java.

MDC

Re: GUI was Re: why Ada is so unpopular ?

[Preben Randhol]

On 2004-01-20, Robert C. Leif <rleif@rleif.com> wrote:
> technology like GtkAda or better yet CLAW to create the simplest version of
> Scalable Vector Graphics or a thick binding to an existing version, such as
> that available from Adobe. This could then serve as a foundation to host
> XForms. 

Why would we want to use a library that *only* works on one OS. I
thought the point was a *portable* library.


-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: GUI was Re: why Ada is so unpopular ?

[Georg Bauhaus]

Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:
:> that available from Adobe. This could then serve as a foundation to host
:> XForms. 
: 
: Why would we want to use a library that *only* works on one OS. I
: thought the point was a *portable* library.

XForms is intended to be not only "portable" but also abstract.

Re: GUI was Re: why Ada is so unpopular ?

[Preben Randhol]

On 2004-01-20, Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:
>:> that available from Adobe. This could then serve as a foundation to host
>:> XForms. 
>: 
>: Why would we want to use a library that *only* works on one OS. I
>: thought the point was a *portable* library.
>
> XForms is intended to be not only "portable" but also abstract.

I wasn't talking about xforms. I was commenting on that one could use
CLAWS



-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: GUI was Re: why Ada is so unpopular ?

[Randy Brukardt]

"Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
message
news:slrnc0q2fu.7as.randhol+valid_for_reply_from_news@k-083152.nt.ntnu.no...
> On 2004-01-20, Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> > Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:
> >:> that available from Adobe. This could then serve as a foundation to
host
> >:> XForms.
> >:
> >: Why would we want to use a library that *only* works on one OS. I
> >: thought the point was a *portable* library.
> >
> > XForms is intended to be not only "portable" but also abstract.
>
> I wasn't talking about xforms. I was commenting on that one could use
> CLAWS

I think he was talking about the abstract design of CLAW, not the
windows-specific implementation.

Something like it, with the Windows-specific stuff filed off, would make a
very decent basis for a higher-level, portable GUI library. We've looked at
doing that for the sockets portion, and it isn't too hard. It would be
harder, of course, to do it for the rest of it, but by no means impossible.

                   Randy.

Re: GUI was Re: why Ada is so unpopular ?

[tmoran]

>Something like it, with the Windows-specific stuff filed off, would make a
>very decent basis for a higher-level, portable GUI library. We've looked at
>doing that for the sockets portion, and it isn't too hard. It would be
>harder, of course, to do it for the rest of it, but by no means impossible.
  www.adaworld.com  Ada Projects  Internet Protocols
has a sockets package like Claw's but with no Claw dependence and two
Windows-specific calls - WSAStartup and WSACleanup for initial startup
and final shutdown.
  Claw.Registry, OTOH, would be bizarre to try to port to an OS with
nothing similar to Windows Registry.

Re: GUI was Re: why Ada is so unpopular ?

[Marin David Condic]

That's why the goal would ultimately have to be to produce a unique "Ada 
Application Environment", if you will. The app would see things like a 
GUI or network or file system or registry as objects it could use & 
manipulate through regular Ada mechanisms. If it maps to an underlying 
OS feature, you use that. If not, there would have to be some 
stand-alone "fake it out" underlying implementation that is part of the 
library.

You couldn't get there overnight and you'd want to start with "least 
common denominator" features, but I think you could get there. This is 
why I've argued for a "Conventional" library that is maintained as a 
reference implementation and blessed by the Powers That Be. You'd have 
to keep growing those features over time & issuing releases faster than 
once every ten years. That's why you couldn't keep it as part of the ARM 
- but it could be maintained as something less formal.

MDC


tmoran@acm.org wrote:
>   Claw.Registry, OTOH, would be bizarre to try to port to an OS with
> nothing similar to Windows Registry.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GUI was Re: why Ada is so unpopular ?

[tmoran]

> >   Claw.Registry, OTOH, would be bizarre to try to port to an OS with
> > nothing similar to Windows Registry.
>  If it maps to an underlying OS feature, you use that.  If not, there
>  would have to be some stand-alone "fake it out" underlying implementation
  Isn't that called a "Windows emulator for Linux" or such?  A non-trivial
undertaking, although a few years ago, IIRC, somebody reported Claw programs
running on such a thing.  (I don't know if that included Registry use.)

Re: GUI was Re: why Ada is so unpopular ?

[Marin David Condic]

Therein, of course, lies the dillema. You can have a GUI that gets you 
all the features of an underlying OS or you can have a portable GUI that 
leaves out some capabilities that may be available on a given platform. 
You win some and you lose some.

Still, a *portable* GUI could conceivably go off and become its own 
thing - having features you don't get on any of the underlying 
platforms. Starting with something like CLAW might be a viable way to 
go. File off the Windows specifics and make an implementation that runs 
on X-Windows as well. Then start building from there to create a GUI 
that might be distinctively "Ada".

It might not be easy, but if Ada were to adopt a goal of having a 
portable GUI/Library via reference implementation I think it would be 
achievable and worth the effort in the sense that it would serve to make 
Ada more useful & more attractive to developers. CLAW might be a good 
starting point for that - if we could get some general consensus to go 
that way.

MDC


Randy Brukardt wrote:
> 
> Something like it, with the Windows-specific stuff filed off, would make a
> very decent basis for a higher-level, portable GUI library. We've looked at
> doing that for the sockets portion, and it isn't too hard. It would be
> harder, of course, to do it for the rest of it, but by no means impossible.
> 
>                    Randy.
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GUI was Re: why Ada is so unpopular ?

[Marin David Condic]

XML is one possible route to get there and I could see your reasons for 
wanting to go that way. I'd have no objections to basing a GUI on some 
form of XML and possibly using some existing tools to do the graphics 
driving. The only real issue is that you are too far ahead of the 
problem. First there needs to be a general *will* to have a GUI for Ada 
that is going to be adopted and shipped with compilers.

So far, there seems to be a certain amount of vague desire in the 
community that Ada ought to have some extended capabilities by way of 
some kind of library of useful stuff - a GUI being part of it. However, 
the reaction can be summarized this way:

The ARG & other "Official" keepers of what it means to be Ada don't have 
the time and/or desire to take on some kind of library/GUI. If they did, 
they'd want something very formal and mostly a specification with "Every 
Vendor For Himself" being the rule of implementation. It could take 
*years* before we'd see anything come about this way.

The vendors have an interest level asymptotically approaching zero. 
*Maybe* if something were to come out of a SIGAda working group and 
*maybe* if it were to achieve some measure of widespread adoption, they 
*might* get on board after the train has already left the station. (In 
other words, if you do all the work and take all the risk and somehow 
make it a success, they'll be glad to take over your success.) Not much 
chance of a strong push coming from that direction.

Various owners of existing libraries of stuff are going "Ohhh! Pick Me! 
Pick Meeeeee!!!!!" Not necessarily a bad idea - select some existing 
library/GUI and start adapting it and adding on to it. But no vendor or 
SIGAda body is standing up saying "O.K. We'll select XYZ and start 
making it the 'Official' Ada library/GUI" Each of these existing 
libraries has its followers and hence there's no clear-cut winner to 
adopt. In the abscence of an existing winner, neither the vendors nor 
SIGAda wants to stand up and dictate an answer, so there is perpetual 
stalemate.

Various enthusiasts have suggested "Well let's go build one from 
bottom-dead-center and *make* it the library of choice..." - a noble 
ambition but one that *at best* would take a really long time to 
accomplish so long as nobody is getting paid to do it. Even if it did 
get built, there are no vendors standing in the wings saying "Yeah, 
we'll go adopt it and distribute it..." - not unless it is already a 
booming success (in which case, they'll gladly take it over to enhance 
their product & make money from it.)

So while I could easily imagine some scenario in which a reasonably 
portable GUI could be added to Ada - perhaps using XML as a supporting 
technology - I just don't see the will to do so forming up anywhere that 
would make it come about.

MDC


Robert C. Leif wrote:
> Since the subject of this discussion is GUI's, I changed the subject.  Since
> we lack both the resources and probably the human engineering expertise to
> develop a GUI, instead of inventing a new GUI for Ada; why not use a
> language neutral technology?  XML has many sublanguages that are
> appropriate.  In fact, it would be possible to use presently existing
> technology like GtkAda or better yet CLAW to create the simplest version of
> Scalable Vector Graphics or a thick binding to an existing version, such as
> that available from Adobe. This could then serve as a foundation to host
> XForms. 
> 
> In fact by using XML schemas and Ada packages that have identical
> data-types, one might have two versions of the same GUI.  The first would be
> an XML version powered as much as possible by Ada and the second would be an
> Ada version with minimal code in other languages.  In short, the simplest
> approach is to use the designs and data-types from the World Wide Web
> Consortium, www.w3.org
> 
> If successful, this might even increase the popularity of Ada.  Ada is now
> worse than unpopular; most of the programming community does not realize
> that it exists; and the others think that Ada is only useful for military
> projects.  Parenthetically, the real reason Ada is not popular is that we do
> not have a hero who has become filthy rich using it. 
> 
> Bob Leif

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GUI was Re: why Ada is so unpopular ?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

...
> Various owners of existing libraries of stuff are going "Ohhh! Pick Me! 
> Pick Meeeeee!!!!!" Not necessarily a bad idea - select some existing 
> library/GUI and start adapting it and adding on to it. But no vendor or 
> SIGAda body is standing up saying "O.K. We'll select XYZ and start 
> making it the 'Official' Ada library/GUI" Each of these existing 
> libraries has its followers and hence there's no clear-cut winner to 
> adopt. In the abscence of an existing winner, neither the vendors nor 
> SIGAda wants to stand up and dictate an answer, so there is perpetual 
> stalemate.
> 
> Various enthusiasts have suggested "Well let's go build one from 
> bottom-dead-center and *make* it the library of choice..." - a noble 
> ambition but one that *at best* would take a really long time to 
> accomplish so long as nobody is getting paid to do it. Even if it did 
> get built, there are no vendors standing in the wings saying "Yeah, 
> we'll go adopt it and distribute it..." - not unless it is already a 
> booming success (in which case, they'll gladly take it over to enhance 
> their product & make money from it.)
> 
> So while I could easily imagine some scenario in which a reasonably 
> portable GUI could be added to Ada - perhaps using XML as a supporting 
> technology - I just don't see the will to do so forming up anywhere that 
> would make it come about.
> 
> MDC

It also doesn't help that some projects are in turmoil at the
moment. For example, the XFree86 project was recently reported
on slashdot that it was disbanding. Meanwhile, there is another
group working on the Y protocol (which sounds interesting). As
you have said, there is much competition on the GUI front, that
builds on top of these protocols in the UNIX world.

So as an Open Sourced developer, you ideally _want_ to choose a
winner and something that isn't going to radically change. Change
requires you to constantly go back and revise previously completed
work (something I avoid, since I like to move onto newer things).

But as I see it presently, there is no clear winner for portable
GUIs. As mentioned, GtkAda seems to be the most logical choice
for Ada programmers.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: GUI was Re: why Ada is so unpopular ?

[Mark Lorenzen]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:

> It also doesn't help that some projects are in turmoil at the
> moment. For example, the XFree86 project was recently reported
> on slashdot that it was disbanding. Meanwhile, there is another
> group working on the Y protocol (which sounds interesting). As
> you have said, there is much competition on the GUI front, that
> builds on top of these protocols in the UNIX world.
>
> So as an Open Sourced developer, you ideally _want_ to choose a
> winner and something that isn't going to radically change. Change
> requires you to constantly go back and revise previously completed
> work (something I avoid, since I like to move onto newer things).
>
> But as I see it presently, there is no clear winner for portable
> GUIs. As mentioned, GtkAda seems to be the most logical choice
> for Ada programmers.
> -- 
> Warren W. Gay VE3WWG
> http://ve3wwg.tk

Just to set the record straight: The XFree86 project is *not*
disbanding. It is the XFree86 Core Team that is disbanding - simply
because the discussions for a long time has taken place on the mailing
list envolving all developers and not just the core team. Instead of a
core team that was supposed to monitor/guide/discuss development of
the X server, task forces may now be created to solve specific
problems.

In short: The XFree86 project is alive and kicking.

- Mark Lorenzen

RE: GUI was Re: why Ada is so unpopular ?

[amado.alves]

<<...
Various enthusiasts have suggested "Well let's go build one from 
bottom-dead-center and *make* it the library of choice..." - a noble 
ambition but one that *at best* would take a really long time...>>

There's another way: compromise. In the ASCLWG we eventually managed to agree upon selecting a pre-existing container library (Charles) to form the basis of the standard proposal. I didn't take long. The group was assembled in June 2002 (the Ada Europe workshop in Vienna), and the proposal was filed in September 2003 (AI-302/2). In the intervening dense discussion (circa 500 messages on the group list, plus circa 100 on the ARG forum) every one of us compromised about something from naming to featured abstractions to iteration methods.

If someone had started a similar process with GTK (or JEWL or...) we'd have it in Ada 2005, the standard GUI. Of course there is still plenty of time for a separate standard, or a reference API or whatever SIGAda calls it.

(I'm not disagreeing with anything, just telling a story.)

Re: GUI was Re: why Ada is so unpopular ?

[Marin David Condic]

Sure. Anything that is going to get done by a group is going to involve 
compromise. I can live with that. The important part is to get some 
start down a path that can be agreed upon and find some way of making it 
pay to build the end result.

My point was that volunteer efforts to build something are by their very 
nature going to be slow to build some relatively large end result. If 
ASCLWG was able to agree on Charles as a starting point, great. But to 
add on to Charles some larger body of capabilities (such as building a 
GUI on top of it) I think that could take *years* unless it got out of 
"All Volunteer" mode somehow.

You can adopt an existing thing like GtkAda or CLAW or JEWL or whatever 
as a starting point too. That has strengths and weaknesses as well. 
GtkAda, for example, doesn't use data structures that come out of 
Charles, right? So now you've got a hodgepodge collection of stuff 
instead of a well integrated toolset. If GtkAda was going to return a 
list of something, shouldn't it ought to be a *Charles* list rather than 
something that was specific to GtkAda? Might not the whole API to GtkAda 
be a better, more Ada-ish thing if it were using Charles data structures 
instead of being a band-aid over the top of a bunch of C parameters? 
Assuming Charles were to become "The Thing" for data structures, 
wouldn't a standard GUI for Ada want to exploit it to the max and be 
well integrated with it?

It might make a good start, but there could be years of effort needed 
from volunteers to produce something that met with expectations for a 
portable GUI for Ada.

MDC

amado.alves wrote:
> 
> There's another way: compromise. In the ASCLWG we eventually managed to agree upon selecting a pre-existing container library (Charles) to form the basis of the standard proposal. I didn't take long. The group was assembled in June 2002 (the Ada Europe workshop in Vienna), and the proposal was filed in September 2003 (AI-302/2). In the intervening dense discussion (circa 500 messages on the group list, plus circa 100 on the ARG forum) every one of us compromised about something from naming to featured abstractions to iteration methods.
> 
> If someone had started a similar process with GTK (or JEWL or...) we'd have it in Ada 2005, the standard GUI. Of course there is still plenty of time for a separate standard, or a reference API or whatever SIGAda calls it.
> 
> (I'm not disagreeing with anything, just telling a story.)
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GUI was Re: why Ada is so unpopular ?

[Jeffrey Carter]

amado.alves wrote:
>
> There's another way: compromise. In the ASCLWG we eventually managed 
> to agree upon selecting a pre-existing container library (Charles) to 
> form the basis of the standard proposal. I didn't take long. The group 
> was assembled in June 2002 (the Ada Europe workshop in Vienna), and 
> the proposal was filed in September 2003 (AI-302/2). In the 
> intervening dense discussion (circa 500 messages on the group list, 
> plus circa 100 on the ARG forum) every one of us compromised about 
> something from naming to featured abstractions to iteration methods.

But the proposal isn't Charles and is very minimalist. The proposal 
based on the PragmAda Reusable Components (AI-302-01) has also had to 
change to something different from the PragmARCs. It's interesting that 
the original request for proposals asked for existing libraries for a 
secondary standard, but the actual proposal process forced us to propose 
new libraries with ARM wording as part of the Ada.* hierarchy.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: GUI was Re: why Ada is so unpopular ?

[Robert C. Leif]

Scalable Vector Graphics, SVG, is a World Wide Web Consortium standard that
is operating system independent.  Since CLAW is a thick binding, it quite is
possible that a good part of it could be hosted on a different technology
than Windows.  I might also note that in terms of address space the Web is
the default operating system and can even be used to manage the files on a
Windows system.  In fact, a large part of Microsoft's next operating system
is in XML.

Copied from W3C SVG site:
"SVG is a language for describing two-dimensional graphics and graphical
applications in XML. SVG 1.1 is a W3C Recommendation and forms the core of
the current SVG developments. SVG 1.2 is the specification currently being
developed as is available in draft form (comments welcome). The SVG Mobile
Profiles: SVG Basic and SVG Tiny are targetted to resource-limited devices
and are part of the 3GPP platform for third generation mobile phones. SVG
Print is a set of guidelines to produce final-form documents in XML suitible
for archiving and printing. Read more about SVG." 

The following are NOT Windows!  Please notice that the amounts of money are
considerable.  A portable, reliable Ada implementation might be worth the
effort.

"2003-12-09: Sharp and BitFlash release SVG Mobile handsets
Sharp Electronics and BitFlash have teamed to release a SVG Tiny handset in
Japan. They also provide a document conversion tool, allowing Word, PDF and
Powerpoint documents to be transcoded to SVG for display on the phone. More
information in the Sharp and BitFlash press releases."

"2003-12-08: libRSVG 2.5.0 available
The librsvg team have anounced a new release of the librsvg SVG rendering
library. This release fixes a lot of rendering bugs in order to enable near
perfect rendering of the Sodipodi flag collection and the
gnome-themes-extras SVG metathemes. People using SVG through the libRSVG
library, for instance with GNOME, are highly recommended to upgrade to this
release."

"2003-10-31: GEMoDe: an SVG Graphics Engine for Mobile Devices
The German research institute Fraunhofer IDG Rostock have announced GEMoDe,
a Java-based graphics engine that supports SVG. It supports interactivity,
and therefore can be used as a platform for developing applications. There
are some screenshots and a demonstration applet. The viewer is designed to
be easily adapted to resource limited devices such as mobile or smart
phones."

"2003-10-28: AOL purchases Viewpoint source for rendering images, including
SVG
AOL has purchased US$9M of source and US$ 1M of services from Viewpoint
Corporation. This gives them the ability to display and intermix video,
audio, 3-D and 2-D images in various formats including SVG. Since SVG 1.2
adds audio and video support, AOL would be well placed to implement SVG 1.2
should they see customer demand." 

"2003-10-27: Geosoft announces US$3M deal for SVG Mobiile GIS content
Geosoft announced a 3 million US dollar deal with MTI to supply SVG based
mapping data for deployment on cellular phones, PDAs and vehicle mapping
systems." 

"2003-10-20: Oracle and Corel integrate SVG tools with Oracle Database 10g
Oracle and Corel announced integration of the XML functionality in OracleR
Database 10g with Corel's XML and SVG tools, CorelR XMetaLR and CorelR Smart
Graphics Studio." 

"2003-10-17: Beatware announce Mobile SVG authoring with e-Picture Pro 4.0
Beatware announced e-Picture Pro 4.0 with authoring support for SVG Tiny,
SVG Basic, and SVG Full. The product is bundled with the BitFlash SVG Tiny
viewer so that content can be previewed on the desktop before deployment to
mobile clients. e-Picture Pro 4.0 runs on Windows platforms and a trial
version is availabe for download." 

Bob Leif
------------------------------------------------------
Message: 9
Date: Tue, 20 Jan 2004 07:39:14 +0000 (UTC)
From: Preben Randhol <randhol+valid_for_reply_from_news@pvv.org>
Subject: Re: GUI was Re: why Ada is so unpopular ?
To: comp.lang.ada@ada-france.org
Message-ID:
	
<slrnc0pmp2.205.randhol+valid_for_reply_from_news@k-083152.nt.ntnu.no>

On 2004-01-20, Robert C. Leif <rleif@rleif.com> wrote:
> technology like GtkAda or better yet CLAW to create the simplest version
of
> Scalable Vector Graphics or a thick binding to an existing version, such
as
> that available from Adobe. This could then serve as a foundation to host
> XForms. 

Why would we want to use a library that *only* works on one OS. I
thought the point was a *portable* library.


-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: GUI was Re: why Ada is so unpopular ?

[Georg Bauhaus]

Robert C. Leif <rleif@rleif.com> wrote:
:   In fact, a large part of Microsoft's next operating system
: is in XML.

Have you noted the licenses (aka precautionary infringement of patent
threatening letters :) they offer for their XML Schemata?
(Doesn't mean that a common standardised way of declaring your
window's resource file section (and probably more) in XML is
a Bad Thing.)


-- Georg

RE: GUI was Re: why Ada is so unpopular ?

[amado.alves]

<<...If GtkAda was going to return a 
list of something, shouldn't it ought to be a *Charles* list rather than 
something that was specific to GtkAda? ...>>

Absolutely. This is a fascinating issue. I thought about it when I wrote here before, but kept silent. But now that you've touched it, I'll add a bit. A *lot* of Ada libraries, including already standard ones (e.g. ASIS) and upcoming standard (e.g. Directory_Operations), deal with a lot of data structures, and so they should be using the standard for that (Ada.Containers, also upcoming, AI-302). The result would be clearly a good thing, more cohesion both in the standard and in applications. This is motivation number 1 for Ada.Containers in my paper in Ada-Europe 2004 (about persistent containers, but touching the general issue in passing).

Re: GUI was Re: why Ada is so unpopular ?

[Randy Brukardt]

"amado.alves" <amado.alves@netcabo.pt> wrote in message
news:mailman.12.1074699773.281.comp.lang.ada@ada-france.org...
<<...If GtkAda was going to return a
list of something, shouldn't it ought to be a *Charles* list rather than
something that was specific to GtkAda? ...>>

> Absolutely. This is a fascinating issue. I thought about it when I wrote
here before, but kept
> silent. But now that you've touched it, I'll add a bit. A *lot* of Ada
libraries, including already
> standard ones (e.g. ASIS) and upcoming standard (e.g.
Directory_Operations), deal with a lot
> of data structures, and so they should be using the standard for that
(Ada.Containers, also
> upcoming, AI-302). The result would be clearly a good thing, more cohesion
both in the
> standard and in applications. This is motivation number 1 for
Ada.Containers in my paper
> in Ada-Europe 2004 (about persistent containers, but touching the general
issue in passing).

I can't speak for ASIS, but in the case of Directory_Operations, there is no
place where a container could usefully be used. Containers are mainly useful
in non-critical parts of your application (where time and/or space
requirements aren't critical), and that cannot be said with certainty about
the various standard libraries. Moreover, you certainly don't want searching
operations returning vectors of file names, you would have no idea
whatsoever what the time/space usage of that would be. (Directories with
thousands of files aren't uncommon.) I wrote a package which did that in the
very early days of Ada, and quickly abandoned it because of problems with
large result sets. Of course, if you need a vector of files, just create it,
it's easy enough.

I agree with your basic point (that the libraries of Ada should be
integrated where possible), but the ones that are really bad offenders (like
the Ada.Strings hierarchy) already exist and aren't going to have major
changes in them.

                  Randy.

Re: GUI was Re: why Ada is so unpopular ?

[Marin David Condic]

Wait a minute. Aren't directories usually considered to be some kind of 
tree structure? Doesn't MSVC++ and the MFC supply some kind of tree 
widget for displaying things like directories? Seems like every time I 
pop up a directory on Windows, I see something that looks very 
reminiscent of a tree and one that looks surprisingly like the one I 
seem to recall was in the MFC. Maybe I'm wrong, but it looks to me like 
Microsoft might just be keeping some kind of tree data structure in 
place for handling directories. Not that the fact that Microsoft does 
something necessarily makes a recomendation for doing the same - but it 
would seem like it might not be all that painful for some apps.

What would be wrong with a "Directories" package having a call that 
would return some kind of tree data structure? Perhaps a bunch of 
smaller tree-walking type subprograms might be faster - go ahead and 
provide that as well. But either you (the Ada vendor) are going to build 
a tree data structure and populate it with data or I (the app developer) 
am going to do it after making a bunch of more primitive calls to your 
library. In the first case "you" is "1 implementation effort" and in the 
second case "I" is "N implementation efforts" where N is the number of 
developers needing such a capability. Seems more efficient to do it only 
once. That, and it makes it darned attractive to a developer to use Ada 
if most of his job is already done for him.

Also, assuming a "Directories" package is going to build data structures 
and return them, we'd likely want to have other packages operating on 
exactly those data structures. (A GUI library, for example) So whatever 
inefficiency might be there, you go through it only once and then have 
all your other operations making use of the result.

And sometimes we just have to accept that doing some things is going to 
take some time. Solving an N by M matrix where N and M are big is just 
plain going to suck up a lot of CPU no matter who does it. Does that 
mean that Ada shouldn't have a matrix math package?

MDC



Randy Brukardt wrote:
> 
> I can't speak for ASIS, but in the case of Directory_Operations, there is no
> place where a container could usefully be used. Containers are mainly useful
> in non-critical parts of your application (where time and/or space
> requirements aren't critical), and that cannot be said with certainty about
> the various standard libraries. Moreover, you certainly don't want searching
> operations returning vectors of file names, you would have no idea
> whatsoever what the time/space usage of that would be. (Directories with
> thousands of files aren't uncommon.) I wrote a package which did that in the
> very early days of Ada, and quickly abandoned it because of problems with
> large result sets. Of course, if you need a vector of files, just create it,
> it's easy enough.
> 
> I agree with your basic point (that the libraries of Ada should be
> integrated where possible), but the ones that are really bad offenders (like
> the Ada.Strings hierarchy) already exist and aren't going to have major
> changes in them.
> 
>                   Randy.
> 
> 
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GUI was Re: why Ada is so unpopular ?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Wait a minute. Aren't directories usually considered to be some kind of 
> tree structure? Doesn't MSVC++ and the MFC supply some kind of tree 
> widget for displaying things like directories? Seems like every time I 
> pop up a directory on Windows, I see something that looks very 
> reminiscent of a tree and one that looks surprisingly like the one I 
> seem to recall was in the MFC. Maybe I'm wrong, but it looks to me like 
> Microsoft might just be keeping some kind of tree data structure in 
> place for handling directories. Not that the fact that Microsoft does 
> something necessarily makes a recomendation for doing the same - but it 
> would seem like it might not be all that painful for some apps.

You're right, but this doesn't work very well when you drop
into a directory with thousands of files. A smart tree widget
might just peruse "directory portions", where the tree widget
is visible (perhaps a less than trivial exercise). But I suspect
they take the easy way out, and require all entries to be loaded
in to the widget's dynamic memory. Otherwise performance in large
directory cases would not be so abysmal.


> What would be wrong with a "Directories" package having a call that 
> would return some kind of tree data structure? 

The OP was referring to the fact that you cannot count on the fact
that you will have a limited number of directory entries returned.
The idea works if you insist on a "reasonable" sized directory.
But this is outside of your control.

This is much like insisting that an SQL query should always return
few enough rows, that can be held in the client program's memory.
Many programs get written without thinking ahead about this very
issue. Usually these short-sighted programs implement ok, but then
with time passing, and database growing, it is realized that
something else must be done about the original design.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: GUI was Re: why Ada is so unpopular ?

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:
> Marin David Condic wrote:
> 
>> Wait a minute. Aren't directories usually considered to be some kind 
>> of tree structure? Doesn't MSVC++ and the MFC supply some kind of tree 
>> widget for displaying things like directories? Seems like every time I 
>> pop up a directory on Windows, I see something that looks very 
>> reminiscent of a tree and one that looks surprisingly like the one I 
>> seem to recall was in the MFC. Maybe I'm wrong, but it looks to me 
>> like Microsoft might just be keeping some kind of tree data structure 
>> in place for handling directories. Not that the fact that Microsoft 
>> does something necessarily makes a recomendation for doing the same - 
>> but it would seem like it might not be all that painful for some apps.
> 
> You're right, but this doesn't work very well when you drop
> into a directory with thousands of files. A smart tree widget
> might just peruse "directory portions", where the tree widget
> is visible (perhaps a less than trivial exercise). But I suspect
> they take the easy way out, and require all entries to be loaded
> in to the widget's dynamic memory. Otherwise performance in large
> directory cases would not be so abysmal.

The Windows directory tree only shows directories; the thousands of 
files are not part of the tree. This helps reduce the size of the tree. 
The thousands of files are shown in the other pane of the window; as you 
note, it can take a long time to display all the files in a directory 
with many files.

-- 
Jeff Carter
"People called Romanes, they go the house?"
Monty Python's Life of Brian
79

Re: GUI was Re: why Ada is so unpopular ?

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
>> Marin David Condic wrote:
>>> Wait a minute. Aren't directories usually considered to be some kind 
>>> of tree structure? Doesn't MSVC++ and the MFC supply some kind of 
>>> tree widget for displaying things like directories? Seems like every 
>>> time I pop up a directory on Windows, I see something that looks very 
>>> reminiscent of a tree and one that looks surprisingly like the one I 
>>> seem to recall was in the MFC. Maybe I'm wrong, but it looks to me 
>>> like Microsoft might just be keeping some kind of tree data structure 
>>> in place for handling directories. Not that the fact that Microsoft 
>>> does something necessarily makes a recomendation for doing the same - 
>>> but it would seem like it might not be all that painful for some apps.
>>
>> You're right, but this doesn't work very well when you drop
>> into a directory with thousands of files. A smart tree widget
>> might just peruse "directory portions", where the tree widget
>> is visible (perhaps a less than trivial exercise). But I suspect
>> they take the easy way out, and require all entries to be loaded
>> in to the widget's dynamic memory. Otherwise performance in large
>> directory cases would not be so abysmal.
> 
> The Windows directory tree only shows directories; the thousands of 
> files are not part of the tree. This helps reduce the size of the tree. 
> The thousands of files are shown in the other pane of the window; as you 
> note, it can take a long time to display all the files in a directory 
> with many files.

What guarantee do you have that you will not have thousands of
directories? There is no such guarantee, although you might
find it more rare in practice ;-)

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: GUI was Re: why Ada is so unpopular ?

[Marin David Condic]

Yeah, but that's still running smack-dab into my hypothetical objection 
to a matrix math package - that solving an N by M matrix where N and M 
are big is just plain going to take some time. Does that mean we 
shouldn't do it? Because *some* cases might perform poorly?

Well then, let's get rid of Text_IO because for some text files that get 
really large, its performance will be abysmal. And we shouldn't ought to 
have Unbounded_String because someone might try to fill it with a few 
megabytes of data and blow out the virtual memory. (We can find other 
examples, I'm sure. ;-)

Just because something might have poor performance in a case where large 
amounts of data are present is not an excuse to not do something in a 
language. Everyone seems to say "Yeah, we ought to have some kind of 
container library..." but then you don't want to actually use the 
container library in other compiler provided packages because it might 
be too slow for some cases? Then why should the developer use the 
container library? It might be too slow for his data as well.

I'd rather have a nicely integrated set of tools that all worked well 
with each other and if I have a case where performance demands I not use 
some capability, then I go for some work-around. For the rest of the 
cases (90%?) I didn't have to run off and roll my own to get the job 
done - it was already done for me. Wouldn't that be attractive to 
developers?

MDC

Warren W. Gay VE3WWG wrote:
> 
> The OP was referring to the fact that you cannot count on the fact
> that you will have a limited number of directory entries returned.
> The idea works if you insist on a "reasonable" sized directory.
> But this is outside of your control.
> 
> This is much like insisting that an SQL query should always return
> few enough rows, that can be held in the client program's memory.
> Many programs get written without thinking ahead about this very
> issue. Usually these short-sighted programs implement ok, but then
> with time passing, and database growing, it is realized that
> something else must be done about the original design.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GUI was Re: why Ada is so unpopular ?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Yeah, but that's still running smack-dab into my hypothetical objection 
> to a matrix math package - that solving an N by M matrix where N and M 
> are big is just plain going to take some time. Does that mean we 
> shouldn't do it? Because *some* cases might perform poorly?

Here you have full control over N and M. In the file and directory
case, you are not (unless your specific application does some
restrictive work to insure this).

> Well then, let's get rid of Text_IO because for some text files that get 
> really large, its performance will be abysmal. And we shouldn't ought to 
> have Unbounded_String because someone might try to fill it with a few 
> megabytes of data and blow out the virtual memory. (We can find other 
> examples, I'm sure. ;-)

Text_IO does things in "parts". I don't know of any Text_IO
feature that loads the entire text file at once (this would
be in the same problem domain, where the entire file might
be resource constrained).  I will grant you that the types
chosen to deal with file position (index) also set limits,
but the point is that you are working with text files in
chunks (lines, characters or blocks).

In the same way, directory operations are usually in pieces
of one file/directory name at a time (though nothing prevents
an API of processing the same in blocks of names).

> Just because something might have poor performance in a case where large 
> amounts of data are present is not an excuse to not do something in a 
> language. 

Agreed, but the examples you cite, don't wash as far as I
can see. If you want to load directory entries in managed
chunks into a container, then this is a fully controlled
operation (no "denial of service" consequence is possible).

As someone else has pointed out in this group, when speaking
of a GET operation that returns an unlimited length string,
there is a danger that the operation will fall over when
you didn't want it to (an attempt to read an extremely long
line from the network or something).

Worse than that, some O/Ss do not respond too well when
all VM is consumed by a process, taking down the whole host.
I know from experience that earlier Linux kernels had this
problem (and may still be so), and I am sure there are
several commercial kernels that also do not handle this
well either (perhaps a good one to do on SCO boxes these
days ;-)

> Everyone seems to say "Yeah, we ought to have some kind of 
> container library..." but then you don't want to actually use the 
> container library in other compiler provided packages because it might 
> be too slow for some cases? Then why should the developer use the 
> container library? It might be too slow for his data as well.

I am not against it on performance grounds. For my money,
performance is still growing quickly, and what some spend
too much time fussing about today, becomes a no-brainer
tomorrow (aside from embedded systems where budgets are
different).

> I'd rather have a nicely integrated set of tools that all worked well 
> with each other and if I have a case where performance demands I not use 
> some capability, then I go for some work-around. For the rest of the 
> cases (90%?) I didn't have to run off and roll my own to get the job 
> done - it was already done for me. Wouldn't that be attractive to 
> developers?
> 
> MDC

No argument there, when it makes sense to use containers. But
I do believe that you must hold the "reins" of them horses ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: GUI was Re: why Ada is so unpopular ?

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> In the same way, directory operations are usually in pieces
> of one file/directory name at a time

Also, while programs may treat directory operations as traversal
of static but potentially large data structures, it's actually
the case that the directory structure could be changing as the
program is running. I know of no way to get an atomic snapshot
of a directory structure.

A standard directory package cannot finesse its way around this,
or ignore it, especially if it offers iterative traversal.

Re: GUI was Re: why Ada is so unpopular ?

[Robert I. Eachus]

Hyman Rosen wrote:

> Also, while programs may treat directory operations as traversal
> of static but potentially large data structures, it's actually
> the case that the directory structure could be changing as the
> program is running. I know of no way to get an atomic snapshot
> of a directory structure.

I do, but you have to have an OS that supports it.  With Multics you 
could create a copy of a directory that you controlled as an atomic 
operation.  It was actually done by creating a new directory entry and 
setting the "copy on write" bits in the new and old directory entries. 
Now if someone modified the original directory while you were walking 
through the new one, the OS basically marked the in memory copy of 
whatever segment of the directory was modified as the copy belonging to 
the old directory, and the copy on disk as owned by the new directory.

That way both atomic operations can be atomic, and neither one actually 
involves allocating (disk or main) memory.

> A standard directory package cannot finesse its way around this,
> or ignore it, especially if it offers iterative traversal.

What I usually do in this case on inferior operating systems ;-) is to 
read the directory in chunks.  For a directory with only a few entries, 
one chunk is the whole directory and you can do things the simple way. 
If the directory is bigger than one chunk you have to do the messy 
version.  Unfortunately, on many operating systems a directory is hashed 
and there is no sorted view of the directory.  If you need to display 
the directory sorted by name, date, or whatever, there is no way to do 
it other than scan the entire directory creating a tree, and then 
display from the tree.


-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: GUI was Re: why Ada is so unpopular ?

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
:  I know of no way to get an atomic snapshot
: of a directory structure.

Don't lockf(3) or ACLs provide a means for this?


-- Georg

Re: GUI was Re: why Ada is so unpopular ?

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:400FD340.3080603@noplace.com...
...
> What would be wrong with a "Directories" package having a call that
> would return some kind of tree data structure?

One obvious answer is there is no such container in the current proposals.

And the second one, as I said before, is that the time and space use of such
a thing could not be predicted. It would be awful to base anything where the
user is waiting for a response on such a package - it could take forever. (I
have a couple of commercial programs that work this way, and they are awful
to use, because you have to wait for the programs to read the whole disk -
and allocate enough memory to hold it - before you can find do any
operations.)

> Perhaps a bunch of
> smaller tree-walking type subprograms might be faster - go ahead and
> provide that as well. But either you (the Ada vendor) are going to build
> a tree data structure and populate it with data or I (the app developer)
> am going to do it after making a bunch of more primitive calls to your
> library. In the first case "you" is "1 implementation effort" and in the
> second case "I" is "N implementation efforts" where N is the number of
> developers needing such a capability. Seems more efficient to do it only
> once. That, and it makes it darned attractive to a developer to use Ada
> if most of his job is already done for him.

Fine, suggest such a thing in a secondary standard. It doesn't make sense in
the main standard, because its something you'd hardly ever do. (I've never
ever made a tree structure in memory out of a directory walk; it's always
been either recursive routines or a single level.)

> Also, assuming a "Directories" package is going to build data structures
> and return them, we'd likely want to have other packages operating on
> exactly those data structures. (A GUI library, for example) So whatever
> inefficiency might be there, you go through it only once and then have
> all your other operations making use of the result.

I think that's the wrong view of "Directories". It provides a set of queries
into a store of some sort. Any data structures are purely programmer
artifacts.

And the ineffieciency you are talking about is massive. The previously
mentioned backup program takes 10 minutes to scan the disk even if you want
to back up a single file. I'm pretty sure we don't want to mandate that of
all Ada programs!

> And sometimes we just have to accept that doing some things is going to
> take some time. Solving an N by M matrix where N and M are big is just
> plain going to suck up a lot of CPU no matter who does it. Does that
> mean that Ada shouldn't have a matrix math package?

I agree to a point. If you really do need to access all of the files on the
disk, it is going to take time.

But the trouble with making a massive tree structure is that it makes it
very easy to do something really stupid. And testing doesn't help much --
even if it works on your desktop, it might run out of memory when run on a
server.

I believe that this sort of thinking comes from the "everything is a
container" mentality. Everything is not best modeled as a container - unless
your set of containers is so large that it would be impossible for mere
mortals to keep it straight.

The containers that hopefully will be in the standard will be a handful of
simple forms - useful for prototyping and non-critical applications, but
insufficiently controlable for places where time and/or space are critical.
They're not going to be appropriate for uses in other libraries.

Now, we're hoping that work will continue on a series of secondary standards
to provide more support for containers and whatever else. But that's clearly
inappropriate for *the* standard.

If you put in half of the time you spend writing these missives about how
wonderful a secondary library standard would be (it must be over an hour a
day based on how long it takes me to write messages here) working on one,
we'd probably have one by now. :-)

                   Randy Brukardt

Re: GUI was Re: why Ada is so unpopular ?

[Marin David Condic]

Show me the paycheck & I'll get right on it! Complaining is free. ;-)

MDC

Randy Brukardt wrote:
> 
> If you put in half of the time you spend writing these missives about how
> wonderful a secondary library standard would be (it must be over an hour a
> day based on how long it takes me to write messages here) working on one,
> we'd probably have one by now. :-)
> 
>                    Randy Brukardt
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: GUI was Re: why Ada is so unpopular ?

[Marin David Condic]

You won't get any argument from me. This was part of the point I was 
trying to make in the paper I sent to Ada Letters a while back. A *well 
integrated* library would be a really attractive thing to a developer. 
(This is why you don't want to simply glom onto some bag of stuff you 
harvested off the internet - its not *integrated*.)

Imagine something like this: Suppose Ada had a container library, a GUI 
library, an XML library and a statistics library all well integrated 
with each other. When the GUI needs a list of something - menus, etc. - 
it uses a list from the container library. When an XML document is 
sucked up into a tree, the tree is based on the container library. The 
statistics library might be defined as working on a dataset specified as 
an XML tree - again using the container library. Further, when the 
statistics library wants to display some output or store some resultant 
data it uses the GUI library and the XML library respectively. The GUI 
library could make use of XML as well for purposes of specifying the 
display or particular forms of output. (Dr. Leif's SVG example, for 
instance.)

Along comes some developer who needs to collect and process some kind of 
statistical data - lets say network analysis stuff. With Ada and its 
conventional library, he just needs to accumulate his data from 
somewhere, put it into an appropriate XML document and - BAM! - he's 99% 
done. The rest is just gluing together tools he automagically gets by 
virtue of using Ada and they all have a consistent, well integrated 
interface so its easy to learn and use.

Try doing *that* with some other language. ;-)

MDC


amado.alves wrote:> 
> Absolutely. This is a fascinating issue. I thought about it when I wrote here before, but kept silent. But now that you've touched it, I'll add a bit. A *lot* of Ada libraries, including already standard ones (e.g. ASIS) and upcoming standard (e.g. Directory_Operations), deal with a lot of data structures, and so they should be using the standard for that (Ada.Containers, also upcoming, AI-302). The result would be clearly a good thing, more cohesion both in the standard and in applications. This is motivation number 1 for Ada.Containers in my paper in Ada-Europe 2004 (about persistent containers, but touching the general issue in passing).


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

RE: GUI was Re: why Ada is so unpopular ?

[amado.alves]

<<But the proposal isn't Charles and is very minimalist.>>

Charles-for-ARG (AI-302/2) is basically a distilled version of Charles, yes.

<<The proposal 
based on the PragmAda Reusable Components (AI-302-01) has also had to 
change to something different from the PragmARCs.>>

I know. It's a pity the AI is split in *alternatives*. I don't see PragmARC-for-ARG (alternative 1) and Charles-for-ARG (alternative 2) really as alternatives. Even if they were in fact developed separately [to my knowledge what is now alternative 2 counted with more discussion in the ASCLWG forum (a Yahoo! group), than PragmARC-for-ARG], both socalled alternatives have specific pluses. For example, I think alternative 1 has better naming and iteration model, and alternative 2 has better reference implementation.

I have formulated my contributions to AI-302 in an alternative-independent way. But by the ARG process they had to go into one alternative. (My document on design bases went to 1, while the persistence and indefinite elements annexes proposal went to 2.

But at least in the second case I explicitly say right there that it is alternative-independent.) Let's hope the Ada.Containers team be able to merge the good things from both alternatives--and with the alternative-independent persistent and indefinite elements proposals ;-)

(Sorry for the illformatted text. I'm currently limited to a stupid webmail system that I cannot configure.)

RE: GUI was Re: why Ada is so unpopular ?

[amado.alves]

<<...this doesn't work very well when you drop
into a directory with thousands of files. A smart tree widget
might just peruse "directory portions", where the tree widget
is visible (perhaps a less than trivial exercise). But I suspect
they take the easy way out, and require all entries to be loaded
in to the widget's dynamic memory...>>

A solution to this is to have and use standard iterator signatures, defined e.g. as formal packages descendants of Ada.Containers. (As an iterator is clearly an item of container design, iterator signatures belong there.)

Directory_Listing (say) builds an 'internal' iterator, and return an instantiation of the standard signature, grounded on this internal iterator. Then all is well. The Directory package would not be using the Ada.Containers 'engines', but just their specification. (The advantages include the possiblity of interaction with other standard containers e.g. perform a deep copy of a part of the tree to send to a GUI object).

However, I think Ada.Containers should provide 'real' containers with the structure and efficiency required by Directories. Even the possible cyclic graphs of directories with links. If Ada.Containers does not have this already (I don't recall), it should be a simple (!) matter of adjusting (basically, generalizing) the structures already in the reference implementation of Directories (?) and moving them to Ada.Containers.

I suspect these things don't happen because of the communication costs between the teams working on the several proposals (Containers, Directories, ASIS, ...) The costs are high, we simply don't have the means to support them, so there simply is no communication. Result: a disconnected standard :-(

Re: GUI was Re: why Ada is so unpopular ?

[Warren W. Gay VE3WWG]

amado.alves wrote:

> <<...this doesn't work very well when you drop
> into a directory with thousands of files. A smart tree widget
> might just peruse "directory portions", where the tree widget
> is visible (perhaps a less than trivial exercise). But I suspect
> they take the easy way out, and require all entries to be loaded
> in to the widget's dynamic memory...>>
> 
> A solution to this is to have and use standard iterator signatures, defined e.g. as formal packages descendants of Ada.Containers. (As an iterator is clearly an item of container design, iterator signatures belong there.)

(BTW, you need to word wrap your responses. When not wrapped
to a reasonable line length, they are difficult to read and
edit).

There are several implementations that can address the performance
issue when it comes to the widget. I am not so easily convinced
that this is possible for a container of "entries". Unless the
O/S can tell you without an exhaustive search of the directory,
how many "entries" you have, some of that same overhead is
still there (memory is excluded, but the reading + counting
of directory entries is still there).

So I don't disagree on theoretical grounds, but in practice
I don't think this would work well.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk