Need advice on Reminder program

Need advice on Reminder program

[Preben Randhol]

Hi

I have started making a small reminder program called avtale (Norwegian
for appointment) because I am tired of all the programs for Linux that
suddenly stop reminding me about appointments I have. I want to make a
small daemon that reads in a text file with appointments and warn me by
popping up a dialog on the screen (possibly sound effect and more later,
but not now I want to keep it simple and reliable).

My thought is to use tasks for this. One task that pop up the dialogs,
one that read the text file and one that keeps track of the time. I do
not have experience with tasks so I am wondering if this is a stupid
approach :-) ? Is there something I should look out for so that the
daemon won't suddenly stop working. I want a really reliable program
:-).

Thanks in advance.

PS: No, this is not homework, well I make the program at home but for my
own leisure and not for any course :-)

-- 
Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: Need advice on Reminder program

[Ted Dennison]

In article <slrn97g027.td.randhol+abuse@kiuk0156.chembio.ntnu.no>,
  randhol+abuse@pvv.org (Preben Randhol) wrote:

> suddenly stop reminding me about appointments I have. I want to make a
> small daemon that reads in a text file with appointments and warn me
> by popping up a dialog on the screen (possibly sound effect and more
> later, but not now I want to keep it simple and reliable).
>
> My thought is to use tasks for this. One task that pop up the dialogs,
> one that read the text file and one that keeps track of the time. I do
> not have experience with tasks so I am wondering if this is a stupid
> approach :-) ? Is there something I should look out for so that the
> daemon won't suddenly stop working. I want a really reliable program
> :-).

Seems sensible to me. The issues I can see off the top of my head that a
tasking newbie needs to be aware of are:

  o  By default, Ada tasks die silently when an unhandled exception is
raised. That can be really rough for debugging. You should probably put
some kind of last-ditch exception handler at the outermost scope of
every task to somehow let you know that the task is dying.

  o  Most I/O calls and GUI operations assume that only one task will
ever make a call on the same object. You should organize things to make
this so.

  o  If you are running on Linux using FSU threads, then I believe any
non-Ada operation (eg: OS I/O calls, some GUI ops) that blocks the task
will block the *entire* program. I'd solve this problem by using the
native threads instead of FSU (unless you need a validated system for
some reason).

  o  A task should generally be designated as either a client (initiates
rendezvous) or a server (accepts rendezvous). The situations where you
can get away with doing both in the same task without danger of deadlock
or undesired extended blocking are rare.

Note that points 1 and 2 together imply that just about any tasking
program needs some kind of message logging task to handle the sending of
error messages to the user.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Need advice on Reminder program

[Preben Randhol]

On Wed, 31 Jan 2001 14:44:11 GMT, Ted Dennison wrote:
>In article <slrn97g027.td.randhol+abuse@kiuk0156.chembio.ntnu.no>,
>
>
>  o  By default, Ada tasks die silently when an unhandled exception is
>raised. That can be really rough for debugging. You should probably put
>some kind of last-ditch exception handler at the outermost scope of
>every task to somehow let you know that the task is dying.

Yes I'll do that :-) 

Does this mean that all the tasks will die or does it mean that only the
one task where the exception occurs dies? If the latter is it possible
to have a task that is "overlooking" the others and restart one that has
died?

>  o  Most I/O calls and GUI operations assume that only one task will
>ever make a call on the same object. You should organize things to make
>this so.

Yes I thought I'd use three different tasks. The task doing I/O puts the
appointments in a list and gives this to the task that keeps track of
the time. This task will then pass a text string to the GUI task with
the info to be displayed.

>  o  If you are running on Linux using FSU threads, then I believe any
>non-Ada operation (eg: OS I/O calls, some GUI ops) that blocks the task
>will block the *entire* program. I'd solve this problem by using the
>native threads instead of FSU (unless you need a validated system for
>some reason).

Hmm OK. I don't know what I have, I'll check that.

>  o  A task should generally be designated as either a client (initiates
>rendezvous) or a server (accepts rendezvous). The situations where you
>can get away with doing both in the same task without danger of deadlock
>or undesired extended blocking are rare.

I see. Perhaps I should use a protected object.

