Ada package registry?

Ada package registry?

[olivier.henley]

Hey,

Anyone thought about doing something similar to DUB, the D package registry (http://code.dlang.org/) ... for Ada? 

(I know there are other projects for other languages but I also know for a fact that the D community did an exhaustive overview about these techs before committing to theirs)

In my opinion this is a silver bullet for the adoption/recruiting of new users to the language. It is also a silver bullet to speed up lib and application complexity/diversity. Just look at the amount/diversity of packages available at code.dlang.org. All this happened in about two years. 

1. It centralizes libs/applications existence knowledge. ('Ah there is a generic markov chain library I was not aware of... why not undertake my next model-based multivariable control system using Markov chains in Ada. Cool.')

2. It centralizes libs/applications efforts. (Huge impact when it comes to collaboration and reducing 'duplicate half-dead efforts' concerning specific tech: 'Ah there is a generic markov chain library I was not aware of... why not help this person improve the lib as I am a Markov Chain specialist. Cool.')

3. You get improved code for free and automatically. Dependencies updates are retrieved on command.

4. It eases complex application build setup and maintenance.

For sure, at the moment, Ada initiatives are not gathered properly. For example, were you aware of the existence of a lean Ada library for generating UUIDs? No you did not and maybe this is why you did your own 'kind-ish' version at your job or on your free time to fulfill the requirements of another project.

An Ada package registry would have informed you of its existence. From there you could have decided to use this lib, improve this lib, propose a new one and/or decide to start that new application that was waiting for that specialised work of implementing UUIDs to be lifted for you. My two cents.


Comments? Thoughts?

How would you do it... or not/why not?

Thx.


p.s: Before we get there... the fact that many wikipedia articles are of poor quality does not affect its tremendous usefulness.

Re: Ada package registry?

[gautier_niouzes]

Perhaps this ?

  http://www.adaic.org/ada-resources/ada-on-the-web/
  http://www.adaic.org/ada-resources/tools-libraries/

_________________________ 
Gautier's Ada programming 
http://www.openhub.net/accounts/gautier_bd

Re: Ada package registry?

[David Botton]

There is work on such a PM in progress, ask on #Ada

Re: Ada package registry?

[Randy Brukardt]

<gautier_niouzes@hotmail.com> wrote in message 
news:581c84fd-ad47-46ab-9dee-64466113b915@googlegroups.com...
> Perhaps this ?
>
>  http://www.adaic.org/ada-resources/ada-on-the-web/
>  http://www.adaic.org/ada-resources/tools-libraries/

Hopefully. I try to put every tool and library that I find out about into 
those. Searching, in particular, will pick up almost every library that I've 
indexed -- I spend a lot of time maintaining that list. (I say "almost" 
because some sites refuse access for us to index them, and as a good 
internet citizen we won't index such sites.)

                              Randy.

Re: Ada package registry?

[Randy Brukardt]

<olivier.henley@gmail.com> wrote in message 
news:02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com...
>For sure, at the moment, Ada initiatives are not gathered properly.

Definitely false. I've been maintaining lists of sources of Ada packages and 
the Ada-wide search engine ever since we took over maintenance of AdaIC. For 
specific requirements, definitely try the Ada-wide search engine. 
(http://www.adaic.org/ada-resources/ada-on-the-web/). If there's an 
Ada-related site that's not included in that, it's either because the owner 
asked us not to include it, or we don't know about it at all. (In the latter 
case, send a message to news@adaic.com and it will get included in a future 
listing.)

(I don't recommend using the raw listing of libraries for searching for 
particular libraries, simply because that doesn't look inside of the various 
repositories [those are listed as single listing], the search engine does.)

> For example, were you aware of the existence of a lean Ada library for 
> generating UUIDs?
> No you did not and maybe this is why you did your own 'kind-ish' version 
> at your job or
> on your free time to fulfill the requirements of another project.

When I stuck "UUID" into the Ada-wide search engine, I got 6 (!) hits. Not 
sure that any of them are relevant, but if not that's because there is no 
such library that's ever been announced here or sent to AdaIC. In which 
case, it doesn't exist (practically). [The primary reason I read this 
newsgroup daily is to pick up announcements for AdaIC.]

                               Randy.

P.S. I'm skeptical that any such repository would be kept very current. 
After the organizers initially populate it, I think it's not very likely 
that much updating would get done. After all, all library authors have to do 
to get on the AdaIC is send us a link -- I do all of the rest of the work. 
Yet hardly anyone does that. To have some sort of automated repository would 
require authors to do more: mirror their work somewhere they're not used to, 
or write a complex description for the repository, or more. (What are the 
odds that such a repository could figure out how to pull files from the 
version control on RRSoftware.Com and Ada-Auth.org, for instance? It could 
surely be done, but it would require some custom coding and I can't see how 
that would happen. In the absence of that, one is clearly going to have a 
subset of offerings...)

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-01-29 23:27, Randy Brukardt wrote:
>
> Yet hardly anyone does that. To have some sort of automated repository would
> require authors to do more: mirror their work somewhere they're not used to,
> or write a complex description for the repository, or more.

There is PAD http://pad.asp-software.org but it is not very suitable for 
software libraries.

> (What are the
> odds that such a repository could figure out how to pull files from the
> version control on RRSoftware.Com and Ada-Auth.org, for instance? It could
> surely be done, but it would require some custom coding and I can't see how
> that would happen. In the absence of that, one is clearly going to have a
> subset of offerings...)

I think that most users need more than raw source code. For example, AWS 
and GtkAda are much too complex to install manually.

Any repository to be useful must provide installers for sources and the 
run-time for an exploding number of targets.

It also must maintain dependencies between packages and tests.

Not to happen, in short.

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

Re: Ada package registry?

[Dirk Heinrichs]

Randy Brukardt wrote:

> <gautier_niouzes@hotmail.com> wrote in message
> news:581c84fd-ad47-46ab-9dee-64466113b915@googlegroups.com...
>> Perhaps this ?
>>
>>  http://www.adaic.org/ada-resources/ada-on-the-web/
>>  http://www.adaic.org/ada-resources/tools-libraries/
> 
> Hopefully. I try to put every tool and library that I find out about into
> those. Searching, in particular, will pick up almost every library that
> I've indexed -- I spend a lot of time maintaining that list. (I say
> "almost" because some sites refuse access for us to index them, and as a
> good internet citizen we won't index such sites.)

BTW: The link to AdaStudio is dead (redirected to some domain reseller 
site).

Bye...

	Dirk
-- 
Dirk Heinrichs <dirk.heinrichs@altum.de>
GPG Public Key CB614542 | Jabber: dirk.heinrichs@altum.de
Tox: heini@toxme.se
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de

Re: Ada package registry?

[Tero Koskinen]

Hi,

30.1.2016, 9.35, Dmitry A. Kazakov wrote:
> On 2016-01-29 23:27, Randy Brukardt wrote:
>>
>> Yet hardly anyone does that. To have some sort of automated
>> repository would require authors to do more: mirror their work
>> somewhere they're not used to, or write a complex description for
>> the repository, or more.
>
> There is PAD http://pad.asp-software.org but it is not very suitable
>  for software libraries.
>
>> (What are the odds that such a repository could figure out how to
>> pull files from the version control on RRSoftware.Com and
>> Ada-Auth.org, for instance? It could surely be done, but it would
>> require some custom coding and I can't see how that would happen.
>> In the absence of that, one is clearly going to have a subset of
>> offerings...)
>
> I think that most users need more than raw source code. For example,
>  AWS and GtkAda are much too complex to install manually.
>
> Any repository to be useful must provide installers for sources and
> the run-time for an exploding number of targets.
>
> It also must maintain dependencies between packages and tests.
>
> Not to happen, in short.

Many languages have this sort of package repository and
package management tools:

NPM for Node.js / Javascript
  - https://www.npmjs.com/
Cargo for Rust
  - https://crates.io/
DUB for D language:
  - http://code.dlang.org/
Hackage for Haskell
  - https://hackage.haskell.org/
PyPI (Python Package Index) for Python
  - https://pypi.python.org/pypi
RubyGems for Ruby
  - https://rubygems.org/
CPAN for Perl
- http://www.cpan.org/
Maven for Java
  - http://maven.apache.org/
Clojars for Clojure
  - https://clojars.org/

Usually the repositories are maintained in "wiki"-style and anyone can
update the package details (within certain limits). This causes some
security concerns/implications, but in general there is not that much
abuse and the repositories work well enough.

The package repository management tool is used like this:

  $ language_package_mananager install X
  Downloading dependencies for 'X', please wait a while...
  Downloading X...
  Package 'X' installed!
  $

Once the package (a library usually) is installed (to your home
directory), you can link it to your program and simply use it.

People using other programming languages have managed to create
these package repositories, so it is a shame if Ada programmers
cannot manage to do the same.

You of course need to solve many problems related to this domain,
but they are already solved by others, so one should be able to
copy the design and just do the Ada implementation.

On the other hand, one could think that the package management
systems provides by Linux distributions and BSD operating systems
are enough. But generally, these are not that flexible. For example,
the language specific package managers allow one to install multiple
versions of the packages at the same time and the code can be even
taken from the version control directly.

Yours,
  Tero

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-01-30 23:14, Tero Koskinen wrote:

> Usually the repositories are maintained in "wiki"-style and anyone can
> update the package details (within certain limits). This causes some
> security concerns/implications, but in general there is not that much
> abuse and the repositories work well enough.
>
> The package repository management tool is used like this:
>
>   $ language_package_mananager install X
>   Downloading dependencies for 'X', please wait a while...
>   Downloading X...
>   Package 'X' installed!
>   $

Yes, the problem is to have it working.

> Once the package (a library usually) is installed (to your home
> directory), you can link it to your program and simply use it.

No, that the point. It cannot be installed in your home directory. It 
must be in the directories mandated by the target system policy. E.g. 
for Debian Linux:

https://people.debian.org/~lbrenta/debian-ada-policy.html#Files-provided-by-the-_002ddev-package

> People using other programming languages have managed to create
> these package repositories, so it is a shame if Ada programmers
> cannot manage to do the same.

I guess these are scripting languages and pure packages having no access 
to the system environment otherwise than through the language run-time. 
There is no problem to do same for GNAT. That is not Ada case. Most Ada 
packages do access platform-specific non-Ada libraries. Pure Ada 
packages face no problem, if gpr file is provided.

> You of course need to solve many problems related to this domain,
> but they are already solved by others, so one should be able to
> copy the design and just do the Ada implementation.
>
> On the other hand, one could think that the package management
> systems provides by Linux distributions and BSD operating systems
> are enough. But generally, these are not that flexible.

But you cannot work around them. E.g. GtkAda must recursively install 
Gtk, GObject, LibC, whatever, which are target system's packages, under 
the target system's repository.


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

Re: Ada package registry?

[Mart van de Wege]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2016-01-30 23:14, Tero Koskinen wrote:
>
>> Usually the repositories are maintained in "wiki"-style and anyone can
>> update the package details (within certain limits). This causes some
>> security concerns/implications, but in general there is not that much
>> abuse and the repositories work well enough.
>>
>> The package repository management tool is used like this:
>>
>>   $ language_package_mananager install X
>>   Downloading dependencies for 'X', please wait a while...
>>   Downloading X...
>>   Package 'X' installed!
>>   $
>
> Yes, the problem is to have it working.
>
>> Once the package (a library usually) is installed (to your home
>> directory), you can link it to your program and simply use it.
>
> No, that the point. It cannot be installed in your home directory. It
> must be in the directories mandated by the target system
> policy. E.g. for Debian Linux:
>
> https://people.debian.org/~lbrenta/debian-ada-policy.html#Files-provided-by-the-_002ddev-package
>
Nope. I am most familiar with Perl, so I shall use that as an example
throughout.

Installing CPAN packages through the CPAN manager requires you to either
adjust the PERLLIB environment variable, or to add a 'use lib' pragma to
your code.

Managing ADA_INCLUDE_PATH in an Ada equivalent would not be much
different.

Plus, as in CPAN, if the libraries are laid out along a standard policy,
it would be easy to provide tools to build system-local packages, like
dh_make_perl does for Perl on Debian.

>> People using other programming languages have managed to create
>> these package repositories, so it is a shame if Ada programmers
>> cannot manage to do the same.
>
> I guess these are scripting languages and pure packages having no
> access to the system environment otherwise than through the language
> run-time. There is no problem to do same for GNAT. That is not Ada
> case. Most Ada packages do access platform-specific non-Ada
> libraries. Pure Ada packages face no problem, if gpr file is provided.
>
This is not unique to Ada. Perl also has packages that require non-Perl
libraries to be available, like XML::LibXML and Text::CSV::XS. The first
has a dependency on libxml2, the second brings its own C code that must
be compiled and then accessed from the Perl module.

In both cases a hard build dependency on a working gcc environment
exists; it is the end-user's responsibility to make sure it does exist
and that the proper header files for the dependencies are installed.

Really, this is not a new issue. It is solvable, if you let go of the
NIH mentality.

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-01-31 16:52, Mart van de Wege wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> On 2016-01-30 23:14, Tero Koskinen wrote:
>>
>>> Usually the repositories are maintained in "wiki"-style and anyone can
>>> update the package details (within certain limits). This causes some
>>> security concerns/implications, but in general there is not that much
>>> abuse and the repositories work well enough.
>>>
>>> The package repository management tool is used like this:
>>>
>>>    $ language_package_mananager install X
>>>    Downloading dependencies for 'X', please wait a while...
>>>    Downloading X...
>>>    Package 'X' installed!
>>>    $
>>
>> Yes, the problem is to have it working.
>>
>>> Once the package (a library usually) is installed (to your home
>>> directory), you can link it to your program and simply use it.
>>
>> No, that the point. It cannot be installed in your home directory. It
>> must be in the directories mandated by the target system
>> policy. E.g. for Debian Linux:
>>
>> https://people.debian.org/~lbrenta/debian-ada-policy.html#Files-provided-by-the-_002ddev-package
>>
> Nope.

There is no use in a repository that does not follow the target platform 
policy.

> Managing ADA_INCLUDE_PATH in an Ada equivalent would not be much
> different.

ADA_INCLUDE_PATH is not enough and of no use anyway because there is no 
way to control it.

I wrote a small tool to install pure Ada libraries:

http://www.dmitry-kazakov.de/ada/gps_installer.htm

But I would not consider this or similar as a solution, even approximately.

> This is not unique to Ada. Perl also has packages that require non-Perl
> libraries to be available, like XML::LibXML and Text::CSV::XS. The first
> has a dependency on libxml2, the second brings its own C code that must
> be compiled and then accessed from the Perl module.
>
> In both cases a hard build dependency on a working gcc environment
> exists; it is the end-user's responsibility to make sure it does exist
> and that the proper header files for the dependencies are installed.

If that can be user responsibility then everything else can be as well.

> Really, this is not a new issue. It is solvable, if you let go of the
> NIH mentality.

I would be glad to see a workable solution. The one where everything 
beyond trivial is user responsibility is already there.

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

Re: Ada package registry?

[olivier.henley]

On Friday, January 29, 2016 at 5:27:41 PM UTC-5, Randy Brukardt wrote:
> <olivier.henley@gmail.com> wrote in message 
> news:02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com...
> >For sure, at the moment, Ada initiatives are not gathered properly.
> 
> Definitely false. I've been maintaining lists of sources of Ada packages and 
> the Ada-wide search engine ever since we took over maintenance of AdaIC. 

First, thank you for the effort and reference. I was not aware of the relevance of AdaIC. But...

1. The fact that a new user is not "naturally" directed to AdaIC is a good sign the community is not properly organised... in comparison with other flourishing communities.

2. I do not mean to break the party but some links are dead or leads to dead ends e.g code removed from page. Not to mention that some referenced website "are yelling" 1997 abandoned code/project. I know we should not and can not juge code by its packaging but we also know how presentation is important. Unity3D may be crappy code inside, I dont know, but look how they present it to you : https://unity3d.com/. Millions of people are jumping on their bandwagon. So redirecting to too old and weird websites, sharing their code, is not a good idea when your goal is to promote the idea that Ada is "actually relevant".

> When I stuck "UUID" into the Ada-wide search engine, I got 6 (!) hits. Not 
> sure that any of them are relevant ...

Well that is the main goal, to find relevant packages. I did the exercise too and AdaID did not come up so we are not in business ... yet. https://github.com/anthony-arnold/AdaID

> P.S. I'm skeptical that any such repository would be kept very current. 
> After the organizers initially populate it, I think it's not very likely 
> that much updating would get done. 

Yes it would. I think you underestimate what is meant by package repository and/or package manager, at least like DUB:

1. There is a website, e.g code.dlang.org, wiki style with limited editing power; enough to add your package infos, e.g JSON file with all infos, authors, name, dependencies etc.
2. Every package code base has to reside on some "handled" version control system ecosystem like github, bitbucket etc.
3. On your machine you need an executable e.g dub.exe

Using this executable, dub.exe, you can fetch code dependencies, generate solutions and build libs and application with simple commands. Other commands let you control all kind of stuff like the particular code version of one of your lib dependencies. 

a. Every time a lib/app owner commit new code to its repo (github, bitbucket etc) it is "automatically" maintained at code.dlang.org because this server only needs to know where to check for a particular package.

b. Dub.exe, on your machine, talks to this server and is capable of issuing git commands. Dub asks for some package, server gives infos and from there dub.exe drives git to fetch code, to a particular version, and then generate solutions and build if needs be.

c. Once in that loop, you can share your package that reference package that reference package that refer...
 
> To have some sort of automated repository would 
> require authors to do more: mirror their work somewhere they're not used to,

To use github/bitbucket/etc is mandatory. I would not hire a guy that does not know or is not interested to learn git/mercurial and use github/bitbucket/etc. Not being aware of these as a programmer, in 2016, only demonstrate serious lack of curiosity and competencies deprecation. 

> What are the odds that such a repository could figure out how to pull files 
> from the version control on RRSoftware.Com and Ada-Auth.org, for instance?

It does not matter if not ALL sources are listed. Its a tool for the future, a community policy: new packages should be setup this way so we can build more effectively, together.

On Sunday, January 31, 2016 at 10:56:07 AM UTC-5, Mart van de Wege wrote:

> This is not unique to Ada. Perl also has packages that require non-Perl
> libraries to be available, like XML::LibXML and Text::CSV::XS. The first
> has a dependency on libxml2, the second brings its own C code that must
> be compiled and then accessed from the Perl module.
> 
> In both cases a hard build dependency on a working gcc environment
> exists; it is the end-user's responsibility to make sure it does exist
> and that the proper header files for the dependencies are installed.

Yeah, its common practice to mention external dependencies in the README and/or by deduction. I would go even further, like special entries in the JSON that explicitly mentions the need for alien stuff. With DUB for example, you find a generic line like -> "libs": ["sqlite3"] inside the json config file... but we say/label "lib" for any piece of code that is not meant to be use as an end-user application, be it coded in the native language or another one. Maybe -> "alien-libs": ["sqlite3"] would be clear enough, at least to consult the doc for the meaning of alien-libs. :)

Re: Ada package registry?

[olivier.henley]

> I wrote a small tool to install pure Ada libraries:
> 
> http://www.dmitry-kazakov.de/ada/gps_installer.htm
> 

Oh Yeah! Thats cool! Thx. :)

Re: Ada package registry?

[Thomas Løcke]

