Ada and Internet stuff

Ada and Internet stuff

[Darren New]

I'm wondering how many people use Ada for Internet things. Do people
write servers in Ada, or clients, or libraries? I note a lack of things
like XML, MIME, base64, etc on AdaPower. If I started building such
libraries, would anyone care? Would anyone use them?  Just
wondering...   

(FWIW, I'm good at internet stuff, and a novice at Ada, but I think I'd
like Ada a lot.)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada and Internet stuff

[Ted Dennison]

In article <3B86A962.33CFA1A8@san.rr.com>, Darren New says...
>
>I'm wondering how many people use Ada for Internet things. Do people
>write servers in Ada, or clients, or libraries? I note a lack of things
>like XML, MIME, base64, etc on AdaPower. If I started building such
>libraries, would anyone care? Would anyone use them?  Just
>wondering...   

Well, there's a couple of internet related projects at
http://libre.act-europe.fr/ :

AWS, the embeddable Ada Web Server - http://libre.act-europe.fr/aws/
and XML/Ada - http://libre.act-europe.fr/xmlada/ . 

By all means, do more. Some have expressed displeasure at the full GPL license
XML/Ada uses (any client s/w has to use the GPL too), so that might even be a
productive area too.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Ada and Internet stuff

[Pascal Obry]

Ted Dennison<dennison@telepath.com> writes:

> In article <3B86A962.33CFA1A8@san.rr.com>, Darren New says...
> >
> >I'm wondering how many people use Ada for Internet things. Do people
> >write servers in Ada, or clients, or libraries? I note a lack of things
> >like XML, MIME, base64, etc on AdaPower. If I started building such
> >libraries, would anyone care? Would anyone use them?  Just
> >wondering...   
> 
> Well, there's a couple of internet related projects at
> http://libre.act-europe.fr/ :
> 
> AWS, the embeddable Ada Web Server - http://libre.act-europe.fr/aws/

As a side note, in AWS there is a base64 encoding as this is needed to
transfer binary data.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Ada and Internet stuff

[Ehud Lamm]

It is worth mentioning that AWS also provides for creating web clients. It
is quite easy to write agents of sorts (filters, downloaders etc.). I've
played with this quite a lot.

It took me some time to install the XmlAda library, but it also looks
useful.

There are also methods for binding to COM objects so you can play with
those.

(The GNAT Regexp tools are also useful for this problem domain).

Ehud Lamm

Re: Ada and Internet stuff

[David Botton]

It is also worth mentioning that on Win32 all the Internet tools you could
want are already available from the OS through COM using GNATCOM.

Almost every day I use the MSXML object to handle all my XML processing
needs. You can also control IE, use the FTP/HTTP controls that comes with
the OS, etc.

It is certainly nice to have native Ada components of this nature, but in
general I prefer to use the OS's capabilities when possible.

David Botton

----- Original Message -----
From: "Ehud Lamm" <mslamm@mscc.huji.ac.il>
> There are also methods for binding to COM objects so you can play with
> those.

Re: Ada and Internet stuff

[Pascal Obry]

"David Botton" <David@Botton.com> writes:

> It is certainly nice to have native Ada components of this nature, but in
> general I prefer to use the OS's capabilities when possible.

Of course, but for me having native Ada components is not the point I want to
have portable ones. I just don't want to be tied to a specific platform :)

Also all the nice MS components are changing all the time and there is not the
same ones installed on all computers... You guess, this could be a real
nightmare !!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Ada and Internet stuff

[David Botton]

That is the beauty about COM. Code written for IE 3.0 still works today
against IE 6.0. Same goes for the FTP components and just about every other
component. The idea of "the moving" APIs has not been an issue for years (at
least not at the COM/DCOM level :-)

Portability is overated...... too many times I have seen sloppy product do
to "portability" when it was clearly known from the start that the product
would be running on a single platform. Even when a product needs to truly be
cross platform, it often makes more sense to abstract out the components and
APIs used and be native on each platform. A little more work, but much more
professional results.

David Botton

"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:uzo8mzhnz.fsf@wanadoo.fr...
> Of course, but for me having native Ada components is not the point I want
to
> have portable ones. I just don't want to be tied to a specific platform :)
>
> Also all the nice MS components are changing all the time and there is not
the
> same ones installed on all computers... You guess, this could be a real
> nightmare !!

Re: Ada and Internet stuff

