4 beginner's questions on the PL Ada

4 beginner's questions on the PL Ada

[Emanuel Berg]

1. How do you make a constant in Ada? Can I make one that is
computed, for example an integer, set to Milliseconds(something)?

2. How do you get options from the CL? I.e., how do you do the C
argv in Ada?

3. Is it possible to get the task *name* (from the code) into a
string, programatically? That way, a generic procedure could be
used to communicate from tasks, with Put_Line, and without having
to hard code the task name every time.

4. How do you exit Ada altogether? For example, if there are 3
tasks, and one solves the problem, how can I terminate the whole
application at once? (Rather than sending messages to all the
tasks, "OK, we're done looking!")

Cheers

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Adam Beneschan]

On Friday, August 9, 2013 9:50:53 AM UTC-7, Emanuel Berg wrote:
> 1. How do you make a constant in Ada? Can I make one that is
> computed, for example an integer, set to Milliseconds(something)?

   Some_Constant : constant integer := <expression>.  The expression can be any expression that can be computed.

 
> 2. How do you get options from the CL? I.e., how do you do the C 
> argv in Ada?

Ada.Command_Line.  http://www.ada-auth.org/standards/12rm/html/RM-A-15.html

 
> 3. Is it possible to get the task *name* (from the code) into a 
> string, programatically? That way, a generic procedure could be
> used to communicate from tasks, with Put_Line, and without having
> to hard code the task name every time.

No, not really.  One thing to keep in mind is that Ada has task *types*, so that you can declare a task type and then start any number of tasks of that type.  And the tasks don't have to be associated with variables; you can start an array of tasks:

   type Task_Array is array (1 .. 10) of Task_Type;
   T : Task_Array;

will start 10 tasks, and they won't really have names.  Well, I guess you can call them T(1), T(2), ...  But tasks can also be record components, and you can have accesses to tasks, so there really isn't a concept of a "name" for a task.  So if you want to give tasks a name, you'll have to do this in the program.


> 4. How do you exit Ada altogether? For example, if there are 3 
> tasks, and one solves the problem, how can I terminate the whole
> application at once? (Rather than sending messages to all the
> tasks, "OK, we're done looking!")

I don't recommend having one task kill the entire program.  Ada allows you to define types that have finalization procedures associated with them (e.g. for a file, you might want a finalization procedure that makes sure any remaining data is flushed to the file).  Ada makes sure that when a procedure or task is exited, anything that needs to be finalized will be finalized.  Performing an operation that just exits the program suddenly will subvert that.  There's an "abort" statement to allow one task to terminate other tasks; that *does* ensure that finalization takes place.  But overall, I think it's better to do things cleanly; one way is to send a message to the other tasks with entry calls, but you can also create a variable (or a protected object) that's accessible to all tasks that they can check at certain points to see if they can quit.

                               -- Adam

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Adam Beneschan <adambeneschan@aol.com> writes:

> ...

Thanks a lot! Very helpful.

> but you can also create a variable (or a protected object)
> that's accessible to all tasks that they can check at certain
> points to see if they can quit.

And is this the solution you would recommend, for the general
case?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Alan Jump]

On Friday, August 9, 2013 10:16:12 AM UTC-7, Emanuel Berg wrote:
> Adam Beneschan <adambeneschan@aol.com> writes:
> 
> 
> 
> > ...
> 
> 
> 
> Thanks a lot! Very helpful.
> 
> 
> 
> > but you can also create a variable (or a protected object)
> 
> > that's accessible to all tasks that they can check at certain
> 
> > points to see if they can quit.
> 
> 
> 
> And is this the solution you would recommend, for the general
> 
> case?
> 
> 
> 
> -- 
> 
> Emanuel Berg - programmer (hire me! CV below)
> 
> computer projects: http://user.it.uu.se/~embe8573
> 
> internet activity: http://home.student.uu.se/embe8573

Barnes discusses this topic in chapter 10 of the paper "Safe and Secure Software - An Invitation to Ada 2012", which is available from Adacore at http://www.adacore.com/knowledge/technical-papers/safe-and-secure-software-an-invitation-to-ada-2012/. (Disclaimer: I am not affiliated with Adacore.) You have several options available, from barriers to select-accept statement pairs to semaphore variables. The software designer will need to decide on the correct approach based on the needs of the specific program.

 - -
73 de N5ILN
Alan

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Alan Jump <alan.jump@gmail.com> writes:

> You have several options available, from barriers to
> select-accept statement pairs to semaphore variables. The
> software designer will need to decide on the correct approach
> based on the needs of the specific program.

Yes, I don't doubt that, but I'm not working on a commercial
project here. Just trying to learn Ada, and was looking for a
benchmark answer. But if there isn't any, I'll have to read that
page, so thanks for the URL.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Jeffrey Carter]

On 08/09/2013 09:50 AM, Emanuel Berg wrote:
>
> 3. Is it possible to get the task *name* (from the code) into a
> string, programatically? That way, a generic procedure could be
> used to communicate from tasks, with Put_Line, and without having
> to hard code the task name every time.

It's possible to get a name using Ada.Tags.Expanded_Name. The question is what 
name you get for instances of a task type. GNAT gives the type name regardless 
of what kind of object the task is (simple object, array component, ...).

For an example of using Expanded_Name to obtain this name, see 
PragmARC.Reflection. The PragmAda Reusable Components are available from

http://pragmada.x10hosting.com/pragmarc.htm

-- 
Jeff Carter
"Well, a gala day is enough for me. I don't think
I can handle any more."
Duck Soup
93

Re: 4 beginner's questions on the PL Ada

[Simon Wright]

Emanuel Berg <embe8573@student.uu.se> writes:

> 4. How do you exit Ada altogether? For example, if there are 3 tasks,
> and one solves the problem, how can I terminate the whole application
> at once? (Rather than sending messages to all the tasks, "OK, we're
> done looking!")

One way is to abort the environment task[1], but as the reference says
"This approach to task termination is not recommended because it does
not allow tasks to terminate in a known state." If that's not a problem,
though ...

[1] http://rosettacode.org/wiki/Program_termination#Ada

Re: 4 beginner's questions on the PL Ada

[Adam Beneschan]

On Friday, August 9, 2013 11:29:31 AM UTC-7, Jeffrey Carter wrote:
> On 08/09/2013 09:50 AM, Emanuel Berg wrote:
> 
> > 3. Is it possible to get the task *name* (from the code) into a
> > string, programatically? That way, a generic procedure could be
> > used to communicate from tasks, with Put_Line, and without having
> > to hard code the task name every time.
> 
> It's possible to get a name using Ada.Tags.Expanded_Name.

Unless he's declaring a tagged task type (which is possible only by deriving it from an interface), there's nothing you can pass as a parameter to Expanded_Name.  If he's declaring a standalone task object (with an anonymous type), then I don't think there's a way to do this even if the task is derived from an interface.

                                 -- Adam

Re: 4 beginner's questions on the PL Ada

[Randy Brukardt]

"Adam Beneschan" <adambeneschan@aol.com> wrote in message 
news:03ea570b-e45f-4694-ab9b-3413c4770379@googlegroups.com...
On Friday, August 9, 2013 9:50:53 AM UTC-7, Emanuel Berg wrote:
...
>> 3. Is it possible to get the task *name* (from the code) into a
>> string, programatically? That way, a generic procedure could be
>> used to communicate from tasks, with Put_Line, and without having
>> to hard code the task name every time.
>
>No, not really.  One thing to keep in mind is that Ada has task *types*, so 
>that
>you can declare a task type and then start any number of tasks of that 
>type.
> And the tasks don't have to be associated with variables; you can start an
>array of tasks:

This is true, but Ada has a better solution for the original problem -- use 
the task identifier (which can be displayed, it has an Image function). 
Every task has a task id. See 
http://www.ada-auth.org/standards/12rm/html/RM-C-7-1.html.

                                    Randy.

Re: 4 beginner's questions on the PL Ada

[Jeffrey Carter]

On 08/09/2013 11:51 AM, Adam Beneschan wrote:
> On Friday, August 9, 2013 11:29:31 AM UTC-7, Jeffrey Carter wrote:
>> On 08/09/2013 09:50 AM, Emanuel Berg wrote:
>>
>>> 3. Is it possible to get the task *name* (from the code) into a string,
>>> programatically? That way, a generic procedure could be used to
>>> communicate from tasks, with Put_Line, and without having to hard code
>>> the task name every time.
>>
>> It's possible to get a name using Ada.Tags.Expanded_Name.
>
> Unless he's declaring a tagged task type (which is possible only by deriving
> it from an interface), there's nothing you can pass as a parameter to
> Expanded_Name.  If he's declaring a standalone task object (with an anonymous
> type), then I don't think there's a way to do this even if the task is
> derived from an interface.

You can declare a tagged type T in the task, and pass T'Tag to Expanded_Name. 
The task "name" is embedded in the resulting string, and is easy to isolate.

-- 
Jeff Carter
"Well, a gala day is enough for me. I don't think
I can handle any more."
Duck Soup
93

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> This is true, but Ada has a better solution for the original
> problem -- use the task identifier (which can be displayed, it
> has an Image function).  Every task has a task id. See
> http://www.ada-auth.org/standards/12rm/html/RM-C-7-1.html.

Yes! This works great:

with Ada.Task_Identification;
use  Ada.Task_Identification;

Task_Name : constant String := Image(Current_Task);

It produces output like

add_one_081838Dt

if the task is referred to as Add_One in the code.