On 01/29/2016 02:13 AM, olivier.henley@gmail.com wrote:
> Anyone thought about doing something similar to DUB, the D package registry (http://code.dlang.org/) ... for Ada?


IMHO we should look to Haskell and how that community have solved this
exact problem:

http://docs.haskellstack.org/en/stable/README.html
https://hackage.haskell.org/

It. Just. Works. Compiler and everything.

It is extremely well done.

-- 
Thomas Løcke | thomas@12boo.net | http://12boo.net

Re: Ada package registry?

[Georg Bauhaus]

On 01.02.16 09:30, Thomas Løcke wrote:
> On 01/29/2016 02:13 AM, olivier.henley@gmail.com wrote:
>> Anyone thought about doing something similar to DUB, the D package registry (http://code.dlang.org/) ... for Ada?
>
>
> IMHO we should look to Haskell and how that community have solved this
> exact problem:
>
> http://docs.haskellstack.org/en/stable/README.html
> https://hackage.haskell.org/
>
> It. Just. Works. Compiler and everything.

It does seem to work as a collector of solutions. Asking for "uuid",
I get a lot:
https://hackage.haskell.org/packages/search?terms=uuid
CPAN and PyPI are similar in this respect, and many will
appreciate some evaluation procedure that tells them which of
these results will just work for them.

Could you say something about portability across implementations
of Haskell?

There is the Ada-wide search engine at
http://www.adaic.org/ada-resources/ada-on-the-web/
What if this search engine knew about some Ada specific markup which
authors of packages could add to the web pages describing packages so that
these tags inform the search engine about Ada packages, specifically?

For reference, that are:
Facebook style Open Graph markup for <head>, or "data-..." attributes of
HTML5, or Dublin Core meta information, ....

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Ada package registry?

[Randy Brukardt]

"Tero Koskinen" <tero.koskinen@iki.fi> wrote in message 
news:n8jcj4$uus$1@loke.gir.dk...
...
> People using other programming languages have managed to create
> these package repositories, so it is a shame if Ada programmers
> cannot manage to do the same.

Not really. People using other programming language *implementations* have 
managed it. I see no evidence that it is possible to build such a thing that 
works with multiple implementations, running on multiple host and target 
systems, with different policies for installation, different project 
management facilities, and so on.

> You of course need to solve many problems related to this domain,
> but they are already solved by others, so one should be able to
> copy the design and just do the Ada implementation.

That wouldn't be an *Ada* repository. It would be a *GNAT* repository! There 
might be use to such a thing, but call a spade a spade here: don't insult 
those who use Ada, but don't exclusively use GNAT, by calling such a thing 
an *Ada* tool.

> On the other hand, one could think that the package management
> systems provides by Linux distributions and BSD operating systems
> are enough. But generally, these are not that flexible. For example,
> the language specific package managers allow one to install multiple
> versions of the packages at the same time and the code can be even
> taken from the version control directly.

Which was my previous point: in order for that to work, you have to insist 
on package authors in using a specific version control system, specific 
installation tools, and most likely a single Ada implementation. A lot of 
authors are not likely to change their methods of working to use such a 
system (or have the time to develop complex installation schemes), so you're 
going to end up with a (smallish) subtest of available libraries. Which 
would be actively harmful for the future of Ada (or GNAT, if you prefer) - 
it would appear that there is a lot less available than there really is.

I note that for "simple" libraries: those that use just Ada and/or target OS 
facilities, distribution simply by source code works well. For instance, we 
distributed Claw that way -- we provided a special main program that was 
designed to ensure that an Ada compiler's build tool would completely 
construct the library. Use gnatmake or corder or whatever did the trick. If 
one wanted to set up a separate project, one would use the tools of the 
implementation to do that (but it's not necessary). (If the user doesn't 
understand how to use the compiler's build tool, they need to understand 
that before doing anything in any case, they're not ready to build 
*anything* in Ada.)

For more complex systems that need other libraries, I doubt there is any 
sensible solution. Unless you're planning to abandon Ada's portability 
between implementations -- not of much value, IMHO.

                                              Randy.

Re: Ada package registry?

[Randy Brukardt]

<olivier.henley@gmail.com> wrote in message 
news:0ed849e7-75aa-4b9c-8085-ba50014ac87c@googlegroups.com...
>On Friday, January 29, 2016 at 5:27:41 PM UTC-5, Randy Brukardt wrote:
>> <olivier.henley@gmail.com> wrote in message
>> news:02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com...
>> >For sure, at the moment, Ada initiatives are not gathered properly.
>>
>> Definitely false. I've been maintaining lists of sources of Ada packages 
>> and
>> the Ada-wide search engine ever since we took over maintenance of AdaIC.
>
>First, thank you for the effort and reference. I was not aware of the 
>relevance of AdaIC. But...
>
>1. The fact that a new user is not "naturally" directed to AdaIC is a good 
>sign the
>community is not properly organised... in comparison with other flourishing 
>communities.

I'd agree with that, but there's nothing new about that. If you like herding 
cats...try an Ada community initative. Not recommended for the faint of 
heart...

>2. I do not mean to break the party but some links are dead or leads to 
>dead ends
>e.g code removed from page.

Surely. I hand-check all of the links that come up dead (or sites that 
change to just one page, which typically means they've turned into a link 
parking site), but it's impractical to check every link all of the time. If 
the links work, I'd have no reason to look at them.

>Not to mention that some referenced website "are yelling" 1997 abandoned 
>code/project.

So what? Good Ada code doesn't suddenly become useless because it's old. 
Good libraries don't NEED any maintenance, and Ada's been around since the 
early 1980s. Obviously, it depends on what you're looking for; if it is 
something relatively new or changable, dead is not good. If it's an FTP 
library, it probably doesn't matter when it was created.

I'm not going to try to judge "goodness" of code, 'cause very little of it 
meets MY standards.

> I know we should not and can not juge code by its packaging but we also
> know how presentation is important. Unity3D may be crappy code inside, I 
> dont
> know, but look how they present it to you : https://unity3d.com/. Millions 
> of people are
> jumping on their bandwagon. So redirecting to too old and weird websites, 
> sharing their
> code, is not a good idea when your goal is to promote the idea that Ada is 
> "actually relevant".

People who are over-interested in "presentation" are not likely to be 
interested in Ada, IMHO.

>> When I stuck "UUID" into the Ada-wide search engine, I got 6 (!) hits. 
>> Not
>> sure that any of them are relevant ...
>
>Well that is the main goal, to find relevant packages. I did the exercise 
>too and AdaID did
> not come up so we are not in business ... yet. 
> https://github.com/anthony-arnold/AdaID

Probably because there is no web page explaining what it is. (And I can't 
index github.com with the current tools; that should change with the next 
generation.) I don't generally link directly to repositories, because 
everything needs more explanation than one line. (Sourceforge is an 
exception, as it includes nice web pages to front the repository.)

...
>> P.S. I'm skeptical that any such repository would be kept very current.
>> After the organizers initially populate it, I think it's not very likely
>> that much updating would get done.
>
>Yes it would. I think you underestimate what is meant by package repository
> and/or package manager, at least like DUB:

I think you overestimate the effort that most Ada programmers will put into 
such things...after all, we've had AdaHome, AdaPower, AdaIC, and probably 
others which such things, and they've all (except AdaIC) died from neglect.

>1. There is a website, e.g code.dlang.org, wiki style with limited editing 
>power;
> enough to add your package infos, e.g JSON file with all infos, authors, 
> name,
> dependencies etc.

Which requires the author to do something; many of them can't even be 
bothered to post about their libraries here (like AdaID) or send a link to 
AdaIC? Why do you think they would use some more complex website?

>2. Every package code base has to reside on some "handled" version control 
>system
>ecosystem like github, bitbucket etc.

Most likely, only one or two. Much too hard to create something that works 
with everything, and like as not the volunteers will run out of energy long 
before.

>3. On your machine you need an executable e.g dub.exe

One would hope that this would be handled by Gnoga and not something that 
has to be installed. As you as you require a program, you're limited to 
Windows and Linux and maybe Mac, and someone has to fix that program every 
time there is an OS update.

>Using this executable, dub.exe, you can fetch code dependencies, generate 
>solutions
>and build libs and application with simple commands. Other commands let you 
>control
>all kind of stuff like the particular code version of one of your lib 
>dependencies.

In order words, yet another tool to learn. One of the reasons I have so much 
trouble with Linux is that you have to figure out the various package 
managers before you can do anything -- but I usually just want to get 
whatever I need done and move on.

...
BTW, this is *exactly* what I thought you meant. I find it a combination of 
overkill and likely harm to the Ada community (by excluding large portions 
of, by the extra work involved at a minimum).

>> To have some sort of automated repository would
>> require authors to do more: mirror their work somewhere they're not used 
>> to,

>To use github/bitbucket/etc is mandatory. I would not hire a guy that does 
>not
>know or is not interested to learn git/mercurial and use 
>github/bitbucket/etc. Not
>being aware of these as a programmer, in 2016, only demonstrate serious 
>lack of
>curiosity and competencies deprecation.

I don't want to reargue this again, but all of these version control systems 
are a serious step backwards for Ada source management from the (custom) 
version control we use here in-house.

I built a series of shell programs to provide the additional facilities that 
are missing from every version control I've ever looked at. They provide 
management of related but different source files (different bodies for 
different targets), including flagging of files that need attention, as well 
as managment of file sets for different targets. The only advantage of 
github et. al.over what we have is collaboration, which is not relevant for 
a propriatary code store that I would never put on-line in the first place. 
("Internet Security" is essentially the same sort of oxymoron as "Military 
Intelligence" :-).

I am not interested into moving to on-line systems that would require 
significant work (to save nearly 30 years of development history), to lose 
important capabilities, and to have less security. Change for the sake of 
change (and that's what most of it is) is actively harmful to everyone, and 
a massive waste of time.

For my public projects, I have little interest in wasting time on tools that 
have nothing to do with the project; so I use the same setups that I use for 
everything else.

>> What are the odds that such a repository could figure out how to pull 
>> files
>> from the version control on RRSoftware.Com and Ada-Auth.org, for 
>> instance?
>
>It does not matter if not ALL sources are listed.

Actually, it does. A tool that includes 30% of the available source will 
make the listing on AdaIC look robust!

> Its a tool for the future, a community policy: new packages should be 
> setup
> this way so we can build more effectively, together.

Don't buy it. Especially once whatever it does becomes obsolete (and change 
for the sake of change, the mantra of this century, will make that sooner 
rather than later).

                            Randy.

Re: Ada package registry?

[Thomas Løcke]

On 02/01/2016 10:32 AM, Georg Bauhaus wrote:
> Could you say something about portability across implementations
> of Haskell?


The stack tool is, to my knowledge, heavily focused on the GHC compiler
right now, but that is to be expected as GHC is by far the most commonly
used Haskell compiler - some would perhaps even argue that it is THE
Haskell compiler.

But using stack does not in any way keep you from building your project
with UHC, if you're so inclined. Stack doesn't enforce building with
stack, it just enables you to do so.

What you get with stack is a dead simple way to make sure that packages
_always_ build, even very complicated and large packages. It enables you
to define compiler version/dependencies, and be comfortable in knowing
that stack will handle those dependencies for you and other stack users.

It provides for a very lean and reliable approach for making and
maintaining Haskell projects.

I've used it on Linux, Windows and OSX, and it just works.


>
> There is the Ada-wide search engine at
> http://www.adaic.org/ada-resources/ada-on-the-web/
> What if this search engine knew about some Ada specific markup which
> authors of packages could add to the web pages describing packages so that
> these tags inform the search engine about Ada packages, specifically?


The problem is that this does not help building complicated libraries /
projects. The fact that I can find project X does not necessarily make
it straightforward for me to use X, and moving across operating systems
this problem becomes pretty huge.

Stack and stack-like tools solve that problem.

I'm under no illusion that this is a simple task to mimic for Ada - I'm
just saying that it works exceedingly well for Haskell.

:o)

-- 
Thomas Løcke | thomas@12boo.net | http://12boo.net

Re: Ada package registry?

[jsquirek]

I think the biggest problem facing the community is the actual portability of many of the most useful libraries and not on locating them. I can't tell you the amount of times I've tried to get Ada working with SQL on Windows and failed.

The bottom line is Make is unreliable on Windows and Autoconfig is unusable. Having a version of ASIS, matreshka, or AWS that built with GPR alone would be a huge selling point.

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-02 15:51, jsquirek@gmail.com wrote:

> I think the biggest problem facing the community is the actual
> portability of many of the most useful libraries and not on locating
> them. I can't tell you the amount of times I've tried to get Ada
> working with SQL on Windows and failed.

What the problem? ODBC bindings work perfectly well under Windows.

> The bottom line is Make is unreliable on Windows and Autoconfig is
> unusable.

Yes, which is why they never should be used. Nor they needed in order to 
distribute Ada libraries.

> Having a version of ASIS, matreshka, or AWS that built with
> GPR alone would be a huge selling point.

I never used any of, but I wonder how they happen not to provide gpr files?

IMO no Ada library should come without it, as GNAT is de-facto standard 
Ada compiler.

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

Re: Ada package registry?

[Shark8]

On Monday, February 1, 2016 at 5:44:50 PM UTC-7, Randy Brukardt wrote:
> <olivier.henley> wrote in message 
> >1. There is a website, e.g code.dlang.org, wiki style with limited editing 
> >power;
> > enough to add your package infos, e.g JSON file with all infos, authors, 
> > name,
> > dependencies etc.
> 
> Which requires the author to do something; many of them can't even be 
> bothered to post about their libraries here (like AdaID) or send a link to 
> AdaIC? Why do you think they would use some more complex website?

Well, to be fair "posting about their libraries here" *IS* requiring the authors to be doing something.

A good tool, IMO, would handle checking and submitting. Probably without much more difficulty than something like PowerArchiver for creating ZIP archives.

> >2. Every package code base has to reside on some "handled" version control 
> >system
> >ecosystem like github, bitbucket etc.
> 
> Most likely, only one or two. Much too hard to create something that works 
> with everything, and like as not the volunteers will run out of energy long 
> before.

If the "submission tool" ensures that anything submitted is compilable, we could process/store it in a DB. The hardest part would probably be going from the intermediate-representation to the DB, something like that could be done by a tool that reads the type definitions, creates the tables, and stores all the objects.

> >3. On your machine you need an executable e.g dub.exe
> 
> One would hope that this would be handled by Gnoga and not something that 
> has to be installed. As you as you require a program, you're limited to 
> Windows and Linux and maybe Mac, and someone has to fix that program every 
> time there is an OS update.

Agreed.
But we don't need to expand the scope to include non-Ada portions of the dependencies; this would mean we wouldn't have to worry about binaries and OSes.

Naturally, having some sort of way to link to binaries/installers would be nice, but it's not requisite.

> >Using this executable, dub.exe, you can fetch code dependencies, generate 
> >solutions
> >and build libs and application with simple commands. Other commands let you 
> >control
> >all kind of stuff like the particular code version of one of your lib 
> >dependencies.
> 
> In order words, yet another tool to learn. One of the reasons I have so much 
> trouble with Linux is that you have to figure out the various package 
> managers before you can do anything -- but I usually just want to get 
> whatever I need done and move on.
> 
> ...
> BTW, this is *exactly* what I thought you meant. I find it a combination of 
> overkill and likely harm to the Ada community (by excluding large portions 
> of, by the extra work involved at a minimum).

I see your point, but I don't agree that it's likely to harm the Ada community. (Provided that it's done competently.)

> >> To have some sort of automated repository would
> >> require authors to do more: mirror their work somewhere they're not used 
> >> to,
> 
> >To use github/bitbucket/etc is mandatory. I would not hire a guy that does 
> >not
> >know or is not interested to learn git/mercurial and use 
> >github/bitbucket/etc. Not
> >being aware of these as a programmer, in 2016, only demonstrate serious 
> >lack of
> >curiosity and competencies deprecation.
> 
> I don't want to reargue this again, but all of these version control systems 
> are a serious step backwards for Ada source management from the (custom) 
> version control we use here in-house.

All of those systems could, in theory, be tied into (or handled by) the "submission tool" -- where an author could click an "update and build" which would sync his environment with the VCS and build then, if successful, push the new version onto the Ada-specific repository.


> I built a series of shell programs to provide the additional facilities that 
> are missing from every version control I've ever looked at. They provide 
> management of related but different source files (different bodies for 
> different targets), including flagging of files that need attention, as well 
> as managment of file sets for different targets. The only advantage of 
> github et. al.over what we have is collaboration, which is not relevant for 
> a propriatary code store that I would never put on-line in the first place. 
> ("Internet Security" is essentially the same sort of oxymoron as "Military 
> Intelligence" :-).

Couldn't we handle these cases if we did it ourselves? I mean we don't need to have the package-manager itself handle building and installing, instead provide an API for those specific tools to do that, so we could limit what we're interested in to what all an Ada project needs.

> I am not interested into moving to on-line systems that would require 
> significant work (to save nearly 30 years of development history), to lose 
> important capabilities, and to have less security. Change for the sake of 
> change (and that's what most of it is) is actively harmful to everyone, and 
> a massive waste of time.

I understand and agree -- however, if the system you're using is 30 years old and contains facilities that modern VCSs lack, doesn't this mean that there's an opportunity here?

> For my public projects, I have little interest in wasting time on tools that 
> have nothing to do with the project; so I use the same setups that I use for 
> everything else.

That is quite understandable; I tend to do the same myself.

> > Its a tool for the future, a community policy: new packages should be 
> > setup
> > this way so we can build more effectively, together.
> 
> Don't buy it. Especially once whatever it does becomes obsolete (and change 
> for the sake of change, the mantra of this century, will make that sooner 
> rather than later).

I think I could buy it -- the biggest issue, I think, seems to be a method for specifying the project (things like alternate bodies, etc), if we could do that then the rest is essentially protocol details, right?

Re: Ada package registry?

[gautier_niouzes]

Le mardi 2 février 2016 15:51:50 UTC+1, jsqu...@gmail.com a écrit :
> I think the biggest problem facing the community is the actual portability of many of the most useful libraries and not on locating them. I can't tell you the amount of times I've tried to get Ada working with SQL on Windows and failed.

For SQL on Windows, use it (works at work for years now!):
  https://github.com/TurboGit/Ada-ODBC
Perhaps SQL is an example of something that is difficult to have portable.
For several projects of mine I do my best to have them portable (i.e. really portable, without tricks like preprocessing) and sometimes it is successful (e.g. Zip-Ada). Of course for that it requires being a bit system-agnostic and test on various compilers / OS, and not only your preferred system.
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont/

Re: Ada package registry?

[gautier_niouzes]

Le mardi 2 février 2016 19:45:06 UTC+1, Shark8 a écrit :

> Well, to be fair "posting about their libraries here" *IS* requiring the authors to be doing something.

It is what Randy means...
 
> A good tool, IMO, would handle checking and submitting. Probably without much more difficulty than something like PowerArchiver for creating ZIP archives.

You mean rather... Zip-Ada :-).
Why not use an Ada package for building an Ada package registry ?...
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont/

Re: Ada package registry?

[Shark8]

On Tuesday, February 2, 2016 at 1:15:00 PM UTC-7, gautier...@hotmail.com wrote:
> Le mardi 2 février 2016 19:45:06 UTC+1, Shark8 a écrit :
> 
> > Well, to be fair "posting about their libraries here" *IS* requiring the authors to be doing something.
> 
> It is what Randy means...

True; my point was that while we can't really have a system agnostic tool that requires no human action, we can make things easy.

> > A good tool, IMO, would handle checking and submitting. Probably without much more difficulty than something like PowerArchiver for creating ZIP archives.
> 
> You mean rather... Zip-Ada :-).

No; I was talking about ease of UI use. Certainly not the underlying formats.

> Why not use an Ada package for building an Ada package registry ?...

This is the ides I would advocate (making it as much self-hosting as possible); however, I don't think that it's a good idea to tie ourselves to a file-system or build-tool (those being sufficiently outside the scope of package management, as well as introducing their own problems [e.g. case-sensitive FS vs case-insensitive]).

I think having an IR amenable to DB-storage would fit quite well here -- we could use the DB itself to help ensure consistency; we could also use it to provide some VCS functionality. (Thinking of programs as 'text' [and 'files'] is going to work against the level of sophistication we can put in our tools.)

Re: Ada package registry?

[Björn Lundin]

On 2016-02-02 15:51, jsquirek@gmail.com wrote:
> I think the biggest problem facing the community is the actual portability of many of the most useful libraries and not on locating them. I can't tell you the amount of times I've tried to get Ada working with SQL on Windows and failed.
> 
> The bottom line is Make is unreliable on Windows and Autoconfig is unusable. Having a version of ASIS, matreshka, or AWS that built with GPR alone would be a huge selling point.
> 

what database ?
ODBC works, especially for sql-server.
However at work we use a home brew binding of
https://vrogier.github.io/ocilib/
which we find well documented and (fairly) easy to use
(this is oracle)

Privately - for Postgresql - I use a binding on top of libpq
which can be found at
https://dl.dropboxusercontent.com/u/26175828/sql.zip

Tested on linux (32 and 64 bit), windows 32 bit, aix 32 bit, mac ppc and
intel



-- 
--
Björn

Re: Ada package registry?

[gautier_niouzes]

Le mardi 2 février 2016 21:46:53 UTC+1, Shark8 a écrit :

> > > A good tool, IMO, would handle checking and submitting. Probably without much more difficulty than something like PowerArchiver for creating ZIP archives.
> > 
> > You mean rather... Zip-Ada :-).
> 
> No; I was talking about ease of UI use. Certainly not the underlying formats.

OK - it was not clear, since PowerArchiver seems to do many different things with or without UI, server-side or client-side...

So perhaps you are thinking about a specialized archive manager (for instance a special version of AZip, to stay with Ada stuff :-) ), which would grab packages or libraries from an Ada-centric repository, running on the programmer's computer ?
_________________________ 
Gautier's Ada programming 
http://gautiersblog.blogspot.com/search/label/Ada 
NB: follow the above link for a valid e-mail address 

Re: Ada package registry?

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:5e723414-8c8d-4487-87ac-60d95e1b4e01@googlegroups.com...
On Monday, February 1, 2016 at 5:44:50 PM UTC-7, Randy Brukardt wrote:
> <olivier.henley> wrote in message
>> >1. There is a website, e.g code.dlang.org, wiki style with limited 
>> >editing
>> >power;
>> > enough to add your package infos, e.g JSON file with all infos, 
>> > authors,
>> > name,
>> > dependencies etc.
>>
>> Which requires the author to do something; many of them can't even be
>> bothered to post about their libraries here (like AdaID) or send a link 
>> to
>> AdaIC? Why do you think they would use some more complex website?
>
>Well, to be fair "posting about their libraries here" *IS* requiring the 
>authors to be doing something.

Surely. But sending a link here or to AdaIC is about the minimum something I 
can imagine (anything less and you don't really want to make the library 
public in the first place -- which is irrelevant to this discussion).


>> ...
>> BTW, this is *exactly* what I thought you meant. I find it a combination 
>> of
>> overkill and likely harm to the Ada community (by excluding large 
>> portions
>> of, by the extra work involved at a minimum).