[Ehud Lamm]

My main concren is ease of use.
I am mainly thinking about small projects, and student exercises, so
partability isn't a major issue.

I am still not sure what's the easiest way to handle XML is such a context.
What would you guys choose in such a case?

Ehud

Re: Ada and Internet stuff

[Pascal Obry]

Darren New <dnew@san.rr.com> writes:

> I'm wondering how many people use Ada for Internet things. Do people

I do. Have a look at AWS a complete Internet framework from Dmitriy
Anisimkov and I. This has been used in real projects some of them stressing 
the server a lot with ~50 requests per second !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Ada and Internet stuff

[Darren New]

Pascal Obry wrote:
> 
> Darren New <dnew@san.rr.com> writes:
> 
> > I'm wondering how many people use Ada for Internet things. Do people
> 
> I do. Have a look at AWS a complete Internet framework from Dmitriy
> Anisimkov and I. This has been used in real projects some of them stressing
> the server a lot with ~50 requests per second !

I did save that announcement. I plan to go though it later. :-) Thanks!

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada and Internet stuff

[Larry Kilgallen]

In article <3B86A962.33CFA1A8@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> I'm wondering how many people use Ada for Internet things. Do people
> write servers in Ada, or clients, or libraries? I note a lack of things
> like XML, MIME, base64, etc on AdaPower. If I started building such
> libraries, would anyone care? Would anyone use them?  Just
> wondering...   

Yes, people care.  There is an Ada Web Server, intended not for general
purpose web server purposes but rather to allow your program to serve
its own pages (such as for remote control purposes).

> (FWIW, I'm good at internet stuff, and a novice at Ada, but I think I'd
> like Ada a lot.)

Another data point is the degree to which people in this newsgroup
fume when their web browser crashes, since they know it is quite
likely to be a buffer overflow resulting from poor programming
practices.  Of course writing something in Ada does not automatically
eliminate bugs, but it does help.

Re: Ada and Internet stuff

[Marc A. Criley]

Darren New wrote:
> 
> I'm wondering how many people use Ada for Internet things. Do people
> write servers in Ada, or clients, or libraries? I note a lack of things
> like XML, MIME, base64, etc on AdaPower. If I started building such
> libraries, would anyone care? Would anyone use them?  Just
> wondering...
> 
> (FWIW, I'm good at internet stuff, and a novice at Ada, but I think I'd
> like Ada a lot.)

Please do delve into writing internet stuff in Ada!  From time to time
I've whined about Ada developers announcing they're going write Yet
Another Data Structures collection, while there's a whole lot of areas
out there where Ada has no software presence.

Dave Botton did wonders with making Ada much easier to employ in the MS
Windows environment; there's plenty of opportunity for someone to do the
same with Internet technologies.

Marc A. Criley

Re: Ada and Internet stuff

[Pascal Obry]

"Marc A. Criley" <mcqada@earthlink.net> writes:

> Dave Botton did wonders with making Ada much easier to employ in the MS
> Windows environment; there's plenty of opportunity for someone to do the
> same with Internet technologies.

Yep ! For example it would be nice to have a simple FTP client in Ada to be
able to store data from time to time in a program. For example AXIS Web Camera
can ftp their pictures using FTP. This is low-level Internet stuff, but quite
useful... of course there are zillions of other things to do :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Ada and Internet stuff

[tmoran]

>I'm wondering how many people use Ada for Internet things. Do people
>write servers in Ada, or clients, or libraries? I note a lack of things
>like XML, MIME, base64, etc on AdaPower. If I started building such
>libraries, would anyone care? Would anyone use them?  Just
>wondering...
  I do.  But a base64 translator, for instance, seems too simple for
www.adapower.com, and at the other end a rather specific web
crawler/scanner seems too specialized.  But perhaps I misjudge.

Re: Ada and Internet stuff

[Tarjei T. Jensen]

tmoran@acm.org wrote in message ...
>>I'm wondering how many people use Ada for Internet things. Do people
>>write servers in Ada, or clients, or libraries? I note a lack of things
>>like XML, MIME, base64, etc on AdaPower. If I started building such
>>libraries, would anyone care? Would anyone use them?  Just
>>wondering...
>  I do.  But a base64 translator, for instance, seems too simple for
>www.adapower.com, and at the other end a rather specific web
>crawler/scanner seems too specialized.  But perhaps I misjudge.