The 8-char code that follows doesn't look like anything I
recognize. Is it a random string ID, or is is generated out of
anything sensible? If it always is 8 chars (and an underscore), I
guess I could simply trim the strings.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Jeffrey Carter]

On 08/09/2013 02:38 PM, Emanuel Berg wrote:
>
> Yes! This works great:
>
> with Ada.Task_Identification;
> use  Ada.Task_Identification;
>
> Task_Name : constant String := Image(Current_Task);
>
> It produces output like
>
> add_one_081838Dt
>
> if the task is referred to as Add_One in the code.

Not necessarily. First, this is only available in compilers that choose to 
implement the optional Annex C, Systems Programming, so this is non-portable. 
Second, the contents of the string returned by Image are implementation defined. 
One particular compiler uses the task name as part of the returned value, but 
others might not, so adding another layer of non-portability.

This may not be a concern for your present needs, though unnecessary 
non-portability usually bites you sooner or later in real projects. An advantage 
of the technique used in PragmARC.Reflection is that it is part of the core 
language, and so implemented by all compilers, and the resulting string is 
defined by the language, and so is the same for all compilers.

-- 
Jeff Carter
"Well, a gala day is enough for me. I don't think
I can handle any more."
Duck Soup
93

Re: 4 beginner's questions on the PL Ada

[Robert A Duff]

Emanuel Berg <embe8573@student.uu.se> writes:

> Task_Name : constant String := Image(Current_Task);
>
> It produces output like
>
> add_one_081838Dt

I doubt that "t".  ;-)

> if the task is referred to as Add_One in the code.
>
> The 8-char code that follows doesn't look like anything I
> recognize. Is it a random string ID, or is is generated out of
> anything sensible? If it always is 8 chars (and an underscore), I
> guess I could simply trim the strings.

It is the address of the task control block in hexadecimal,
which can vary in length -- e.g. on a 64-bit machine, it will
be 16 characters.

You should read the GNAT documentation on Task_Identification.Image.
Also doc for pragma Task_Name.

This is all GNAT-specific, of course.  Some other Ada compiler
can return something completely different.

Trimming the string might not be a good idea -- it uniquely identifies
the task in case the name part doesn't.  But it shouldn't be hard to
write a trimming function that won't crash on any Ada implementation,
while doing what you like for GNAT.

- Bob

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> This may not be a concern for your present needs, though
> unnecessary non-portability usually bites you sooner or later in
> real projects.

Yes, I agree.

> An advantage of the technique used in PragmARC.Reflection is
> that it is part of the core language, and so implemented by all
> compilers, and the resulting string is defined by the language,
> and so is the same for all compilers.

That sounds great. Unless it requires lots of code, why don't you
just show me how it is done? It is much easier understanding that
way.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

>> Task_Name : constant String := Image(Current_Task);
>>
>> It produces output like
>>
>> add_one_081838Dt
>
> I doubt that "t".  ;-)

You are right! No wonder that pattern was hard to "recognize"...

> This is all GNAT-specific, of course.  Some other Ada compiler
> can return something completely different.

I guess I use GNAT because I compile with gnatmake: gcc-4.6 -c,
gnatbind -x, and last gnatlink.

> Trimming the string might not be a good idea -- it uniquely
> identifies the task in case the name part doesn't.

Yeah, but aren't the names unique as long as there aren't more
than one instance of each task? I don't mean to trim the actual
data, which I BTW am very far from knowing how to do, I mean just
dump the task name (the letters) in a new string, and use that for
communicating the task's name (to a human, executing the program).

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Robert A Duff]

Emanuel Berg <embe8573@student.uu.se> writes:

> Yeah, but aren't the names unique as long as there aren't more
> than one instance of each task?

You mean each task type, I think.

GNAT tries to make the names unique, but they are not always.
Read the docs for details, but for example:

    X := new Some_Task_Type;
    X := new Some_Task_Type;
    X := new Some_Task_Type;

You get three heap-allocated tasks, with nothing in the Image
to distinguish them other than the TCB address.

- Bob

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

>> Yeah, but aren't the names unique as long as there aren't more
>> than one instance of each task?
>
> You mean each task type, I think.

Yes.

> GNAT tries to make the names unique, but they are not always.
> Read the docs for details, but for example:
>
>     X := new Some_Task_Type;
>     X := new Some_Task_Type;
>     X := new Some_Task_Type;
>
> You get three heap-allocated tasks, with nothing in the Image
> to distinguish them other than the TCB address.

Aha! I don't use new, I just setup the tasks specifications and
bodies (three of them), and then

begin
  null;
end;

I assumed I got three tasks, concurrently, one of each type, all
unique with regards to their human readable name, with no need for
the control block hex?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Alan Jump]

On Friday, August 9, 2013 3:36:52 PM UTC-7, Robert A Duff wrote:

> You mean each task type, I think.
> 
> GNAT tries to make the names unique, but they are not always.
> Read the docs for details, but for example:
> 
>     X := new Some_Task_Type;
>     X := new Some_Task_Type;
>     X := new Some_Task_Type;
> 
> You get three heap-allocated tasks, with nothing in the Image
> to distinguish them other than the TCB address.
> 
> - Bob

Umm...I'm a neophyte when it comes to Ada, but the example you gave doesn't register with me as being valid. I read that as three separate allocations in a row of Some_Task_Type to the same variable name, and logic would tell me that with each new allocation, the previous allocation terminates, with questionable (and likely implementation-specific) grace. Would that not result in each allocation generating its own unique 'Image(Current_Task) result?

It's been a long day, and I ran out of coffee hours ago...

 - -
73 de N5ILN
Alan

Re: 4 beginner's questions on the PL Ada

[Dennis Lee Bieber]

On Fri, 09 Aug 2013 18:50:53 +0200, Emanuel Berg <embe8573@student.uu.se>
declaimed the following:

>1. How do you make a constant in Ada? Can I make one that is
>computed, for example an integer, set to Milliseconds(something)?
>
http://www.adaic.org/resources/add_content/standards/12rm/html/RM-3-3-1.html

>2. How do you get options from the CL? I.e., how do you do the C
>argv in Ada?

http://www.adaic.org/resources/add_content/standards/12rm/html/RM-A-15.html

>
>3. Is it possible to get the task *name* (from the code) into a
>string, programatically? That way, a generic procedure could be
>used to communicate from tasks, with Put_Line, and without having
>to hard code the task name every time.

	What do you consider a task name? Since you can declare task /types/,
and then create instances of the type are you asking for the /type/ name
(which would be the same for all instances) or the "variable" name -- which
may vary depending upon where in the code one is (if a task instance is
somehow passed to a procedure is it supposed to display the name by which
it was instantiated, or the name by which it is being accessed in the
procedure).

http://www.adaic.org/resources/add_content/standards/12rm/html/RM-C-7-1.html

>
>4. How do you exit Ada altogether? For example, if there are 3
>tasks, and one solves the problem, how can I terminate the whole
>application at once? (Rather than sending messages to all the
>tasks, "OK, we're done looking!")
>

http://www.adaic.org/resources/add_content/standards/12rm/html/RM-9-8.html


	IOWs, it is all there in the reference manual.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: 4 beginner's questions on the PL Ada

[Dennis Lee Bieber]

On Fri, 09 Aug 2013 23:38:53 +0200, Emanuel Berg <embe8573@student.uu.se>
declaimed the following:

>
>The 8-char code that follows doesn't look like anything I
>recognize. Is it a random string ID, or is is generated out of
>anything sensible? If it always is 8 chars (and an underscore), I
>guess I could simply trim the strings.

	What is returned as an ID is compiler dependent -- a different compiler
may just return an integer (the OS PID).

	I suspect this one is the name of the declaration of the task type with
the address in memory where the task control block was created appended to
it.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: 4 beginner's questions on the PL Ada

[Adam Beneschan]

On Friday, August 9, 2013 3:47:27 PM UTC-7, Alan Jump wrote:
> On Friday, August 9, 2013 3:36:52 PM UTC-7, Robert A Duff wrote:

> Umm...I'm a neophyte when it comes to Ada, but the example you gave doesn't register with me as being valid. I read that as three separate allocations in a row of Some_Task_Type to the same variable name, and logic would tell me that with each new allocation, the previous allocation terminates

No.  First of all, if you do this on other record types:

   X := new Record1;
   X := new Record1;
   X := new Record1;

the memory allocated for the first Record1 doesn't get released when the second X is allocated, and so on.  The data is still there in memory.  And it needs to be, in case there was some code in between those allocations that caused something else to point to the record (or to one of its components) in between.  You can't automatically destroy the record objects if something else might be pointing to them.

But even if nothing else was pointing to them (as in the above example), Ada still doesn't mandate garbage collection--i.e. reclaiming storage that nothing points to.  A compiler *could* generate code to do this automatically, but I don't know of any that do.  Generally, you have to do your own memory management (using Unchecked_Deallocation).  So if you can see that in the above example, memory storage won't automatically be reclaimed, you can see by analogy that tasks won't automatically be terminated either.  

But there's another factor: if you allocate a task (or a record containing a task), using Unchecked_Deallocation (or automatic memory reclamation) won't terminate the task.  That's just the way the language authors decided.  This discussion has come up before, and it's surprised other people that a task will still run after Unchecked_Deallocation has been used on it, but there were reasons why things are the way they are.  I don't remember the reasons, though. 

                             -- Adam

Re: 4 beginner's questions on the PL Ada

[Robert A Duff]