>I see your point, but I don't agree that it's likely to harm the Ada 
>community. (Provided that it's done competently.)

Harm from two things:
(1) Working only with a limited number of Ada implementations (most likely 
one);
(2) Only having a limited subset of code available;

Both of these could be fixed, but it would be very difficult to do. (A 
similar example was the job posting site that the AdaIC used to have. It was 
underpopulated enough so as to be more harmful than valuable, giving the 
impression of a lack of jobs. We finally got rid of it.)

>> I am not interested into moving to on-line systems that would require
>> significant work (to save nearly 30 years of development history), to 
>> lose
>> important capabilities, and to have less security. Change for the sake of
>> change (and that's what most of it is) is actively harmful to everyone, 
>> and
>> a massive waste of time.
>
>I understand and agree -- however, if the system you're using is 30 years 
>old
> and contains facilities that modern VCSs lack, doesn't this mean that 
> there's an opportunity here?

Surely. The system we have works quite well for our needs, but I suspect it 
would be too inflexible for others. The layout needs to be more akin to a 
network or even relational system than the hierarchical approach I took. The 
hierarchical approach is easy to understand, but the one way dependencies 
can be overly limiting. I never figured out a good way to generalize it, 
thus I've never pursued it further. Besides, VCSes seem to be nearly a 
religious experience (similar to the way many programmers feel about their 
editors), and I wasn't sure I wanted to wade into that (having done 
something similar with Ada when I was younger).

                                    Randy.

Re: Ada package registry?

[Randy Brukardt]

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

"Thomas Løcke" <thomas@12boo.net> wrote in message 
news:56b06eb8$0$301$14726298@news.sunsite.dk...
...
> The problem is that this does not help building complicated libraries /
> projects. The fact that I can find project X does not necessarily make
> it straightforward for me to use X, and moving across operating systems
> this problem becomes pretty huge.

Well, for the sorts of projects I'm interested in, finding them is 90% of 
the battle. Building an Ada library almost never requires more than dumping 
the source code into a directory and running the compiler's build tool 
(gnatmake, corder, or whatever). If it's more complicated than that, 
someone's overthought the whole thing and I most likely will forget that 
library. (After all, the reason I want an Ada library in the first place is 
so that I can fix it, include it in the source managed by Ada tools, and the 
like. If that's impractical, it's not helping.)

I realize that when libraries are bindings on third-party components, the 
situation gets more complex. But that also goes against my overall goal (if 
possible, write it or get it in Ada, and if not, try to go without).

                                  Randy.

Re: Ada package registry?

[Shark8]

On Tuesday, February 2, 2016 at 3:51:23 PM UTC-7, Randy Brukardt wrote:
> "Shark8" <onewingedshark> wrote in message 
> >> ...
> >> BTW, this is *exactly* what I thought you meant. I find it a combination 
> >> of
> >> overkill and likely harm to the Ada community (by excluding large 
> >> portions
> >> of, by the extra work involved at a minimum).
> 
> >I see your point, but I don't agree that it's likely to harm the Ada 
> >community. (Provided that it's done competently.)
> 
> Harm from two things:
> (1) Working only with a limited number of Ada implementations (most likely 
> one);
> (2) Only having a limited subset of code available;
> 
> Both of these could be fixed, but it would be very difficult to do.

The second can be ameliorated by the aforementioned "packaging tool", I think, and the first needn't be a problem at all: we don't need to tie ourselves to a particular Ada-implementation or build-system and could easily consider those to be outside the scope of such a project.

> >> I am not interested into moving to on-line systems that would require
> >> significant work (to save nearly 30 years of development history), to 
> >> lose
> >> important capabilities, and to have less security. Change for the sake of
> >> change (and that's what most of it is) is actively harmful to everyone, 
> >> and
> >> a massive waste of time.
> >
> >I understand and agree -- however, if the system you're using is 30 years 
> >old
> > and contains facilities that modern VCSs lack, doesn't this mean that 
> > there's an opportunity here?
> 
> Surely. The system we have works quite well for our needs, but I suspect it 
> would be too inflexible for others. The layout needs to be more akin to a 
> network or even relational system than the hierarchical approach I took. The 
> hierarchical approach is easy to understand, but the one way dependencies 
> can be overly limiting. I never figured out a good way to generalize it, 
> thus I've never pursued it further. Besides, VCSes seem to be nearly a 
> religious experience (similar to the way many programmers feel about their 
> editors), and I wasn't sure I wanted to wade into that (having done 
> something similar with Ada when I was younger).

Hm, I would be most interested in hearing how it handles things. -- Also, I have a Google-document (world editable) that currently contains my incomplete thoughts/ideas: https://drive.google.com/file/d/0BzyjMtQJe7iWTTBsS2o4TXBvWFU/view?usp=sharing -- So you're more than welcome to edit or comment.

Re: Ada package registry?

[Shark8]

On Tuesday, February 2, 2016 at 2:32:16 PM UTC-7, gautier...@hotmail.com wrote:
> 
> So perhaps you are thinking about a specialized archive manager (for instance a special version of AZip, to stay with Ada stuff :-) ), which would grab packages or libraries from an Ada-centric repository, running on the programmer's computer?

Closer but not quite.
The way I envision it would be essentially three programs:
(1) the 'server', which contains the library, stored in an IR;
(2) the 'client', which pulls the info from the library and inserts it into the Ada environment,
(3) the 'project-manager', which takes the library/module on the hosting computer, compiles it, and submits it to the 'server'.

Re: Ada package registry?

[Pascal Obry]

Le mardi 02 février 2016 à 17:06 -0600, Randy Brukardt a écrit :
> I realize that when libraries are bindings on third-party components,
> the 
> situation gets more complex. But that also goes against my overall
> goal (if 
> possible, write it or get it in Ada, and if not, try to go without).

Without OpenSSL or GNUTLS? Without Gtk or Qt? Without sockets? Without
Lapack/Blas?

For toy projects or embedded ones it may work but apart from that it is
difficult to avoid third party libraries and most of the time one
programmed in C.

My 2 cents,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada package registry?

[Georg Bauhaus]

On 03.02.16 05:21, Shark8 wrote:
> On Tuesday, February 2, 2016 at 2:32:16 PM UTC-7, gautier...@hotmail.com wrote:
>>
>> So perhaps you are thinking about a specialized archive manager (for instance a special version of AZip, to stay with Ada stuff :-) ), which would grab packages or libraries from an Ada-centric repository, running on the programmer's computer?
>
> Closer but not quite.
> The way I envision it would be essentially three programs:
> (1) the 'server', which contains the library, stored in an IR;
> (2) the 'client', which pulls the info from the library and inserts it into the Ada environment,
> (3) the 'project-manager', which takes the library/module on the hosting computer, compiles it, and submits it to the 'server'.
>

(2a) the 'client', which also produces a library archive ready for pushing,
one that follows a simple "standard".

The setup is easier when there is a small, agreed-upon set of requirements,
I think, such as

- P, by default, can be built with

     pragma Restrictions (No_Implementation_*)

- [optional] P is a leaf, it can be built with

      pragma Restrictions (No_Dependence)

- there are test/example programs for P which can be built after P has been
    added to the normal Ada library

Note that the first item has "by default", which is an opportunity for
vendors to put incentives into non-default editions (think: edition for Win32,
edition for proprietary OS, ...).

If this scheme is simple, then, still, complexity may be seen as an opportunity
by sales personnel, since the technical staff is payed for handling that complexity
on behalf of the vendor's customers. No other vendor can handle the same instance
of complexity. Which will be different when it is an instance of simplicity.
Yet, the is a "by default" edition, mentioned earlier, for a freemium library,
maybe.

At all costs, avoid the complexity of Linux style package management whenever
there is a chance of it becoming Ubuntu style package management. ("How to force
a dense graph of half-maintained packages, even when 'Recommended' dependences
are turned off.") Unless, of course, you can sell Ubuntu, too.

Re: Ada package registry?

[Randy Brukardt]

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

"Pascal Obry" <pascal@obry.net> wrote in message 
news:1454483747.2785.135.camel@obry.net...
Le mardi 02 février 2016 à 17:06 -0600, Randy Brukardt a écrit :
>> I realize that when libraries are bindings on third-party components, the
>> situation gets more complex. But that also goes against my overall
>> goal (if possible, write it or get it in Ada, and if not, try to go 
>> without).

>Without OpenSSL

Until very recently, I've never had a need for this (most sites have 
unencrypted access, and nothing I'm doing needs any sort of protected).

> or GNUTLS?

I don't even know what that is.

> Without Gtk or Qt?

All my GUI work to date has been on Windows, for which (as I'm sure you 
know) we constructed Claw -- which depends on nothing other than the stuff 
Microsoft includes in the OS (and an Ada compiler). If I wanted to make a 
portable GUI today, I'd use HTML directly for simple systems and most likely 
something like GNOGA for more complex ones. If you're going to compromise 
with a "portable" GUI, might was well use something that really does work 
anywhere (and you get remote access for free).

> Without sockets?

Sockets have been part of Windows since Windows 95, and I think part of Unix 
much longer than that. Nothing 3rd-party to use sockets. And of course, I'm 
mostly used Claw Sockets (part of Claw), or the generic version thereof (NC 
Sockets). We of course have an ecosystem of tools and libraries built on top 
of those. (One of the projects I'm working on occassionally in my spare time 
is erasing lingering Window-isms in them and testing them on Linux; once 
done I intend to release the entire set of libraries under the BSD license.)

> Without Lapack/Blas?

Never needed that sort of math support. There is of course a simple version 
of that support in Ada (which I certainly would create totally from scratch 
when it gets implemented in Janus/Ada); I'm sure those libraries have much 
better performance than our stuff, but that rarely really matters.

>For toy projects or embedded ones it may work but apart from that it is
>difficult to avoid third party libraries and most of the time one 
>programmed in C.

I would hardly call the Janus/Ada compiler and an ecosystem a "toy project". 
Nor the AdaIC web server/search engine, the Trash Finder anti-spam filter, 
the various ACATS tools, or the RM formatter. None of which have a darn 
thing to do with embedded software, either. Of these, only the RM formatter 
depends on anything 3rd party, and that is on MS Word (a tool, not a 
library).

I realize my background is "build everything from scratch"; it was necessary 
with Janus/Ada where we couldn't afford to license much 3rd-party stuff. (No 
open source in the 1980s, nor Internet, and the free stuff was of dubious 
quality and hard to find.) All of the 3rd party stuff we did use ended up as 
a dead-end of one sort or another, and either got replaced or needs to be 
replaced as soon as possible.

On top of which is my paranoid nature: I don't view anything I didn't write 
as truly trustworthy (see the OpenSSL problems for an example of why). But 
that comes at least in part from experience: when you build a fine edifice 
on top of sand, you usually end up with trouble. If that foundation is Ada 
source code, I have tools and knowledge to be able to fix it in an 
emergency. If that foundation is something else, you run the risk of 
watching it all wash away in that situation.

Just my 10c. (Inflation has hit hard in my 35 years of Ada work. ;-)

                            Randy.

Re: Ada package registry?

[Pascal Obry]

Randy,

> I would hardly call the Janus/Ada compiler and an ecosystem a "toy
> project". 

In fact a compiler does not push the computing environment very far. A
compiler is just a re-rewriter. It takes a set of bytes on entry and
write a set of bytes as output.

It would be *nice* to be able to do everything in Ada. But again we are
very far from this goal for most projects. So I still think that it is
not possible to do many projects without using third party libraries.
In my case I have almost zero project meeting this goal!

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada package registry?

[Dmitry A. Kazakov]

On 03/02/2016 23:11, Randy Brukardt wrote:
> "Pascal Obry" <pascal@obry.net> wrote in message
> news:1454483747.2785.135.camel@obry.net...
> Le mardi 02 février 2016 à 17:06 -0600, Randy Brukardt a écrit :
>>> I realize that when libraries are bindings on third-party components, the
>>> situation gets more complex. But that also goes against my overall
>>> goal (if possible, write it or get it in Ada, and if not, try to go
>>> without).
>
>> Without OpenSSL
>
> Until very recently, I've never had a need for this (most sites have
> unencrypted access, and nothing I'm doing needs any sort of protected).
>
>> or GNUTLS?
>
> I don't even know what that is.

It is an alternative to OpenSSL. Regardless of the merits of encrypted 
network protocols, the problem is indicative to the weakness of Ada 
community. There is nothing in OpenSSL or GNUTLS that would prevent them 
designed in Ada. Moreover some pioneering encryption work was done in 
Ada. Yet we have to resort to quite ugly C libraries [I maintain GNUTLS 
Ada bindings] for what should have been available in Ada.

>> Without Gtk or Qt?
>
> All my GUI work to date has been on Windows, for which (as I'm sure you
> know) we constructed Claw -- which depends on nothing other than the stuff
> Microsoft includes in the OS (and an Ada compiler). If I wanted to make a
> portable GUI today, I'd use HTML directly for simple systems and most likely
> something like GNOGA for more complex ones. If you're going to compromise
> with a "portable" GUI, might was well use something that really does work
> anywhere (and you get remote access for free).

Well, I don't think browser-based GUI will ever replace native GUI.

>> Without sockets?
>
> Sockets have been part of Windows since Windows 95, and I think part of Unix
> much longer than that. Nothing 3rd-party to use sockets. And of course, I'm
> mostly used Claw Sockets (part of Claw), or the generic version thereof (NC
> Sockets). We of course have an ecosystem of tools and libraries built on top
> of those. (One of the projects I'm working on occassionally in my spare time
> is erasing lingering Window-isms in them and testing them on Linux; once
> done I intend to release the entire set of libraries under the BSD license.)

The problem with external socket libraries is handling "esoteric" stuff 
like socket select, raw sockets, socketCAN etc. External libraries do 
not work well across platforms and are too low-level, e.g.  asynchronous 
socket I/O is not integrated integrated with Ada tasks.

> I realize my background is "build everything from scratch";

It is a solid background.

> On top of which is my paranoid nature: I don't view anything I didn't write
> as truly trustworthy (see the OpenSSL problems for an example of why). But
> that comes at least in part from experience: when you build a fine edifice
> on top of sand, you usually end up with trouble. If that foundation is Ada
> source code, I have tools and knowledge to be able to fix it in an
> emergency. If that foundation is something else, you run the risk of
> watching it all wash away in that situation.

Yes, but that applies to the OS as well. We cannot fix that, but we 
should try to get as much stuff as possible in Ada. Which is why Ada 
community is important.

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

Re: Ada package registry?

[Mark Carroll]

On 04 Feb 2016, Dmitry A. Kazakov wrote:

> On 03/02/2016 23:11, Randy Brukardt wrote:
(snip)
>> All my GUI work to date has been on Windows, for which (as I'm sure you
>> know) we constructed Claw -- which depends on nothing other than the stuff
>> Microsoft includes in the OS (and an Ada compiler). If I wanted to make a
>> portable GUI today, I'd use HTML directly for simple systems and most likely
>> something like GNOGA for more complex ones. If you're going to compromise
>> with a "portable" GUI, might was well use something that really does work
>> anywhere (and you get remote access for free).
>
> Well, I don't think browser-based GUI will ever replace native GUI.

Quite probably, but I do expect things like http://electron.atom.io/ to
see increasing use, especially by those maintain both web and desktop
interfaces to their systems; it's kind of the opposite of Google Web
Toolkit's approach. Such tools seem to become increasingly available and
usable.

-- Mark

Re: Ada package registry?

[Nasser M. Abbasi]

On 2/4/2016 3:05 AM, Dmitry A. Kazakov wrote:

>
> Well, I don't think browser-based GUI will ever replace native GUI.
>

What about Java applets?

:)

People think HTML5 and Javascript can be used to make amazing GUI.

The problem is which browser to use? something might run ok
on Chrome, but not on Firefox, or IE, etc.. So we replaced
the selection of the operating systems, with having to
select different browsers (which now have become the new
operating systems), but one still still have to select
which operating system to run the browser on. May be Chrome
runs better on Windows than on Mac or Linux? etc...

So the GUI problems got more complex, not better and simpler.

--Nasser

>>> Without sockets?
>>
>> Sockets have been part of Windows since Windows 95, and I think part of Unix
>> much longer than that. Nothing 3rd-party to use sockets. And of course, I'm
>> mostly used Claw Sockets (part of Claw), or the generic version thereof (NC
>> Sockets). We of course have an ecosystem of tools and libraries built on top
>> of those. (One of the projects I'm working on occassionally in my spare time
>> is erasing lingering Window-isms in them and testing them on Linux; once
>> done I intend to release the entire set of libraries under the BSD license.)
>
> The problem with external socket libraries is handling "esoteric" stuff
> like socket select, raw sockets, socketCAN etc. External libraries do
> not work well across platforms and are too low-level, e.g.  asynchronous
> socket I/O is not integrated integrated with Ada tasks.
>
>> I realize my background is "build everything from scratch";
>
> It is a solid background.
>
>> On top of which is my paranoid nature: I don't view anything I didn't write
>> as truly trustworthy (see the OpenSSL problems for an example of why). But
>> that comes at least in part from experience: when you build a fine edifice
>> on top of sand, you usually end up with trouble. If that foundation is Ada
>> source code, I have tools and knowledge to be able to fix it in an
>> emergency. If that foundation is something else, you run the risk of
>> watching it all wash away in that situation.
>
> Yes, but that applies to the OS as well. We cannot fix that, but we
> should try to get as much stuff as possible in Ada. Which is why Ada
> community is important.
>

Re: Ada package registry?

[Björn Lundin]

On 2016-02-03 23:11, Randy Brukardt wrote:

> On top of which is my paranoid nature: I don't view anything I didn't write 
> as truly trustworthy (see the OpenSSL problems for an example of why). But 
> that comes at least in part from experience: when you build a fine edifice 
> on top of sand, you usually end up with trouble. If that foundation is Ada 
> source code, I have tools and knowledge to be able to fix it in an 
> emergency. If that foundation is something else, you run the risk of 
> watching it all wash away in that situation.
> 

I note that you do not mention working with relation databases.
If you work with them, it's hard to avoid c-bindings .


--
Björn

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-04 17:52, Björn Lundin wrote:
> On 2016-02-03 23:11, Randy Brukardt wrote:
>
>> On top of which is my paranoid nature: I don't view anything I didn't write
>> as truly trustworthy (see the OpenSSL problems for an example of why). But
>> that comes at least in part from experience: when you build a fine edifice
>> on top of sand, you usually end up with trouble. If that foundation is Ada
>> source code, I have tools and knowledge to be able to fix it in an
>> emergency. If that foundation is something else, you run the risk of
>> watching it all wash away in that situation.
>>
>
> I note that you do not mention working with relation databases.
> If you work with them, it's hard to avoid c-bindings .

You could have a relational persistence storage in Ada, though. Use of a 
DBMS is frequently motivated by non-Ada tools, which arguably could be 
replaced as well.

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

Re: Ada package registry?

[Björn Lundin]

On 2016-02-04 17:59, Dmitry A. Kazakov wrote:
> On 2016-02-04 17:52, Björn Lundin wrote:
>> On 2016-02-03 23:11, Randy Brukardt wrote:
>>

>>
>> I note that you do not mention working with relation databases.
>> If you work with them, it's hard to avoid c-bindings .
> 
> You could have a relational persistence storage in Ada, though.

Yes, I've seen your comparisons with Ada storage vs sqlite.

> Use of a
> DBMS is frequently motivated by non-Ada tools, which arguably could be
> replaced as well.

Depends. It is often not possible to sell an administrative system,
that is a core part of a business logistics, and
tell the customer:

- you cannot make reports from it in SQL.

That is not going to sell a lot of systems

Especially bad is when a customer cannot pull data to Excel.
And a very easy way to do that is via DBMS.

As you say - driven by non-Ada tools, but I do not agree upon
replacing them -from a business point of view.

DBMS is also motivated by its history. It is a proven concept.

--
Björn

Re: Ada package registry?

[Randy Brukardt]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:1454568668.2996.15.camel@obry.net...

>> I would hardly call the Janus/Ada compiler and an ecosystem a "toy
>> project".
>
>In fact a compiler does not push the computing environment very far. A
>compiler is just a re-rewriter. It takes a set of bytes on entry and
>write a set of bytes as output.

Almost all programs can be described that way (taking a set of bytes in and 
writing a set out). And of course the ecosystem of an Ada implementation 
does a lot more than just "transforming bytes". Debugging and editing are 
very interactive, while build tools are rather data-intensive.

The real question is how much risk is one willing to take on, and in what 
parts of a project? Use of third-party things get things up quicker (which 
is good), but greatly increase the risk down the road. So all you're really 
saying is that you don't care about what happens down the road, which is a 
sad-but-true state of affairs in many areas of today's world.

                                   Randy.

Re: Ada package registry?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:n8v49a$19uo$1@gioia.aioe.org...
> On 03/02/2016 23:11, Randy Brukardt wrote:
...
> It is an alternative to OpenSSL. Regardless of the merits of encrypted 
> network protocols, the problem is indicative to the weakness of Ada 
> community. There is nothing in OpenSSL or GNUTLS that would prevent them 
> designed in Ada.

Precisely. I'd be more likely to implement the underlying protocol in an Ada 
package set than I would be to use some third-party library to do the job. I 
might do something different if I needed a quick and dirty solution, but I 
surely wouldn't stake my business on such things.

...
>> Sockets have been part of Windows since Windows 95, and I think part of 
>> Unix
>> much longer than that. Nothing 3rd-party to use sockets. And of course, 
>> I'm
>> mostly used Claw Sockets (part of Claw), or the generic version thereof 
>> (NC
>> Sockets). We of course have an ecosystem of tools and libraries built on 
>> top
>> of those. (One of the projects I'm working on occassionally in my spare 
>> time
>> is erasing lingering Window-isms in them and testing them on Linux; once
>> done I intend to release the entire set of libraries under the BSD 
>> license.)
>
> The problem with external socket libraries is handling "esoteric" stuff 
> like socket select, raw sockets, socketCAN etc. External libraries do not 
> work well across platforms and are too low-level, e.g.  asynchronous 
> socket I/O is not integrated integrated with Ada tasks.