Everything is useful. After all you are increasing the Ada presence.


Greetings,

Re: Ada and Internet stuff

[Ehud Lamm]

Tarjei T. Jensen <tarjei.jensen@kvaerner.com> wrote in message
news:9md9g8$7ah2@news.kvaerner.com...
>
> tmoran@acm.org wrote in message ...
> >  I do.  But a base64 translator, for instance, seems too simple for
> >www.adapower.com, and at the other end a rather specific web
> >crawler/scanner seems too specialized.  But perhaps I misjudge.
>
> Everything is useful. After all you are increasing the Ada presence.
>
>

In fact small components are usually easier to reuse, so they may be
better...

Ehud

Re: Ada and Internet stuff

[Pascal Obry]

It will be also very nice to have a client LDAP API. This has been on my TODO
list for some time but I won't have time to work on this for a long time.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Ada and Internet stuff

[David Botton]

I don't see either as too small or too large.

David Botton

<tmoran@acm.org> wrote in message
news:tGhi7.17725$sa.8914875@news1.rdc1.sfba.home.com...
> >I'm wondering how many people use Ada for Internet things. Do people
> >write servers in Ada, or clients, or libraries? I note a lack of things
> >like XML, MIME, base64, etc on AdaPower. If I started building such
> >libraries, would anyone care? Would anyone use them?  Just
> >wondering...
>   I do.  But a base64 translator, for instance, seems too simple for
> www.adapower.com, and at the other end a rather specific web
> crawler/scanner seems too specialized.  But perhaps I misjudge.

Re: Ada and Internet stuff

[tmoran]

> >   I do.  But a base64 translator, for instance, seems too simple for
> I don't see either as too small or too large.
>
> David Botton
  David has posted base64 encode/decode source code at
www.adapower.com/alg/base64.html
(That was pretty fast, eh? :)

Re: Ada and Internet stuff

[Darren New]

>   David has posted base64 encode/decode source code at
> www.adapower.com/alg/base64.html
> (That was pretty fast, eh? :)

Cool! I definitely want to read this a few times and learn more Ada. :-)
Thanks!  (My primary goal in writing the base64 stuff was practicing
simple Ada stuff.)

I'm wondering something. 

Do people generally treat Ada.Streams.Stream_Element_Array as the
equivalent of an array of octets without further checking? 

Also, what's the mechanism for dealing with things like UTF-8? I.e., I'm
assuming that Wide_String is a string of UTF or other non-ASCII
characters. Does one simply read a file with the wide character reading
routines and assume that the runtime will do the right translations?
E.g., how would one properly read an XML (default of UTF-8 encoding)
file?

As for the base64 stuff, I'd suggest the following additions:

  -- Target'length must be at least:
  -- Output_Quad_Count: constant := (Source'length + 2) / 3;
  -- Output_Byte_Count: constant := 4 * Output_Quad_Count;
  -- Target'length = Output_Byte_Count + 2 * (Output_Byte_Count / 76)

This should be a function. :-) Probably, it would be best to have a
function that takes an input length and returns the output length in
both directions, so you can allocate your buffers properly before
calling the functions.

Also, a function where you can say "tell me how many characters of
base64 text I should pass in to get as close to N octets back" and "how
many octets will give me just under N characters back" would be useful.
I.e., if I have a file that I'm outputting the big base64-encoded file
out to, how much text do I read and pass to the decoder in one chunk,
and in the other direction, if I have String(1..100_000) to encode into,
how many bytes of raw data is that?

I'd be happy to tackle this. :-)


-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada and Internet stuff

[David Botton]

When you have some thing, send it to me and I'll make sure to add it along
with the Base 64 article.

----- Original Message -----
From: "Darren New" <dnew@san.rr.com>

> I'd be happy to tackle this. :-)

Re: Ada and Internet stuff

[Ted Dennison]

In article <3B8D181E.8C9523D@san.rr.com>, Darren New says...
>Do people generally treat Ada.Streams.Stream_Element_Array as the
>equivalent of an array of octets without further checking? 

That's most likely what it is, but it could easily be 32-bit or 64-bit objects.
Rather than AssUMe anything, its best to calculate it using
Ada.Streams.Stream_Element'size.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Ada and Internet stuff

[tmoran]

> Do people generally treat Ada.Streams.Stream_Element_Array as the
> equivalent of an array of octets without further checking?
  They shouldn't.  Base64 encoding conceptually takes 24 bit chunks