>Note that points 1 and 2 together imply that just about any tasking
>program needs some kind of message logging task to handle the sending of
>error messages to the user.

Noted.

Thanks for the help.

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
iMy favorite editor is Emacs!<ESC>bcwVim<ESC>
                                         -- vim best-editor.txt

Re: Need advice on Reminder program

[Ted Dennison]

In article <slrn97gg4p.113.randhol+abuse@kiuk0156.chembio.ntnu.no>,
  randhol+abuse@pvv.org (Preben Randhol) wrote:
> On Wed, 31 Jan 2001 14:44:11 GMT, Ted Dennison wrote:
> >  o  By default, Ada tasks die silently when an unhandled exception
> >is raised. That can be really rough for debugging. You should
> Does this mean that all the tasks will die or does it mean that only
> the one task where the exception occurs dies? If the latter is it

Only the one task where the exception occurs. However, if an exception
occurs within the "do ... end" part of a rendezvous accect, then it gets
propagated out to *both* taks.

> possible to have a task that is "overlooking" the others and restart
> one that has died?

I have taken that approach in the past with mission-critical software.
You'd have to make the task a task *type*, so that a new task object can
be created. The only problem is that it is also concievable for the
"manager" task itself to die. To prevent that, I added another managed
task called the "ombudsman" to watch and restart the "manager". They
could still *both* die at the same time, but we weren't required to
handle multiple failures. :-)

Another possibliity would be to put the entire task's functionality in a
(infinite) loop, and put the exception-handling block immediately inside
the loop. As long as you can trust the loop not to raise an exception,
that'll keep the task running. But you have to have some usable recovery
mechanism.

In most cases I'd say the best approach is to have it just spit out an
error to a log, then let it die. Then you can just fix the bug so it
doesn't happen again.


> >  o  A task should generally be designated as either a client
> >(initiates rendezvous) or a server (accepts rendezvous). The
> >situations where you can get away with doing both in the same task
> >without danger of deadlock or undesired extended blocking are rare.
>
> I see. Perhaps I should use a protected object.

Protected objects are damn useful for reducing the number of tasks in a
system. Unfortunately, can only be treated as servers (under the scheme
I outlined above), so they are only useful for interfacing clients to
clients. Think of them as sort of a software gender-bender. :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Client-Server 'Gender' [was Need advice on ...]

[Nick Roberts]

So which, of client and server, is the male (sex really, not gender), and
which the female?

;-)

--
Nick Roberts
http://www.AdaOS.org


"Ted Dennison" <dennison@telepath.com> wrote in message
news:959nrl$rk5$1@nnrp1.deja.com...
> ...
> Protected objects are damn useful for reducing the number of tasks in a
> system. Unfortunately, can only be treated as servers (under the scheme
> I outlined above), so they are only useful for interfacing clients to
> clients. Think of them as sort of a software gender-bender. :-)

Re: Client-Server 'Gender' [was Need advice on ...]

[Ted Dennison]

In article <95ctlo$ff437$4@ID-25716.news.dfncis.de>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> So which, of client and server, is the male (sex really, not gender),
> and which the female?

I tend to think of severs as "female" connectors. But if you want to
look at it the other way around, you a free to do so. I don't think it
makes any difference, as long as you are consistent about it. It can
occasionaly be useful to make this decision, so you can properly diagram
things.

I don't know why I look at it the way I do; that's a rock in my mind
that I'd really rather not look underneath. :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Need advice on Reminder program

[sk]

Preben Randhol wrote:
> 
<snip>
> I have started making a small reminder program called avtale (Norwegian
> for appointment) because I am tired of all the programs for Linux that
<snip>

Funnily enough I was looking at Cohen[1] yesterday, chapter 20.2.1 
concerning "Passive Partitions" and his example is an appointment 
calendar. 

Probably of no use to you, but it could be interesting to look at.

sknipe@ktc.com

---------------
[1] "Ada as a Second Language", 2nd Edition 1996, Norman H. Cohen.

Re: Need advice on Reminder program

[Preben Randhol]

On Wed, 31 Jan 2001 08:47:36 -0600, sk wrote:
>Funnily enough I was looking at Cohen[1] yesterday, chapter 20.2.1 
>concerning "Passive Partitions" and his example is an appointment 
>calendar. 
>
>Probably of no use to you, but it could be interesting to look at.