Alan Jump <alan.jump@gmail.com> writes:

> On Friday, August 9, 2013 3:36:52 PM UTC-7, Robert A Duff wrote:
>>     X := new Some_Task_Type;
>>     X := new Some_Task_Type;
>>     X := new Some_Task_Type;
>> 
>> You get three heap-allocated tasks, with nothing in the Image
>> to distinguish them other than the TCB address.
>
> Umm...I'm a neophyte when it comes to Ada, but the example you gave
> doesn't register with me as being valid.

It allocates three tasks, which will run concurrently with each
other, and with the task doing these allocations.  There's a memory
leak here (the first two allocated task objects can never be
Unchecked_Deallocated), but that's not relevant to the questions
about Image.  So perhaps a more realistic example would be:

    for X in Index range 1..3 loop
        Some_Array(X) := new Some_Task_Type;
    end loop;

Or the tasks could be chained in a linked list, or whatever.  In any
case, they run concurrently, and they terminate when they get to their
"end", or raise an unhandled exception, or when a "terminate"
alternative is selected.  The master that owns the access type will wait
for them to terminate -- probably after the main procedure returns.

>...I read that as three separate
> allocations in a row of Some_Task_Type to the same variable name, and
> logic would tell me that with each new allocation, the previous
> allocation terminates, with questionable (and likely
> implementation-specific) grace.

Not sure what you mean by "allocation terminates".  The allocator
returns a pointer to a task, which will run until it is done -- it
depends what's in the task body.  In many embedded systems, tasks
have infinite loops and never terminate.

There's nothing questionable, implementation specific, or ungraceful
here, other than the memory leak I mentioned, and the fact that
Image is defined to be implementation specific.

>...Would that not result in each
> allocation generating its own unique 'Image(Current_Task) result?

I think that in GNAT, the Image of those three tasks will be something
like "Some_Task_Type_0ABC1230", where the "0ABC1230" part is different
for each.  So yes, they're unique, but the OP was thinking of chopping
that part off before printing it out.

- Bob

Re: 4 beginner's questions on the PL Ada

[Alan Jump]

On Friday, August 9, 2013 4:33:51 PM UTC-7, Adam Beneschan wrote:

> No.  First of all, if you do this on other record types:
> 
> 
>    X := new Record1;
>    X := new Record1;
>    X := new Record1;
> 
> the memory allocated for the first Record1 doesn't get released when the second X is allocated, and so on.  The data is still there in memory.  And it needs to be, in case there was some code in between those allocations that caused something else to point to the record (or to one of its components) in between.  You can't automatically destroy the record objects if something else might be pointing to them.
> 
> But even if nothing else was pointing to them (as in the above example), Ada still doesn't mandate garbage collection--i.e. reclaiming storage that nothing points to.  A compiler *could* generate code to do this automatically, but I don't know of any that do.  Generally, you have to do your own memory management (using Unchecked_Deallocation).  So if you can see that in the above example, memory storage won't automatically be reclaimed, you can see by analogy that tasks won't automatically be terminated either.  
> 
> But there's another factor: if you allocate a task (or a record containing a task), using Unchecked_Deallocation (or automatic memory reclamation) won't terminate the task.  That's just the way the language authors decided.  This discussion has come up before, and it's surprised other people that a task will still run after Unchecked_Deallocation has been used on it, but there were reasons why things are the way they are.  I don't remember the reasons, though. 
> 
>                              -- Adam

So what you have shown here is a classic recipe for a memory leak. That strikes me as poor code design in any language. I was given Java as a first OO language, so maybe that's what spoiled me on memory reclamation, but I still tried to avoid reusing variables unless I was absolutely certain that what I was writing was going to remain in a limited scope.

Turning back to the point at hand, it seems to me that a better example would have been to allocate an array of task types, then examine the 'Image(Current_Task). But then, if one did produce the array of task types, one would then use the array index as the unique task name, yes?

Pardon me whilst I wander off to find more coffee. Something tells me I'm going to need it.

 - -
73 de N5ILN
Alan

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> 	What do you consider a task name? Since you can declare task
> /types/, and then create instances of the type are you asking
> for the /type/ name (which would be the same for all instances)
> or the "variable" name -- which may vary depending upon where in
> the code one is (if a task instance is somehow passed to a
> procedure is it supposed to display the name by which it was
> instantiated, or the name by which it is being accessed in the
> procedure).

task This_Is_The_Task_Name is ...

Or perhaps task *type* name, as you can have several instances
(didn't think of that when I wrote my OP). But I don't have
several instances, so in my case, it doesn't matter.

Anyway, if you had read the following discussion, it would have
made perfect sense what I was looking for.

> IOWs, it is all there in the reference manual.

Well, as I see it, the point with Usenet is that you *talk* about
technology (and other things). Just yanking one million URLs isn't
going to help. (Although you took it to a new high, there has been
a lot of URLs in this thread. Do you guys really enjoy that?)

If I had the book here, that'd be a different ballgame. I'll visit
the public library tomorrow and see what they got on Ada.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Robert A Duff]

Emanuel Berg <embe8573@student.uu.se> writes:

> Aha! I don't use new, I just setup the tasks specifications and
> bodies (three of them), and then
>
> begin
>   null;
> end;
>
> I assumed I got three tasks, concurrently, one of each type, all
> unique with regards to their human readable name, with no need for
> the control block hex?