of input and encodes it in 4 output text characters.  But the code
to automagically adjust to Stream_Elements that aren't 8 bits wide
would, I suspect, be substantally less clear, and rarely used, so
my base64 routine doesn't do it.  I thought about putting in
a test that Stream_Element'size=8, but decided, again for simplicity
and clarity vs frequency of use, to settle for a comment instead.
Full generality might be an interesting exercise.

> Also, what's the mechanism for dealing with things like UTF-8?
  Base64 is specifically designed to work across various character
encodings.  Thus an 'A' means 6 bits of zeroes, regardless of how
that 'A' is represented.  You *should* be able to replace String
with Wide_String and Character with Wide_Character appropriately
and have it work.  Of course your 24 bits of input would then be
64, rather than 32 bits, encoded, for an expansion factor of 2.66,
which would rather argue against it.

>   -- Target'length must be at least:
>   -- Output_Quad_Count: constant := (Source'length + 2) / 3;
>   -- Output_Byte_Count: constant := 4 * Output_Quad_Count;
>   -- Target'length = Output_Byte_Count + 2 * (Output_Byte_Count / 76)
>
> This should be a function. :-) Probably, it would be best to have a
> function that takes an input length and returns the output length in
> both directions, so you can allocate your buffers properly before
> calling the functions.
  Extra whitespace and missing line breaks are both allowed in encoded
data, so you can't tell without looking at it, ie running the decoding,
just what it will decode into.  No such problem on encoding.

You could make
    function Encode(X : Stream_Element_Array) return String;
    function Decode(S : String) return Stream_Element_Array;
and let them generate and return the correct size results.  That's
not terribly hard but is surely less speedy, which may matter.

> I'd be happy to tackle this. :-)
  Looking forward to it!

Re: Ada and Internet stuff

[Darren New]

> > Also, what's the mechanism for dealing with things like UTF-8?
>   Base64 is specifically designed to work across various character
> encodings.  Thus an 'A' means 6 bits of zeroes, regardless of how
> that 'A' is represented.

Actually, I think it's that ASCII 64 means 6 bits of zeros, but I'd have
to double-check the RFC specifically. :-) But I understand what you're
saying, that the text-io routines are responsible for mapping 'A' in the
source to 'A' in your input file.

>  You *should* be able to replace String
> with Wide_String and Character with Wide_Character appropriately
> and have it work.  Of course your 24 bits of input would then be
> 64, rather than 32 bits, encoded, for an expansion factor of 2.66,
> which would rather argue against it.

Sorry. That second question was kind of a non-sequitar. Not asking about
its relation to base64 as such, but in general about character encoding
problems. Like, if I were to deal with XML, how could I expect to handle
wide characters in the input stream?

> >   -- Target'length must be at least:
> >   -- Output_Quad_Count: constant := (Source'length + 2) / 3;
> >   -- Output_Byte_Count: constant := 4 * Output_Quad_Count;
> >   -- Target'length = Output_Byte_Count + 2 * (Output_Byte_Count / 76)
> >
> > This should be a function. :-) Probably, it would be best to have a
> > function that takes an input length and returns the output length in
> > both directions, so you can allocate your buffers properly before
> > calling the functions.
>   Extra whitespace and missing line breaks are both allowed in encoded
> data, so you can't tell without looking at it, ie running the decoding,
> just what it will decode into. 

True. But that might be useful anyway, even if inefficient.

> No such problem on encoding.

Yes.

> You could make
>     function Encode(X : Stream_Element_Array) return String;
>     function Decode(S : String) return Stream_Element_Array;
> and let them generate and return the correct size results.  That's
> not terribly hard but is surely less speedy, which may matter.

I was fiddling around with variable length strings, and I thought I
understood but I apparently don't. What would I *do* with such a
returned result? There isn't a variable I could assign it to, is there?
The only thing I could do is to pass it to some other routine that takes
unconstrained strings as an in parameter, yes?

I thought I could do
  declare
    s : String;
  begin
    s := Encode(yadda);
  end;
but that doesn't work. Bummer.