Yes, but unfortunately I don't have that book and neither has the
library :-(

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
iMy favorite editor is Emacs!<ESC>bcwVim<ESC>
                                         -- vim best-editor.txt

Re: Need advice on Reminder program

[Tarjei T. Jensen]

Preben Randhol wrote in message ...
>On Wed, 31 Jan 2001 08:47:36 -0600, sk wrote:
>>Funnily enough I was looking at Cohen[1] yesterday, chapter 20.2.1
>>concerning "Passive Partitions" and his example is an appointment
>>calendar.
>>
>>Probably of no use to you, but it could be interesting to look at.
>
>Yes, but unfortunately I don't have that book and neither has the
>library :-(


Buy it! It is a worthwhile investment. A treasure! It explains a lot of Ada and
the library in detail.


Greetings,

Re: Need advice on Reminder program

[Preben Randhol]

On Thu, 1 Feb 2001 12:47:08 +0100, Tarjei T. Jensen wrote:
>
>Buy it! It is a worthwhile investment. A treasure! It explains a lot of Ada and
>the library in detail.

Yes, but I have J. Barnes book and Cohens book cost about $80.

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
iMy favorite editor is Emacs!<ESC>bcwVim<ESC>
                                         -- vim best-editor.txt

Re: Need advice on Reminder program

[Tarjei T. Jensen]

Preben Randhol wrote in message ...
>On Thu, 1 Feb 2001 12:47:08 +0100, Tarjei T. Jensen wrote:
>>
>>Buy it! It is a worthwhile investment. A treasure! It explains a lot of Ada
and
>>the library in detail.
>
>Yes, but I have J. Barnes book and Cohens book cost about $80.
>

Amazon.co.uk says it costs GBP 52.99 for the paperback. You can do without beer
this weekend. Buy the book instead or get in on loan from another library
through bibsys (it might be that they do not have the second edititon).


Greetings,

Re: Need advice on Reminder program

[Preben Randhol]

On Thu, 1 Feb 2001 16:18:38 +0100, Tarjei T. Jensen wrote:
>Amazon.co.uk says it costs GBP 52.99 for the paperback. You can do without beer

Hmm, yes I need to get a VISA card soon I guess ;-)

>this weekend. Buy the book instead or get in on loan from another library

he he he sure, but is it so much better than �Programming in Ada 95� (2nd
Ed)?

>through bibsys (it might be that they do not have the second edititon).

I'll check that.

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
iMy favorite editor is Emacs!<ESC>bcwVim<ESC>
                                         -- vim best-editor.txt

Re: Need advice on Reminder program

[sknipe]

Hi, 

>he he he sure, but is it so much better than �Programming in
>Ada 95� (2nd Ed)?

Not a situation of "better", a situation of different styles.

For me, it breaks down to the following:

LRM => for absolutly rigorous language definition

Barnes => for sometimes humourous exploration of language. 
Useful as an introduction to key concepts and as a quick 
reminder to half-forgotten concepts and techniques.

Cohen => for in-depth coverage of new topics and concepts, 
and how these concepts can be applied, and relate, to 
possible "real-world" situations.


sknipe@ktc.com

Re: Need advice on Reminder program

[Matthew Woodcraft]

"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:

[Norman Cohen's _Ada as a second language_]
> Buy it! It is a worthwhile investment. A treasure! It explains a lot of Ada
> and the library in detail.

I think it's a very good book. Anyone buying a copy would do well to
look at the errata list, though:

http://www.research.ibm.com/people/n/ncohen/a3sl_errata.html

-M-

Re: Need advice on Reminder program

[Preben Randhol]

On 01 Feb 2001 21:10:15 +0000, Matthew Woodcraft wrote:
>http://www.research.ibm.com/people/n/ncohen/a3sl_errata.html

Ah thanks. I just put in an order for the book so I'll print out the
errata now :-)

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
iMy favorite editor is Emacs!<ESC>bcwVim<ESC>
                                         -- vim best-editor.txt

Re: Need advice on Reminder program

[(null)]

In article <95bibs$7n3@news.kvaerner.com>,
Tarjei T. Jensen <tarjei.jensen@kvaerner.com> wrote:
>
>Preben Randhol wrote in message ...
>>On Wed, 31 Jan 2001 08:47:36 -0600, sk wrote:
>>>Funnily enough I was looking at Cohen[1] yesterday, 
[...]
>
>
>Buy it! It is a worthwhile investment. A treasure! It explains a lot of Ada and
>the library in detail.


A lot of people on the list really like "Ada as a Second Language",
but I'm not all that fond of it.  It's overly wordy and repetitious
in some spots.  The book is ~1100 pages, probably 500 pages longer
than it needs to be.

On the other hand, It certainly is higher quality than a lot of books
out there and it is the only Ada book I own.  It is complete and
doesn't really have that many mistakes for a book it's size.  It just
really need a good hack and slash editor to cut it down to size.

Just my 2 cents worth.


-- 
=======================================================================
 Life is short.                  | Craig Spannring 
      Bike hard, ski fast.       | cts@internetcds.com
 --------------------------------+------------------------------------

Re: Need advice on Reminder program

[Stephen Leake]

randhol+abuse@pvv.org (Preben Randhol) writes:

> Hi
> 
> I have started making a small reminder program called avtale (Norwegian
> for appointment) because I am tired of all the programs for Linux that
> suddenly stop reminding me about appointments I have. I want to make a
> small daemon that reads in a text file with appointments and warn me by
> popping up a dialog on the screen (possibly sound effect and more later,
> but not now I want to keep it simple and reliable).
> 
> My thought is to use tasks for this. One task that pop up the dialogs,
> one that read the text file and one that keeps track of the time. I do
> not have experience with tasks so I am wondering if this is a stupid
> approach :-) ? Is there something I should look out for so that the
> daemon won't suddenly stop working. I want a really reliable program
> :-).