Yes.  In that case, it might be reasonable to write a function to
chop off the hex part, something like:

    function My_Image return String is
        X : constant String := Image(Current_Task);
    begin
        for J in reverse X'Range loop
            if X(J) = '_' then
                return X(X'First..J-1);
            end if;
        end loop;
        return X;
    end My_Image;

I didn't compile the above -- it might have typos/bugs.

I assume this is all for debugging/logging/tracing.
So it doesn't really matter too much what My_Image does,
so long as it doesn't crash.  If/when you start using "new",
or switch to a different Ada compiler, you can tweak that function.

- Bob

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

>     function My_Image return String is
>         X : constant String := Image(Current_Task);
>     begin
>         for J in reverse X'Range loop
>             if X(J) = '_' then
>                 return X(X'First..J-1);
>             end if;
>         end loop;
>         return X;
>     end My_Image;
>
> I didn't compile the above -- it might have typos/bugs.
>
> I assume this is all for debugging/logging/tracing.  So it
> doesn't really matter too much what My_Image does, so long as it
> doesn't crash.  If/when you start using "new", or switch to a
> different Ada compiler, you can tweak that function.

Yes, this is more like it! OK, point taken.

Will read, then try the code, now.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

>     function My_Image return String is
>         X : constant String := Image(Current_Task);
>     begin
>         for J in reverse X'Range loop
>             if X(J) = '_' then
>                 return X(X'First..J-1);
>             end if;
>         end loop;
>         return X;
>     end My_Image;

Works excellent.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Robert A Duff]

Alan Jump <alan.jump@gmail.com> writes:

> So what you have shown here is a classic recipe for a memory leak.

Yes.

>... That strikes me as poor code design in any language.

Right.  My example was not meant to illustrate how to avoid memory leaks
or any other good design principles -- just to show an example about the
Image function on Task_Ids, and their uniqueness in particular.

> Turning back to the point at hand, it seems to me that a better
> example would have been to allocate an array of task types, then
> examine the 'Image(Current_Task). But then, if one did produce the
> array of task types, one would then use the array index as the unique
> task name, yes?

It depends.  As I suggested, read the docs.  Sometimes the array index
is included in the Image.  Yes, an array might have been a better
example (to avoid getting side-tracked on the memory-leak issue),
but I think it would have to be an array of *pointers* to tasks,
not an array of tasks, to illustrate my point about Image.

By the way, we're talking about Image, not 'Image.
That is, the Image function, not the 'Image attribute.

> Pardon me whilst I wander off to find more coffee. Something tells me
> I'm going to need it.

You're a Java programmer, so there ought to be some apt pun involving
coffee/java here, but it's escaping me at the moment.  ;-)

- Bob

Re: 4 beginner's questions on the PL Ada

[Anh Vo]

On Friday, August 9, 2013 3:16:34 PM UTC-7, Emanuel Berg wrote:
> Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:
>  
> > This may not be a concern for your present needs, though
> 
> > unnecessary non-portability usually bites you sooner or later in
> 
> > real projects.
>  
> Yes, I agree.
>  
> > An advantage of the technique used in PragmARC.Reflection is
> 
> > that it is part of the core language, and so implemented by all
> 
> > compilers, and the resulting string is defined by the language,
> 
> > and so is the same for all compilers.
>  
> That sounds great. Unless it requires lots of code, why don't you
> 
> just show me how it is done? It is much easier understanding that
> 
> way.

You can give/assign a name to a task the way you like by using predefined package Ada.Task_Attributes. In this case you most likely instantiate it with String subtype. Therefore, it is will be completely portable.

Anh Vo
 

Re: 4 beginner's questions on the PL Ada

[Jeffrey Carter]

On 08/09/2013 04:48 PM, Robert A Duff wrote:
>
> Yes.  In that case, it might be reasonable to write a function to
> chop off the hex part, something like:
>
>      function My_Image return String is
>          X : constant String := Image(Current_Task);
>      begin
>          for J in reverse X'Range loop
>              if X(J) = '_' then
>                  return X(X'First..J-1);
>              end if;
>          end loop;
>          return X;
>      end My_Image;

Or use Ada.Strings.Fixed.Index to find the index of the final underline and 
avoid reinventing the wheel.

-- 
Jeff Carter
"Well, a gala day is enough for me. I don't think
I can handle any more."
Duck Soup
93

Re: 4 beginner's questions on the PL Ada

[Robert A Duff]

This is getting a bit esoterical -- beyond the simple questions the
OP was asking about how to print out the Image of a task!
But anyway:

Adam Beneschan <adambeneschan@aol.com> writes:

> But there's another factor: if you allocate a task (or a record
> containing a task), using Unchecked_Deallocation (or automatic memory
> reclamation) won't terminate the task.

Well, there's no notion in Ada of "to terminate a task" (as in "task T1
terminates T2").  Tasks terminate themselves.  Normally, when they're
done.  In the case of "terminate" alternatives of select statements, a
task signals that it is in a ready-to-terminate state, and then gets
told to go ahead and terminate itself.  In the case of "abort", the task
is told to terminate itself as soon as possible after it is out of any
abort-deferred region.

In no case does a task get terminated from outside itself.
And that's as it should be.  Anything else is just asking for
all sorts of race conditions.

So I claim it makes no sense at all for Unchecked_Deallocation of an
object containing tasks to terminate those tasks.  And I don't think
it makes sense for U_D to abort those tasks (and then what? wait for
them to terminate themselves?  Or just go ahead, and hope they do so?).

>...That's just the way the
> language authors decided.  This discussion has come up before, and
> it's surprised other people that a task will still run after
> Unchecked_Deallocation has been used on it, but there were reasons why
> things are the way they are.  I don't remember the reasons, though.

I think it would make sense for U_D to await the termination of those
tasks, and then free up the memory.

But the actual Ada semantics are admittedly weird:  U_D on an object
containing running tasks doesn't free all the memory, but it expresses
a hope that the memory will be freed when the tasks terminate.
GNAT was recently changed so that "hope" comes true, but it's not
required, and older versions of GNAT, and probably other compilers,
just leak memory if you do U_D on running tasks.

- Bob

Re: 4 beginner's questions on the PL Ada

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> Or use Ada.Strings.Fixed.Index to find the index of the final underline
> and avoid reinventing the wheel.

Good point.

- Bob

Re: 4 beginner's questions on the PL Ada

[Jeffrey Carter]

On 08/09/2013 03:16 PM, Emanuel Berg wrote:
>
> That sounds great. Unless it requires lots of code, why don't you
> just show me how it is done? It is much easier understanding that
> way.

In my original response I referenced PragmARC.Reflection and included a link to 
the PragmAda Reusable Components, allowing you to examine how it's done if you 
wanted. It's not a whole lot of code, but it is somewhat complex, using 
Ada.Strings.Fixed.Index to trim off unwanted parts of the returned name and 
converting the result to mixed case. Even after seeing it you'll probably want 
to experiment with Expanded_Name to understand what it's doing.

-- 
Jeff Carter
"Well, a gala day is enough for me. I don't think
I can handle any more."
Duck Soup
93

Re: 4 beginner's questions on the PL Ada

[Jeffrey Carter]

On 08/09/2013 04:43 PM, Alan Jump wrote:
>
> So what you have shown here is a classic recipe for a memory leak. That
> strikes me as poor code design in any language. I was given Java as a first
> OO language, so maybe that's what spoiled me on memory reclamation, but I
> still tried to avoid reusing variables unless I was absolutely certain that
> what I was writing was going to remain in a limited scope.

That is basically the pattern often used for pools of job tasks. The tasks run 
until the program ends (they check a protected object periodically to see if 
they should exit.) The idea is to have as many tasks as are needed for the 
maximum number of concurrent jobs, so a new task is allocated whenever there is 
a new job and no idle task to work on it. Each task is allocated and the access 
value discarded. The tasks, when idle, wait for work on a protected queue of jobs.

This isn't a memory leak, since we want that many tasks to exist and don't need 
to access them through their access values. If we knew how many tasks we needed 
at start up we'd declare them in an array.

-- 
Jeff Carter
"Well, a gala day is enough for me. I don't think
I can handle any more."
Duck Soup
93

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Anh Vo <anhvofrcaus@gmail.com> writes:

> You can give/assign a name to a task the way you like by using
> predefined package Ada.Task_Attributes. In this case you most
> likely instantiate it with String subtype. Therefore, it is will
> be completely portable.

And (drumroll...) how would that look?

You guys should do a field trip to gnu.emacs.help - there, we just
post code all days! It is much better. Code speaks louder than
words. It is very difficult to follow all this discussion on
memory allocation etc., but the few times you posted code there
wasn't a letter I didn't understand immediately.

And isn't that the same way with you? If you were to explain the C
for loop to another programmer, would you not just write

for (i = 0; i < STOP; i++) { printf("Pretty clear, huh?\n"); }

But I don't doubt your Ada knowledge, or you helpful attitude.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Dennis Lee Bieber]

On Sat, 10 Aug 2013 01:48:08 +0200, Emanuel Berg <embe8573@student.uu.se>
declaimed the following:

>Well, as I see it, the point with Usenet is that you *talk* about
>technology (and other things). Just yanking one million URLs isn't
>going to help. (Although you took it to a new high, there has been
>a lot of URLs in this thread. Do you guys really enjoy that?)
>

	While I do sometimes just drop in code snippets, I more often prefer
the "teach a man to fish" mode for such direct questions-- which plugging
in links to the HTML manual were meant to suggest... Search the manual
first, and then ask for clarification if needed, providing the information
as to what is unclear.

>If I had the book here, that'd be a different ballgame. I'll visit
>the public library tomorrow and see what they got on Ada.

	Just Google for 

Ada Reference Manual

and you should find that it is available as a PDF (in both regular and
annotated forms, along with red-line mark-up of the changes from previous
version).

	While I do sometimes just drop in code snippets, I more often prefer
the "teach a man to fish" mode -- which plugging in links to the HTML
manual were meant to indicate... Search the manual first, and then ask for
clarification if needed, providing the information as to what is unclear.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> While I do sometimes just drop in code snippets, I more often
> prefer the "teach a man to fish"

Code communicates better than documentation, is my firm belief. I
can guarantee you, I study such all code in detail, and my eyes
are trained. I don't kill and yank the code, not learning anything
from it, and then come back, demanding more. I know, some do that,
on the SX sites not the least. If you do that, then I do agree
reading is a lot better. But if you do that, you're an idiot, and
those tend not to read, either :)

No, I'm going to the library, as said. It will be interesting to
see what they have. Probably one or two old books. That is usually
the case. Tomorrow, I'll tell you the result. Could be interesting
for you, if you are into documentation and stuff, as I sense that
you are.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Jeffrey Carter]

On 08/09/2013 07:45 PM, Dennis Lee Bieber wrote:
>
> 	While I do sometimes just drop in code snippets, I more often prefer
> the "teach a man to fish" mode for such direct questions-- which plugging
> in links to the HTML manual were meant to suggest... Search the manual
> first, and then ask for clarification if needed, providing the information
> as to what is unclear.

With the exception of Annex A (which describes the Ada.* hierarchy), the ARM is 
not very good for learning the language. For that I'd recommend some of the 
documents at

http://www.adaic.org/learn/materials/

For someone familiar with another imperative language, I generally suggest /Ada 
Distilled/.

-- 
Jeff Carter
"Well, a gala day is enough for me. I don't think
I can handle any more."
Duck Soup
93

Re: 4 beginner's questions on the PL Ada

[Simon Wright]

Emanuel Berg <embe8573@student.uu.se> writes:

> Anh Vo <anhvofrcaus@gmail.com> writes:
>
>> You can give/assign a name to a task the way you like by using
>> predefined package Ada.Task_Attributes. In this case you most
>> likely instantiate it with String subtype. Therefore, it is will
>> be completely portable.
>
> And (drumroll...) how would that look?

Well, it turns out to be more complicated than Ahn Vo said, because
Ada.Task_Attributes[1] has to be instantiated with a definite type (it
begins "type Attribute is private;") and String is indefinite.

So it might look like

with Ada.Strings.Bounded;
with Ada.Task_Attributes;
with Ada.Task_Identification;
with Ada.Text_IO; use Ada.Text_IO;
procedure Task_Naming is
   package Task_Name_Strings
   is new Ada.Strings.Bounded.Generic_Bounded_Length (Max => 64);
   package Task_Names
   is new Ada.Task_Attributes
     (Attribute => Task_Name_Strings.Bounded_String,
      Initial_Value => Task_Name_Strings.Null_Bounded_String);
   task Tsk is end Tsk;
   task body Tsk is
   begin
      delay 5.0;
   end Tsk;
