From: glade@cs.cornell.edu (Bradford Glade)
Subject: About floats and being killed because not answering to requests
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Fri, 9 Oct 1992 13:09:58 GMT

(The email that follows and my reply to it seem to be of the flavor
that people would find generally interesting)

Date: Fri, 9 Oct 92 11:46:12 +0100
From: simatic@aar.alcatel-alsthom.fr ( Michel Simatic )
To: ken@cs.cornell.edu, simatic@pyrite.alcatel-alsthom.fr
Subject: About floats and being killed because not answering to requests

Hi Ken,

Recently, I found two problems using Isis (Relax ! I did not
write bugs :-)) and I'd like your opinion about them

Problem 1 : Let's talk about floats !
-------------------------------------

A while ago, you spoke about floats in comp.sys.isis newsgroup :

>Article: 268 of comp.sys.isis
>From: ken@cs.cornell.edu (Ken Birman)
>Newsgroups: comp.sys.isis
>Subject: Question about %f
>Message-ID: <1992Apr15.122348.10941@cs.cornell.edu>
>Date: Wed, 15 Apr 92 14:23:48 MET DST
>Organization: Cornell Univ. CS Dept, Ithaca NY 14853
>
>> Date:     Sat, 11 Apr 92 12:47 CDT
>> From: <HH00819%SWTEXAS.BITNET@CORNELLC.cit.cornell.edu>
>> Subject:  ISIS
>
>>         This is Henry Hsu from Southwest Texas State University.
>> .
>> .
>> .
>>         I also have question about Isis. I tried to use reply() to give the
>> broadcast caller two floating point numbers. I used
>>         reply("%f%f",float1,float2);
>> in my code. I can compile this program, but I have problem when I run it,
>> Does the ISIS v2.1 support the using of %f format in msg_put()?
>>                 Thank you very much.
>>                                                 Henry Hsu 04/10/92
>
>Because different compilers use different conventions to send
>floating point arguments to procedures, Isis can't support a %f
>format in a way that would work for both CC and GCC and C++.
>So, we instead require that you use
>        reply("%F[1]%F[1]", &float1, &float2);
>This works and is compiled the same way for all compilers.
>
>The same restriction applies in V2.2 and V3.0

   Actually, this is a bit annoying for my project ==> It would help me
a lot if Isis could have a "%f1" format for CC and GCC and a "%f2" for
C++ compiler.
As my dream has not come true (yet ?!?), what I do for the moment
is the following :
                  reply("%d%d",float1,float2)
and get the message with /...."%d%d", &float1, &float2......./
I know this is just disgusting and really bad programming, but
it works perfectly well (at least on Sun SPARC 1 running Sun-OS 4.1.1).
The only problem is that I can take bets that if the sender is of a
certain architecture and the receiver of another one, I can
immediately move my "solution" to /dev/garbage.

Could you tell a bit more about floats ?
Do you intend to change anything in the way Isis handles them ?
Could you give more details on parameter marshalling in Isis ?


Problem 2 : Isis makes debugging more spicy
-------------------------------------------

I have an application made out of prog1 and prog2 using Isis. Our
debugging is done in the following way :

     station1                           station2
     --------                           --------
   dbx prog1                           dbx prog2
   run                                 stop at %^$&@^&@^*&^%^$#_file:line ???
    .                                  run

Actually, Isis makes debugging more spicy : when prog2 stops at its
breakpoint, I've got to be really fast in order to avoid the following message
on station 1 :

WARNING: many retransmissions to (21/0:3637.0)... continuing to retry
WARNING: unable to communicate with (21/0:3637.0)... asking <isis/protos> to bre
ak connection

Of course, when I enter "cont" on station 2, prog2 dies and I swear because
it takes 5 (very) long minutes to bring it back to life (my nickname is
"Jesus" :-))
I guess prog1 wants to send messages to prog2 and that, as prog2 does
not answer, prog1 believes it is impolite (or worse dead) so that it does
not want to talk to prog2 anymore.

One solution, I found is to stop prog1 whenever prog2 stops. But, this is
not very convenient.
Is there any other way to avoid this problem during debugging (and do not
answer "don't have bugs in prog2 !":-)) ?



Thanks in advance


P.S. : if you find those bugs of general interest, I can post on this
       mail on Comp.sys.isis

======================================================              __
| Michel SIMATIC                                     |              \/
| Alcatel Alsthom Recherche                          |       +--------------+
| Route de Nozay, 91460 MARCOUSSIS, FRANCE           |       |A L C /\ T E L|
| Voice : +33 1 64 49 13 73   Fax: +33 1 64 49 17 89 |       +--------------+
| E-mail: simatic@aar.alcatel-alsthom.fr             |        A L S T  H O M
|                                                    |       ================
| Always look at the bright side of life !           |           RECHERCHE
|                             Monty Python           |
======================================================
-- 
Bradford B. Glade             |  glade@cs.cornell.edu    
Dept. of Computer Science     |  Tel. (607) 255-9124 (Office)
314 Upson Hall Cornell Univ.  |  FAX  (607) 255-4428 (CS Dept.)
Ithaca, NY 14853              |  
Newsgroups: comp.sys.isis