You only need to read the text file once, at startup, so you don't
need a separate task for that. Hmm, you do need some way to add
appointments; leave that for later?

When a dialog box is popped up, do you want the "timer" function to keep
operating, to allow another dialog box to pop up before the first is
closed? or just pop later ones up after the first is closed?

If you don't want multiple dialog boxes, one task is all you need.
Depending on the details of the windowing toolkit (Gtk? Motif?), you
may be able to popup multiple dialog boxes from one task.

Keeping things simple is the key to keeping them reliable. Using more
tasks than you really need is _not_ keeping it simple.

One confusion I often see is between "task" and "module". You
definitely should have one _package_ for reading the text file, one
package for poping up dialogs, and one package for managing the timer.
That is _not_ the same as needing three _tasks_.

> Thanks in advance.

You're welcome.

-- 
-- Stephe

Re: Need advice on Reminder program

[Preben Randhol]

On 31 Jan 2001 13:08:55 -0500, Stephen Leake wrote:
>You only need to read the text file once, at startup, so you don't
>need a separate task for that. Hmm, you do need some way to add
>appointments; leave that for later?

I want the daemon to reread the file when it changes. I want the daemon
to run "forever" :-). To add apointments I want to use a different
program.

>When a dialog box is popped up, do you want the "timer" function to keep
>operating, to allow another dialog box to pop up before the first is
>closed? or just pop later ones up after the first is closed?

I want it to pop up and the daemon to continue to the next appointment.
I don't want to wait for user input.

>If you don't want multiple dialog boxes, one task is all you need.
>Depending on the details of the windowing toolkit (Gtk? Motif?), you
>may be able to popup multiple dialog boxes from one task.

GtkAda

>Keeping things simple is the key to keeping them reliable. Using more
>tasks than you really need is _not_ keeping it simple.

Yes :-)

>One confusion I often see is between "task" and "module". You
>definitely should have one _package_ for reading the text file, one
>package for poping up dialogs, and one package for managing the timer.
>That is _not_ the same as needing three _tasks_.

Yes, but I need the tasks so that if the user alters the appointments
the daemon will update itself to the new info. And to do that I think I
will need more than one task. :-)

But you are right that the less tasks the better so I'll think about
that and see if I can manage with one, I'll check what GtkAda can do in
this respect.

Thanks
-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
iMy favorite editor is Emacs!<ESC>bcwVim<ESC>
                                         -- vim best-editor.txt