Taking another spanking.

Taking another spanking.

[Petter]

I think I am an instance of Stevie Vai (see Frank Zappa discography).

I just changed to GPL 2009 from way old ... on my portable. Now
GNAT.Sockets.Thin has changed a lot. Send is nomore and I'll probably
have to use Sendto. Documentation is very brief.... Why do we keep on
punishing ourselfs with these small unneeded changes.

No more hiarbrush treatment please, Debra!

Re: Taking another spanking.

[Per Sandberg]

"GNAT.Sockets.This" is a very internal unit and it stated in the docs 
that the contents of that file will change over time.
However "GNAT.Sockets" is a public unit that is promised to be stable 
over time and platforms.

/Don't lose yourself to the dark side
/Per


Petter wrote:
> I think I am an instance of Stevie Vai (see Frank Zappa discography).
> 
> I just changed to GPL 2009 from way old ... on my portable. Now
> GNAT.Sockets.Thin has changed a lot. Send is nomore and I'll probably
> have to use Sendto. Documentation is very brief.... Why do we keep on
> punishing ourselfs with these small unneeded changes.
> 
> No more hiarbrush treatment please, Debra!

Re: Taking another spanking.

[sjw]

On Jun 2, 9:28 am, Petter <petter_frykl...@hotmail.com> wrote:
> I think I am an instance of Stevie Vai (see Frank Zappa discography).
>
> I just changed to GPL 2009 from way old ... on my portable. Now
> GNAT.Sockets.Thin has changed a lot. Send is nomore and I'll probably
> have to use Sendto. Documentation is very brief.... Why do we keep on
> punishing ourselfs with these small unneeded changes.
>
> No more hiarbrush treatment please, Debra!

This from g-socthi.ads:
--  This package provides a target dependent thin interface to the
sockets
--  layer for use by the GNAT.Sockets package (g-socket.ads). This
package
--  should not be directly with'ed by an applications program.

Re: Taking another spanking.

[Petter]