begin
   Task_Names.Set_Value (T => Tsk'Identity,
                         Val => Task_Name_Strings.To_Bounded_String ("foo"));
   --  later ...
   Put_Line
     ("id is "
        & Task_Name_Strings.To_String (Task_Names.Value (Tsk'Identity)));
end Task_Naming;

Alternatively, you could say

   subtype Task_Name_String is String (1 .. 16);
   package Task_Names
   is new Ada.Task_Attributes
     (Attribute => Task_Name_String,
      Initial_Value => (others => ' '));

but then you'd have to say

   Task_Names.Set_Value (T => Tsk'Identity,
                         Val => ('f', 'o', 'o', others => ' '));

> You guys should do a field trip to gnu.emacs.help - there, we just
> post code all days! It is much better. Code speaks louder than
> words. It is very difficult to follow all this discussion on
> memory allocation etc., but the few times you posted code there
> wasn't a letter I didn't understand immediately.

We don't like to post code that doesn't work, and producing a working
example takes time. Also, we have an excellent on-line reference manual,
though it takes a special kind of person to want to read it at bed-time!

[1] http://www.adaic.org/resources/add_content/standards/12rm/html/RM-C-7-2.html

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Simon Wright <simon@pushface.org> writes:

> Well, it turns out to be more complicated than Ahn Vo said,
> because Ada.Task_Attributes[1] has to be instantiated with a
> definite type (it begins "type Attribute is private;") and
> String is indefinite.
>
> So it might look like ...

Thanks a lot. I'm not expecting anyone to produce that much code
in response to my questions, for the record. But if someone enjoys
writing it, of course, I don't have a problem with that, either.

> We don't like to post code that doesn't work

Of course, the code works! You are the Ada owls and foxes. Why
shouldn't it work?

> and producing a working example

It doesn't have to work *in isolation*. It can be just 1-3
lines. I am able to glue it together with my code. Almost all
programmers are.

> Also, we have an excellent on-line reference manual, though it
> takes a special kind of person to want to read it at bed-time!

Yes, I've read lots of books on Linux, Unix, some one theory,
distributed systems, DBs, etc., and some of those have been great,
but books on PLs are often, either

1) they try to learn you *programming* (in general) *by means of*
the particular language. "On the second line, you see some words
delimited by a pair of double quotation marks. This is a so called
_string_. A string..." - impossible to read,

or

2) they are reference books, for people who already know the
language, but not all of it, and sometimes forgetting details
(which happens all the time). From this kind of book, if you don't
know the PL at all to begin with, you can learn Basic, and
possibly C. What about C++? Lisp? I doubt a lot of people could do
it. Without rudimentary explanations, and especially *examples*, I
doubt save but a few could do it.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> 2. How do you get options from the CL? I.e., how do you do the C
> argv in Ada?

Now, as an example, here is how I would answer my question:

with Ada.Command_Line;
use  Ada.Command_Line;
-- ...
Try_Hit : Boolean := (Argument_Count = 1 and
                      Argument(1) = "-h");

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

>> 2. How do you get options from the CL? I.e., how do you do the C
>> argv in Ada?
>
> Now, as an example, here is how I would answer my question:
>
> with Ada.Command_Line;
> use  Ada.Command_Line;
> -- ...
> Try_Hit : Boolean := (Argument_Count = 1 and
>                       Argument(1) = "-h");

Holy - isn't Ada short circuited on "and"?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> Holy - isn't Ada short circuited on "and"?

Try_Hit : constant Boolean := (Argument_Count = 1 and then
                               Argument(1) = "-h");

Brilliant! I'm impressed.
                               
-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Shark8]

On Friday, August 9, 2013 9:33:06 PM UTC-6, Emanuel Berg wrote:
> Dennis Lee Bieber writes:
> 
> > While I do sometimes just drop in code snippets, I more often
> > prefer the "teach a man to fish"
> 
> Code communicates better than documentation, is my firm belief. 

There's a *huge* problem with this: superficial understanding.
This problem can lead to extremely bad code adopted as "best practice"/"standard practice".

An excellent example: PHP's official site.
They go to the code side even in the documentation, to the point where the mb/forum attached to the particular function is oft littered with code examples... and usually bad ones once you gain a deeper understanding of what's going on.

> I can guarantee you, I study such all code in detail, and my eyes
> are trained. I don't kill and yank the code, not learning anything
> from it, and then come back, demanding more.

Then you're a step ahead of the cut-n-past script monkeys that the "code snipet" style seems to generate -- not to say that code isn't useful but, again, it seems to encourage a lazy psudeo-understanding.

> I know, some do that,
> on the SX sites not the least. If you do that, then I do agree
> reading is a lot better. But if you do that, you're an idiot, and
> those tend not to read, either :)

LOL - Point.

Re: 4 beginner's questions on the PL Ada

[Mike H]

In message <87mwoqbao2.fsf@VLAN-3434.student.uu.se>, Emanuel Berg 
<embe8573@student.uu.se> writes
>And isn't that the same way with you? If you were to explain the C
>for loop to another programmer, would you not just write
>
>for (i = 0; i < STOP; i++) { printf("Pretty clear, huh?\n"); }
>
No. Because I would not know the type of the loop control variable and 
hence which of a number of different possible loop constructs would best 
suit the questioner's needs for that particular occasion, e.g.
for ... loop;  ... end loop;
for ... in reverse ... loop; end ... loop;
while ... loop; ... end loop;
loop ... ; exit when ...; ... end loop;

Please understand that other contributors to this news group have 
provided alternative answers to your questions because your questions 
have not always been specific enough to get a specific answer.
-- 
"Why," said Ford squatting down beside him and shivering, "are you lying face
down in the dust?" "It's a very effective way of being wretched," said Marvin.
Mike ;-(

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Shark8 <onewingedshark@gmail.com> writes:

> There's a *huge* problem with this: superficial understanding.
> This problem can lead to extremely bad code adopted as "best
> practice"/"standard practice".

There is nothing superficial about code. Code *is* programming!

And code can have a "maturing" side just as reading a book:
re-reading it two years later, and basically reading a new book
(and not because the book has changed by even a single letter).

Can you honestly say you understood semaphores, pipes, etc., the
first time you used them? For one, I admit I didn't. But now I do,
because I wrote that code, and invoked those commands, so many
times.

And all the while, I *did* something that made my system better,
more user-friendly, and/or more fun.

I could have read that chapter in "Big Book of Unix IPC" (a couple
of times), and that would have given me - the same understanding?
Perhaps, but not for sure (actually, I doubt it). The same
experience? No. Not typing, not managing a project, not compiling,
nothing like that at all. All the million "side-effects" to doing
stuff: self-confidence, creativity, etc.?  None. And all the
improvements to my system - all the .profile, .rc, .emacs,
.Xresources, all that stuff? (Now I move away from the IPC
example, but the principle holds.) Nothing. Just a very impressive
bookshelf!

But, that being said, books are *great*. If they weren't so
expensive, I would own a lot more of them. References are great,
as well. But I like mine offline (i.e., on paper).

I don't like Googling - it disturbs my workflow, and hearts my
eyes (I exclusively work in Emacs, in a Linux VT - see the
screenshots [1] - it is the best configuration - faces, the font,
etc. - that I spent years configuring, to counteract tired/dry
eyes).

Googling also reduces the mental-physical presence: relying on it
will reduce your attention span - in the room, in time - giving
you "short thoughts" instead of "long".

This may seem monkish, and it is. I like Lisp, C, LaTeX, that
stuff. I don't like Python, Java, PHP (or any web programming). I
don't like GUIs (except for very specific applications, e.g., GIS
and the like; and then I accept them for *others* to use). I don't
like IM but love mails, which I send from rmail. I don't like the
SX sites, but Usenet, for which I use Gnus. I see a pattern in
this, and I hope you do, too. (And not be offended if *you* happen
to like Java.) So you see, you can, as I, prefer code to
documentation, and there is nothing superficial about it.

> An excellent example: PHP's official site.  They go to the code
> side even in the documentation, to the point where the mb/forum
> attached to the particular function is oft littered with code
> examples... and usually bad ones once you gain a deeper
> understanding of what's going on.

That's not an excellent example. If the code is *bad*, all bets
are off... (Well, not quite, because I can learn a thing or two
from that code, and then re-write it the way I think it should be
done.) It's like me picking up the worst documentation ever
written, saying it exemplifies why documentation shouldn't be
studied.

> Then you're a step ahead of the cut-n-past script monkeys that
> the "code snipet" style seems to generate -- not to say that
> code isn't useful but, again, it seems to encourage a lazy
> psudeo-understanding.

This is 100% incorrect. I'm not going to argue with you if this is
your base, because it is not productive one bit.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Mike H <postmaster@ada-augusta.demon.co.uk> writes:

>>And isn't that the same way with you? If you were to explain the C
>>for loop to another programmer, would you not just write
>>
>>for (i = 0; i < STOP; i++) { printf("Pretty clear, huh?\n"); }
>>
> No. Because I would not know the type of the loop control variable
> and hence which of a number of different possible loop constructs
> would best suit the questioner's needs for that particular
> occasion, e.g.

> for ... loop;  ... end loop;
> for ... in reverse ... loop; end ... loop;
> while ... loop; ... end loop;
> loop ... ; exit when ...; ... end loop;

That's Ada, not C. The for loop in C is the for loop in C, and the
best way to explain it is to say it is excellent for cases where
the increment variable is usable inside the loop, as in iterating
an array, *or* when it is known beforehand how many times
something should be done. Then you post the syntax (the code, the
example), and - perhaps - mention that 'continue' and 'break' can
be used to circumvent execution flow. This is the way I would have
done it. If you would have queried further on the context, and
dumping URLs to documentation, that's your call.

> Please understand that other contributors to this news group
> have provided alternative answers to your questions because your
> questions have not always been specific enough to get a specific
> answer.

That's not the point. There are (almost) always many ways to do
things. (That typically hasn't to do with the question, anyway,
but is the normal case.)

The point is, if you talk about programming by being active with
*code*, this is a lot better in many, many ways, and worse in
maybe one or two ways.

Code is not superficial or lazy. Code *is* programming!

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