Right, but I'm of the opinion that most users don't need that "esoteric" 
stuff. I've(*) been concentrating on making sockets as easy to use as 
possible, which necessarily is going to cost a bit of performance. But as 
with all things, performance has to be measured -- it's almost never what 
you expect to be a problem that turns out to be the real bottleneck.

Case-in-point: the web server that runs Ada-Auth.org. I was concerned that 
the sockets library would be too primitive to handle bursts of traffic, that 
Janus/Ada's cooperative multitasking would be a problem, and that the 
expensive operations that essentially stop the entire web server would make 
performance too choppy to be usable. But in actual fact (and even though the 
server machine is way underpowered for what it is doing), the real problem 
when the server has been overloaded has been the size of the Internet pipe 
to the server. It gets clogged long before the server grinds to a halt. So 
most work on server performance would have been just be wasted.

...
> Yes, but that applies to the OS as well. We cannot fix that, but we should 
> try to get as much stuff as possible in Ada. Which is why Ada community is 
> important.

My fantasy of course included running on top of an all-Ada OS. I eventually 
concluded that one has to pick their battles, and it made most sense to 
consider the OS the foundation and build up from there. But in an ideal 
world, I would run no C at all, and hardly anything that I don't have Ada 
source for. Sigh - the real world is never ideal.

                                    Randy.

Re: Ada package registry?

[Randy Brukardt]

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

"Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
news:n8vvfk$ml3$1@dont-email.me...
> On 2016-02-03 23:11, Randy Brukardt wrote:
...
> I note that you do not mention working with relation databases.
> If you work with them, it's hard to avoid c-bindings .

I personally think databases are WAAAAY overused. For a lot of projects, 
some sort of Ada persistent storage is a better solution. The problem in the 
past has been that such storage couldn't be abstracted very well, so one 
typically has built something custom. Ada 2012 has enough syntactic sugar 
that persistent storage libraries (like containers) should be reasonable to 
construct abstract systems that are still reasonably easy to read and write.

(The reason that we adopted the generalized reference feature that we did is 
because of the ability to use it to manage persistence -- in particular, to 
be able to figure out when the in-memory copy can be freed and written to 
the backing store.)

                                     Randy.

Re: Ada package registry?

[Randy Brukardt]

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

"Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
news:n901l6$b7$1@dont-email.me...
> On 2016-02-04 17:59, Dmitry A. Kazakov wrote:
>> On 2016-02-04 17:52, Björn Lundin wrote:
>>> On 2016-02-03 23:11, Randy Brukardt wrote:
...
> Especially bad is when a customer cannot pull data to Excel.

Why would that be hard? I do it all the time in my programs, no database (or 
even persistent storage) in sight. It's easy to read/write .csv files in 
Ada, and I believe that someone even has a library for writing .xls files.

(I'd like a nice spreadsheet program in Ada, too; one would hope it would 
stay up more than LibreOffice Calc does. But I can be a realist when 
necessary...)

> As you say - driven by non-Ada tools, but I do not agree upon
> replacing them -from a business point of view.

The real reason to stick with non-Ada tools is when large parts of the 
system already are in a non-Ada language, and you're just adding to it.

> DBMS is also motivated by its history. It is a proven concept.

Yeah, proven to make Larry Ellison very rich! The rise of No_SQL has shown 
that it's overkill (and even harmful) in many cases. But off topic to 
discuss here...

                                            Randy.

Re: Ada package registry?

[Björn Lundin]

On 2016-02-04 22:21, Randy Brukardt wrote:
> "Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
> news:n901l6$b7$1@dont-email.me...
>> On 2016-02-04 17:59, Dmitry A. Kazakov wrote:
>>> On 2016-02-04 17:52, Björn Lundin wrote:
>>>> On 2016-02-03 23:11, Randy Brukardt wrote:
> ...
>> Especially bad is when a customer cannot pull data to Excel.
> 
> Why would that be hard? I do it all the time in my programs, no database (or 
> even persistent storage) in sight. It's easy to read/write .csv files in 
> Ada, and I believe that someone even has a library for writing .xls files.

Yeah, having millions of records in .csv and
joining with a couple of other .csv files with
the same amount of data and
sounds like a really good idea...
If you got plenty of time, that is.

Looking at a customers trace table I see they generate about 100_000
records a day. Order lines are around the same.
Data saved for a month or two, before moving to long-term storage (db
not connected to production)

It very soon becomes messy to make a program to parse/group/join
aggregate any sensible information from that using pure Ada constructs.
But sql likes it.
It gets even worse when you tell the customer
- 'Write your own Ada-tool for data mining'

> (I'd like a nice spreadsheet program in Ada, too; one would hope it would 
> stay up more than LibreOffice Calc does. But I can be a realist when 
> necessary...)
> 
>> As you say - driven by non-Ada tools, but I do not agree upon
>> replacing them -from a business point of view.
> 
> The real reason to stick with non-Ada tools is when large parts of the 
> system already are in a non-Ada language, and you're just adding to it.

Nope, the real reason is that SQL is a good enough way for
non-engineers (read economists/warehouse manager etc) to make reports.
They do not write their own Ada programs. They do not care.
They want to use Excel and get data in ways THEY understand.


I'd like to hear of an ERP system (or WMS) that does NOT
use a DBMS, and has customers with 1_000+ employees.


>> DBMS is also motivated by its history. It is a proven concept.
> 
> Yeah, proven to make Larry Ellison very rich!

That too. However there are good free RDBMSs too,
but that is another story.


>The rise of No_SQL has shown 
> that it's overkill (and even harmful) in many cases.

No, it shows that not _every_ area can
make good use of a relational data base. That not every
problem breaks down to fit Codd's rules
But where it fits, it's really good.
Like Order/Orderline/delivery per day/  etc


> But off topic to  discuss here...
Indeed.


-- 
--
Björn

Re: Ada package registry?

[Pascal Obry]

Le jeudi 04 février 2016 à 14:52 -0600, Randy Brukardt a écrit :
> So all you're really 
> saying is that you don't care about what happens down the road, which
> is a 
> sad-but-true state of affairs in many areas of today's world.

Wrong reading... or just what you want to think!

No I do care... But I have do the job and since I don't have 100 years
myself to rewrite OpenSSL, part of the OS to have an Ada Socket library
and a full graphical toolkit I do have to use third party and possibly
written in C for my projects.

If *you* don't care about security and don't use an SSL implementation
that's up to you, but please don't just say that other do not care
because they are not using the same approach... For one thing it would
be at least respectful.

Thanks.
 
-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada package registry?

[Dmitry A. Kazakov]

On 04/02/2016 22:03, Randy Brukardt wrote:

> Case-in-point: the web server that runs Ada-Auth.org. I was concerned that
> the sockets library would be too primitive to handle bursts of traffic, that
> Janus/Ada's cooperative multitasking would be a problem, and that the
> expensive operations that essentially stop the entire web server would make
> performance too choppy to be usable. But in actual fact (and even though the
> server machine is way underpowered for what it is doing), the real problem
> when the server has been overloaded has been the size of the Internet pipe
> to the server. It gets clogged long before the server grinds to a halt. So
> most work on server performance would have been just be wasted.

Thank to gnoga it is to expect more web servers running on tiny SBCs. 
The tables might get turned.

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

Re: Ada package registry?

[Dmitry A. Kazakov]

On 04/02/2016 23:04, Björn Lundin wrote:

> I'd like to hear of an ERP system (or WMS) that does NOT
> use a DBMS, and has customers with 1_000+ employees.

Well, maybe 80% of ERP code and performance is spent on adapters between 
its components, most of which useless. There is a great deal of legacy, 
legality and custom in ERP systems. You are right that all of them 
deploy DBMS (sometimes dozens of). Nobody knows how smaller and more 
maintainable they could be if designed differently. But they never will.

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

Re: Ada package registry?

[Dmitry A. Kazakov]

On 04/02/2016 22:09, Randy Brukardt wrote:
> "Björn Lundin" <b.f.lundin@gmail.com> wrote in message
> news:n8vvfk$ml3$1@dont-email.me...
>> On 2016-02-03 23:11, Randy Brukardt wrote:
> ....
>> I note that you do not mention working with relation databases.
>> If you work with them, it's hard to avoid c-bindings .
>
> I personally think databases are WAAAAY overused.

Yes

> For a lot of projects,
> some sort of Ada persistent storage is a better solution. The problem in the
> past has been that such storage couldn't be abstracted very well, so one
> typically has built something custom. Ada 2012 has enough syntactic sugar
> that persistent storage libraries (like containers) should be reasonable to
> construct abstract systems that are still reasonably easy to read and write.

Well, I disagree. Ada still lacks some key features to have types like 
relational tables declared. There is no way you could do that even with 
generics (which have no use for a persistent storage anyway). But even 
with generics you cannot do:

generic
    type Column_1 is private;
    type Column_2 is private;
    ...
    type Column_n is private;

For dealing with relational algebra you need introspection and 
containers of any-non-limited type.

> (The reason that we adopted the generalized reference feature that we did is
> because of the ability to use it to manage persistence -- in particular, to
> be able to figure out when the in-memory copy can be freed and written to
> the backing store.)

That is not enough. You need references with a notification upon 
dereferencing.

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

Re: Ada package registry?

[G.B.]

On 04.02.16 22:21, Randy Brukardt wrote:
> The rise of No_SQL has shown
> that it's overkill (and even harmful) in many case.

The rise of C has shown that Ada is overkill (and even harmful)
in many cases. Right?

> But off topic to
> discuss here...

Actually, some Ada guy much smarter than most of us, Ichbiah, has
put on record that Ada lacks interfaces to those things very
much on topic in the commercial, world of programming, perhaps
even in the Govt. funded niche.(*) So, that may be on topic.

I wonder why one would want Ada bindings to Windows like CLAW if
Windows had better be redesigned (in Ada) rather than programs
for Windows be written in Ada? Now substitute "RDBMS" for "Windows".

Using a relational DBMS with competitive Ada could like this:

     with Ada.ODBC;

and since SQL knows cursors, the Ada type system could provide
for a corresponding standard Cursor type, etc.

Also, SQL-invoked routines should be dead easy to write in Ada
using just the language and library of Ada.

__
(*) "I consider the lack of interfaces to be the most severe
impediment to increasing usage of Ada."
https://groups.google.com/forum/#!topic/comp.lang.ada/clH6maq5fgY
Message-ID: <SRCTRAN.93Feb16213209@world.std.com>

Re: Ada package registry?

[Dmitry A. Kazakov]

On 05/02/2016 13:54, G.B. wrote:

> Using a relational DBMS with competitive Ada could like this:
>
>      with Ada.ODBC;
>
> and since SQL knows cursors, the Ada type system could provide
> for a corresponding standard Cursor type, etc.

No, it cannot. Cursor in ODBC is invisible, which is a source of 
countless errors because operations implicitly create, remove, change 
the cursor.

But other types, environment, connection, statement are Ada controlled 
types in the ODBC bindings. See:

http://www.dmitry-kazakov.de/ada/components.htm#ODBC_Bindings

> Also, SQL-invoked routines should be dead easy to write in Ada
> using just the language and library of Ada.

You mean RA, stored procedures or statement execution? In all cases you 
need bind parameters, fetch results. That requires conversions Ada type 
<-> ODBC type <-> DB type. A native RA implementation would make things 
easier, though not easy because Ada lack important features to implement 
RA. Furthermore Ada lacks constructs to express transactions. So no, it 
is not dead easy.

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

Re: Ada package registry?

[G.B.]

On 05.02.16 14:27, Dmitry A. Kazakov wrote:
> On 05/02/2016 13:54, G.B. wrote:
>
>> Using a relational DBMS with competitive Ada could like this:
>>
>>      with Ada.ODBC;
>>
>> and since SQL knows cursors, the Ada type system could provide
>> for a corresponding standard Cursor type, etc.
>
> No, it cannot. Cursor in ODBC is invisible, which is a source of
> countless errors because operations implicitly create, remove, change
> the cursor.

The correspondence between DBMS cursors and Ada cursors
need not be that of being identical. It is supposed to be of
a behavioral nature:
You get a result set, then look at the tuples in the result
set one by one. These notions can be mapped to both, either SQL,
or to Ada.Containers.

It is just annoying to have common and widespread notions,
such as looking at elements of a set of tuples one by one,
but nothing in Ada to meet these requirements both portably,
and easily when the tuples are coming from something that
is as unusual as an RDBMS!

>> Also, SQL-invoked routines should be dead easy to write in Ada
>> using just the language and library of Ada.
>
> You mean RA, stored procedures or statement execution?

I mean "SQL-invoked routines", just the technical term of SQL.
ODBC is not necessarily involved, here. An Ada subprogram is being
called by the MS part of the DBMS, logically from within some
SQL statementent. As is done with stored procedures written in
SQL. E.g., when evaluating an expression, the DBMS passes database
values to an Ada function; when CALL-ing an Ada procedure, it
might expect the procedure to place a result into some IN OUT
parameter, or it might call the Ada procedure just for its effect.

One thing that is realistically needed, then, is a mapping from
vanilla RDBMS's system defined types to Ada types. Not hard to
do, I imagine, in Ada's Interfaces.* hierarchy.

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-05 16:53, G.B. wrote:

> I mean "SQL-invoked routines", just the technical term of SQL.
> ODBC is not necessarily involved, here. An Ada subprogram is being
> called by the MS part of the DBMS, logically from within some
> SQL statementent. As is done with stored procedures written in
> SQL. E.g., when evaluating an expression, the DBMS passes database
> values to an Ada function; when CALL-ing an Ada procedure, it
> might expect the procedure to place a result into some IN OUT
> parameter, or it might call the Ada procedure just for its effect.

This is not how DB clients work.

> One thing that is realistically needed, then, is a mapping from
> vanilla RDBMS's system defined types to Ada types. Not hard to
> do, I imagine, in Ada's Interfaces.* hierarchy.

SQL types have parameters and depend on the RDBMS. This is not working 
either.

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

Re: Ada package registry?

[G.B.]

On 05.02.16 17:45, Dmitry A. Kazakov wrote:
> On 2016-02-05 16:53, G.B. wrote:
>
>> I mean "SQL-invoked routines", just the technical term of SQL.
>> ODBC is not necessarily involved, here. An Ada subprogram is being
>> called by the MS part of the DBMS, logically from within some
>> SQL statementent. As is done with stored procedures written in
>> SQL. E.g., when evaluating an expression, the DBMS passes database
>> values to an Ada function; when CALL-ing an Ada procedure, it
>> might expect the procedure to place a result into some IN OUT
>> parameter, or it might call the Ada procedure just for its effect.
>
> This is not how DB clients work.

It is how SQL-invoked routines are being done, by definition.
They are just written in languages other than Ada.

> SQL types have parameters and depend on the RDBMS. This is not working
> either.

We'd be talking about C types and UTFs, to cover the vast majority
of types used in all typical databases. That's a realistic
assumption.  ISO/IEC 8652 addresses these.

If needed, Interfaces.C provides a lot more already,
by defining how Ada implementations handle C structs,
such as geo points, and maybe enums.

How would this be "not working"?

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-05 18:58, G.B. wrote:
> On 05.02.16 17:45, Dmitry A. Kazakov wrote:
>> On 2016-02-05 16:53, G.B. wrote:
>>
>>> I mean "SQL-invoked routines", just the technical term of SQL.
>>> ODBC is not necessarily involved, here. An Ada subprogram is being
>>> called by the MS part of the DBMS, logically from within some
>>> SQL statementent. As is done with stored procedures written in
>>> SQL. E.g., when evaluating an expression, the DBMS passes database
>>> values to an Ada function; when CALL-ing an Ada procedure, it
>>> might expect the procedure to place a result into some IN OUT
>>> parameter, or it might call the Ada procedure just for its effect.
>>
>> This is not how DB clients work.
>
> It is how SQL-invoked routines are being done, by definition.
> They are just written in languages other than Ada.

There are DBMS servers and clients. Client API are constrained to be 
procedural rather than RA. Which is why subprgrams they define have 
little to do with RA operations and types involved. Ada's type system is 
not fit to provide with that regard something significantly better than 
C client API do.

>> SQL types have parameters and depend on the RDBMS. This is not working
>> either.
>
> We'd be talking about C types and UTFs, to cover the vast majority
> of types used in all typical databases. That's a realistic
> assumption.  ISO/IEC 8652 addresses these.
>
> If needed, Interfaces.C provides a lot more already,
> by defining how Ada implementations handle C structs,
> such as geo points, and maybe enums.

Most of the work is done by the pragma Convention.

> How would this be "not working"?

type Timestamp is new Time;
pragma Convention (MySQL, Timestamp); -- Is it TIMESTAMP or YEAR?

type Decimal is delta 0.01 digits 10;
pragma Convention (MySQL, Decimal); -- DECIMAL (10, 2)?

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

Re: Ada package registry?

[Tero Koskinen]

2.2.2016, 1.22, Randy Brukardt wrote:
> "Tero Koskinen" <tero.koskinen@iki.fi> wrote in message
> news:n8jcj4$uus$1@loke.gir.dk... ...
>> People using other programming languages have managed to create
>> these package repositories, so it is a shame if Ada programmers
>> cannot manage to do the same.
>
> Not really. People using other programming language *implementations*
> have managed it. I see no evidence that it is possible to build such
> a thing that works with multiple implementations, running on multiple
> host and target systems, with different policies for installation,
> different project management facilities, and so on.

NetBSD's pkgsrc should run on multiple platforms (all *BSDs, most Linux
distributions, not sure about OS X or Windows) and support multiple
programming languages/build systems. And if you want to support
multiple host *and target systems* you could always check how
OpenEmbedded/Yocto/bitbake combo is doing things.

Of course, pkgsrc and OpenEmbedded are little different from
the language (implementation) specific build systems, but they
are still pieces of software which install a library (with dependencies)
for you (under your $HOME dir) when you type
"$my_package_manager install".

> That wouldn't be an *Ada* repository. It would be a *GNAT*
> repository! There might be use to such a thing, but call a spade a
> spade here: don't insult those who use Ada, but don't exclusively use
> GNAT, by calling such a thing an *Ada* tool.

I think you are forgetting who you are replying right now. :)

Most of my Ada software compiles nicely with other Ada compilers
(Janus/Ada, ICCAda) and I don't think it would be impossible to
add Janus/Ada or ICCAda support to the package repository tool.
You just need to make sure you don't try to compile Ada 2005/2012
code with Janus/Ada, which supports only Ada 95.

>> On the other hand, one could think that the package management
>> systems provides by Linux distributions and BSD operating systems
>> are enough. But generally, these are not that flexible. For
>> example, the language specific package managers allow one to
>> install multiple versions of the packages at the same time and the
>>  code can be even taken from the version control directly.
>
> Which was my previous point: in order for that to work, you have to
> insist on package authors in using a specific version control system,
> specific installation tools, and most likely a single Ada
> implementation. A lot of authors are not likely to change their
> methods of working to use such a system (or have the time to develop
>  complex installation schemes), so you're going to end up with a
> (smallish) subtest of available libraries. Which would be actively
> harmful for the future of Ada (or GNAT, if you prefer) - it would
> appear that there is a lot less available than there really is.

The package repository/tool which I am thinking about, would be only
for open source projects/libraries/applications. Open source developers
usually use only open source version control systems (cvs, subversion,
mercurial, git, darcs, monotone, and fossil) and there are existing
practices how to interface with them. Also, old-fashioned zip/tgz
release package (fetched over http/https) is easy to support.

What comes to installation methods, the $language community usually
provides enough pressure and shaming to make the rogue project to
follow the rules or to provide an installation method which is easy
enough to integrate into the package management system.

> For more complex systems that need other libraries, I doubt there is
>  any sensible solution. Unless you're planning to abandon Ada's
> portability between implementations -- not of much value, IMHO.

Not sure what sort of complexity you are thinking about. Just iterate
through the dependency chain and build one dependency at time using
the selected Ada compiler. When building one package, link the
dependencies, and be happy.

If there are C language libraries involved, call gcc or Visual C,
and continue as usual.

...
Building the package repository and related tool might take a lot
of wall clock time, since the amount of volunteer Ada programmers with
free time is limited, but I don't really see any blocking technical
problems. And if there are any, I think then it is time to start
making adjustments to the next Ada (or Ada compiler implementation)
version!

Yours,
  Tero

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-05 20:52, Tero Koskinen wrote:

> Building the package repository and related tool might take a lot
> of wall clock time, since the amount of volunteer Ada programmers with
> free time is limited, but I don't really see any blocking technical
> problems.

Building and packaging my libraries for ARM takes about 6 hours per 
distribution (Debian and Fedora) on RPI2.

> And if there are any, I think then it is time to start
> making adjustments to the next Ada (or Ada compiler implementation)
> version!

Hmm, things like cross compiling and linking is not really an Ada issue. 
Native compilation is a lot of time, hardware (virtualized or not) and 
tools to move files across.

The major issue is that the maintainer of the repository has no chance 
to build and package contributed software from the sources. It means 
that this must be the responsibility of the contributor. Who in turn has 
no idea about the repository infrastructure to be able to deliver 
working scripts or rules to build and package for all range of targets. 
Nor he have the hardware to make and test their builds.

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