Of course I know I need to use GNAT.SOckets, but lazy as I am, I had
got some code from elsewhere and cannot tell that person to do the job
for me. It seems to me that Debra is changing her hairbrush just
because she told me she would. I just don't want to eat the banana :
( And there are very many bananas  and hairbrushes around, A# doesn't
work, GANTCOM is broken ...

Re: Taking another spanking.

[Pascal Obry]

Petter a �crit :
> Of course I know I need to use GNAT.SOckets, but lazy as I am, I had

So if you are lazy use GNAT.Sockets as it has been told to you here.
Using GNAT.Sockets.Thin will give you more troubles in the long term as
upward compatibility is not guaranteed.

> got some code from elsewhere and cannot tell that person to do the job
> for me. 

?? That's what we call code review and quality management. If you don't
like it, don't complain and adjust your code to the new API.

It seems to me that Debra is changing her hairbrush just
> because she told me she would. I just don't want to eat the banana :
> ( And there are very many bananas  and hairbrushes around, A# doesn't
> work, GANTCOM is broken ...

Patches welcomed!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Taking another spanking.

[anon]

It seams that Adacore is switching its Sockets package from IPv4/6 to IPv6 
only.

        IPv4 
	    Send
 
        IPv6
            Sendto
            Sendmsg



For those that say you should not use GNAT.Sockets.Thin.

There are a few applications that can not be handled by GNAT.Sockets, so 
either the application must use "pragma Import" or better yet use 
GNAT.Sockets.Thin.  I think using GNAT.Sockets.Thin is better and is more 
portable.  That's because if GNAT changes the interface it is easier to find 
and adapt the code, than trying to find the new routine and pick the right 
parameters and types used by that altered or new imported routine.



In <6f8fcf5b-09d7-40b6-9ac3-ed7e9f228b89@t21g2000yqi.googlegroups.com>, Petter <petter_fryklund@hotmail.com> writes:
>I think I am an instance of Stevie Vai (see Frank Zappa discography).
>
>I just changed to GPL 2009 from way old ... on my portable. Now
>GNAT.Sockets.Thin has changed a lot. Send is nomore and I'll probably
>have to use Sendto. Documentation is very brief.... Why do we keep on
>punishing ourselfs with these small unneeded changes.
>
>No more hiarbrush treatment please, Debra!

Re: Taking another spanking.

[sjw]

On Jun 3, 11:40 am, a...@anon.org (anon) wrote:

> For those that say you should not use GNAT.Sockets.Thin.

It's more that people shouldn't expect something declared to be
subject to change and private to remain as it used to be!

We built code based on GNAT's representation of 1 Jan 1970 in
Ada.Calendar.Time being zero. That's no longer the case, since Ada
2005's extension of the supported range of Ada.Calendar.Time. Too bad!
(the actual change to our code is pretty small, even so).

Re: Taking another spanking.

[anon]

When the Ada 83 became Ada 95 and now Ada 2005, it was known that changes 
would occur and these changes could be major. Just look at the MAJOR changes 
from Ada 83 to Ada 95. Now as for GNAT, GNAT give the programmers spoilers, 
between Ada 83 to Ada 95 and between 95 and Ada 2005 everybody had 
a working insider view of next version of Ada before its time.

From GNAT-1.83 to GNAT GPL 2008, the GNAT.Sockets, GNAT.Sockets.Thin 
and GNAT.Sockets.Constants packages were basically static only adding IPv6 
when it became available.  But since Window 7 is dropping IPv4 support a 
change is needed, actually it time for all programmers to move to IPv6. 
And GNAT is just given another spoiler since the GNAT version (Adacore 
release) for Window 7 will not come out until summer of 2010. 

But some like you talk that Ada should NEVER go beyond the RM and use 
Sockets, that is just wrong. Ada like all languages must be able to adapt and 
handle all devices both physical as well as virtual to be compatible to be used 
for all applications. Else its the death by limitation of the language. 

But then again, I think it was you that stated last year that if you rewrote 
or updated "C2Ada" you would never write the program in Ada! 


In <0ca1d49a-c13b-4dad-907e-982bcfb6c01f@q2g2000vbr.googlegroups.com>, sjw <simon.j.wright@mac.com> writes:
>On Jun 3, 11:40=A0am, a...@anon.org (anon) wrote:
>
>> For those that say you should not use GNAT.Sockets.Thin.
>
>It's more that people shouldn't expect something declared to be
>subject to change and private to remain as it used to be!
>
>We built code based on GNAT's representation of 1 Jan 1970 in
>Ada.Calendar.Time being zero. That's no longer the case, since Ada
>2005's extension of the supported range of Ada.Calendar.Time. Too bad!
>(the actual change to our code is pretty small, even so).

Re: Taking another spanking.

[Per Sandberg]

To fill in from an GNATPro user.

In the recent versions of gnatpro gcc and g++ got a new switch 
"-fdump-ada-spec" that will generate Ada specs from a C or C++ header files.
/Very convenient and it works like a dream when interfacing libraries 
with interfaces specified in the languages C and C++.
/Per

sjw wrote:
> On Jun 4, 1:43 am, a...@anon.org (anon) wrote:
> 
> Are you really just one person, or a collective? Sometimes you're
> sensible, sometimes plain bananas .. this time on the sensible side. I
> wish you'd admit to your real name!
> 
>> But some like you talk that Ada should NEVER go beyond the RM and use
>> Sockets, that is just wrong. Ada like all languages must be able to adapt and
>> handle all devices both physical as well as virtual to be compatible to be used
>> for all applications. Else its the death by limitation of the language.
> 
> Nothing wrong with GNAT.Sockets, use it all the time. But see no need
> to go the .Thin level. If I did, I wouldn't moan at AdaCore for
> changing it.
> 
>> But then again, I think it was you that stated last year that if you rewrote
>> or updated "C2Ada" you would never write the program in Ada!
> 
> c2ada is written in C, with some Python that I haven't had to
> understand yet (and which seem to be related to converting C _bodies_
> to Ada, not a sensible project or one likely to lead to success IMO).
> 
> So I might have said that I would rewrite it in Ada; but now, given
> that AdaCore have announced a conversion facility, I think I'll find
> something more worth while.

Re: Taking another spanking.

[sjw]

On Jun 4, 1:43 am, a...@anon.org (anon) wrote:

Are you really just one person, or a collective? Sometimes you're
sensible, sometimes plain bananas .. this time on the sensible side. I
wish you'd admit to your real name!

> But some like you talk that Ada should NEVER go beyond the RM and use
> Sockets, that is just wrong. Ada like all languages must be able to adapt and
> handle all devices both physical as well as virtual to be compatible to be used
> for all applications. Else its the death by limitation of the language.

Nothing wrong with GNAT.Sockets, use it all the time. But see no need
to go the .Thin level. If I did, I wouldn't moan at AdaCore for
changing it.

> But then again, I think it was you that stated last year that if you rewrote
> or updated "C2Ada" you would never write the program in Ada!

c2ada is written in C, with some Python that I haven't had to
understand yet (and which seem to be related to converting C _bodies_
to Ada, not a sensible project or one likely to lead to success IMO).

So I might have said that I would rewrite it in Ada; but now, given
that AdaCore have announced a conversion facility, I think I'll find
something more worth while.

Re: Taking another spanking.

[anon]

As for GNAT.Sockets.Thin -- I expand what "Robert Dewar" the CEO and 
one of the chief authors of GNAT said in Aug 3, 1996 at 3:00 am.  
	"If you can do it in C, you can do it in Ada! Use pragma Import 
         and call exactly the same routines that you would call from C." 

In this case, I expand that to: Why not use GNAT package GNAT.Sockets.Thin 
instead of re-creating a few "pragma import" or re-creating the Thin package. 
Having GNAT.Sockets.Thin is more common and makes better code design then 
each file or package having its own set of "pragma import" statements.  And 
then when IPv4 is completely phase out by all OS it is easier to write a 
GNAT.Sockets.Thin sub-class package that simulates the IPv4 routines which 
calls the IPv6 only GNAT.Sockets.Thin. Then all that is needed is to alter the 
with/use "GNAT.Sockets.Thin" statements to the new sub-class package 
name.  That is, until one has the time or need to rewrite the program to use 
the IPv6 only routines in which the the program can again use 
"GNAT.Sockets.Thin". That is, until the next update to the IP, or more likey 
a replacement to IPv6 protocol.

Plus, using "GNAT.Sockets" is great if your working with Streams or on the 
the client side. But if your creating non-stream server class appplication, its 
may be easier to go low-level (Thin). Especially if the program requires other 
low-level components such as ports or interrupts. Or includes a scanner or 
translation subsystem, before processing the data. 

As for Adacore updating it, the only problem that I see is that each year 
they have added more and more C code to GNAT system.  In GNAT system
you can look at the files "socket.c" and "gsocket.h".  In GNAT 3.15p, they 
used only Ada code. So, they should follow the older design and their own 
CEO rule and use Ada with "pragma import" statements only and skip the 
C code completely. 

Now since, AdaCore has announced a conversion facility, why are they still 
using C code in the GNAT system? And why do they expand the amount of C 
in every additional yearly release (now at 71 c/h files). Starting with the 
conversion to GCC-4.x (a GCC major design change), and introduction of Ada 
2005 they should of deleted all C coding in all current versions of GNAT. 
When they re-wrote "GIGI" backend routine to use GCC-4.x they should of 
use Ada and "pragma Imports" into the GCC compiler system only, but the 
"GIGI" routine is all most 7800 lines of C code. With Adacore using multiple 
files (like, the multiple system*.ads), and with them using the preprocessor 
(GNATPREP) to convert a multi-OS use single file into the packages that is 
needed for that OS and that version of GNAT, they could delete all C coding. 
So, what type of conversion facility is Adacore using, from looking at that 
the "C-like conditional expression" statement in the 2009 version of GNAT 
I would say that Adacore is trying to include or absob the C language into 
the Ada language, but if that's what they want they should create a new 
language like "Programming Language 2 or PL/2". Where "PL/2" would be 
created from Ada, C, and JAVA.

For the "C2Ada", program and using Python, well Python or any other language 
should never had been used. Plus, I think most would prefer not to wait for 
Adacore to post a C-to-Ada program or a compiler that merges C like structure 
into Ada.

And to show it is possible to use Ada only. Last year when it was made clear 
that GLADE was PHASE OUT, I created a Ada version Sun RPCGEN to takes the 
SUN RPC script file which has a C like structure and creates the Ada version 
RPC stubs. I used only GNAT 3.15p Ada, which only had one problem and that 
was Ada 95 does not contain "UNION"s. Later I create the SUN RPC subsystem 
which uses System.RPC. It works great in my Ada OS tests. 

Note: Why SUN RPC. Well, its non-Microsoft and non-JAVA based. Then there 
is lot of documentation and examples to work with. Plus, it is a RFC standard. 


In <bb5ed272-2e72-4d39-8855-242b8a12e4b1@m19g2000yqk.googlegroups.com>, sjw <simon.j.wright@mac.com> writes:
>On Jun 4, 1:43=A0am, a...@anon.org (anon) wrote:
>
>Are you really just one person, or a collective? Sometimes you're
>sensible, sometimes plain bananas .. this time on the sensible side. I
>wish you'd admit to your real name!
>
>> But some like you talk that Ada should NEVER go beyond the RM and use
>> Sockets, that is just wrong. Ada like all languages must be able to adapt=
> and
>> handle all devices both physical as well as virtual to be compatible to b=
>e used
>> for all applications. Else its the death by limitation of the language.
>
>Nothing wrong with GNAT.Sockets, use it all the time. But see no need
>to go the .Thin level. If I did, I wouldn't moan at AdaCore for
>changing it.
>
>> But then again, I think it was you that stated last year that if you rewr=
>ote
>> or updated "C2Ada" you would never write the program in Ada!
>
>c2ada is written in C, with some Python that I haven't had to
>understand yet (and which seem to be related to converting C _bodies_
>to Ada, not a sensible project or one likely to lead to success IMO).
>
>So I might have said that I would rewrite it in Ada; but now, given
>that AdaCore have announced a conversion facility, I think I'll find
>something more worth while.

Re: Taking another spanking.

[anon]

In using a special or extra program to provide that service is great.  But to 
embed that feature into the GNAT compiler is wrong.  It is saying that Ada is 
no long a viable language.

In <96fWl.3064$z92.689@newsfe23.ams2>, Per Sandberg <per.sandberg@bredband.net> writes:
>To fill in from an GNATPro user.
>
>In the recent versions of gnatpro gcc and g++ got a new switch 
>"-fdump-ada-spec" that will generate Ada specs from a C or C++ header files.
>/Very convenient and it works like a dream when interfacing libraries 
>with interfaces specified in the languages C and C++.
>/Per
>
>sjw wrote:
>> On Jun 4, 1:43 am, a...@anon.org (anon) wrote:
>> 
>> Are you really just one person, or a collective? Sometimes you're
>> sensible, sometimes plain bananas .. this time on the sensible side. I
>> wish you'd admit to your real name!
>> 
>>> But some like you talk that Ada should NEVER go beyond the RM and use
>>> Sockets, that is just wrong. Ada like all languages must be able to adapt and
>>> handle all devices both physical as well as virtual to be compatible to be used
>>> for all applications. Else its the death by limitation of the language.
>> 
>> Nothing wrong with GNAT.Sockets, use it all the time. But see no need
>> to go the .Thin level. If I did, I wouldn't moan at AdaCore for
>> changing it.
>> 
>>> But then again, I think it was you that stated last year that if you rewrote
>>> or updated "C2Ada" you would never write the program in Ada!
>> 
>> c2ada is written in C, with some Python that I haven't had to
>> understand yet (and which seem to be related to converting C _bodies_
>> to Ada, not a sensible project or one likely to lead to success IMO).
>> 
>> So I might have said that I would rewrite it in Ada; but now, given
>> that AdaCore have announced a conversion facility, I think I'll find
>> something more worth while.

Re: Taking another spanking.

[sjw]

On Jun 5, 8:25 pm, Per Sandberg <per.sandb...@bredband.net> wrote:
> To fill in from an GNATPro user.
>
> In the recent versions of gnatpro gcc and g++ got a new switch
> "-fdump-ada-spec" that will generate Ada specs from a C or C++ header files.
> /Very convenient and it works like a dream when interfacing libraries
> with interfaces specified in the languages C and C++.

This feature is in gnat-gpl-2009 too.

Re: Taking another spanking.

[Georg Bauhaus]

anon wrote:
> As for GNAT.Sockets.Thin -- I expand what "Robert Dewar" the CEO and 
> one of the chief authors of GNAT said in Aug 3, 1996 at 3:00 am.  
> 	"If you can do it in C, you can do it in Ada! Use pragma Import 
>          and call exactly the same routines that you would call from C." 
> 
> In this case, I expand that to: Why not use GNAT package GNAT.Sockets.Thin 
> instead of re-creating a few "pragma import" or re-creating the Thin package. 

GNAT.Sockets is vendor specific, sockets aren't as far as Ada goes.
GNAT.Sockets.Thin is not only vendor specific, the vendor says you
should not use it.
Pragma Import is standard Ada.  POSIX is a standard.
If sockets are ubiquituous, I'd think that the community
of Ada programmers might like vendor neutral sockets code.
Much more than it would like, say, IBM.Rational.Sockets.NonGNAT,
or GNAT.Sockets.Thin.

Re: Taking another spanking.

[tmoran]

>of Ada programmers might like vendor neutral sockets code.
>Much more than it would like, say, IBM.Rational.Sockets.NonGNAT,
>or GNAT.Sockets.Thin.
   Claw.Sockets runs under Windows with Aonix, Gnat, Janus, and Rational
compilers.

Re: Taking another spanking.

[anon]

GNAT uses both Ada and C code to create it RTL.  If they were truly serious 
about programmers not using the GNAT.Sockets.Thin package they would simply 
replace the Ada version of Thin with a C version.  And may be the body of 
GNAT.Sockets.  

The deal is if your partition calls for streams type of Sockets then use 
GNAT.Sockets only.  But if a package needs low_level access to the sockets 
interface such as creating a non-standard or security protocol, use 
GNAT.Sockets.Thin only and rebuild a replacement Sockets package. This is 
from a set of emails back in the late 1990s with Adacore.

And besides why recreate the "pragma Import" from the Thin package in order 
to use those low_level routines. That just causes bad programming habits.

Plus with the concept that the GNAT 2009 compiler including C and C like 
structures, I think Adacore wants the new programmers to act as if they if 
they are programming in C/C++ with the style of C/C++. Which means any 
thing goes! 

Comments are for the legal department! No programmer should care about the 
comments in any Ada packages, because as most of the posters here including 
Simon, Martin and yourself have said, Ada programmer must use the Ada RM 
for any reference. So, where is the additional RM sections that not only 
includes the Sockets, but explain the other device packages such as Printer, 
Serial, USB, etc?



In <4a2a6ef5$0$30223$9b4e6d93@newsspool1.arcor-online.net>, Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:
>anon wrote:
>> As for GNAT.Sockets.Thin -- I expand what "Robert Dewar" the CEO and 
>> one of the chief authors of GNAT said in Aug 3, 1996 at 3:00 am.  
>> 	"If you can do it in C, you can do it in Ada! Use pragma Import 
>>          and call exactly the same routines that you would call from C." 
>> 
>> In this case, I expand that to: Why not use GNAT package GNAT.Sockets.Thin 
>> instead of re-creating a few "pragma import" or re-creating the Thin package. 
>
>GNAT.Sockets is vendor specific, sockets aren't as far as Ada goes.
>GNAT.Sockets.Thin is not only vendor specific, the vendor says you
>should not use it.
>Pragma Import is standard Ada.  POSIX is a standard.
>If sockets are ubiquituous, I'd think that the community
>of Ada programmers might like vendor neutral sockets code.
>Much more than it would like, say, IBM.Rational.Sockets.NonGNAT,
>or GNAT.Sockets.Thin.

Re: Taking another spanking.

[Randy Brukardt]

"Georg Bauhaus" <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> wrote in 
message news:4a2a6ef5$0$30223$9b4e6d93@newsspool1.arcor-online.net...
...
>> In this case, I expand that to: Why not use GNAT package 
>> GNAT.Sockets.Thin
>> instead of re-creating a few "pragma import" or re-creating the Thin 
>> package.
>
> GNAT.Sockets is vendor specific, sockets aren't as far as Ada goes.
> GNAT.Sockets.Thin is not only vendor specific, the vendor says you
> should not use it.

Packages like GNAT.Sockets.Thin are supposed to be private packages; then 
users *couldn't* use it (it would be illegal to reference in a with clause). 
Indeed, the reason that "private with" was added in Ada 2005 was to make 
that more possible.

It's always better to use the language facilities to prevent misuse rather 
than trust users to read and follow the documentation. There's always 
someone who won't follow the written directions! (That's why almost all of 
the Claw implementation articfacts are hidden in private parts and private 
packages.)

                                          Randy.

Re: Taking another spanking.

[sjw]

On Jun 8, 11:40 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> Packages like GNAT.Sockets.Thin are supposed to be private packages; then
> users *couldn't* use it (it would be illegal to reference in a with clause).
> Indeed, the reason that "private with" was added in Ada 2005 was to make
> that more possible.

Even in Ada95 it could have been 'private package GNAT.Sockets.Thin'.
At any rate in the Mac OS X version I have here. This may or may not
have been a design decision, even if not I suspect that AdaCore have
too many customers using the low-level interfce for a change to be
easy.