>> There's a *huge* problem with this: superficial understanding.
>> This problem can lead to extremely bad code adopted as "best
>> practice"/"standard practice".
>
> There is nothing superficial about code. Code *is* programming!
>
> And code can have a "maturing" side just as reading a book:
> re-reading it two years later, and basically reading a new book
> (and not because the book has changed by even a single letter).
>
> Can you honestly say you understood semaphores, pipes, etc., the
> first time you used them? For one, I admit I didn't. But now I do,
> because I wrote that code, and invoked those commands, so many
> times.
>
> And all the while, I *did* something that made my system better,
> more user-friendly, and/or more fun.
>
> I could have read that chapter in "Big Book of Unix IPC" (a couple
> of times), and that would have given me - the same understanding?
> Perhaps, but not for sure (actually, I doubt it). The same
> experience? No. Not typing, not managing a project, not compiling,
> nothing like that at all. All the million "side-effects" to doing
> stuff: self-confidence, creativity, etc.?  None. And all the
> improvements to my system - all the .profile, .rc, .emacs,
> .Xresources, all that stuff? (Now I move away from the IPC
> example, but the principle holds.) Nothing. Just a very impressive
> bookshelf!
>
> But, that being said, books are *great*. If they weren't so
> expensive, I would own a lot more of them. References are great,
> as well. But I like mine offline (i.e., on paper).
>
> I don't like Googling - it disturbs my workflow, and hearts my
> eyes (I exclusively work in Emacs, in a Linux VT - see the
> screenshots [1] ...

Forgot the link:

[1] http://user.it.uu.se/~embe8573/gnus/index.html

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Dennis Lee Bieber]

On Sat, 10 Aug 2013 19:53:41 +0200, Emanuel Berg <embe8573@student.uu.se>
declaimed the following:

>That's Ada, not C. The for loop in C is the for loop in C, and the
>best way to explain it is to say it is excellent for cases where
>the increment variable is usable inside the loop, as in iterating
>an array, *or* when it is known beforehand how many times
>something should be done. Then you post the syntax (the code, the
>example), and - perhaps - mention that 'continue' and 'break' can
>be used to circumvent execution flow. This is the way I would have
>done it. If you would have queried further on the context, and
>dumping URLs to documentation, that's your call.
>

	And that description is rather meaningless to me...

	C-style for loops pretty much mandate breaking apart into parts as they
ARE so generic.

	for ( [initialization part]; 
			[repeat condition part]; 
			[{iteration setup part])
	{
		[action part]
	};

After all, each part is optional!

	for (; [repeat condition part];)
	{
		...
	}

is identical to a while loop

	while ([repeat condition part])
	{
		...
	}

	Heck:

	[initialization part]
	while ([repeat condition part])
	{
		...
		[iteration setup part]
	}

is a full description of the C-style for loop (especially in older C where
you have to predeclare any "loop variables" used in the initialization).

	In Ada, the basic loop, from which all others are built, is:

	loop
		....
	end loop;

From that one can define loops that iterate over a known/consecutive range
of values

	for counter in first..last loop
		....
	end loop;

Or a loop that has variable number of repeats based upon some condition
determined within the loop itself

	while condition loop
		....
	end loop;

Or even loops that need to repeat some setup actions for each iteration
which affects the exit criteria

	loop
		pre-condition action
		exit when not condition;
		post-condition action
	end loop;

which would require duplicated code in other languages (or misleading loop
structures)

	pre-condition action
	while (condition)
	{
		post-condition action
		pre-condition action /* to set up next iteration */
	}

or

	while (1)	/*	superfluous "condition check", it never exits loop	*/
	{
		pre-condition action
		if (not condition) break;
		post-condition action
	}

or

	for (pre-condition action; condition; pre-condition action)
	{
		post-condition action
	}



>Code is not superficial or lazy. Code *is* programming!

	Code is IMPLEMENTATION...

	Programming takes place outside of any language; one maps algorithms
into the language specific syntax/semantics to implement the algorithm
(program/recipe).
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> 	And that description is rather meaningless to me...
>
> C-style for loops pretty much mandate breaking apart into parts
> as they ARE so generic.

Yes, I think it is clear by now that we prefer to describe things
in different ways.

> Code is IMPLEMENTATION...

OK, then what is not? Modelling? Drawing UML diagrams on
whiteboards? Or keeping it in your head, but still doing it in
stages?

Well, I don't do it in stages, I do everything at once, namely, when I
write code.

I do it bottom-up, like the Unix way of small, unique tools with a
common IF, and then you add complexity not by making a new tool,
but by combining those that you have.

Perhaps you do it top-down? I never did that, but then, I suspect
modelling and verification are motivated, at least to a higher
degree than with the bottom-up approach (in what case I think
modelling is a waste of time, and UML a joke).

On the whole, I don't like modelling. I think its importance is
exaggerated to the outmost. (But for commercial RT systems, that
cannot be easily patched (or revoked), and where human safety is
involved, I see the point of it.)

I don't prefer C++ to C, and I would only use Java on a sinking
ship.

The real time/concurrent model of real time and/or distributed
systems are a lot more appealing to me than the OO model, but I
know too little of it to say for sure. Most of all, I like C and
Lisp (which I don't consider FP any more than plain
procedural/imperative).

> Programming takes place outside of any language; one maps
> algorithms into the language specific syntax/semantics to
> implement the algorithm (program/recipe).

I agree that all programming is the same, only, again, I don't
map, to me it is all a mental-physical activity that has become
one (if it ever was separated).

Also, algorithms, as in CS - with hash tables, greedy traversal of
balanced search trees, all that stuff - that's exaggerated, and
often but an academic discipline. Programming is in general not
that advanced. I don't map algorithms into code. The little I
think, I think in code. The rest I write.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Simon Clubley]

On 2013-08-10, Emanuel Berg <embe8573@student.uu.se> wrote:
> Shark8 <onewingedshark@gmail.com> writes:
>
>> There's a *huge* problem with this: superficial understanding.
>> This problem can lead to extremely bad code adopted as "best
>> practice"/"standard practice".
>
> There is nothing superficial about code. Code *is* programming!
>

Code explains _what_ is being done but it does not explain _why_ it
is being done in this way.

Would you rather implement, say, a communications protocol by looking
at a existing implementation only, or would you rather work from a
design specification which will include the background and overview
as well as explain the reason for why certain things are done in the
way they are ?

If you look at the code only, you only gain a superficial understanding
of how the protocol is implemented and can end up falling into a
cargo cult mentality. If you work from the design specification, you
gain a far deeper understanding of what is going on.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: 4 beginner's questions on the PL Ada

[Shark8]

On Saturday, August 10, 2013 11:43:11 AM UTC-6, Emanuel Berg wrote:
> Shark8 writes:
> 
> > There's a *huge* problem with this: superficial understanding.
> > This problem can lead to extremely bad code adopted as "best
> > practice"/"standard practice".
> 
> There is nothing superficial about code. Code *is* programming!

The word 'superficial' there modifies the word 'understanding'.
Therefore I'm not talking about "coding", but rather about the "just look at the code" mentality and the practices it encourages.


> But, that being said, books are *great*. If they weren't so
> expensive, I would own a lot more of them. References are great,
> as well. But I like mine offline (i.e., on paper).

Somewhat agreed; I do have several hard-copy Ada books floating around.


> I don't like Googling - it disturbs my workflow, and hearts my
> eyes (I exclusively work in Emacs, in a Linux VT - see the
> screenshots [1] - it is the best configuration - faces, the font,
> etc. - that I spent years configuring, to counteract tired/dry
> eyes).
> 
> Googling also reduces the mental-physical presence: relying on it
> will reduce your attention span - in the room, in time - giving
> you "short thoughts" instead of "long".

Question: who mentioned googling? I did not.
But your "just the code" attitude dose fit well with "just google it."

> This may seem monkish, and it is. I like Lisp, C, LaTeX, that
> stuff. I don't like Python, Java, PHP (or any web programming).

And? I didn't say anything one way or the other -- you're reading a *LOT* into what I wrote, which was ultimately about understanding, not about some block of code.

> I don't like GUIs (except for very specific applications, e.g., GIS
> and the like; and then I accept them for *others* to use). I don't
> like IM but love mails, which I send from rmail. I don't like the
> SX sites, but Usenet, for which I use Gnus. I see a pattern in
> this, and I hope you do, too. (And not be offended if *you* happen
> to like Java.) So you see, you can, as I, prefer code to
> documentation, and there is nothing superficial about it.

...You've said almost nothing about code vs documentation the whole time; you have been talking about text vs GUI though.

I can therefore assume that you only superficially read my reply.


> > An excellent example: PHP's official site.  They go to the code
> > side even in the documentation, to the point where the mb/forum
> > attached to the particular function is oft littered with code
> > examples... and usually bad ones once you gain a deeper
> > understanding of what's going on.
> 
> That's not an excellent example. If the code is *bad*, all bets
> are off...

And how are you ever going to know if the code is bad if all you have to compare it with is itself? See, that's why documentation is important: a thing cannot be calibrated solely internally but needs an external measure/meter to check.

> It's like me picking up the worst documentation ever
> written, saying it exemplifies why documentation shouldn't be
> studied.

...that's exactly what I did: I used PHP's "documentation" as an example.

> > Then you're a step ahead of the cut-n-past script monkeys that
> > the "code snipet" style seems to generate -- not to say that
> > code isn't useful but, again, it seems to encourage a lazy
> > psudeo-understanding.
> 
> This is 100% incorrect. I'm not going to argue with you if this is
> your base, because it is not productive one bit.

You just partially *agreed* with me when you were talking about googling and how it reduces attention-spans!