Re: Ada package registry?

[Björn Lundin]

On 2016-02-05 09:51, Dmitry A. Kazakov wrote:
> On 04/02/2016 23:04, Björn Lundin wrote:
> 
>> I'd like to hear of an ERP system (or WMS) that does NOT
>> use a DBMS, and has customers with 1_000+ employees.
> 
> Well, maybe 80% of ERP code and performance is spent on adapters between
> its components, most of which useless. 

While I don't agree on that percentage I do agree with that it is too much.

>There is a great deal of legacy,
> legality and custom in ERP systems. You are right that all of them
> deploy DBMS (sometimes dozens of).

> Nobody knows how smaller and more
> maintainable they could be if designed differently. But they never will.
> 
And that is the key conclusion here. There are lots and lots of
system that use SQL. And that is a common denominator.
Good or bad, but that is the reality, and it will not likely
change in many years.

Meaning that lots of tools (reports/data mining/business
intelligence/buzzword/buzzword again) exists and is a big market.
It is no good then to say
- I streamed down my linked list of that keeps all of my inventory
to a blob that you can access if you write Ada-code only.
nor is it ok to say
- The 40 mb csv file is todays traceability on pallets,
make something useful of it, joined wit 5 other 100+ mb files.

You may say RDBMS:es are overused, and perhaps they are, but in my line
of work, they are indispensable.

-- 
--
Björn

Re: Ada package registry?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:n91oau$1bk5$1@gioia.aioe.org...
> On 04/02/2016 22:09, Randy Brukardt wrote:
...
>> (The reason that we adopted the generalized reference feature that we did 
>> is
>> because of the ability to use it to manage persistence -- in particular, 
>> to
>> be able to figure out when the in-memory copy can be freed and written to
>> the backing store.)
>
> That is not enough. You need references with a notification upon 
> dereferencing.

That's called "a function call" :-). There's no need for a separate feature 
for that (since anonymous access results are essentially uncopyable). What 
was missing was a way to know when the access itself goes away.

                             Randy.


                     Randy. 

Re: Ada package registry?

[Randy Brukardt]

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

"Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
news:n90hnb$3bd$1@dont-email.me...
> On 2016-02-04 22:21, Randy Brukardt wrote:
>> "Björn Lundin" <b.f.lundin@gmail.com> wrote in message
>> news:n901l6$b7$1@dont-email.me...
>>> On 2016-02-04 17:59, Dmitry A. Kazakov wrote:
>>>> On 2016-02-04 17:52, Björn Lundin wrote:
>>>>> On 2016-02-03 23:11, Randy Brukardt wrote:
>> ...
>>> Especially bad is when a customer cannot pull data to Excel.
>>
>> Why would that be hard? I do it all the time in my programs, no database 
>> (or
>> even persistent storage) in sight. It's easy to read/write .csv files in
>> Ada, and I believe that someone even has a library for writing .xls 
>> files.
>
> Yeah, having millions of records in .csv and
> joining with a couple of other .csv files with
> the same amount of data and
> sounds like a really good idea...
> If you got plenty of time, that is.

Huh? You said that it is hard to pull data to Excel, and I disagreed. You 
didn't say anything about pulling *all* of the data -- and why would you do 
that? Excel would fall over if you gave it a million lines of anything - the 
maximum number of rows is (or at least was) less than that.

Obviously, you'd do the selection before exporting to Excel (the case I was 
talking about).

 > Looking at a customers trace table I see they generate about 100_000
> records a day. Order lines are around the same.
> Data saved for a month or two, before moving to long-term storage (db
> not connected to production)

Way too much data -- clearly a business that is far too large to be 
managable. I don't care too much about the problems of entities that we'd be 
better off without in the first place.

...
>> The real reason to stick with non-Ada tools is when large parts of the
>> system already are in a non-Ada language, and you're just adding to it.
>
> Nope, the real reason is that SQL is a good enough way for
> non-engineers (read economists/warehouse manager etc) to make reports.
> They do not write their own Ada programs. They do not care.
> They want to use Excel and get data in ways THEY understand.

Surely. But the number of such people that can understand SQL well enough to 
do anything beyond the trivial has to be countable on fingers and toes. They 
typically use report tools to get such data, and those tools surely wouldn't 
have to be based on SQL (or anything in particular).

> I'd like to hear of an ERP system (or WMS) that does NOT
> use a DBMS, and has customers with 1_000+ employees.

I don't care about systems for organizations that necessarily are in hell. I 
*hope* they waste their time with fancy ERP systems rather than getting 
anything done so they can go out of business faster... :-)

                             Randy. 

Re: Ada package registry?

[Randy Brukardt]

"G.B." <bauhaus@futureapps.invalid> wrote in message 
news:n925rt$th2$1@dont-email.me...
> On 04.02.16 22:21, Randy Brukardt wrote:
>> The rise of No_SQL has shown
>> that it's overkill (and even harmful) in many case.
>
> The rise of C has shown that Ada is overkill (and even harmful)
> in many cases. Right?

C predates Ada by many years, so this statement is nonsense. (I wrote 
student programs in C in 1978; there weren't any Ada compilers, even for 
subsets, until 1981 or so.) C was already well entrenched and Ada has never 
been able to root it out. And of course there is no "harm" to using Ada, 
whereas there is clearly harm to using SQL. (Every program that I've had to 
use that has been built on top of DBs has been difficult to set up, 
difficult to back up, and most have been unstable.)

> I wonder why one would want Ada bindings to Windows like CLAW if
> Windows had better be redesigned (in Ada) rather than programs
> for Windows be written in Ada?

Practical reasons only. It didn't make financial sense to fight *every* 
trend, even if stupid. I would have much rather built a GUI all in Ada 
(indeed, we did that for MS-DOS), but it's unlikely that many people would 
have wanted it.

I would much rather have created systems for bare-machines (that is, 
ground-up all-Ada systems), but the world wants more interoperability and 
sharing and other stuff that makes things harder and less reliable. I'm 
enough of a realist to realize that you can't provide nothing that people 
want, but you surely don't have to provide harmful stuff, even if people 
want it.

> Now substitute "RDBMS" for "Windows".

Seems to be the same case to me: the only reason to do it is because 
clueless customers want it. That's life. Sigh.

                                Randy.

Re: Ada package registry?

[Randy Brukardt]

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

"Pascal Obry" <pascal@obry.net> wrote in message 
news:1454656310.19706.31.camel@obry.net...
Le jeudi 04 février 2016 à 14:52 -0600, Randy Brukardt a écrit :
>> So all you're really
>> saying is that you don't care about what happens down the road, which
>> is a
>> sad-but-true state of affairs in many areas of today's world.
>
>Wrong reading... or just what you want to think!
>
>No I do care... But I have do the job and since I don't have 100 years
>myself to rewrite OpenSSL, part of the OS to have an Ada Socket library
>and a full graphical toolkit I do have to use third party and possibly
>written in C for my projects.

Surely YOU personally don't (and shouldn't) have to rewrite everything, but 
it would be good if *someone* did that.

And, again, I've drawn the line at what is in the target system natively; so 
there's no need to "rewrite sockets" or (at least on Windows) a "graphical 
toolkit"). It doesn't make much sense to recreate those things if one is 
targeting an OS. (If you were running on a bare system, then of course you'd 
need to do it.)

>If *you* don't care about security and don't use an SSL implementation
>that's up to you, but please don't just say that other do not care
>because they are not using the same approach... For one thing it would
>be at least respectful.

Huh? I said that I've personally never had the need for SSL in an Ada 
program, but I surely didn't mean to imply that no one else did. I very 
*definitely* care about security. Indeed, I care enough that I would want to 
implement SSL in Ada (and probably SPARK) if I had a real business need for 
it. I could see using something like OpenSSL, but only for a non-critical 
need in a Q&D program. I would not be too likely to want to distribute that 
sort of thing, precisely because it was Q&D. I wouldn't expect anybody to 
hand-hold some jury-rigged Q&D solution to any problem.

But as always, YMMV. That goes without saying, especially in this case when 
so far as I recall I was only talking about me and where I would want Ada to 
go. What, precisely, you think is not respectful about that is beyond me. 
And being accused of being "not respectful" makes me want to prove you 
right...so I'll stop now before I say something I might actually regret.

                                Randy.

Re: Ada package registry?

[Randy Brukardt]

"Tero Koskinen" <tero.koskinen@iki.fi> wrote in message 
news:n92uia$do6$1@loke.gir.dk...
> 2.2.2016, 1.22, Randy Brukardt wrote:
...
>> That wouldn't be an *Ada* repository. It would be a *GNAT*
>> repository! There might be use to such a thing, but call a spade a
>> spade here: don't insult those who use Ada, but don't exclusively use
>> GNAT, by calling such a thing an *Ada* tool.
>
> I think you are forgetting who you are replying right now. :)

Yes, surely. :-)

> Most of my Ada software compiles nicely with other Ada compilers
> (Janus/Ada, ICCAda) and I don't think it would be impossible to
> add Janus/Ada or ICCAda support to the package repository tool.
> You just need to make sure you don't try to compile Ada 2005/2012
> code with Janus/Ada, which supports only Ada 95.

But you are the shining exception to the rule. I think you and one other 
author are the only ones that are currently trying for portable Ada code; 
the vast majority don't seem to care or don't know how to do it or 
something. It would help if there were more tools for enforcing portability, 
as well as some way of expressing assumptions. (A package manager would help 
there, of course.)

[What I mean by expressing assumptions is that it's unlikely that any real 
Ada code would really run anywhere. I've been having fun with Gautier over 
his "unconditional portability" claim, as one only needs a single 
counter-example to disprove the claim. After a few obvious problems with the 
choices of Janus/Ada were worked out, I pointed out that his types wouldn't 
work on our old U2200 compiler (as that was a 1's completement, 36-bit 
machine). He decided quite reasonably not to worry about that, but that 
means in his case, that means his code is "unconditionally portable" so long 
as your target supports 32-bit integers and is 2's complement. That might be 
99% of machines, but its not quite unconditional.]

...
>> For more complex systems that need other libraries, I doubt there is
>>  any sensible solution. Unless you're planning to abandon Ada's
>> portability between implementations -- not of much value, IMHO.
>
> Not sure what sort of complexity you are thinking about. Just iterate
> through the dependency chain and build one dependency at time using
> the selected Ada compiler. When building one package, link the
> dependencies, and be happy.

That's trivial: run the compiler's Make. The issues I was thinking about is 
dependencies on things like OpenSSL. One could manage to automate that sort 
of dependency on one system fairly easily, but to do it on all reasonable 
targets (various Windows versions, Linux distributions, OS X, FreeBSD, etc.) 
is a combinational explosion (given that some sort of Ada compiler 
configuration is also involved - which is different for every compiler and 
often for different targets as well).

That's the problem that other people here were talking about. It probably 
isn't the problem YOU were trying to solve - what you described is perfectly 
reasonable. (I'm dubious that it would be that useful for Ada, since 
compilers already include good build tools, and little more is needed to use 
third-party stuff -- but if it helped determine what is and is not portable, 
that certainly would help the non-GNAT users out there.)

                                                    Randy.

Re: Ada package registry?

[Jeffrey R. Carter]

On 02/05/2016 06:25 PM, Randy Brukardt wrote:
> 
> [What I mean by expressing assumptions is that it's unlikely that any real 
> Ada code would really run anywhere. I've been having fun with Gautier over 
> his "unconditional portability" claim, as one only needs a single 
> counter-example to disprove the claim. After a few obvious problems with the 
> choices of Janus/Ada were worked out, I pointed out that his types wouldn't 
> work on our old U2200 compiler (as that was a 1's completement, 36-bit 
> machine). He decided quite reasonably not to worry about that, but that 
> means in his case, that means his code is "unconditionally portable" so long 
> as your target supports 32-bit integers and is 2's complement. That might be 
> 99% of machines, but its not quite unconditional.]

Wasn't that an Ada-83 compiler? And isn't he trying for portability across
Ada-95 compilers?

If you had an Ada-95 compiler for that machine, what would be the problem with

type U is mod 2 ** 32;
for U'Size use 32;

type S is range -(2 ** 31) .. (2 ** 31) - 1;
for S'Size use 32;
?

(I guess in Ada 83 you could do

type U is range 0 .. (2 ** 32) - 1;
for U'Size use 32;

There'd be plenty of room in the base type for the corresponding negative
values, unlike a 32-bit machine.)

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail
16

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-06 01:04, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:n91oau$1bk5$1@gioia.aioe.org...
>> On 04/02/2016 22:09, Randy Brukardt wrote:
> ....
>>> (The reason that we adopted the generalized reference feature that we did
>>> is
>>> because of the ability to use it to manage persistence -- in particular,
>>> to
>>> be able to figure out when the in-memory copy can be freed and written to
>>> the backing store.)
>>
>> That is not enough. You need references with a notification upon
>> dereferencing.
>
> That's called "a function call" :-). There's no need for a separate feature
> for that (since anonymous access results are essentially uncopyable). What
> was missing was a way to know when the access itself goes away.

That is called a function call too.

For persistence layer you need dereference primitive operations. One for 
read access in order to cache data and one write access to mark the 
cache dirty.

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

Re: Ada package registry?

[olivier.henley]

@ M. Brukardt:

1. You can look at it the way you want, the end result of something like code.dlang.org or haskell stack is more neat, efficient, structured, coherent and appealing than the noisy search engine at AdaIC. (I entered the term physic ... OMG It was disastrous. Nothing relevant. I even tried to find that search utility directly from google. It was like a detective quest!) Arguing the opposite is, IMO, like arguing that the earth is flat. 

2. You use way too much strong words like harmful and insult, to nuke a PM/PR proposition. I get it that you are a tenor of the Ada community but it does not qualify you to serve what I call 'toxic arguments'. IMHO, your statu quo and orthodoxy deeply anchored in 'has been' technology poses much more of a drag to the Ada pipelines than the envisioning of a PM for Ada; for future, open source, pure Ada code projects.

3. By not acting to attract people, you are constantly redirecting smart young people to other communities, e.g Dlang. Many clever pals want to ditch C++ and Ada would be a perfect fit to foster them. Wont happen with loud voices like yours 'bullying' sensible propositions around. (I work at Ubisoft Montreal. Yesterday my boss was asking about my website and I told him I did it in Ada. You know what he asked me: 'Ada... is it not an old programming language?'. By old he meant dead; Ada needs a nice haircut.) To me it looks like you want to keep Ada and the accompanying discourse for yourself. Am I wrong?

4. A PM/PR ... yeah it is for open source projects. If you took the time to check code.dlang you would have get it from the start. You can keep your proprietary stuff for you alone, on your MUCH better VCS system than what is in main use. Oh btw, I myself solved the problem for a quantum computer. It is in my basement... but I cant show you its proprietary stuff and I lost the key to enter the vault too... sorry.

5. Would you mind stop musing about your realizations and views of the world in precise topic forum threads. It slides the discussion into 'not constructive land'. Thank you.

6. All your knowledge about software architecture, maybe you could put it to good use by writing a book and/or making free software so people like me could study your code and learn. If you already did please direct me. 

My one cent... to put my false humility on the back of deflation.

  

Re: Ada package registry?

[AdaMagica]

Am Samstag, 6. Februar 2016 02:25:59 UTC+1 schrieb Randy Brukardt:
> [What I mean by expressing assumptions is that it's unlikely that any real 
> Ada code would really run anywhere. I've been having fun with Gautier over 
> his "unconditional portability" claim, as one only needs a single 
> counter-example to disprove the claim. After a few obvious problems with the 
> choices of Janus/Ada were worked out, I pointed out that his types wouldn't 
> work on our old U2200 compiler (as that was a 1's completement, 36-bit 
> machine). He decided quite reasonably not to worry about that, but that 
> means in his case, that means his code is "unconditionally portable" so long 
> as your target supports 32-bit integers and is 2's complement. That might be 
> 99% of machines, but its not quite unconditional.]

In my Ada courses, I warn participants not to take compiler traits for Ada properties. I also warned them to be aware of implicit presuppositions, e.g. do not assume that integers are implemented as two's complement; if your code somehow depends on this fact, do document it somewhere.
I just try to make them aware of hidden presuppositions.
Whether they will be is a different story. I myself do not know which implicit presuppositions I depended on in my professional life.

I ported MLoC airborne Ada 83 code to Ada 95 on different HW for full scale flight simulation and was astonished how little changes were needed. But I was bitten by the requirement that source and target sizes for Unchecked_Conversion have to be the same. That was a lesson, you can believe me!

Re: Ada package registry?

[Björn Lundin]

On 2016-02-06 01:30, Randy Brukardt wrote:
> "Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
> news:n90hnb$3bd$1@dont-email.me...
>> On 2016-02-04 22:21, Randy Brukardt wrote:
>>> "Björn Lundin" <b.f.lundin@gmail.com> wrote in message
>>> news:n901l6$b7$1@dont-email.me...
>>>> On 2016-02-04 17:59, Dmitry A. Kazakov wrote:
>>>>> On 2016-02-04 17:52, Björn Lundin wrote:
>>>>>> On 2016-02-03 23:11, Randy Brukardt wrote:
>>> ...
>>>> Especially bad is when a customer cannot pull data to Excel.
>>>
>>> Why would that be hard? I do it all the time in my programs, no database 
>>> (or
>>> even persistent storage) in sight. It's easy to read/write .csv files in
>>> Ada, and I believe that someone even has a library for writing .xls 
>>> files.
>>
>> Yeah, having millions of records in .csv and
>> joining with a couple of other .csv files with
>> the same amount of data and
>> sounds like a really good idea...
>> If you got plenty of time, that is.
> 
> Huh? You said that it is hard to pull data to Excel, and I disagreed. You 
> didn't say anything about pulling *all* of the data -- and why would you do 
> that? Excel would fall over if you gave it a million lines of anything - the 
> maximum number of rows is (or at least was) less than that.
> 
> Obviously, you'd do the selection before exporting to Excel (the case I was 
> talking about).


And that is the hard part. Of course you don't pull that kind of data
into excel. But the selection itself  - into useful data from several
sources - is hard using csv-files and ada.
and no one in the business would be able to conclude anything
useful from their own data.

> 
>  > Looking at a customers trace table I see they generate about 100_000
>> records a day. Order lines are around the same.
>> Data saved for a month or two, before moving to long-term storage (db
>> not connected to production)
> 
> Way too much data -- 

for csv-files : yes. for an RDBMS : no
for business analysis : no.
For tracking what store got delivery from what pallet : definitely no.
And that is really important, if you find trouble in a batch of say
food, and want to withdraw it from the stores. Which stores are affected?
- Wait , I need to call an Ada-programmer to write a tool to extract
that data from our many and BIG csv-files...

No - won't work.

> clearly a business that is far too large to be 
> managable. I don't care too much about the problems of entities that we'd be 
> better off without in the first place.

Not at all. Just because it is a type of problem outside your
normal domain, does not make it impossible. And
it does definitely not make you an expert in saying what
is too much data or not.

Especially, since we do have laws here that decides how much
traceability you HAVE to save, and for how long.
As a food supplier, you MUST be able to track your deliveries.

> 
> ...
>>> The real reason to stick with non-Ada tools is when large parts of the
>>> system already are in a non-Ada language, and you're just adding to it.
>>
>> Nope, the real reason is that SQL is a good enough way for
>> non-engineers (read economists/warehouse manager etc) to make reports.
>> They do not write their own Ada programs. They do not care.
>> They want to use Excel and get data in ways THEY understand.
> 
> Surely. But the number of such people that can understand SQL well enough to 
> do anything beyond the trivial has to be countable on fingers and toes. 

Not true. But if it was, it is still far more that people who can
make something useful from csv-files of a substantial set of data.

>They 
> typically use report tools to get such data, and those tools surely wouldn't 
> have to be based on SQL (or anything in particular).

No, but most I've seen are.

>> I'd like to hear of an ERP system (or WMS) that does NOT
>> use a DBMS, and has customers with 1_000+ employees. 
> I don't care about systems for organizations that necessarily are in hell.
Who said they are in hell ? Sure, some are, but far from all.
And I'm pretty sure they would be in hell even without an ERP.
That is not was is tipping big organizations over.

> I 
> *hope* they waste their time with fancy ERP systems rather than getting 
> anything done so they can go out of business faster... :-)

A statement that I do not know what to think of.
I see the smiley, but I don't see the fun in it.
I do see it as fairly immature though.

--
Björn

Re: Ada package registry?

[Jeffrey R. Carter]

On 02/06/2016 04:26 PM, Björn Lundin wrote:
> 
> But the selection itself  - into useful data from several
> sources - is hard using csv-files and ada.

I think you've misunderstood Brukardt's position. He said it's easy to convert
data, not stored in CSV files, to CSV format, whether said data are stored in a
DBMS or not. He never proposed using CSV files as the primary storage format.

Whether selecting desired data from a large data set is easier or faster with a
DBMS or some form of Ada persistent containers is a more interesting question.

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67

Re: Ada package registry?

[gautier_niouzes]

Le samedi 6 février 2016 02:25:59 UTC+1, Randy Brukardt a écrit :