(Yes, as you can tell, I'm all the way up to "Hello World". :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada and Internet stuff

[tmoran]

> I thought I could do
>   declare
>     s : String;
>   begin
>     s := Encode(yadda);
>   end;
> but that doesn't work. Bummer.

But
  declare
    s : String := Encode(yadda);
  begin
    ada.text_io.put_line(s);  -- or whatever...
  end;
does work and is a standard Ada cliche.

Re: Ada and Internet stuff

[Darren New]

> But
>   declare
>     s : String := Encode(yadda);
>   begin
>     ada.text_io.put_line(s);  -- or whatever...
>   end;
> does work and is a standard Ada cliche.

Ah! Excellent! Yes, that's what I needed. Thanks!

I've been too long with really low-level (C) and really high-level (Tcl,
Java, etc) languages and this is going to take getting used to. :-)
Thanks!

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada and Internet stuff

[Ted Dennison]

In article <pQaj7.28143$sa.14123276@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>of input and encodes it in 4 output text characters.  But the code
>to automagically adjust to Stream_Elements that aren't 8 bits wide
>would, I suspect, be substantally less clear, and rarely used, so
>my base64 routine doesn't do it.  I thought about putting in
>a test that Stream_Element'size=8, but decided, again for simplicity
>and clarity vs frequency of use, to settle for a comment instead.
>Full generality might be an interesting exercise.

It only takes about 2 declarations to do this, and the resulting constants can
be named whatever is clearest for you (I usually use something like
"Foos_Per_Stream_Element").

But that assumes that you are using Unchecked_Conversion to convert between your
source data type and Stream_Element_Array. If you wanted to actually use
Stream_Element *as* your source data type, assuming a certian size would
probably simplify matters.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Ada and Internet stuff

[tmoran]

> >of input and encodes it in 4 output text characters.  But the code
> >to automagically adjust to Stream_Elements that aren't 8 bits wide
> >would, I suspect, be substantally less clear, and rarely used, so
>
> It only takes about 2 declarations to do this, and the resulting constants can
  For true generality, the obvious is something along the lines:
Finding the GCD of 24 and any number from 1 .. 64 takes at most 5
iterations.  So
a1 : constant := 24;
b1 : constant := Stream_Element'size;
...
a5 :=
b5 :=
will give the GCD.
LCM : constant := 24*Stream_Element'size/GCD;
-- LCM is the least common multiple of 24 bits and Stream_Element'size
type Encoded_24 is record
  a,b,c,d:Six_Bits;
end record;
for Encoding_Block use record
  a at 0 range 0 .. 5;
  b at 0 range 6 .. 11;
  c at 0 range 12 .. 17;
  d at 0 range 18 .. 23;
end record;
for Encoding_Block'size use 24;

type Encodable_Group is array(1 .. LCM/24) of Encodable_Block;
for Encodable_Group'size use LCM;