Re: 4 beginner's questions on the PL Ada

[Georg Bauhaus]

On 11.08.13 00:23, Emanuel Berg wrote:
> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>
>> 	And that description is rather meaningless to me...
>>
>> C-style for loops pretty much mandate breaking apart into parts
>> as they ARE so generic.
>
> Yes, I think it is clear by now that we prefer to describe things
> in different ways.
>
>> Code is IMPLEMENTATION...
>
> OK, then what is not? Modelling? Drawing UML diagrams on
> whiteboards? Or keeping it in your head, but still doing it in
> stages?


Programming, a human activity, produces code manifesting the human
activity. The two words don't denote the same thing, even when quick
use of language unhelpfully dismisses the difference as pedantic.
Expressing ideas is part of writing a program; understanding ideas
is part of reading a program, one hopes. Both human activities do
not depend on that single, exemplary program's code, though:

Since different codes can express the same idea, typically there
isn't just one code for every idea.  Some ideas are so general that
a single example will not capture all of it, whereas words might:

"Better not terminate a master if dependent tasks might still be
doing some work."

Then, a single example will depict one of the many possible
situations in which the above sentence applies, and the reader
may or may not find its code helpful for understanding the idea.

task body Foo
-- ...
begin

    accept Hit;
    ...  -- more work


end Foo;

-- In a master,
-- make sure that a dependent Foo is given a chance to run to
-- completion, i.e. do its work. E.g., call an entry that comes
-- after "more work" above.

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> Would you rather implement, say, a communications protocol by
> looking at a existing implementation only, or would you rather
> work from a design specification which will include the
> background and overview as well as explain the reason for why
> certain things are done in the way they are?

Again, those CS models - if your task is to implement one of those
- of course you need to study the model/specification. Naturally,
in all those cases, it is as you describe.

My layman's attempt to define what constitutes a protocol would
be:

1. The message format, including its OH fields and what they
carry. For example, in a CAN bus message, there are 11 bits of
message ID (which is also used as priority), and after that, ...

2. How the communication should be conducted. For example, the
dance steps of the TCP/IP, with ack's back and forth: how it is
done, and what it means, and when, and in what order, ...

For 1., I'd use a data structure, and for 2., ordinary control flow
logic, perhaps in a PL with IPC support (Ada tasks with entry -
accept, perhaps? but I'm new at Ada).

All this is just examples, but it is clear that: *no*, you can't,
and shouldn't, write a single line of code until you have the
specification, and have studied it in detail.

Still, while interesting, it is not really what I tried to, um,
"communicate".

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Shark8 <onewingedshark@gmail.com> writes:

> The word 'superficial' there modifies the word 'understanding'.
> Therefore I'm not talking about "coding", but rather about the
> "just look at the code" mentality and the practices it
> encourages.

OK, this seems to carry lots of subtleties. I'm not saying "*just*
look at the code". I say *looking* at the code is the first
step. The second step is understanding it, and this can be done,
for example by integrating it into your project(s), and modifying
it to work seamlessly. (Or just the same: deciding no, that code
won't help, for this and that reason. This can still be helpful:
what if you write it the other way around?)

Especially when you are new to a language, you can't "learn by
doing it", because your toolbox is all but empty. You need to
study what other people wrote. Examples are better, much better,
at this stage, than plowing a reference manual. When you have
achieved some level of fluency, the reference is great to have on
you desk, though.

> Somewhat agreed; I do have several hard-copy Ada books floating
> around.

I found out, there is a book in Swedish (!) on Ada, written for
the general public (or the programming public, perhaps - it is not
an exclusively university publication, at least), written by some
Ph.D. guy. This surprised me a bit, as we seldom have such books
(most Swedish programmers read English very well - too well,
perhaps). The same guy also had some books on more famous PLs
(like C and C++), and even a book on X.

> But your "just the code" attitude dose fit well with "just
> google it."

Again, I've never said *just* the code. I'm saying code is the
bloodstream of any programmer, just as wood to a carpenter, fish
to a fisherman, and the parachute to the sky diver.

To just Google things is the worse thing you can do. You get
inconsistent, fragmented knowledge, and you often get caught up in
discussions of people who don't know what they talk about, so you
litter your brain with it.

Example: I wrote an article on the difference between .Xresources
and .Xdefaults the other day, and did some research. And, the
first Google hit on the issue was a joke, with incorrect
information in all but every paragraph. (But, interestingly, the
second hit was correct.)

> ... what I wrote, which was ultimately about understanding, not
> about some block of code.

I don't see the conflict. On the contrary, I *know* understanding
can come from code.

> ...You've said almost nothing about code vs documentation the
> whole time; you have been talking about text vs GUI though.

Yes, and did you ever meet a guy who exclusively used the CLI,
because this made for precision and flexibility, while at the same
time having a lazy attitude to computers, dealing with superficial
knowledge? No - it doesn't make any sense.

> And how are you ever going to know if the code is bad if all you
> have to compare it with is itself?

After years of programming every day and every night, I don't
*compare*. I am able to assess the material *as it is*.

> ... when you were talking about googling and how it reduces
> attention-spans!

Yes, for the record: to be code-oriented does not imply Googling!

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> task body Foo
> -- ...
> begin
>
>    accept Hit;
>    ...  -- more work
>
>
> end Foo;
>
> -- In a master,
> -- make sure that a dependent Foo is given a chance to run to
> -- completion, i.e. do its work. E.g., call an entry that comes
> -- after "more work" above.

Good example! Mixing code with comments, when trying to explain
something, is *optimal*.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Peter C. Chapin]

On Sun, 11 Aug 2013, Emanuel Berg wrote:

> Especially when you are new to a language, you can't "learn by doing 
> it", because your toolbox is all but empty. You need to study what other 
> people wrote. Examples are better, much better, at this stage, than 
> plowing a reference manual. When you have achieved some level of 
> fluency, the reference is great to have on you desk, though.

I admit that I haven't been following this thread closely so I may be out 
of touch with the points being discussed. However, as an educator I wanted 
to point out that it isn't really about code examples vs written 
explanations. Both tools are useful when it comes to deepening one's 
understanding. Written explanations tend to be more general but a good, 
concrete code example can help the mind form a useful model for a concept 
and lead a person to a more abstract level of understanding.

Also when it comes to written explanations there are certainly more 
resources than the reference manual for a language. In fact, books about 
software design and engineering without regard to any particular 
programming language can often make one a better programmer in any 
language. Isn't that the point of such books?

Finally the way a person learns a new language depends greatly on that 
person's background. It's a very different process for a person who 
already programs extensively and knows several languages than it is for a 
person who has never programmed before.

Peter

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

"Peter C. Chapin" <PChapin@vtc.vsc.edu> writes:

> ...

Well, well! Now the power play formation is one the ice :)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Mike H]

Once again a thread in this news group shows a polarisation of mind sets 
concerning right and wrong approaches to writing a program. I am 
reminded of my teaching days when, even before writing a single piece of 
Ada code on the white board, I would initiate some class discussion on 
the question of whether time and duration are same and, if they are not 
the same, does it matter. I knew I could expect general agreement that 
the result of adding a pair of time variables was meaningless whereas 
subtracting such pair of times could be valid, but only if one was aware 
that the result was not a time. The fun would start when the discussion 
moved on to questions of how one might detect or, better still prevent, 
a time/duration program error. If I was lucky, opinions would become 
quite heated concerning personal responsibility and managerial 
responsibility should such an error reach a production version of a 
product.

When the dust began to settle I would ask whether it might no be useful 
if such an error could be detected at compilation time. Sometimes there 
would be a small minority who would greet that question with 
incredulity. More interesting to me was identifying those who showed an 
interest in how this might be achieved in well written Ada and, in 
comparison, those who were sufficiently sure of their own capabilities 
that they could regard any additional lines of defensive coding in any 
language as an unnecessary irrelevance. Worse still were those who would 
be deaf to the idea that although additional lines of declaration source 
code can be expected to change the resulting executable code that does 
not necessarily mean a change of the amount of generated execution code 
nor necessarily a change of execution times.

-- 
Knowledge is knowing a tomato is a fruit
Wisdom in knowing not to put it in the fruit salad.
Mike

Re: 4 beginner's questions on the PL Ada

[Bill Findlay]

Emanuel Berg <embe8573@student.uu.se> wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
> 
>> task body Foo
>> -- ...
>> begin
>> 
>>    accept Hit;
>>    ...  -- more work
>> 
>> 
>> end Foo;
>> 
>> -- In a master,
>> -- make sure that a dependent Foo is given a chance to run to
>> -- completion, i.e. do its work. E.g., call an entry that comes
>> -- after "more work" above.
> 
> Good example! Mixing code with comments, when trying to explain
> something, is *optimal*.

For you. Do not presume to speak for us all.

-- 
Bill Findlay

Re: 4 beginner's questions on the PL Ada

[Emanuel Berg]

Bill Findlay <yaldnif.w@blueyonder.co.uk> writes:

> For you. Do not presume to speak for us all.

Okaay.