> [What I mean by expressing assumptions is that it's unlikely that any real 
> Ada code would really run anywhere. I've been having fun with Gautier over 
> his "unconditional portability" claim, as one only needs a single 
> counter-example to disprove the claim. After a few obvious problems with the 
> choices of Janus/Ada were worked out, I pointed out that his types wouldn't 
> work on our old U2200 compiler (as that was a 1's completement, 36-bit 
> machine). He decided quite reasonably not to worry about that, but that 
> means in his case, that means his code is "unconditionally portable" so long 
> as your target supports 32-bit integers and is 2's complement. That might be 
> 99% of machines, but its not quite unconditional.]

Actually I do worry - well, a bit: don't worry that I'm worrying too much!
It's why I've mitigated the "unconditional portability" claim with "within limits of compiler's provided integer types and target architecture capacity".
Note that I don't claim "unlimited portability".
Only, within limits that are target machine's and compiler supported integer types, there is no need of conditional compilation, preprocessing, #ifdef's and other tricks to fake portability.
I test some of my libraries with both GNAT (most recent GPL) and ObjectAda 7.2.2 (an old, free version).
It's very rewarding to punch the build button on both IDEs and get something working (be it Zip, image or PDF tool) with exactly the same source set.
Moreover, both compilers issue warnings or in very rare cases, errors, that the other doesn't.
You also see that a claim like "our software is an Ada 95 compiler" is perhaps met by nobody so far in 2016 if you take the Manual stricto sensu.
This includes the Interpretations of the Manual: if a warning or an error is issued, it makes a difference...
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont/

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-07 01:16, Jeffrey R. Carter wrote:

> Whether selecting desired data from a large data set is easier or faster with a
> DBMS or some form of Ada persistent containers is a more interesting question.

That depends on the structure of the data. There are operations 
effective in RA and there are ones awfully slow, e.g. operations on 
graphs or nearest neighbour search etc. Data are bend to fit into RA to 
make frequent operation performance tolerable.

BTW, the whole idea of exporting something (data) into something (Excel) 
shows bogus design. Why cannot the end data consumer access data directly?

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

Re: Ada package registry?

[gautier_niouzes]

Le dimanche 7 février 2016 09:02:53 UTC+1, Dmitry A. Kazakov a écrit :

> BTW, the whole idea of exporting something (data) into something (Excel) 
> shows bogus design. Why cannot the end data consumer access data directly?

It all depends of the context. In some businesses the end data consumer knows *only* Excel, regarding data (I am since 16 years in such businesses). Databases are for the "gurus". Of course you summarize and sort information when exporting to an Excel format (some people forget to, and handle 100MB+ Excel files that crash Excel.exe relatively reliably).
_________________________ 
Gautier's Ada programming 
http://www.openhub.net/accounts/gautier_bd

Re: Ada package registry?

[Georg Bauhaus]

On 06.02.16 01:49, Randy Brukardt wrote:

> Practical reasons only.

Yes. Those reasons make a theory viable.

Interfacing is how the Ada effort can improve practice. Without it,
no Ada programs have influence on anything.


-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Ada package registry?

[gautier_niouzes]

Regarding the U2200 machine I think it's OK. The type in question is:

  min_bits: constant:= Integer'Max(32, System.Word_Size);
  -- 13.3(8): A word is the largest amount of storage that can be
  -- conveniently and efficiently manipulated by the hardware,
  -- given the implementation's run-time model.

  type Integer_M32 is range -2**(min_bits-1) .. 2**(min_bits-1) - 1;
  --  We define an Integer type which is at least 32 bits, but n bits
  --  on a native n > 32 bits architecture (no performance hit on 64+
  --  bits architectures).

You say: "The lower bound would have to be -2**(min_bits-1)-1 on such a machine.". Since -2**(min_bits-1) > -2**(min_bits-1)-1, Integer_M32 is a subrange of what you mean and it should be OK.

I let you the pleasure of trying the actual compilation for the U2200. I wait with excitement for the results ;-).
_________________________ 
Gautier's Ada programming 
http://gautiersblog.blogspot.com/search/label/Ada 
NB: follow the above link for a valid e-mail address 

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-07 09:36, gautier_niouzes@hotmail.com wrote:
> Le dimanche 7 février 2016 09:02:53 UTC+1, Dmitry A. Kazakov a écrit :
>
>> BTW, the whole idea of exporting something (data) into something (Excel)
>> shows bogus design. Why cannot the end data consumer access data directly?
>
> It all depends of the context. In some businesses the end data
> consumer knows *only* Excel, regarding data (I am since 16 years in such
> businesses). Databases are for the "gurus". Of course you summarize and
> sort information when exporting to an Excel format (some people forget
> to, and handle 100MB+ Excel files that crash Excel.exe relatively reliably).

So why Excel cannot access the DB? A spreadsheet program should be able 
to do that, if DB and the program were properly designed...

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

Re: Ada package registry?

[Georg Bauhaus]

On 05.02.16 19:47, Dmitry A. Kazakov wrote:

>> It is how SQL-invoked routines are being done, by definition.
>> They are just written in languages other than Ada.
>
> There are DBMS servers and clients.

Databases just have APIs, SQL databases have several kinds of APIs.
As a programmer using some API, what you can program depends
on the kind of API. It doesn't have to be "server" or "client".
Similarly, the impossibility of all of the relational model within
the Ada type system proper is interesting, but not so interesting
if all you desperately want some easy, standard access to RDBMSs.

In many cases, access to SQL databases is like access to the file
system. It is a matter of course. Like directories. It has taken decades
for Ada to get standard Directory access. Maybe Ada.Directories does
not cover all of every file system ever invented. But, the package is
being used, I understand, making Ada more viable, and practical.
And real.

Particular counterexamples just don't matter much: if one of Ada's
standard packages does not purport to be universal, then it is like most
business efforts. That's sufficient to get started.


>> How would this be "not working"?
>
> type Timestamp is new Time;
> pragma Convention (MySQL, Timestamp); -- Is it TIMESTAMP or YEAR?

A SQL TIMESTAMP has enough description for it to be abstracted,
for interfacing. By comparison, consider

    type Bits is mod System.Word_Size;
    type Pos is new Integer range 1 .. Integer'Last;

Again, "not working"? Or perfectly normal?

> type Decimal is delta 0.01 digits 10;
> pragma Convention (MySQL, Decimal); -- DECIMAL (10, 2)?

If C programmers get along with representing decimals in ad-hoc
fashion, I don't see why Ada programmers should not store decimals of
ready make types in databases, even when the RDBMS library requires
some shielding, such as an instance of Unchecked_Conversion,
or tackling the legacy of MySQL.


-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Ada package registry?

[Georg Bauhaus]

On 07.02.16 09:02, Dmitry A. Kazakov wrote:
>
> BTW, the whole idea of exporting something (data) into something (Excel) shows bogus design. Why cannot the end data consumer access data directly?

They don't know the database.
Privileges would have to be set up.
Views would have to be created.
They'd need to learn, and accept, what matters to the statistics, and what doesn't.
...

IOW, all the work that the provider of report data is now doing
for the consumers would have to be done by consumer. Would you say
that a consumer, instead of a buying a cupboard (a meal) should
just get wood and tools and lacquer (get access to the chef's kitchen)?

Even assuming that there is some business entity that is
freely offering their customers access to data, this shows
some negligence of necessary business variables.

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Ada package registry?

[gautier_niouzes]

> So why Excel cannot access the DB? A spreadsheet program should be able 
> to do that, if DB and the program were properly designed...

Access rights, connection times (or connection at all) - all that is not obvious in an international business. For various reasons (security, legal, or license) you just don't have access to other locations' networks within the same company. In some contexts you are limited to e-mails and Excel files.
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont/

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-07 10:40, Georg Bauhaus wrote:
> On 05.02.16 19:47, Dmitry A. Kazakov wrote:
>
>>> How would this be "not working"?
>>
>> type Timestamp is new Time;
>> pragma Convention (MySQL, Timestamp); -- Is it TIMESTAMP or YEAR?
>
> A SQL TIMESTAMP has enough description for it to be abstracted,
> for interfacing. By comparison, consider
>
>     type Bits is mod System.Word_Size;
>     type Pos is new Integer range 1 .. Integer'Last;
>
> Again, "not working"? Or perfectly normal?
>
>> type Decimal is delta 0.01 digits 10;
>> pragma Convention (MySQL, Decimal); -- DECIMAL (10, 2)?
>
> If C programmers get along with representing decimals in ad-hoc
> fashion, I don't see why Ada programmers should not store decimals of
> ready make types in databases, even when the RDBMS library requires
> some shielding, such as an instance of Unchecked_Conversion,
> or tackling the legacy of MySQL.

C API convert types: C type <-> ODBC type <-> SQL type <-> DB type.

Interfaces.X in Ada do not convert anything, it provides Ada types 
exactly matching their alien language counterparts.

This is the "not working" part.

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

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-07 11:00, Georg Bauhaus wrote:
> On 07.02.16 09:02, Dmitry A. Kazakov wrote:
>>
>> BTW, the whole idea of exporting something (data) into something
>> (Excel) shows bogus design. Why cannot the end data consumer access
>> data directly?
>
> They don't know the database.
> Privileges would have to be set up.
> Views would have to be created.
> They'd need to learn, and accept, what matters to the statistics, and
> what doesn't.
> ....

Who? MS programmers? BTW, Excel has an ODBC driver. So MS programmers 
are well aware of representing Excel as a DB, but didn't care about the 
reverse. No wonder, given the garbage "SQL standard" is, as well as ODBC 
and RDBMS implementations. It is a huge mess, which is the point.

> Even assuming that there is some business entity that is
> freely offering their customers access to data, this shows
> some negligence of necessary business variables.

Of course pushing .xls files around is much safer. As if access rights 
had anything to do with the issue.

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

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-07 11:06, gautier_niouzes@hotmail.com wrote:
>> So why Excel cannot access the DB? A spreadsheet program should be able
>> to do that, if DB and the program were properly designed...
>
> Access rights, connection times (or connection at all) - all that is
> not obvious in an international business. For various reasons (security,
> legal, or license) you just don't have access to other locations'
> networks within the same company. In some contexts you are limited to
> e-mails and Excel files.

What is the problem? It is up to a DB client to handle these issues. An 
ODBC driver and DB clients do all this. The single reason for all this 
is bogus design.

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

Re: Ada package registry?

[gautier_niouzes]

Le samedi 6 février 2016 02:25:59 UTC+1, Randy Brukardt a écrit :

> But you are the shining exception to the rule. I think you and one other 
> author are the only ones that are currently trying for portable Ada code; 
> the vast majority don't seem to care or don't know how to do it or 
> something.

There is a good reason for that: AdaCore is currently the only compiler vendor that cares to meet authors willing to test their packages (could be via a supportless version (GNAT), or an evaluation version with some limitations (ObjectAda used to do that), for instance).
All other vendors show themselves (be it right or wrong) on the Web as shops in run-off.
_________________________ 
Gautier's Ada programming 
http://www.openhub.net/accounts/gautier_bd

Re: Ada package registry?

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2016-02-07 10:40, Georg Bauhaus wrote:
>> On 05.02.16 19:47, Dmitry A. Kazakov wrote:

> Interfaces.X in Ada do not convert anything, it provides Ada types 
> exactly matching their alien language counterparts.

How does Interfaces.X provide matching
types for decimals or task types in C, Cobol, or Fortran?

Re: Ada package registry?

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2016-02-07 11:00, Georg Bauhaus wrote:
>> On 07.02.16 09:02, Dmitry A. Kazakov wrote:
>>> 
>>> BTW, the whole idea of exporting something (data) into something
>>> (Excel) shows bogus design. Why cannot the end data consumer access
>>> data directly?
>> 
>> They don't know the database.
>> Privileges would have to be set up.
>> Views would have to be created.
>> They'd need to learn, and accept, what matters to the statistics, and
>> what doesn't.
>> ....
> 
> Who? 

Any customer who, as you suggest, is to gain access
to the companies' internal databases.

This free access is normally seen as an absurd proposition.
Gaultier has in addition mentioned The Law, and company rules.
These exist for reasons that transcend  technological considerations
of programmers.

It would be like removing the keyword "private" from the Ada language.
Actually more than that, I think.

Re: Ada package registry?

[Georg Bauhaus]

On 07.02.16 20:27, Georg Bauhaus wrote:

> Gaultier has in addition mentioned The Law, and company rules.

I'm sorry! I need a spell checker with access to a database
of first names and last names, suitably matched with threads
of USENET discussions.

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-07 20:27, Georg Bauhaus wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 2016-02-07 11:00, Georg Bauhaus wrote:
>>> On 07.02.16 09:02, Dmitry A. Kazakov wrote:
>>>>
>>>> BTW, the whole idea of exporting something (data) into something
>>>> (Excel) shows bogus design. Why cannot the end data consumer access
>>>> data directly?
>>>
>>> They don't know the database.
>>> Privileges would have to be set up.
>>> Views would have to be created.
>>> They'd need to learn, and accept, what matters to the statistics, and
>>> what doesn't.
>>> ....
>>
>> Who?
>
> Any customer who, as you suggest, is to gain access
> to the companies' internal databases.

Customer has data <=> customer has access to data.

You are confusing interfacing with a right to execute a given interface 
operation with given operands. An access to execute SELECT on a DB table 
is no different to an ability to view the table in Excel or any other 
program. In both cases authorization happens outside the corresponding 
interface.

> It would be like removing the keyword "private" from the Ada language.
> Actually more than that, I think.

Private in Ada has nothing to do with security.

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

Re: Ada package registry?

[Björn Lundin]

On 2016-02-07 09:02, Dmitry A. Kazakov wrote:

> 
> BTW, the whole idea of exporting something (data) into something (Excel)
> shows bogus design. Why cannot the end data consumer access data directly?

Of course they can.
But some WANTS to get it into Excel.
Has nothing to do with design.

-- 
--
Björn

Re: Ada package registry?

[Dmitry A. Kazakov]

On 2016-02-07 20:21, Georg Bauhaus wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 2016-02-07 10:40, Georg Bauhaus wrote:
>>> On 05.02.16 19:47, Dmitry A. Kazakov wrote:
>
>> Interfaces.X in Ada do not convert anything, it provides Ada types
>> exactly matching their alien language counterparts.
>
> How does Interfaces.X provide matching
> types for decimals or task types in C, Cobol, or Fortran?

See ARM Annex B.

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

Re: Ada package registry?

[Björn Lundin]

On 2016-02-07 11:23, Dmitry A. Kazakov wrote:

> What is the problem? It is up to a DB client to handle these issues. An
> ODBC driver and DB clients do all this. The single reason for all this
> is bogus design.

Ther is none. Of course they can access it with ODBC. That's
part of what the thread is about.

Users access the RDBMS via SQL into excel.
Some people think that is awful around here,
However it gives the possiblity for users to create
user defined queriers so the can pivot around as they like.

With Standard SQL as the tool in one hand,
and the data model of the system in the other.

Designing your own reports AS YOU WANT, without having
to write programs th go from one binary storage to csv-files...

-- 
--
Björn

Re: Ada package registry?

[Björn Lundin]

On 2016-02-07 01:16, Jeffrey R. Carter wrote:
> On 02/06/2016 04:26 PM, Björn Lundin wrote:
>>
>> But the selection itself  - into useful data from several
>> sources - is hard using csv-files and ada.
> 
> I think you've misunderstood Brukardt's position. He said it's easy to convert
> data, not stored in CSV files, to CSV format, whether said data are stored in a
> DBMS or not. 

And I say no - it is not. Unless you are a programmer, that
understands the primary storage format.
Because that is not standadized in a way that end users
can pull data from it in a meaningfull way.

>He never proposed using CSV files as the primary storage format.

Be that as it may, but it is in the end about data openess (for the
end user) or not.

> Whether selecting desired data from a large data set is easier or faster with a
> DBMS or some form of Ada persistent containers is a more interesting question.

That depends on the model amongst many things.
But that is not the most interesting question.
That one is about data openess for end users.
Do they have to hire someone to get data into a report,
or can they do it themselves.

And end users are rarely programmers in this case, but
they do know SQL, or are sent to courses to learn it.




-- 
--
Björn

Re: Ada package registry?

[Björn Lundin]

On 2016-02-07 11:00, Georg Bauhaus wrote:
> On 07.02.16 09:02, Dmitry A. Kazakov wrote:
>>
>> BTW, the whole idea of exporting something (data) into something
>> (Excel) shows bogus design. Why cannot the end data consumer access
>> data directly?
> 
> They don't know the database.

They do. They get a copy of the datamodel,
at courses where they also learn what objects changne status at what
moment. And they can ask us if they forget.

> Privileges would have to be set up.
Yes - read -only user. Shipped by default with the system
> Views would have to be created.
No - we do not use them.
Bu are willing to set up if asked
> They'd need to learn, and accept, what matters to the statistics, and
> what doesn't.

> ...

> Even assuming that there is some business entity that is
> freely offering their customers access to data, this shows
> some negligence of necessary business variables.

It does not. End users does not HAVE to do this.
But some WANTS it.

> 


-- 
--
Björn

Re: Ada package registry?

[Georg Bauhaus]

On 07.02.16 21:11, Björn Lundin wrote:
> On 2016-02-07 11:00, Georg Bauhaus wrote:
>> On 07.02.16 09:02, Dmitry A. Kazakov wrote:
>>>
>>> BTW, the whole idea of exporting something (data) into something
>>> (Excel) shows bogus design. Why cannot the end data consumer access
>>> data directly?
>>
>> They don't know the database.
>
> They do.

Before this degrades to positioning particular cases against
other particular cases of opposite organisational design:
The crucial bit is that, in the end, access to data (what, how)
is not a consequence of programming decisions.  Technical
facilities will be ordered .IFF. they facilitate achieving
what has been agreed on, starting from more general premises
of an organisational nature.

Re: Ada package registry?

[Georg Bauhaus]

On 07.02.16 20:57, Dmitry A. Kazakov wrote:
> On 2016-02-07 20:21, Georg Bauhaus wrote:
>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>> On 2016-02-07 10:40, Georg Bauhaus wrote:
>>>> On 05.02.16 19:47, Dmitry A. Kazakov wrote:
>>
>>> Interfaces.X in Ada do not convert anything, it provides Ada types
>>> exactly matching their alien language counterparts.
>>
>> How does Interfaces.X provide matching
>> types for decimals or task types in C, Cobol, or Fortran?
>
> See ARM Annex B.

Let me rephrase: How does the Interface hierarchy from Annex B
of the Ada LRM provide matching types for decimals or task types in
C, Cobol, or Fortran? For, if it does not, then the alleged exact
matches simply are not there. Not even one-way.

However, there is something in Ada from which to build interfaces for
SQL RDBMS, for practical reasons.

Re: Ada package registry?

[Georg Bauhaus]

On 07.02.16 20:54, Dmitry A. Kazakov wrote:
> An access to execute SELECT on a DB table is no different to an ability to view the table in Excel or any other program.


This kind of access is a no-go area in some organisations.
No one, including own employees, may know the names of tables;
or even learn if there is an RDMBS at all. Let alone enjoy the
privileges of learning about the particulars of the databases.

An Excel table is a passive data entity, and a document(!).
It is an entity that is separate from the DBMS and therefore
leaks nothing about the database, and imposes no risk of a broken
security setup. Shit happens, some want to avoid that by putting
databases behind walls.  Database programs will produce documents
to be forwarded, after checking and signing.

You could call these considerations "abstraction" between commercial
entities or other organisations, or individuals.

I'd be very surprised if I could go to my bank and ask
them about their database schema, and be told it! Or ask Google
about the ad network's databases from which they produce the CSVs
that they send, and be given read-only access.

It is at this level of organisational design that I meant to put the
analogy of dropping Ada's "private".  "Body" could mean, by analogy,
that you will get to see something at some interface level, but no bodies!
As a user of the spec, you'd know absolutely nothing about bodies,
compiled or not.

Database schemas, like bodies, can be declared to be part of corporate
property, by the powers that be.

Even interfaces can be part of corporate property: I understand that
some legal initiative is on its way in order to get a decision on whether
a collection of type's interfaces (names, patterns, etc. of a framework)
can be put under copyright law or some such. It takes some effort to produce
one, after all, so the logical consequence from BA theory is obvious:
prevent copying OS interfaces, for example, by disallowing the use of
the same names in APIs.

Re: Ada package registry?

[Björn Lundin]

On 2016-02-07 23:11, Georg Bauhaus wrote:
> On 07.02.16 21:11, Björn Lundin wrote:
>> On 2016-02-07 11:00, Georg Bauhaus wrote:
>>> On 07.02.16 09:02, Dmitry A. Kazakov wrote:
>>>>
>>>> BTW, the whole idea of exporting something (data) into something
>>>> (Excel) shows bogus design. Why cannot the end data consumer access
>>>> data directly?
>>>
>>> They don't know the database.
>>
>> They do.
> 
> Before this degrades to positioning particular cases against
> other particular cases of opposite organisational design:
> The crucial bit is that, in the end, access to data (what, how)
> is not a consequence of programming decisions.  Technical
> facilities will be ordered .IFF. they facilitate achieving
> what has been agreed on, starting from more general premises
> of an organisational nature.
> 

Right. I agree.
And I agree with your statement about large organizations hiding
the underlaying storage from employees, like in banking systems.
That is of course a decision by the system owner, not
caused by the design of the system.

And also that some system vendors like to keep this
underlaying storage from customers as well.
And I think that is wrong - in my line of work.
In others - like system for hospitals or others keeping more sensible
data - it might be a good thing.

-- 
--
Björn

Re: Ada package registry?

[Dmitry A. Kazakov]

On 07/02/2016 21:02, Björn Lundin wrote:
> On 2016-02-07 11:23, Dmitry A. Kazakov wrote:
>
>> What is the problem? It is up to a DB client to handle these issues. An
>> ODBC driver and DB clients do all this. The single reason for all this
>> is bogus design.
>
> Ther is none. Of course they can access it with ODBC. That's
> part of what the thread is about.
>
> Users access the RDBMS via SQL into excel.
> Some people think that is awful around here,

What for? If the user sees the DB table directly in Excel this is 
everything he needs.

> However it gives the possiblity for users to create
> user defined queriers so the can pivot around as they like.

I don't know customers who write SQL queries. Ours demand that the data 
were exported into Excel from some GUI application. That does not stop 
them requiring an SQL interface, but this is a typical nice-to-have 
feature nobody actually uses.

> With Standard SQL as the tool in one hand,
> and the data model of the system in the other.

> Designing your own reports AS YOU WANT, without having
> to write programs th go from one binary storage to csv-files...

It would be much simpler to do in Excel.

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

Re: Ada package registry?

[Björn Lundin]

On 2016-02-07 23:16, Georg Bauhaus wrote:

> 
> However, there is something in Ada from which to build interfaces for
> SQL RDBMS, for practical reasons.
> 

That is an interesting thought.

-- 
--
Björn

Re: Ada package registry?

[Dmitry A. Kazakov]

On 07/02/2016 23:56, Georg Bauhaus wrote:
> On 07.02.16 20:54, Dmitry A. Kazakov wrote:
>> An access to execute SELECT on a DB table is no different to an
>> ability to view the table in Excel or any other program.
>
> This kind of access is a no-go area in some organisations.
> No one, including own employees, may know the names of tables;

Good. Then nobody can write an SQL query either. The case is closed.

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

Re: Ada package registry?

[Dmitry A. Kazakov]

On 07/02/2016 20:57, Björn Lundin wrote:
> On 2016-02-07 09:02, Dmitry A. Kazakov wrote:
>
>>
>> BTW, the whole idea of exporting something (data) into something (Excel)
>> shows bogus design. Why cannot the end data consumer access data directly?
>
> Of course they can.
> But some WANTS to get it into Excel.
> Has nothing to do with design.

It has: Excel cannot interface the DBMS.

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

Re: Ada package registry?

[Dmitry A. Kazakov]

On 07/02/2016 21:07, Björn Lundin wrote:
> On 2016-02-07 01:16, Jeffrey R. Carter wrote:

>> Whether selecting desired data from a large data set is easier or faster with a
>> DBMS or some form of Ada persistent containers is a more interesting question.
>
> That depends on the model amongst many things.
> But that is not the most interesting question.
> That one is about data openess for end users.

That suggests containers more closed than DB. This is a wrong assumption.

The difference is that DB interface is lower level compared to a 
container library, which makes the later more difficult to use in the 
environment where everything is communicated through files. It is 
self-replicating lowest common denominator design which poisons everything.

> Do they have to hire someone to get data into a report,
> or can they do it themselves.
>
> And end users are rarely programmers in this case, but
> they do know SQL, or are sent to courses to learn it.
>

SQL is a language, so they are programmers. But in my world no customer 
writes SQL queries. It is just to many DBs, too many tables and too much 
data for a customer to learn an handle. All types of reports are done 
from the GUI with corresponding parameters given from the GUI.

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

Re: Ada package registry?

[Dmitry A. Kazakov]

On 07/02/2016 23:16, Georg Bauhaus wrote:
> On 07.02.16 20:57, Dmitry A. Kazakov wrote:
>> On 2016-02-07 20:21, Georg Bauhaus wrote:
>>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>> On 2016-02-07 10:40, Georg Bauhaus wrote:
>>>>> On 05.02.16 19:47, Dmitry A. Kazakov wrote:
>>>
>>>> Interfaces.X in Ada do not convert anything, it provides Ada types
>>>> exactly matching their alien language counterparts.
>>>
>>> How does Interfaces.X provide matching
>>> types for decimals or task types in C, Cobol, or Fortran?
>>
>> See ARM Annex B.
>
> Let me rephrase: How does the Interface hierarchy from Annex B
> of the Ada LRM provide matching types for decimals or task types in
> C, Cobol, or Fortran? For, if it does not, then the alleged exact
> matches simply are not there. Not even one-way.

The languages like C have few base integral types which Annex B defines. 
Derived types are arrays and records created from the base types with 
pragma Convention applied.

So it boils down to the alien language types algebra mapped onto the 
Ada's types algebra. So far used:

record type operation
array type operation
tagged type operation (for C++ virtual pointer tables)

In short you should be able to describe the data type model in Ada. It 
works well for primitive procedural languages like C. It won't work for 
complicated declarative languages.

> However, there is something in Ada from which to build interfaces for
> SQL RDBMS, for practical reasons.

Ada does not have operations to express RA. As for SQL types the problem 
that they are not the types the DBMS actually uses and not the types at 
the DB client's end.

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

Re: Ada package registry?

[G.B.]

On 08.02.16 10:03, Dmitry A. Kazakov wrote:
> In short you should be able to describe the data type model in Ada. It
> works well for primitive procedural languages like C. It won't work for
> complicated declarative languages.

For an easy to use, standard interface between Ada and a vanilla
RDBMS, the DB operators involving relations won't be needed as
part of the Ada type system proper: the DBMS would not be mapped,
just like the Windows OS is not mapped to Ada.Directories, or
even to Some_Binding.Win32.

It's I/O.

Re: Ada package registry?

[Dmitry A. Kazakov]

On 08/02/2016 11:08, G.B. wrote:
> On 08.02.16 10:03, Dmitry A. Kazakov wrote:
>> In short you should be able to describe the data type model in Ada. It
>> works well for primitive procedural languages like C. It won't work for
>> complicated declarative languages.
>
> For an easy to use, standard interface between Ada and a vanilla
> RDBMS, the DB operators involving relations won't be needed as
> part of the Ada type system proper: the DBMS would not be mapped,
> just like the Windows OS is not mapped to Ada.Directories, or
> even to Some_Binding.Win32.

You are free to make a proposal if you believe in that.

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

Re: Ada package registry?

[Björn Lundin]

On 2016-02-08 09:38, Dmitry A. Kazakov wrote:
> On 07/02/2016 21:07, Björn Lundin wrote:
>> On 2016-02-07 01:16, Jeffrey R. Carter wrote:
> 
>>> Whether selecting desired data from a large data set is easier or
>>> faster with a
>>> DBMS or some form of Ada persistent containers is a more interesting
>>> question.
>>
>> That depends on the model amongst many things.
>> But that is not the most interesting question.
>> That one is about data openess for end users.
> 
> That suggests containers more closed than DB. This is a wrong assumption.

Yes I find SQL (DML-part) standardized enough to consider it open.
I do not see how a binary blob on disk can be called open,
unless there is a way to query it.



> SQL is a language, so they are programmers. 
Most economist that are good in Excel can handle Visual Basic for
Applications too.
So, perhaps, in a sense they are programmers.


>But in my world no customer
> writes SQL queries.
In my world they do. Not all, but some.


> It is just to many DBs, too many tables and too much
> data for a customer to learn an handle.

And sometimes they want to cross-reference with other systems.
Kind of difficult to put that on one vendor.


-- 
--
Björn

Re: Ada package registry?

[Randy Brukardt]

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

"Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
news:n95v9b$3hi$1@dont-email.me...
> On 2016-02-06 01:30, Randy Brukardt wrote:
...
>>> Yeah, having millions of records in .csv and
>>> joining with a couple of other .csv files with
>>> the same amount of data and
>>> sounds like a really good idea...
>>> If you got plenty of time, that is.
>>
>> Huh? You said that it is hard to pull data to Excel, and I disagreed. You
>> didn't say anything about pulling *all* of the data -- and why would you 
>> do
>> that? Excel would fall over if you gave it a million lines of anything - 
>> the
>> maximum number of rows is (or at least was) less than that.
>>
>> Obviously, you'd do the selection before exporting to Excel (the case I 
>> was
>> talking about).
>
> And that is the hard part. Of course you don't pull that kind of data
> into excel. But the selection itself  - into useful data from several
> sources - is hard using csv-files and ada.
> and no one in the business would be able to conclude anything
> useful from their own data.