subtype To_Encode is Stream_Element_Array(1 .. LCM/Stream_Element'size);
for To_Encode'size use LCM;

function SE_To_Group is new Ada.Unchecked_Conversion
  (Source => To_Encode,
   Target => Encodable_Group);

The_Group : Encodable_Group;

Then encoding proceeds in chunks by collecting a slice,
si := Source'first;
while si <= Source'last loop
  The_Group := SE_To_Group(Source(si .. Stream_Element_Offset'min(
                                           Source'last,
                                           si+To_Encode'length-1))
                           & end_case_padding);
  for i in Encodable_Group'range loop
    Emit(Translation_Character(The_Group(i).a);
    exit when this is the last actual datum excluding padding;
    Emit(Translation_Character(The_Group(i).b);
    exit when this is the last actual datum excluding padding;
    Emit(Translation_Character(The_Group(i).c);
    exit when this is the last actual datum excluding padding;
    Emit(Translation_Character(The_Group(i).d);
    exit when this is the last actual datum excluding padding;
  end loop;
  si := si+To_Encode'length;
end loop;

That's large and obscure.  Is there a better way?

Re: Ada and Internet stuff

[tmoran]

Dealing with Stream_Element'size /= 8 raises the question: Is there
any required relationship between System.Storage_Unit (used in
record rep clause) and Stream_Element'size?

Re: Ada and Internet stuff

[Ted Dennison]

In article <VNCj7.33150$sa.16737236@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>
>Dealing with Stream_Element'size /= 8 raises the question: Is there
>any required relationship between System.Storage_Unit (used in
>record rep clause) and Stream_Element'size?

That's another good point. I don't think there is, but its probably almost
always going to be a reasonable assumption that Stream_Element'size is evenly
divisiable by Storage_Unit'size. It would be nice if this were in the standard
though. I can't see what good use anyone could make of the extra flexiblity.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Ada and Internet stuff

[Marin David Condic]

In practical terms, I'm not sure that it is terribly important. Most
computers these days have memory addressable in 8-bit bytes and
communications equipment that is oriented towards 8-bit bytes. I doubt that
there are many actual, validated implementations of Ada95 that *don't* use 8
bits for a stream element. In most applications, I would feel very
comfortable writing code that depended on Stream_Element being an 8-bit byte
and not worrying about absolute portability. Most apps are not ported to
begin with and the minority that are, typically are going to be ported to
similar machines. So if most machines use 8-bit bytes and most Ada
implementations use 8-bits for Stream_Element, is there really a practical
problem here?

I'd be interested to hear of a case where it did make a difference. I'm sure
a few exist, but I think its got to be a small percentage.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:CnMj7.465$F4.1099@www.newsranger.com...
> That's another good point. I don't think there is, but its probably almost
> always going to be a reasonable assumption that Stream_Element'size is
evenly
> divisiable by Storage_Unit'size. It would be nice if this were in the
standard
> though. I can't see what good use anyone could make of the extra
flexiblity.
>

Re: Ada and Internet stuff

[tmoran]

> communications equipment that is oriented towards 8-bit bytes. I doubt that
> there are many actual, validated implementations of Ada95 that *don't* use 8
> Bits for a stream element.
  But Randy Brukardt mentioned the other day an Ada 95 compiler on a
Univac machine with, IIRC, 36 bit words and 9 bit Stream_Element'size

> and not worrying about absolute portability. Most apps are not ported to
> begin with and the minority that are, typically are going to be ported to
> similar machines.
  I would normally agree, but here we are talking about Base64 encoding
for sending data over the internet, and I could certainly imagine wanting
to have my Univac machine able to talk with 8-bit byte machines.
  We are of course talking about mathematician's solutions here, not
engineer's solutions, so reasonableness is not relevant.  ;)

Re: Ada and Internet stuff

[Marin David Condic]

<tmoran@acm.org> wrote in message
news:UXPj7.34990$sa.18017430@news1.rdc1.sfba.home.com...
> > communications equipment that is oriented towards 8-bit bytes. I doubt
that
> > there are many actual, validated implementations of Ada95 that *don't*
use 8
> > Bits for a stream element.
>   But Randy Brukardt mentioned the other day an Ada 95 compiler on a
> Univac machine with, IIRC, 36 bit words and 9 bit Stream_Element'size
>

A single counter example does not a negation of the premise make. :-) I
*did* say "many actual, validated..." specifically because I'm sure there
are a few machines with odd sized words that might have an Ada
implementation. (I once got into an argument at a roulette table over what I
considered to be an "odd" number :-) The 1750a would be a prime candidate to
have Stream_Element be other than 8-bits and there are a few Ada
implentations for that machine. (Don't know if any are Ada95 though.) A
1750a with a Mil-Std-1553 communications bus would be quite happy having
Stream_Element be 16 bits.


> > and not worrying about absolute portability. Most apps are not ported to
> > begin with and the minority that are, typically are going to be ported
to
> > similar machines.
>   I would normally agree, but here we are talking about Base64 encoding
> for sending data over the internet, and I could certainly imagine wanting
> to have my Univac machine able to talk with 8-bit byte machines.
>   We are of course talking about mathematician's solutions here, not
> engineer's solutions, so reasonableness is not relevant.  ;)

They once lined up the math majors and the engineering majors at one end of
the football field. They put the cheerleaders at the other end and told the
math/engineering students they could cross half the distance, then stop,
then cross half the remaining distance, then stop, etc. and when they got to
the other end, they could make mad, passionate love to the cheerleaders. The
math students went home because they knew they couldn't get there. The
engineering students hung around because they figured they could get close
enough to get the job done. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada and Internet stuff

[tmoran]

>They once lined up the math majors and the engineering majors at one end of
  Impressive how a mathematician's idea 2.5K years later is so well known
it can be the basis for a joke.
Tom Moran
B.S. Mathematics ("but some of my best friends are engineers"  ;)

Re: Ada and Internet stuff

[Marin David Condic]

My ARM says: "type Stream_Element is mod implementation-defined;" which
would seem to suggest that an implementation is free to do anything they
please. I think it would be foolish to use anything other than a size that
lines up with your memory units and/or communications hardware and I'd be
willing to bet a fair amount of money that the majority of Ada
implementations are going to use 8-bit bytes for this.

I could see reasons why an implementation might want to make Stream_Element
8-bits no matter what the internal storage unit size is. Streams are going
to get used primarily for two things: Data in files and data along
communication links. The bulk of that is going to be in 8-bit bytes, given
the common trend in hardware. So I doubt there is any expressed or implied
relationship between Stream_Element and Storage_Unit.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:VNCj7.33150$sa.16737236@news1.rdc1.sfba.home.com...
> Dealing with Stream_Element'size /= 8 raises the question: Is there
> any required relationship between System.Storage_Unit (used in
> record rep clause) and Stream_Element'size?

Re: Ada and Internet stuff

[Ted Dennison]

In article <9mo3p9$22t$1@nh.pace.co.uk>, Marin David Condic says...
>8-bits no matter what the internal storage unit size is. Streams are going
>to get used primarily for two things: Data in files and data along
>communication links. The bulk of that is going to be in 8-bit bytes, given
>the common trend in hardware. So I doubt there is any expressed or implied

Well, I'd actually throw out the "data along communication links" one. Data put
in streams is just *not* portable, unless extreme efforts are put forth to make
it so (eg: GLADE).

Without a lot of effort, streams are really only useful for dealing with data
that is going to be read and written from Ada code on the same type of platform
compiled with the same compiler.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Ada and Internet stuff

[Marin David Condic]

The scenario you describe is kind of where I was going with communications
links. Probably the most popular link today would be TCP/IP - although I
hesitate to make the claim because someone will come out of the woodwork
challenging that. Certainly, its *one* of the most popular. Throw on top of
that Sockets and you have a very common way of building distributed apps.
Streams would be a natural way to connect to Sockets and you'd quite often
be building a Socket system with the same compiler on the same or similar
machines. So even though streams aren't highly portable (at least in terms
of using 'Input and 'Output - but that is by far not the only means of
getting data into a stream) in all communications apps, you could still see
that a lot of communications could be 8-bit byte oriented and streams would
want to hook up to that.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:v9Qj7.886$F4.5311@www.newsranger.com...
>
> Well, I'd actually throw out the "data along communication links" one.
Data put
> in streams is just *not* portable, unless extreme efforts are put forth to
make
> it so (eg: GLADE).
>
> Without a lot of effort, streams are really only useful for dealing with
data
> that is going to be read and written from Ada code on the same type of
platform
> compiled with the same compiler.
>

compile time Least Common Multiple, was Re: Ada and Internet stuff

[tmoran]

This code may be so bizarre as to be whimsical, but what the heck.

Problem: Given that Stream_Element'size is not necessarily 8 bits,
but can be assumed to be no greater than 128 bits, declare a
Stream_Element_Array subtype that is the shortest possible, but
a multiple of 24 bits.

-- Finding the GCD of 24 and any number from 1 .. 128 takes at most 5
-- iterations.

Larger1 : constant
  := boolean'pos(24 > Stream_Element'size) * 24
     + boolean'pos(24 <= Stream_Element'size) * Stream_Element'size;
Smaller1 : constant
  := boolean'pos(24 > Stream_Element'size) * Stream_Element'size
     + boolean'pos(24 <= Stream_Element'size) * 24;
R1 : constant := Larger1 mod Smaller1;
Is_Zero1 : constant := boolean'pos(R1 = 0);
GCD1 : constant := Is_Zero1 * Smaller1;

-- Once R(n) = 0, then Is_Zero(n) = 1 and Smaller(n+1) = 0
-- so R(n+1) = Larger(n+1) mod 1 = 0.  ie all following R(n+1 ...) = 0
-- and exactly one of Is_Zero(i) is non-zero

Larger2 : constant := Smaller1;
Smaller2 : constant := R1;
R2 : constant := Larger2 mod (Smaller2 + Is_Zero1);
Is_Zero2 : constant := boolean'pos(R2 = 0);
GCD2 : constant := Is_Zero2 * Smaller2;

Larger3 : constant := Smaller2;
Smaller3 : constant := R2;
R3 : constant := Larger3 mod (Smaller3 + Is_Zero2);
Is_Zero3 : constant := boolean'pos(R3 = 0);
GCD3 : constant := Is_Zero3 * Smaller3;

Larger4 : constant := Smaller3;
Smaller4 : constant := R3;
R4 : constant := Larger4 mod (Smaller4 + Is_Zero3);
Is_Zero4 : constant := boolean'pos(R4 = 0);
GCD4 : constant := Is_Zero4 * Smaller4;

Larger5 : constant := Smaller4;
Smaller5 : constant := R4;
R5 : constant := Larger5 mod (Smaller5 + Is_Zero4);
Is_Zero5 : constant := boolean'pos(R5 = 0);
GCD5 : constant := Is_Zero5 * Smaller5;

GCD : constant := GCD1+GCD2+GCD3+GCD4+GCD5;
-- will give the Greatest Common Divisor.

-- LCM is the least common multiple of 24 bits and Stream_Element'size
LCM : constant := 24*Stream_Element'size/GCD;

subtype To_Encode is Stream_Element_Array(1 .. LCM/Stream_Element'size);
-- To_Encode'size = LCM

Re: compile time Least Common Multiple, was Re: Ada and Internet stuff

[Ted Dennison]

In article <Z_Cj7.33172$sa.16763963@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>Problem: Given that Stream_Element'size is not necessarily 8 bits,
>but can be assumed to be no greater than 128 bits, declare a
>Stream_Element_Array subtype that is the shortest possible, but
>a multiple of 24 bits.

Why are you doing that, though? What you would generally want to figure out with
a stream is the minimum number of stream elements that will be required to cover
your data object's 'size.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: compile time Least Common Multiple, was Re: Ada and Internet stuff

[tmoran]

>Why are you doing that, though?  What you would generally want to figure
>out with a stream is the minimum number of stream elements that will be
>required to cover your data object's 'size.
  No, I'm not concerned here with converting from my data objects to stream
elements, but with encoding successive 24 bit chunks from a supplied
stream_element_array.  So I need an Unchecked_Conversion from a
subtype of stream_element_array of some length, to an array of 24 bit chunks,
so I need to know how many stream_element's are needed to make that
subtype an even multiple of 24 bits.

  type Twenty_Four_Bits is ...
  for Twenty_Four_Bits'size use 24;

  -- LCM is the Least Common Multiple of 24 and Stream_Element'size

  type Group_Of_Encodees is array(1 .. LCM/24) of Twenty_Four_Bits;
  pragma pack(Group_Of_Encodees);
  for Group_Of_Encodees'size use LCM;

  subtype Set_Of_Stream_Elements
  is Stream_Element_array(1 .. LCM/Stream_Element'size);
  -- assuming System.Storage_Unit = Stream_Element'size,
  -- then Set_Of_Stream_Elements'size = LCM = Group_Of_Encodees'size

  function SE_To_Groups is new Ada.Unchecked_Conversion -- LCM Bits to LCM Bits
    (Source=>Set_Of_Stream_Elements,
     Target=>Group_Of_Encodees);

  function Encode(Source : in Stream_Element_array) return String is
    The_Group : Group_Of_Encodees;
    si : Stream_Element_offset := Source'first;
  begin
    while si <= Source'last loop
      The_Group := SE_To_Groups(Source(si .. si+Group_Of_Encodees'length-1));
      for i in The_Group'range loop
        Encode_And_Emit(The_Group(i));  -- handle a set of 24 Bits
      end loop;
      ...

Re: compile time Least Common Multiple, was Re: Ada and Internet stuff

[Ted Dennison]

In article <UXPj7.34989$sa.18017934@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>
>>Why are you doing that, though?  What you would generally want to figure
>>out with a stream is the minimum number of stream elements that will be
>>required to cover your data object's 'size.
>  No, I'm not concerned here with converting from my data objects to stream
>elements, but with encoding successive 24 bit chunks from a supplied
>stream_element_array.  So I need an Unchecked_Conversion from a
>subtype of stream_element_array of some length, to an array of 24 bit chunks,
>so I need to know how many stream_element's are needed to make that
>subtype an even multiple of 24 bits.

OK. So I was talking encoding while you were talking decoding. But both
processes are reversible, so we are still back to the same issue. Unless they
match up perfectly, you are still going to have to deal with some extra leftover
slag bits in the source object (the stream element array). So you are *still*
going to have some waste at the end, which you will have to deal with by
calulating the minimum number of 24 bit chunks needed to store it (or maximum
that doesn't, depending on whether you want to save the leftover data, or try to
use it). Why not just do that for the whole array at once and be done with it?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com