(Of course I'm never speaking for anyone else but me.)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: 4 beginner's questions on the PL Ada

[Eryndlia Mavourneen]

On Saturday, August 10, 2013 1:03:20 AM UTC-5, Jeffrey Carter wrote:
> On 08/09/2013 07:45 PM, Dennis Lee Bieber wrote:
> 
> . . . 
> With the exception of Annex A (which describes the Ada.* hierarchy), the ARM is 
> not very good for learning the language. For that I'd recommend some of the 
> . . .

I really have to disagree.  I learned Ada from the LRM and, in fact, was able to use tasking with task types, U_D, record bit fields, operating system (kernel) modification, etc.  With a few exceptions, I have found the LRM to be clear, concise, and deliberative. After all, it *is* the international standard for the Ada language and at least used to be the USA's military programming language standard.

I have little patience for questions that are trivially answered in the LRM.  I also, however, don't believe in beating my head against a wall for many hours trying to understand something that someone else can easily answer.  There is a balance here, and individuals fall on one side or the other.  I do believe, though, that too many people are either lazy or possibly discouraged by the really badly laid-out and written reference manuals for other languages.  I'm guilty, too.  :-)

-- Eryndlia (KK1T)

Re: 4 beginner's questions on the PL Ada

[Jeffrey Carter]

On 08/12/2013 10:17 AM, Eryndlia Mavourneen wrote:
>
> I really have to disagree.  I learned Ada from the LRM and, in fact, was able
> to use tasking with task types, U_D, record bit fields, operating system
> (kernel) modification, etc.  With a few exceptions, I have found the LRM to
> be clear, concise, and deliberative. After all, it *is* the international
> standard for the Ada language and at least used to be the USA's military
> programming language standard.

It was possible to learn Ada 83 from ARM-83, but I think most people will agree 
that, beginning with ARM-95, that is no longer the case (for most people). If 
you learned Ada 95 or later from the ARM, you must have a much higher tolerance 
for having your brain hurt than most people. Even the people who wrote it say 
that parts of it are effectively impossible to understand.

-- 
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail
13

Re: 4 beginner's questions on the PL Ada

[Anh Vo]

On Friday, August 9, 2013 6:24:13 PM UTC-7, Emanuel Berg wrote:
> Anh Vo <anhvofrcaus@gmail.com> writes:
>  
> You guys should do a field trip to gnu.emacs.help - there, we just 
> post code all days! It is much better. Code speaks louder than 
> words. It is very difficult to follow all this discussion on 
> memory allocation etc., but the few times you posted code there 
> wasn't a letter I didn't understand immediately.
>  
> And isn't that the same way with you? If you were to explain the C 
> for loop to another programmer, would you not just write
>  
> for (i = 0; i < STOP; i++) { printf("Pretty clear, huh?\n"); }
>  
> But I don't doubt your Ada knowledge, or you helpful attitude.

Hmmmm... These have nothing to do with how a task name implemented with respect to portability.
 
>> You can give/assign a name to a task the way you like by using
>> predefined package Ada.Task_Attributes. In this case you most
>> likely instantiate it with String subtype. Therefore, it is will
>> be completely portable.
>  
> And (drumroll...) how would that look?
 
Here is how a task name is consistently implemented across different compilers. By the way, this is a complete running program.

with Ada.Exceptions;
with Ada.Text_Io; 
with Ada.Task_Attributes;
with Ada.Task_Identification;
with GNAT.Traceback.Symbolic;
use Ada;

procedure Task_Name_Test is
   use Text_Io;
   
   type Name is access String;
   Default_Name : constant Name := new String'("Generic task name");
   
   Package Task_Manager is new Task_Attributes (Name, Default_Name);
   
   task Gentleman is
      entry Hello;
      entry Goodbye;
   end Gentleman;
   
   task body Gentleman is
   begin
      accept Hello;
      Put_Line ("My name is " & 
                   Task_Manager.Value (Task_Identification.Current_Task).all &
                  ". It's my pleasure to meeting you");
      accept Goodbye;
      Put_Line ("Hopefully, we will meet again in the future.");
   end Gentleman;

   Gentleman_Name : Name := new String'("Gentleman");
      
begin
   Put_Line ("Task_Name_Test starts");

   Task_Manager.Set_Value (Val => Gentleman_Name, T => Gentleman'Identity);
   
   Gentleman.Hello;
   Gentleman.Goodbye;

   Put_Line ("Task_Name_Test starts");
   
exception
   when Err : others =>
      Put_Line (Exceptions.Exception_Name(Err) & " was raised");
      Put_Line (GNAT.Traceback.Symbolic.Symbolic_Traceback(Err));
end Task_Name_Test;


Once again, it is about task name. If it is not, it should not belong here.

Anh Vo.

Re: 4 beginner's questions on the PL Ada

[Adam Beneschan]

On Saturday, August 10, 2013 7:57:19 AM UTC-7, Shark8 wrote:

> An excellent example: PHP's official site.
> 
> They go to the code side even in the documentation, to the point where the mb/forum attached to the particular function is oft littered with code examples... and usually bad ones once you gain a deeper understanding of what's going on.

There's no need to go into a deeper understanding, for PHP.  If you want an in-depth understanding, you can get it from the official Perl language site.  And the official C++ language site.  And the official JavaScript language site.  And the official Java language site.  You just have to guess which language PHP stole any one particular feature from.

:) :) :) :) :) :) :) :) :)

                               -- Adam

Re: 4 beginner's questions on the PL Ada

[Adam Beneschan]

On Saturday, August 10, 2013 4:15:05 PM UTC-7, Simon Clubley wrote:
> On 2013-08-10, Emanuel Berg wrote:
> 
> > Shark8 writes:
> 
> >
> 
> >> There's a *huge* problem with this: superficial understanding.
> >> This problem can lead to extremely bad code adopted as "best
> >> practice"/"standard practice".
> 
> > There is nothing superficial about code. Code *is* programming.
>
> Code explains _what_ is being done but it does not explain _why_ it
> is being done in this way.
> 
> Would you rather implement, say, a communications protocol by looking
> at a existing implementation only, or would you rather work from a
> design specification which will include the background and overview
> as well as explain the reason for why certain things are done in the
> way they are ?
> 
> If you look at the code only, you only gain a superficial understanding
> of how the protocol is implemented and can end up falling into a
> cargo cult mentality. If you work from the design specification, you
> gain a far deeper understanding of what is going on.

Before we keep this argument up too long, I think we need to step back and acknowledge that people's brains are wired differently, and that different people learn things in different ways.  I definitely need to know the exact rules for things early on; and I usually understand things well enough just by reading the rules without needing too many examples.  But I don't really think of myself as "normal" in this regard.  Others do better by starting with examples and filling in details later.  Please, let's respect our differences here.  

                                 -- Adam

Re: 4 beginner's questions on the PL Ada

[Anh Vo]

On Monday, August 12, 2013 10:39:31 AM UTC-7, Anh Vo wrote:
> On Friday, August 9, 2013 6:24:13 PM UTC-7, Emanuel Berg wrote:
> [...]
> 
>    Gentleman.Hello;
>    Gentleman.Goodbye;
>  
>    Put_Line ("Task_Name_Test starts");

It is supposed to be

    Put_Line ("Task_Name_Test ends");

It is a cut & paste error.

A. Vo
 

Re: 4 beginner's questions on the PL Ada

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:ku3opa$svn$3@dont-email.me...
> On 08/09/2013 02:38 PM, Emanuel Berg wrote:
>>
>> Yes! This works great:
>>
>> with Ada.Task_Identification;
>> use  Ada.Task_Identification;
>>
>> Task_Name : constant String := Image(Current_Task);
>>
>> It produces output like
>>
>> add_one_081838Dt
>>
>> if the task is referred to as Add_One in the code.
>
> Not necessarily. First, this is only available in compilers that choose to 
> implement the optional Annex C, Systems Programming, so this is 
> non-portable.

That's formally true, but practically, I don't know of any Ada compilers 
that don't implement Ada.Task_Identification. An Ada compiler vendor needs 
something like it for debugging tasking programs, and it would be silly to 
create something different for that job.

> Second, the contents of the string returned by Image are implementation 
> defined. One particular compiler uses the task name as part of the 
> returned value, but others might not, so adding another layer of 
> non-portability.

Right. Janus/Ada uses "@nnnn", where "nnnn" is a task number (they're all 
assigned integers by our task supervisor). The task supervisor doesn't know 
anything about the names used in the program (its much lower level than 
that).

But the *real* problem is having a unique identification for each task 
without having to worry about the task type. There might an additional level 
of work to figure out which task object is associated with which identifier 
string, but that's easily handled by printing out the id for each task when 
it starts.

                                Randy.

Re: 4 beginner's questions on the PL Ada

[Simon Wright]

Anh Vo <anhvofrcaus@gmail.com> writes:

> Here is how a task name is consistently implemented across different
> compilers.

? I think not, because ...

> with Ada.Exceptions;
> with Ada.Text_Io; 
> with Ada.Task_Attributes;
> with Ada.Task_Identification;
> with GNAT.Traceback.Symbolic;
       ^^^^                       <<<<< this!
> use Ada;
>
> procedure Task_Name_Test is

Re: 4 beginner's questions on the PL Ada

[Anh Vo]

On Monday, August 12, 2013 12:57:49 PM UTC-7, Simon Wright wrote:
> Anh Vo <anhvofrcaus@gmail.com> writes:
>  
> > Here is how a task name is consistently implemented across different 
> > compilers.
>  
> ? I think not, because ...
>  
> > with Ada.Exceptions; 
> > with Ada.Text_Io;  
> > with Ada.Task_Attributes; 
> > with Ada.Task_Identification; 
> > with GNAT.Traceback.Symbolic;
> 
>        ^^^^                       <<<<< this! 

It is true that GNAT and its children packages are not portable. GNAT.Traceback.Symbolic package is actually not needed for task name testing purposes.