You're still not making much sense. The Ada code would do the selections, of 
course; .csv would only be an export format. If you're exporting ALL of the 
data, something is wrong. Besides, when I say that DBs are overused, I 
surely don't mean that they have NO uses. If you have to do a lot of join 
selections and the like, you might very well need a DB. The problem is, a 
lot of the time people are using "join" when there is a better solution.

>>  > Looking at a customers trace table I see they generate about 100_000
>>> records a day. Order lines are around the same.
>>> Data saved for a month or two, before moving to long-term storage (db
>>> not connected to production)
>>
>> Way too much data -- 
>
> for csv-files : yes. for an RDBMS : no
> for business analysis : no.
> For tracking what store got delivery from what pallet : definitely no.
> And that is really important, if you find trouble in a batch of say
> food, and want to withdraw it from the stores. Which stores are affected?
> - Wait , I need to call an Ada-programmer to write a tool to extract
> that data from our many and BIG csv-files...

Big .csv files? Surely hope not. And as far as needing a programmer: of 
course, a programmer has to be involved somewhere. Whether that be Ada or 
SQL or Java, still need a programmer.

...
>> I *hope* they waste their time with fancy ERP systems rather than getting
>> anything done so they can go out of business faster... :-)
>
> A statement that I do not know what to think of.
> I see the smiley, but I don't see the fun in it.
> I do see it as fairly immature though.

Sorry, I made a political remark and mixed it into a technical discussion; 
too off-topic for here. But I will say that as someone who started a 
business and have some insight into day-to-day activities, the balancing act 
required for a small business to do right by their customers and 
employee/owners is very difficult. Once you throw in the disconnect of size 
and of outside owners, it becomes completely impossible. Smaller businesses 
are preferred, in part because failure *is* an option -- meaning no one is 
locked in.

I detest ERP systems for many reasons, but they seem to help clog up the 
works at many businesses that are better off being replaced by smaller 
versions anyway. So in that sense they are a positive... :-)

                                            Randy.

Re: Ada package registry?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:n96tn6$r9h$1@gioia.aioe.org...
...
> BTW, the whole idea of exporting something (data) into something (Excel) 
> shows bogus design. Why cannot the end data consumer access data directly?

They can, but a tool like Excel can provide capabilties not present in the 
original system without retooling. I use it, for instance, to make pretty 
charts out of Ada data -- not wanting to create some charting mechanism nor 
a PDF writer. (I note that libraries for both of those things exist for Ada, 
so maybe I ought to rethink that down the road.) Excel is also great for 
playing with data to find out things that you didn't previously know 
(sorting and formulas can easily be applied). Ada will never be good for 
exploratory tasks.

                                         Randy.

Re: Ada package registry?

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:n942ha$bks$1@dont-email.me...
> On 02/05/2016 06:25 PM, Randy Brukardt wrote:
>>
>> [What I mean by expressing assumptions is that it's unlikely that any 
>> real
>> Ada code would really run anywhere. I've been having fun with Gautier 
>> over
>> his "unconditional portability" claim, as one only needs a single
>> counter-example to disprove the claim. After a few obvious problems with 
>> the
>> choices of Janus/Ada were worked out, I pointed out that his types 
>> wouldn't
>> work on our old U2200 compiler (as that was a 1's completement, 36-bit
>> machine). He decided quite reasonably not to worry about that, but that
>> means in his case, that means his code is "unconditionally portable" so 
>> long
>> as your target supports 32-bit integers and is 2's complement. That might 
>> be
>> 99% of machines, but its not quite unconditional.]
>
> Wasn't that an Ada-83 compiler? And isn't he trying for portability across
> Ada-95 compilers?

No, it was Ada 95 (we worked on it roughly 1995-8).

> If you had an Ada-95 compiler for that machine, what would be the problem 
> with
>
> type U is mod 2 ** 32;
> for U'Size use 32;
>
> type S is range -(2 ** 31) .. (2 ** 31) - 1;
> for S'Size use 32;
> ?

Those would work, but the data would still be stored in 36-bits. Since he 
uses streaming to get data in and out, the 9-bit stream-elements on that 
machine would get him. It *might* even have worked on that machine, but the 
.jpg files still wouldn't be portable to/from more normal machines. So it 
still would have been pointless.

                                   Randy. 

Re: Ada package registry?

[Randy Brukardt]

<gautier_niouzes@hotmail.com> wrote in message 
news:dbd56a53-7a9c-4707-8d6d-0156174f7263@googlegroups.com...
> Regarding the U2200 machine I think it's OK. The type in question is:
>
>  min_bits: constant:= Integer'Max(32, System.Word_Size);
>  -- 13.3(8): A word is the largest amount of storage that can be
>  -- conveniently and efficiently manipulated by the hardware,
>  -- given the implementation's run-time model.
>
>  type Integer_M32 is range -2**(min_bits-1) .. 2**(min_bits-1) - 1;
>  --  We define an Integer type which is at least 32 bits, but n bits
>  --  on a native n > 32 bits architecture (no performance hit on 64+
>  --  bits architectures).
>
> You say: "The lower bound would have to be -2**(min_bits-1)-1 on such a 
> machine.". Since -2**(min_bits-1) > -2**(min_bits-1)-1, Integer_M32 is a 
> subrange of what you mean and it should be OK.
>
> I let you the pleasure of trying the actual compilation for the U2200. I 
> wait with excitement for the results ;-).

Since we didn't implement stream attributes until after that project petered 
out, it sadly wouldn't prove anything. But I know I say String'Read in there 
somewhere, and the 9-bit Size for Character on the U2200 would have 
interesting effects.

It really doesn't make sense to run those programs on the U2200 anyway; no 
browsers or that sort of thing there. They had a POSIX emulator, but that 
was about as modern as it got.

                                      Randy.

Re: Ada package registry?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:n94cbv$19ed$1@gioia.aioe.org...
> On 2016-02-06 01:04, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:n91oau$1bk5$1@gioia.aioe.org...
>>> On 04/02/2016 22:09, Randy Brukardt wrote:
>> ....
>>>> (The reason that we adopted the generalized reference feature that we 
>>>> did
>>>> is
>>>> because of the ability to use it to manage persistence -- in 
>>>> particular,
>>>> to
>>>> be able to figure out when the in-memory copy can be freed and written 
>>>> to
>>>> the backing store.)
>>>
>>> That is not enough. You need references with a notification upon
>>> dereferencing.
>>
>> That's called "a function call" :-). There's no need for a separate 
>> feature
>> for that (since anonymous access results are essentially uncopyable). 
>> What
>> was missing was a way to know when the access itself goes away.
>
> That is called a function call too.

Well, actually a procedure call (to Finalize).

> For persistence layer you need dereference primitive operations. One for 
> read access in order to cache data and one write access to mark the cache 
> dirty.

The first is the function call (to Reference, if you're looking at the Ada 
containers), and the second is the Finalize call that happens when the 
object returned from Reference goes away. That was the whole point of the 
design. (Of course, you could have written that in Ada 95, but without the 
syntactic sugar that makes it easier to read and write.)

                                   Randy.

Re: Ada package registry?

[Randy Brukardt]

<olivier.henley@gmail.com> wrote in message 
news:dce00efe-1391-416e-9b2e-ec77e7b558ff@googlegroups.com...
>1. You can look at it the way you want, the end result of something like 
>code.dlang.org
> or haskell stack is more neat, efficient, structured, coherent and 
> appealing than the noisy
> search engine at AdaIC. (I entered the term physic ... OMG It was 
> disastrous. Nothing
> relevant. I even tried to find that search utility directly from google. 
> It was like a detective
> quest!) Arguing the opposite is, IMO, like arguing that the earth is flat.

Umm, "physic" isn't a word, I'm surprised you got any result at all. 
Probably only misspellings in old e-mail, surely couldn't be helpful.

I agree with you that Ada needs better publicity of the available tools and 
the like. The search engine would have gotten more mind-share if I could 
have come up with a snappy name for it -- but that's been beyond my 
capabilities. Since it doesn't have a snappy name, there's nothing to look 
for in Google. (And I'm not sure another search engine is the best place to 
look for our search engine anyway.)

Constructive suggestions are always welcome.

>2. You use way too much strong words like harmful and insult, to nuke a 
>PM/PR
> proposition. I get it that you are a tenor of the Ada community but it 
> does not qualify
> you to serve what I call 'toxic arguments'. IMHO, your statu quo and 
> orthodoxy
> deeply anchored in 'has been' technology poses much more of a drag to the 
> Ada
> pipelines than the envisioning of a PM for Ada; for future, open source, 
> pure Ada
> code projects.

My vision of Ada is of a language in which to construct code that is 
portable across implementations and across targets. To the extent that a 
tool, no matter how well-intentioned, interfers with that, then it is 
harmful to the future of Ada. GNAT /= Ada!! What I heard being discussed 
only seemed to make sense within the context of GNAT on Linux, because 
that's the only place where "package managers" make sense. Perhaps I 
over-reacted a bit; I don't think there is much benefit to such a system, 
but it wouldn't hurt so long as it is not tied to a particular 
implementation or target. In particular, the setup Tero described would not 
bother me (I'd still be worried about it providing an image of relatively 
inactive community by not having much in it, but that might be a risk worth 
taking if enough of you care).

>3. By not acting to attract people, you are constantly redirecting smart 
>young people
> to other communities, e.g Dlang. Many clever pals want to ditch C++ and 
> Ada
> would be a perfect fit to foster them. Wont happen with loud voices like 
> yours
> 'bullying' sensible propositions around.

Building complicated tools to do things that aren't really needed for Ada 
doesn't make it a "sensible proposition". If the "young people" need too 
much handholding, they're not really ready to engineer software with a 
professional tool like Ada. (How they get anything done in C++ is beyond 
me!) They'd be better off with Python or some such language.

> (I work at Ubisoft Montreal. Yesterday
> my boss was asking about my website and I told him I did it in Ada. You 
> know
> what he asked me: 'Ada... is it not an old programming language?'. By old 
> he
> meant dead; Ada needs a nice haircut.) To me it looks like you want to 
> keep Ada
> and the accompanying discourse for yourself. Am I wrong?

I've put virtually my entire life into Ada, and as such I don't want others 
to come in and destroy the very properties that make Ada attractive in the 
first place. That would make my entire life a waste. I have absolutely no 
problem with new ideas that don't harm the good things about Ada.

>4. A PM/PR ... yeah it is for open source projects. If you took the time to
> check code.dlang you would have get it from the start. You can keep your
> proprietary stuff for you alone, on your MUCH better VCS system than
> what is in main use. Oh btw, I myself solved the problem for a quantum
>computer. It is in my basement... but I cant show you its proprietary stuff
>and I lost the key to enter the vault too... sorry.

What the heck are you babbling about here?

I was talking about the various things we've made available as open source 
or freely available over the years. Did you know that there is an open 
source subset of Claw? (Probably not, we've never made that very clear on 
our website.) We used to provide floppy disks of free Ada software back in 
the days before the internet and "Open Source". It's that sort of stuff that 
I was talking about.

> 5. Would you mind stop musing about your realizations and views of the
> world in precise topic forum threads. It slides the discussion into 'not
> constructive land'. Thank you.

????

Surely everyone's opinions are influenced by their world view. That's 
clearly going to show through from time-to-time. And the notion that 
everyone stay precisely on topic in an Internet thread is laughable. It 
drives my nutty sometimes (especially on the ARG list where I need to file 
the mail on the appropriate AI), but it's part of the territory.

>6. All your knowledge about software architecture, maybe you could put it 
>to
>good use by writing a book and/or making free software so people like me
>could study your code and learn. If you already did please direct me.

No time for a book, sadly; I have to earn money to live on. Maybe when I 
retire.

As far as software goes, Claw is probably my best work, and of course as I 
noted earlier the sample version is open source. Hopefully, NC-Sockets will 
be available soon as well. I've thought about making Janus/Ada open source, 
but quite honestly I find the code quality embarassing and thus don't really 
want others to see the code. :-) [Large parts of Janus/Ada were constructed 
before I really understood software engineering, plus it is primarily Ada 83 
code so a lot of structuring choices that we have now were not available.]

> My one cent... to put my false humility on the back of deflation.

???

The price was one cent when my mother was little, so I'm pretty sure 
everyone's opinion is worth more than that today. :-)

                                 Randy.

Re: Ada package registry?

[Shark8]

> My vision of Ada is of a language in which to construct code that is
portable across implementations and across targets. To the extent that a tool, no matter how well-intentioned, interfers with that, then it is harmful to the future of Ada.


I don't think anyone here wants to interfere with that vision. Especially considering that it is generally agreed that the single free implementation (GNAT) isn't good for Ada.

> GNAT /= Ada!!

Agreed.
And most here don't think that it would be good if it were.

> What I heard being discussed only seemed to make sense within the context of GNAT on Linux, because that's the only place where "package managers" make sense.

I think that it depends on what the definition is. Given that early on in the thread the perl packag emanager (CPAN) was cited, it seems that the Linux idea of package manager was not intended -- the subject of the thread concurs -- I think what is being talked about could be described as an "online library".

If that is the case, I would recomend:
1) an internal representation, instead of text, which can be verified as consistant/compiled. [This may require a standard way to define an Ada project.]
2) a method (header-field?) marking the license(s) that the contained sources are under [to help w/ filtering, as well as making it feasable for non open source distribution].
3) a method for marking dependencies. (Also a header field?)
4) versioning. (To include changes impacting #2 & #3)
5) that building be handled separately. (Though a standard method for describing an Ada project could definately help here.)
6) that any installation (of non-Ada items) be handled separately.

While something like integrated tests would ne nice, I think they might be a bit beyond the scope of of the project. (#5 and #6 are there to both reduce the complexity and the scope of such a repository.)

> In particular, the setup Tero described would not
bother me (I'd still be worried about it providing an image of relatively inactive community by not having much in it, but that might be a risk worth taking if enough of you care).

I think any new system would have this problem. The initial populating would be the sticking point... but, arguably, the current situation is worse. (That being the exact impetus for suggesting such a repository.)

>> 3. By not acting to attract people, you are constantly redirecting smart young people to other communities, e.g Dlang. Many clever pals want to ditch C++ and Ada would be a perfect fit to foster them. Wont happen with loud voices like yours 'bullying' sensible propositions around.
>
>
> Building complicated tools to do things that aren't really needed for Ada doesn't make it a "sensible proposition". If the "young people" need too much handholding, they're not really ready to engineer software with a professional tool like Ada. (How they get anything done in C++ is beyond me!)

Does your opinion change if what is being talked about is a library/dependency manager (as described above) rather than the Linux idea of "package manager"?

>> (I work at Ubisoft Montreal. Yesterday my boss was asking about my website and I told him I did it in Ada. You know what he asked me: 'Ada... is it not an old programming language?'. By old he meant dead; Ada needs a nice haircut.) To me it looks like you want to keep Ada and the accompanying discourse for yourself. Am I wrong?
>
>
>I've put virtually my entire life into Ada, and as such I don't want others to come in and destroy the very properties that make Ada attractive in the first place. That would make my entire life a waste. I have absolutely no problem with new ideas that don't harm the good things about Ada.


I don't think anyone here wants your life to be wasted. I, for one, am quite gratful for the time and energy you have put in.


Thank you.

>. Did you know that there is an open source subset of Claw? (Probably not, we've never made that very clear on
our website.)

The trial version?

Re: Ada package registry?

[Thomas Løcke]

On 02/09/2016 01:05 AM, Randy Brukardt wrote:
> My vision of Ada is of a language in which to construct code that is
> portable across implementations and across targets. To the extent that a
> tool, no matter how well-intentioned, interfers with that, then it is
> harmful to the future of Ada. GNAT /= Ada!! What I heard being discussed
> only seemed to make sense within the context of GNAT on Linux, because
> that's the only place where "package managers" make sense.


Package managers make sense on all operating systems I'm aware of. The
fact that some don't have a package manager does not mean that they
can't or shouldn't have one. I've installed and used the Haskell Stack
tool on Windows, OS X and Linux, and it works equally well on all three.

I urge you to take a look at how the Haskell community have solved this
particular "challenge". Stack / Cabal / Hackage are wonderful tools,
created and maintained by a fairly small community.

http://docs.haskellstack.org/en/stable/README.html

I'm quite sure the Ada community could adapt those tools to match the
needs of Ada in the 21st. century. I don't think we have to reinvent the
wheel in order to gain the benefits of a proper package manager.

:o)

-- 
Thomas Løcke | thomas@12boo.net | http://12boo.net

Re: Ada package registry?

[Dmitry A. Kazakov]

On 09/02/2016 00:02, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:n94cbv$19ed$1@gioia.aioe.org...

>> For persistence layer you need dereference primitive operations. One for
>> read access in order to cache data and one write access to mark the cache
>> dirty.
>
> The first is the function call (to Reference, if you're looking at the Ada
> containers), and the second is the Finalize call that happens when the
> object returned from Reference goes away. That was the whole point of the
> design. (Of course, you could have written that in Ada 95, but without the
> syntactic sugar that makes it easier to read and write.)

It is not same. A reference points to a proxy object, a cached copy of 
the external object in the persistent storage. When the proxy object is 
updated via any reference, it must be marked dirty. So that when the 
object at some point gets finalized or the transaction is committed it 
would be written back to the storage.

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

Re: Ada package registry?

[Alejandro R. Mosteo]

On 09/02/16 09:04, Thomas Løcke wrote:
> On 02/09/2016 01:05 AM, Randy Brukardt wrote:
>> My vision of Ada is of a language in which to construct code that is
>> portable across implementations and across targets. To the extent that a
>> tool, no matter how well-intentioned, interfers with that, then it is
>> harmful to the future of Ada. GNAT /= Ada!! What I heard being discussed
>> only seemed to make sense within the context of GNAT on Linux, because
>> that's the only place where "package managers" make sense.
>
>
> Package managers make sense on all operating systems I'm aware of. The
> fact that some don't have a package manager does not mean that they
> can't or shouldn't have one.

And what's more, once you get used to them you miss them dearly when absent.

I've installed and used the Haskell Stack
> tool on Windows, OS X and Linux, and it works equally well on all three.
>
> I urge you to take a look at how the Haskell community have solved this
> particular "challenge". Stack / Cabal / Hackage are wonderful tools,
> created and maintained by a fairly small community.
>
> http://docs.haskellstack.org/en/stable/README.html
>
> I'm quite sure the Ada community could adapt those tools to match the
> needs of Ada in the 21st. century. I don't think we have to reinvent the
> wheel in order to gain the benefits of a proper package manager.

I'm totally behind the idea. Alas, time is as scarce as ever.

Also, I think we're witnessing a new case of 'perfect is the enemy of 
the good'. Should really a submitted library compile in every OS ever, 
with every compiler ever, using the most complex dependencies there to 
be found? Just mark what works and what doesn't and let the Ada masses 
(:-)) improve on that.

>
> :o)
>

Re: Ada package registry?

[Shark8]

> Should really a submitted library compile in every OS ever,
with every compiler ever, using the most complex dependencies there to
be found?

Given that Ada has always alowed the compiler to reject programs dependant upon implementation limits, I think that's a poor argument. However, it can be argued that compiling should not ne part of the package manager's job. (OTOH, it makes sense to ensure that no invalid [non-compilabe due to syntax or other detectable error] is accepted into the repository.

Dependencies also ought to be indiccated/managed so as to allow a "recursive" retrival -- but, again, this should be limited to only the Ada side of things. (E.G. installing Firebird for a firebird-binding can properly be the responsibility of the user.

Re: Ada package registry?

[Jeffrey R. Carter]

On 02/09/2016 01:04 AM, Thomas Løcke wrote:
> 
> I urge you to take a look at how the Haskell community have solved this
> particular "challenge". Stack / Cabal / Hackage are wonderful tools,
> created and maintained by a fairly small community.

"stack is a project of the Commercial Haskell group, spearheaded by FP Complete.
... While stack itself has been around since June of 2015, it is based on
codebases used by FP Complete for its corporate customers and internally for
years prior."

In other words, the initial version of stack was created by developers who were
paid for their effort. While I have no problem with the idea, I doubt if any Ada
company is going to be able to fund such a project. We could perhaps just modify
stack for our purposes, but I doubt if we have enough Haskell expertise for
that. Many of us are willing to contribute, but without funding or an existing
system to adapt it seems unlikely to happen.

-- 
Jeff Carter
"I was in love with a beautiful blonde once, dear.
She drove me to drink. That's the one thing I'm
indebted to her for."
Never Give a Sucker an Even Break
109

Re: Ada package registry?

[Björn Lundin]

On 2016-02-08 23:38, Randy Brukardt wrote:
> "Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
> 
> You're still not making much sense. The Ada code would do the selections, of 
> course;

And that's my point. With SQL, you don't NEED to be an Ada programmer
to get the data you'd like.
You DO need to know SQL, but a greater number of people does.


 .csv would only be an export format. If you're exporting ALL of the
> data, something is wrong. Besides, when I say that DBs are overused, I 
> surely don't mean that they have NO uses. If you have to do a lot of join 
> selections and the like, you might very well need a DB. The problem is, a 
> lot of the time people are using "join" when there is a better solution.

Ok, that is a statement I sure can buy.


> I detest ERP systems for many reasons, 
Well so do I. They are big and clumpsy,
costs a fortune, and even more to adapt.
But I sure don't want people USING them to go out of business.

-- 
--
Björn

Re: Ada package registry?

[Shark8]

> Many of us are willing to contribute, but without funding or an existing system to adapt it seems unlikely to happen.

I don't know about that. I think that with the amount of willingness shown on the thread we're close to the 'crystalization point' -- I think the biggest thingss holding is back is a solid well thought plan.

I am somewhat against using an extant (and presumably general purpose) system, precisely because the real power/utility will come from properties a generalized system is ill-suited for. (Consider how diff is hampered in programmongs by being about text and not semantic diferences.)

Re: Ada package registry?

[Björn Lundin]

On 2016-02-09 01:05, Randy Brukardt wrote:
> 
> My vision of Ada is of a language in which to construct code that is 
> portable across implementations and across targets. To the extent that a 
> tool, no matter how well-intentioned, interfers with that, then it is 
> harmful to the future of Ada. GNAT /= Ada!! 

GNAT is not Ada, but speaking of the future,
why bother putting out new Ada-revisions when there is only
1 implementation of Ada2012 and Ada05?
(Or is ObjectAda an Ada05 compiler now ?)

Writing libraries that HAVE to compile in Ada95
does not really encourage using all the new fine features.


--
Björn

Re: Ada package registry?

[Shark8]

> GNAT is not Ada, but speaking of the future, why bother putting out new Ada-revisions when there is only 1 implementation of Ada2012 and Ada05?

This is somethong that the Byron project aims to rectify by being an Ada 2012 compiler written in Ada 2012.

> (Or is ObjectAda an Ada05 compiler now?)

I'm npt sure, but I recall one of the other comertial compilers had full Ada 2005 -- I think it was Irvine or GreenHills.

> Writing libraries that HAVE to compile in Ada95 does not really encourage using all the new fine features.

Agreed, which is one reason that I'm working on Byron, and why I would recomend that an Ada library-reposotory be written in Ada 2012. (If we were really enterprising, we would make it so that the networking libs were abstracted enough they could be replaced by SPARK networking libs and then added to the library itself.)

Re: Ada package registry?

[Jeffrey R. Carter]

On 02/09/2016 02:31 PM, Shark8 wrote:
> 
> I'm npt sure, but I recall one of the other comertial compilers had full Ada 2005 -- I think it was Irvine or GreenHills.

Based on my informal surveys, in 2000, 5 yrs after ISO/IEC 8652:1995, every
compiler vendor had a compiler for it. In 2012, 5 yrs after ISO/IEC 8652:2007,
about half the vendors had compilers for it. It will be interesting to see what
things are like in 2017.

> Agreed, which is one reason that I'm working on Byron, and why I would recomend that an Ada library-reposotory be written in Ada 2012. (If we were really enterprising, we would make it so that the networking libs were abstracted enough they could be replaced by SPARK networking libs and then added to the library itself.)

That's not being enterprising. That's being a competent S/W engineer.

-- 
Jeff Carter
"I was in love with a beautiful blonde once, dear.
She drove me to drink. That's the one thing I'm
indebted to her for."
Never Give a Sucker an Even Break
109

Re: Ada package registry?

[J-P. Rosen]

Le 09/02/2016 22:31, Shark8 a écrit :
> I'm npt sure, but I recall one of the other comertial compilers had
> full Ada 2005 -- I think it was Irvine or GreenHills.

It's APEX-Ada (now from PTC). Irvine has a 2005 compiler in "limited
beta". But definitely not GreenHills!

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada package registry?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:n9c9a8$mt9$1@gioia.aioe.org...
> On 09/02/2016 00:02, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:n94cbv$19ed$1@gioia.aioe.org...
>
>>> For persistence layer you need dereference primitive operations. One for
>>> read access in order to cache data and one write access to mark the 
>>> cache
>>> dirty.
>>
>> The first is the function call (to Reference, if you're looking at the 
>> Ada
>> containers), and the second is the Finalize call that happens when the
>> object returned from Reference goes away. That was the whole point of the
>> design. (Of course, you could have written that in Ada 95, but without 
>> the
>> syntactic sugar that makes it easier to read and write.)
>
> It is not same. A reference points to a proxy object, a cached copy of the 
> external object in the persistent storage. When the proxy object is 
> updated via any reference, it must be marked dirty. So that when the 
> object at some point gets finalized or the transaction is committed it 
> would be written back to the storage.

But actually they are the same, because the reference can only exist for a 
very short time. (You can't assign a reference because the accessibility is 
too shallow.) Thus, the proxy object can be marked dirty (if you created a 
writable reference, which is only created when you actually use the 
reference in a writable context) and written back to the persistent storage. 
You do have to make sure that only one task is potentially writing a proxy 
object at a time, but that seems like a good thing. (Obviously, sharing 
proxy objects between read-only references is fine.)

                                      Randy. 

Re: Ada package registry?

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:9e5fa75d-bcf3-4bd9-b62b-284464f44d27@googlegroups.com...
...
>>. Did you know that there is an open source subset of Claw? (Probably not, 
>>we've
>> never made that very clear on our website.)
>
>The trial version?

Right. It has all of the basic building blocks, it omits some of the bells 
and whistles. The ultimate goal was to make the entire binding open source, 
but that never happened.

                   Randy.

Re: Ada package registry?

[Randy Brukardt]

"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:n9cpmm$cud$1@dont-email.me...
...
> Also, I think we're witnessing a new case of 'perfect is the enemy of the 
> good'. Should really a submitted library compile in every OS ever, with 
> every compiler ever, using the most complex dependencies there to be 
> found? Just mark what works and what doesn't and let the Ada masses (:-)) 
> improve on that.

No, but it should be crystal clear what assumptions it is making of 
compilers, target OSes, and hardware. That's where such a repository could 
be a significant improvement over the current situation. I don't want to 
start depending on stuff that only works in one situation, but it's pretty 
hard to tell that for most of the libraries that I've linked to. And even if 
you only want to work on Linux GNAT, you probably would want to avoid stuff 
that only works on Windows. And so on. Putting that into some sort of common 
format would be a worthwhile goal.

                                           Randy.

Re: Ada package registry?

[Randy Brukardt]

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

"Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
news:n9dk9u$r85$1@dont-email.me...
> On 2016-02-09 01:05, Randy Brukardt wrote:
>>
>> My vision of Ada is of a language in which to construct code that is
>> portable across implementations and across targets. To the extent that a
>> tool, no matter how well-intentioned, interfers with that, then it is
>> harmful to the future of Ada. GNAT /= Ada!!
>
> GNAT is not Ada, but speaking of the future,
> why bother putting out new Ada-revisions when there is only
> 1 implementation of Ada2012 and Ada05?
> (Or is ObjectAda an Ada05 compiler now ?)

Both the Irvine and Rational (now part of PTC) compilers have Ada05 versions 
as I understand it. The current version of Janus/Ada supports some Ada05 
stuff (and all of the syntax). (The working version does the same for Ada 
2012 -- but of course that's a long way from being an Ada2012 compiler.)

                       Randy.

Re: Ada package registry?

[Shark8]

> it should be crystal clear what assumptions it is making of compilers, target OSes, and hardware. That's where such a repository could be a significant improvement over the current situation. I don't want to start depending on stuff that only works in one situation, but it's pretty hard to tell that for most of the libraries that I've linked to.

You're absolutely right. This is why I think that a standard Ada-project format is in order: we would get a standard way to indicate system-dependencies,* multiple/varient bodies, and could use THAT in the repository to indicate those parameters.

There is, of course the problem of having a library add/drop support for a system (eg Lumen & Windows), but that can be handled by the version-control aspect of the system.

* My Ada Project Manager takes the idea of Ada's generics as the basis for handling parameters, so depending on project-x transitively applies the parameter. Creating a standard "root" project for the repository-system would ensure that all the requsite parameters are extant.

Re: Ada package registry?

[Dmitry A. Kazakov]

On 11/02/2016 02:37, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:n9c9a8$mt9$1@gioia.aioe.org...
>> On 09/02/2016 00:02, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:n94cbv$19ed$1@gioia.aioe.org...
>>
>>>> For persistence layer you need dereference primitive operations. One for
>>>> read access in order to cache data and one write access to mark the
>>>> cache
>>>> dirty.
>>>
>>> The first is the function call (to Reference, if you're looking at the
>>> Ada
>>> containers), and the second is the Finalize call that happens when the
>>> object returned from Reference goes away. That was the whole point of the
>>> design. (Of course, you could have written that in Ada 95, but without
>>> the
>>> syntactic sugar that makes it easier to read and write.)
>>
>> It is not same. A reference points to a proxy object, a cached copy of the
>> external object in the persistent storage. When the proxy object is
>> updated via any reference, it must be marked dirty. So that when the
>> object at some point gets finalized or the transaction is committed it
>> would be written back to the storage.
>
> But actually they are the same, because the reference can only exist for a
> very short time. (You can't assign a reference because the accessibility is
> too shallow.) Thus, the proxy object can be marked dirty (if you created a
> writable reference, which is only created when you actually use the
> reference in a writable context) and written back to the persistent storage.

Writing objects is very expensive. So objects must be reference counted 
anyway. I don't see how the schema can handle all this, as well as 
inducing the reference type (read-only vs. read-write) from the context.

> You do have to make sure that only one task is potentially writing a proxy
> object at a time, but that seems like a good thing.

Not good. Object updating through a reference and handling reference 
counts must be atomic. References must act as read-write locks.

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

Re: Ada package registry?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:n9hgje$vai$1@gioia.aioe.org...
> On 11/02/2016 02:37, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:n9c9a8$mt9$1@gioia.aioe.org...
>>> On 09/02/2016 00:02, Randy Brukardt wrote:
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>> news:n94cbv$19ed$1@gioia.aioe.org...
>>>
>>>>> For persistence layer you need dereference primitive operations. One 
>>>>> for
>>>>> read access in order to cache data and one write access to mark the
>>>>> cache
>>>>> dirty.
>>>>
>>>> The first is the function call (to Reference, if you're looking at the
>>>> Ada
>>>> containers), and the second is the Finalize call that happens when the
>>>> object returned from Reference goes away. That was the whole point of 
>>>> the
>>>> design. (Of course, you could have written that in Ada 95, but without
>>>> the
>>>> syntactic sugar that makes it easier to read and write.)
>>>
>>> It is not same. A reference points to a proxy object, a cached copy of 
>>> the
>>> external object in the persistent storage. When the proxy object is
>>> updated via any reference, it must be marked dirty. So that when the
>>> object at some point gets finalized or the transaction is committed it
>>> would be written back to the storage.
>>
>> But actually they are the same, because the reference can only exist for 
>> a
>> very short time. (You can't assign a reference because the accessibility 
>> is
>> too shallow.) Thus, the proxy object can be marked dirty (if you created 
>> a
>> writable reference, which is only created when you actually use the
>> reference in a writable context) and written back to the persistent 
>> storage.
>
> Writing objects is very expensive. So objects must be reference counted 
> anyway. I don't see how the schema can handle all this, as well as 
> inducing the reference type (read-only vs. read-write) from the context.

The language rules determine the reference type from context, so that's done 
automatically for you. (And, yes, there are ACATS tests for it, so a 
conforming Ada compiler will do it correctly -- now. [The tests failed on 
compilers when they came out, but those problems were swiftly fixed.]) See 
the difference between Reference and Constant_Reference in the 
Ada.Containers library.

You don't necessarily have to reference count objects, especially if you use 
a read-write lock (as discussed below); in that case, there can never be 
more than one writable reference active at a time anyway. But you surely can 
do that.

>> You do have to make sure that only one task is potentially writing a 
>> proxy
>> object at a time, but that seems like a good thing.
>
> Not good. Object updating through a reference and handling reference 
> counts must be atomic. References must act as read-write locks.

That's what I meant: the implementation of Reference can include an 
appropriate read-write lock. I wouldn't leave it to the programmer to get 
right.

Everything you've asked about is present in the Ada 2012 features (or 
before), so I think it's possible to write such a library and have it work 
reasonably transparently. Not having tried it myself, I don't want to make a 
100% certainty claim, but surely we intended that it would work.

                       Randy.

Re: Ada package registry?

[Alejandro R. Mosteo]

On 29/01/16 02:13, olivier.henley@gmail.com wrote:
> Hey,
>
> Anyone thought about doing something similar to DUB, the D package registry (http://code.dlang.org/) ... for Ada?

Whatcha say the people interested in such a thing move the discussion to 
a place where things could start rolling? Just as a suggestion: 
https://github.com/mosteo/alire/issues/1

Cheers.

Re: Ada package registry?

[olivier.henley]

On Friday, February 12, 2016 at 11:05:49 AM UTC-5, Alejandro R. Mosteo wrote:
> Whatcha say the people interested in such a thing move the discussion to 
> a place where things could start rolling? Just as a suggestion: 
> https://github.com/mosteo/alire/issues/1
> 
> Cheers.

Yes, please step in the discussion. BTW, IMO the name you choose Alejandro, Alire, is very nice!

Re: Ada package registry?

[Alejandro R. Mosteo]

On 13/02/16 06:42, olivier.henley@gmail.com wrote:
> On Friday, February 12, 2016 at 11:05:49 AM UTC-5, Alejandro R. Mosteo wrote:
>> Whatcha say the people interested in such a thing move the discussion to
>> a place where things could start rolling? Just as a suggestion:
>> https://github.com/mosteo/alire/issues/1
>>
>> Cheers.
>
> Yes, please step in the discussion. BTW, IMO the name you choose Alejandro, Alire, is very nice!
>

Thanks! :)